Problemas conhecidos e solução de problemas do Azure Kinect
Esta página contém problemas conhecidos e dicas de solução de problemas durante o uso do SDK do Sensor com o Azure Kinect DK. Confira também as páginas de suporte do produto para obter problemas específicos de hardware do produto.
Problemas conhecidos
- Problemas de compatibilidade com controladores de host USB ASMedia (por exemplo, chipset ASM1142)
- Alguns casos que usam o driver USB da Microsoft podem ser desbloqueados
- Muitos computadores também têm controladores de host alternativos, e a alteração da porta USB3 pode ser útil
Para obter mais problemas relacionados ao SDK do Sensor, confira Problemas do GitHub
Coleta de logs
O log de K4A.dll é habilitado por meio de variáveis de ambiente. Por padrão, o log é enviado para StdOut e somente as mensagens críticas e os erros são gerados. Essas configurações podem ser alteradas para que o log chegue a um arquivo. O detalhamento também pode ser ajustado conforme necessário. Veja abaixo um exemplo, para o Windows, de como habilitar o log em um arquivo chamado k4a.log, que captura mensagens de aviso e de nível superior.
set K4A_ENABLE_LOG_TO_A_FILE=k4a.log
set K4A_LOG_LEVEL=w
- Executar o cenário no prompt de comando (por exemplo, iniciar visualizador)
- Procure k4a.log e compartilhe o arquivo.
Para obter mais informações, confira o recorte abaixo do arquivo de cabeçalho:
/**
* 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
*/
O log do SDK de Acompanhamento de Corpo K4ABT.dll é semelhante, com a exceção de que os usuários devem modificar um conjunto diferente de nomes de variáveis de 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
*/
O dispositivo não está enumerado no Gerenciador de Dispositivos
- Verifique o LED de status atrás do dispositivo. Se ele estiver piscando em âmbar, há um problema de conectividade USB e ele não está obtendo energia suficiente. O cabo da fonte de alimentação deve ser conectado ao adaptador de energia fornecido. Embora o cabo de alimentação tenha um tipo USB A conectado, o dispositivo exige mais energia do que uma porta USB do computador pode fornecer. Portanto, não se conecte a ele com uma porta do computador ou com um hub USB.
- Verifique se você tem um cabo de alimentação conectado e que esteja usando a porta USB3 para dados.
- Tente alterar a porta USB3 para a conexão de dados (a recomendação é usar a porta USB próxima à placa-mãe, por exemplo, na parte traseira do computador).
- Verifique o cabo. Cabos danificados ou de baixa qualidade podem causar uma enumeração não confiável (o dispositivo fica "piscando" no Gerenciador de Dispositivos).
- Se você tiver se conectado a um laptop e ele estiver em execução com a bateria ligada, ele poderá estar limitando a energia para a porta.
- Reinicialize o computador host.
- Se o problema persistir, poderá haver um problema de compatibilidade.
- Se a falha ocorreu durante a atualização do firmware e o dispositivo não foi recuperado por si só, execute a redefinição de fábrica.
Falha ao abrir o Azure Kinect Viewer
Verifique primeiro se o dispositivo está enumerado no Gerenciador de Dispositivos do Windows.
Verifique se qualquer outro aplicativo está usando o dispositivo (por exemplo, aplicativo de câmera do Windows). Somente um aplicativo por vez pode acessar o dispositivo.
Verifique o log k4aviewer.err em busca de mensagens de erro.
Abra o aplicativo de câmera do Windows e verifique se ele funciona.
Realize um ciclo de energia do dispositivo. Aguarde o LED de transmissão ser desligado antes de usar o dispositivo.
Reinicialize o computador host.
Verifique se você está usando os drivers gráficos mais recentes no computador.
Se você estiver usando um build próprio do SDK, experimente usar a versão lançada oficialmente se isso corrigir o problema.
Se o problema persistir, colete os logs e envie comentários sobre o arquivo.
Não é possível localizar o microfone
Verifique primeiro se a matriz de microfone está enumerada no Gerenciador de Dispositivos.
Se um dispositivo estiver enumerado e funcionar corretamente no Windows, o problema poderá ser que, após a atualização do firmware, o Windows atribuiu uma ID de contêiner diferente à câmera de profundidade.
Você pode tentar redefini-lo acessando o Gerenciador de Dispositivos, clicando com o botão direito do mouse em "Matriz de Microfone do Azure Kinect" e selecionando "Desinstalar dispositivo". Quando isso for concluído, desanexe e anexe novamente o sensor.
Depois disso, reinicie o Azure Kinect Viewer e tente novamente.
Problemas de atualização do firmware do dispositivo
- Se o número de versão correto não for relatado após a atualização, talvez seja necessário realizar o ciclo de energia do dispositivo.
- Se a atualização do firmware for interrompida, ela poderá entrar em um estado inválido, e a enumeração falhará. Desanexe e anexe novamente o dispositivo e aguarde 60 segundos para ver se ele pode ser recuperado. Caso contrário, execute uma redefinição de fábrica
Problemas de qualidade da imagem
- Inicie o Azure Kinect Viewer e verifique o posicionamento do dispositivo quanto à interferência, se o sensor está bloqueado ou se as lentes estão sujas.
- Experimente modos de operação diferentes para restringi-lo se o problema estiver ocorrendo em um modo específico.
- Para compartilhar problemas de qualidade da imagem com a equipe, você poderá:
- Pausar a exibição do Azure Kinect Viewer e fazer uma captura de tela ou
- Fazer uma gravação usando o gravador do Azure Kinect, por exemplo,
k4arecorder.exe -l 5 -r 5 output.mkv
Carimbos de data/hora inconsistentes ou inesperados do dispositivo
A chamada a k4a_device_set_color_control
pode induzir temporariamente as alterações de tempo no dispositivo, que poderá levar algumas capturas para ser estabilizado. Evite chamar a API no loop de captura de imagem para evitar redefinir o cálculo de tempo interno a cada nova imagem. Em vez disso, chame a API antes de iniciar a câmera ou apenas quando precisar alterar o valor dentro do loop de captura de imagem. Em particular, evite chamar k4a_device_set_color_control(K4A_COLOR_CONTROL_AUTO_EXPOSURE_PRIORITY)
.
Compatibilidade do controlador de host USB3
Se o dispositivo não estiver sendo enumerado no Gerenciador de Dispositivos, isso poderá ocorrer devido a ele estar conectado a um controlador USB3 sem suporte.
Para o Azure Kinect DK no Windows, o Intel, o TI (Texas Instruments) e o Renesas são os únicos controladores de host com suporte. O SDK do Azure Kinect em plataformas Windows depende de uma ID de contêiner unificada e precisa abranger dispositivos USB 2.0 e 3.0 para que o SDK possa encontrar os dispositivos de profundidade, cor e áudio que estão localizados fisicamente no mesmo dispositivo. No Linux, mais controladores de host podem ter suporte, pois essa plataforma depende menos da ID de contêiner e mais dos números de série do dispositivo.
O tópico dos controladores de host USB fica ainda mais complicado quando um computador tem mais de um controlador de host instalado. Quando os controladores de host estão combinados, um usuário pode enfrentar problemas em que algumas portas funcionam bem e outras não funcionam. Dependendo de como as portas são conectadas à caixa, poderá ocorrer problemas com todas as portas frontais no Azure Kinect
Windows: para descobrir o controlador de host existente que abriu o Gerenciador de Dispositivos
- Exibir –> Dispositivos por Tipo
- Com o Azure Kinect conectado, selecione Câmeras– >Câmera do Azure Kinect 4K
- Exibir –> Dispositivos por Conexão
Para entender melhor qual porta USB está conectada ao computador, repita essas etapas para cada porta USB ao conectar o Azure Kinect DK a diferentes portas USB no computador.
Desligamento automático da câmera de profundidade
O laser usado pela câmera de profundidade para calcular os dados de profundidade de imagem tem um ciclo de vida limitado. Para maximizar a vida útil dos lasers, a câmera de profundidade detectará quando os dados de profundidade não estiverem sendo consumidos. A câmera de profundidade é desligada quando o dispositivo transmite conteúdo por vários minutos, mas o computador do host não lê os dados. Isso também afeta a sincronização de vários dispositivos, em que os dispositivos subordinados são iniciados em um estado em que a câmera de profundidade transmite o conteúdo e os quadros de profundidade ajudam ativamente a aguardar que o dispositivo mestre inicie a sincronização de capturas. Para evitar esse problema em cenários de captura de vários dispositivos, verifique se o dispositivo mestre é iniciado em até um minuto após a inicialização do primeiro subordinado.
Como usar o SDK de Acompanhamento de Corpo com o Unreal
Para usar o SDK de Acompanhamento de Corpo com o Unreal, verifique se você adicionou <SDK Installation Path>\tools
à variável de ambiente PATH
e copiou dnn_model_2_0.onnx
e cudnn64_7.dll
para Program Files/Epic Games/UE_4.23/Engine/Binaries/Win64
.
Como usar o Azure Kinect em um sistema Linux sem periféricos
O mecanismo de profundidade do Azure Kinect no Linux usa o OpenGL. Para o OpenGL, é necessário ter uma instância de janela, o que exige que um monitor esteja conectado ao sistema. Uma solução alternativa para esse problema é:
- Habilitar o logon automático para a conta de usuário que você pretende usar. Veja este artigo para obter instruções sobre como habilitar o logon automático.
- Desligar o sistema, desconectar o monitor e ligar o sistema. O logon automático força a criação de uma sessão x-Server.
- Conectar-se via SSH e definir a variável de ambiente DISPLAY
export DISPLAY=:0
- Iniciar o aplicativo do Azure Kinect.
O utilitário xtrlock pode ser usado para bloquear imediatamente a tela após o logon automático. Adicione o seguinte comando ao aplicativo de inicialização ou ao serviço do sistema:
bash -c “xtrlock -b”
Documentação do C# ausente
A documentação do SDK do Sensor para C# está localizada aqui.
A documentação do SDK do Acompanhamento de Corpo para C# está localizada aqui.
Alterações no conteúdo dos pacotes de Acompanhamento de Corpo
Os pacotes MSI e NuGet não incluem mais os arquivos do Pacote Redistribuível do Microsoft Visual C++. Baixe o pacote mais recente aqui.
O pacote NuGet está de volta. No entanto, ele não inclui mais arquivos DirectML da Microsoft ou NVIDIA CUDA e TensorRT.