Problemi noti e risoluzione dei problemi di Azure Kinect
Questa pagina contiene problemi noti e suggerimenti sulla loro risoluzione quando si usa Sensor SDK con Azure Kinect DK. Vedere anche pagine di supporto del prodotto per problemi specifici dell'hardware del prodotto.
Problemi noti
- Problemi di compatibilità con i controller host ASMedia USB (ad esempio, ASM1142 chipset)
- In alcuni casi l’uso dei driver USB di Microsoft può aiutare a sbloccare
- Molti PC hanno anche controller host alternativi e modificare la porta USB3 può essere d’aiuto
Per altri problemi relativi a Sensor SDK, consultare Problemi relativi a GitHub
Raccolta di log
La registrazione di K4A.dll si abilita attraverso le variabili di ambiente. Per impostazione predefinita, la registrazione viene inviata a stdout e vengono generati solo errori e messaggi critici. Queste impostazioni possono essere modificate in modo che la registrazione finisca in un file. Anche il livello di dettaglio può essere modificato in base alle esigenze. Di seguito è riportato un esempio per Windows di come abilitare la registrazione in un file denominato k4a.log e come acquisire messaggi di avviso e di livello superiore.
set K4A_ENABLE_LOG_TO_A_FILE=k4a.logset K4A_LOG_LEVEL=w- Eseguire lo scenario dal prompt dei comandi (ad esempio, avviando il visualizzatore)
- Passare a k4a.log e condividere il file.
Per altre informazioni, vedere la sequenza seguente dal file di intestazione:
/**
* environment variables
* K4A_ENABLE_LOG_TO_A_FILE =
* 0 - completely disable logging to a file
* log\custom.log - log all messages to the path and file specified - must end in '.log' to
* be considered a valid entry
* ** When enabled this takes precedence over the value of K4A_ENABLE_LOG_TO_STDOUT
*
* K4A_ENABLE_LOG_TO_STDOUT =
* 0 - disable logging to stdout
* all else - log all messages to stdout
*
* K4A_LOG_LEVEL =
* 'c' - log all messages of level 'critical' criticality
* 'e' - log all messages of level 'error' or higher criticality
* 'w' - log all messages of level 'warning' or higher criticality
* 'i' - log all messages of level 'info' or higher criticality
* 't' - log all messages of level 'trace' or higher criticality
* DEFAULT - log all message of level 'error' or higher criticality
*/
La registrazione di Body Tracking SDK K4ABT.dll è simile, ad eccezione del fatto che gli utenti devono modificare un set diverso di nomi di variabili di ambiente:
/**
* environment variables
* K4ABT_ENABLE_LOG_TO_A_FILE =
* 0 - completely disable logging to a file
* log\custom.log - log all messages to the path and file specified - must end in '.log' to
* be considered a valid entry
* ** When enabled this takes precedence over the value of K4A_ENABLE_LOG_TO_STDOUT
*
* K4ABT_ENABLE_LOG_TO_STDOUT =
* 0 - disable logging to stdout
* all else - log all messages to stdout
*
* K4ABT_LOG_LEVEL =
* 'c' - log all messages of level 'critical' criticality
* 'e' - log all messages of level 'error' or higher criticality
* 'w' - log all messages of level 'warning' or higher criticality
* 'i' - log all messages of level 'info' or higher criticality
* 't' - log all messages of level 'trace' or higher criticality
* DEFAULT - log all message of level 'error' or higher criticality
*/
Il dispositivo non enumera in Gestione Dispositivi
- Controllare il LED di stato dietro il dispositivo; se lampeggia di colore ambra, si è verificato un problema di connettività USB e non arriva una potenza sufficiente. Il cavo di alimentazione deve essere collegato all'alimentatore fornito. Mentre il cavo di alimentazione è connesso a un’USB tipo A, il dispositivo richiede una maggiore potenza rispetto a quella fornita da una porta USB di un PC. Quindi, si consiglia di non connetterlo a una porta PC o a un hub USB.
- Verificare di avere collegato il cavo di alimentazione e di usare la porta USB3 per i dati.
- Provare a modificare la porta USB3 per la connessione dati (ad esempio, si consiglia di usare la porta USB vicina alla scheda madre nella parte posteriore del PC).
- Controllare il cavo; i cavi danneggiati o di qualità inferiore possono causare un’enumerazione inaffidabile (il dispositivo continua a "lampeggiare" in Gestione Dispositivi).
- Connettersi a un portatile alimentato a batteria potrebbe limitare la potenza della porta.
- Riavviare il PC host.
- Se il problema persiste, potrebbe essersi verificarsi un problema di compatibilità.
- Se si è verificato un errore durante l'aggiornamento del firmware e il dispositivo non si è ripristinato da solo, eseguire il ripristino delle impostazioni predefinite.
Impossibile aprire Azure Kinect Viewer
Controllare innanzitutto se il dispositivo enumera in Gestione Dispositivi di Windows.
Controllare se qualche altra applicazione sta usando il dispositivo (ad esempio, l’applicazione della fotocamera di Windows). Solo un'applicazione alla volta può accedere al dispositivo.
Controllare k4aviewer.err log per i messaggi di errore.
Aprire l'applicazione della fotocamera di Windows e verificare che funzioni.
Spegnere e riaccendere il dispositivo, attendere che il LED di streaming sia spento prima di usare il dispositivo.
Riavviare il PC host.
Assicurarsi di installare i driver di grafica più recenti nel PC.
Se si usa la propria build di SDK, provare a usare la versione di rilascio ufficiale per risolvere il problema.
Se il problema persiste, raccogliere i log e il feedback dei file.
Impossibile trovare il microfono
Controllare innanzitutto che la matrice di microfoni sia enumerata in Gestione Dispositivi.
Se un dispositivo è enumerato e funziona correttamente in Windows, il problema potrebbe essere che dopo l'aggiornamento del firmware Windows ha assegnato un ID contenitore diverso alla fotocamera di profondità.
È possibile provare a reimpostarla andando in Gestione Dispositivi, facendo clic con il pulsante destro del mouse su "Matrice di microfoni di Azure Kinect" e selezionando "Disinstalla dispositivo". Al termine rimuovere e ricollegare il sensore.
In seguito riavviare Azure Kinect Viewer e riprovare.
Problemi di aggiornamento del firmware del dispositivo
- Se dopo l'aggiornamento non viene segnalato il numero di versione corretto, potrebbe essere necessario spegnere e riaccendere il dispositivo.
- Se l'aggiornamento del firmware viene interrotto, potrebbe verificarsi uno stato non valido e potrebbe essere impossibile eseguire l’enumerazione. Rimuovere e ricollegare il dispositivo e attendere 60 secondi per verificare se esegue il ripristino. In caso contrario, eseguire un ripristino delle impostazioni predefinite
Problemi di qualità dell'immagine
- Avviare Azure Kinect Viewer e controllare il posizionamento del dispositivo per eventuali interferenze e accertarsi che il sensore non sia bloccato o l'obiettivo non sia sporco.
- Se il problema si verifica in una modalità specifica, provare diverse modalità operative per restringere il campo.
- Per la condivisione dei problemi di qualità delle immagini con il team, è possibile:
- Sospendere la visualizzazione su Azure Kinect Viewer e acquisire uno screenshot o
- Eseguire la registrazione con il registratore di Azure Kinect, ad esempio,
k4arecorder.exe -l 5 -r 5 output.mkv
Timestamp del dispositivo incoerenti o imprevisti
La chiamata k4a_device_set_color_control può determinare temporaneamente modifiche degli intervalli del dispositivo, che potrebbe richiedere alcune acquisizioni per stabilizzarsi. Evitare di eseguire chiamate all'API nel ciclo di acquisizione di immagini per evitare di reimpostare il calcolo degli intervalli interni per ogni nuova immagine. Invece, effettuare chiamate all'API prima di avviare la fotocamera o quando è necessario modificare il valore all'interno del ciclo di acquisizione immagini. In particolare, evitare di effettuare chiamate k4a_device_set_color_control(K4A_COLOR_CONTROL_AUTO_EXPOSURE_PRIORITY).
Compatibilità del controller host USB3
Se il dispositivo non enumera in Gestione Dispositivi, potrebbe essere perché è collegato a un controller USB3 non supportato.
Per Azure Kinect DK su Windows, Intel, Texas Instruments (TI)e Renesas sono gli unici controller host supportati. Azure Kinect SDK sulle piattaforme Windows si basa su un contenitore ID unificato e deve coprire dispositivi USB 2.0 e 3.0 in modo che l'SDK possa trovare i dispositivi di profondità, di colore e audio che si trovano fisicamente sullo stesso dispositivo. In Linux, è possibile supportare più controller host perché tale piattaforma si basa meno sull'ID contenitore e più sui numeri di serie del dispositivo.
La questione relativa ai controller host USB si complica ancora di più quando un PC ha più di un controller host installato. Quando si uniscono più controller host, l’utente potrebbe riscontrare il problema in cui alcune porte funzionano correttamente e altre non funzionano affatto. A seconda del modo in cui le porte sono collegate al case, è possibile che tutte le porte frontali presentino problemi con Azure Kinect
Windows: per scoprire quale controller host è aperto in Gestione Dispositivi
- Visualizza -> Dispositivi per tipo
- Con Azure Kinect connesso selezionare Fotocamere->Fotocamera di Azure Kinect 4K Camera
- Visualizza -> Dispositivi per connessione
Per comprendere meglio quale porta USB è connessa al PC, ripetere questi passaggi per ogni porta USB mentre si connette Azure Kinect DK a porte USB diverse nel PC.
La fotocamera di profondità si spegne automaticamente
Il laser usato dalla fotocamera di profondità per calcolare i dati di profondità dell'immagine ha una durata limitata. Per ottimizzare la durata dei laser, la fotocamera di profondità rileverà quando i dati di profondità non vengono utilizzati. La fotocamera di profondità si spegne quando il dispositivo è in streaming da alcuni minuti, ma il PC host non legge i dati. Influisce anche sulla sincronizzazione di più dispositivi dove i dispositivi subordinati vengono avviati in uno stato in cui la fotocamera di profondità è in streaming e i fotogrammi di profondità consentono attivamente di attendere che il dispositivo master avvii le acquisizioni di sincronizzazione. Per evitare questo problema negli scenari di acquisizione di più dispositivi, assicurarsi che il dispositivo master venga avviato entro un minuto dall'avvio del primo subordinato.
Uso di Body Tracking SDK con Unreal
Per usare Body Tracking SDK con Unreal, assicurarsi di aver aggiunto <SDK Installation Path>\tools alla variabile di ambiente PATH e copiato dnn_model_2_0.onnx e cudnn64_7.dll in Program Files/Epic Games/UE_4.23/Engine/Binaries/Win64.
Uso di Azure Kinect su sistema headless Linux
Il motore di profondità di Azure Kinect su Linux usa OpenGL. OpenGL richiede un'istanza della finestra che richieda la connessione di un monitor al sistema. Una soluzione alternativa a questo problema è:
- Abilitare l'accesso automatico per l'account utente che si intende usare. Fare riferimento a questo articolo per istruzioni sull'abilitazione dell’accesso automatico.
- Spegnere il sistema, disconnettere il monitor e riaccendere il sistema. L'accesso automatico forza la creazione di una sessione x-server.
- Connettersi tramite SSH e impostare la variabile di ambiente DISPLAY
export DISPLAY=:0 - Avviare l'applicazione Azure Kinect.
L'utilità xtrlock può essere usata per bloccare immediatamente la schermata dopo l'accesso automatico. Aggiungere il comando seguente all'applicazione di avvio o al servizio systemd:
bash -c “xtrlock -b”
Documentazione C# mancante
La documentazione C# di Sensor SDK è disponibile qui.
La documentazione C# di Body Tracking SDK è disponibile qui.
Modifiche al contenuto dei pacchetti di rilevamento del corpo
I pacchetti MSI e NuGet non includono più i file del pacchetto di Microsoft Visual C++ Redistributable. Scaricare il pacchetto più recente qui.
Il pacchetto NuGet non include più i file DirectML di Microsoft, NVIDIA CUDA e TensorRT.