Resolução de problemas e problemas conhecidos do Azure Kinect

  • Artigo

Esta página contém problemas conhecidos e sugestões de resolução de problemas ao utilizar o SDK do Sensor com o Azure Kinect DK. Veja também páginas de suporte de produtos para problemas específicos de hardware do produto.

Problemas conhecidos

  • Problemas de compatibilidade com controladores anfitriões USB ASMedia (por exemplo, chipset ASM1142)
    • Alguns casos que utilizam o controlador USB da Microsoft podem desbloquear
    • Muitos PCs também têm controladores anfitriões alternativos e alterar a porta USB3 pode ajudar

Para obter mais problemas relacionados com o SDK do Sensor, veja Problemas do GitHub

Recolher registos

O registo de K4A.dll é ativado através de variáveis de ambiente. Por predefinição, o registo é enviado para stdout e apenas são gerados erros e mensagens críticas. Estas definições podem ser alteradas para que o registo vá para um ficheiro. A verbosidade também pode ser ajustada conforme necessário. Segue-se um exemplo, para o Windows, de ativar o registo num ficheiro, com o nome k4a.log, e irá capturar mensagens de aviso e de nível superior.

  1. set K4A_ENABLE_LOG_TO_A_FILE=k4a.log
  2. set K4A_LOG_LEVEL=w
  3. Cenário de execução a partir da linha de comandos (por exemplo, iniciar visualizador)
  4. Navegue para k4a.log e partilhe o ficheiro.

Para obter mais informações, veja o clip abaixo do ficheiro 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 registo do SDK de Controlo de Corpo K4ABT.dll é semelhante, exceto que os utilizadores 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 enumera no gestor de dispositivos

  • Verifique o ESTADO LED por trás do dispositivo. Se estiver a piscar, significa que tem um problema de conectividade USB e não tem energia suficiente. O cabo de alimentação deve estar ligado ao adaptador de alimentação fornecido. Embora o cabo de alimentação tenha um usb do tipo A ligado, o dispositivo necessita de mais energia do que uma porta USB do PC pode fornecer. Por isso, não se ligue a uma porta do PC ou a um concentrador USB.
  • Verifique se tem o cabo de alimentação ligado e a porta USB3 para obter dados.
  • Tente alterar a porta USB3 para a ligação de dados (recomendação para utilizar a porta USB perto da placa principal, por exemplo, na parte de trás do PC).
  • Verifique o cabo, os cabos danificados ou de qualidade inferior podem causar uma enumeração pouco fiável (o dispositivo continua a "piscar" no gestor de dispositivos).
  • Se tiver ligado ao portátil e a funcionar com a bateria, poderá estar a limitar a alimentação à porta.
  • Reinicie o PC anfitrião.
  • Se o problema persistir, poderá existir um problema de compatibilidade.
  • Se tiver ocorrido uma falha durante a atualização de firmware e o dispositivo não tiver sido recuperado por si só, efetue a reposição de fábrica.

Falha ao abrir o Visualizador do Azure Kinect

  • Verifique primeiro se o seu dispositivo enumera no Windows Gestor de Dispositivos.

    Câmaras do Azure Kinect no gestor de dispositivos Windows

  • Verifique se tem outra aplicação a utilizar o dispositivo (por exemplo, a aplicação de câmara do Windows). Apenas uma aplicação de cada vez pode aceder ao dispositivo.

  • Verifique se existem mensagens de erro no registo k4aviewer.err.

  • Abra a aplicação de câmara do Windows e verifique se funciona.

  • Dispositivo de ciclo de energia, aguarde que o LED de transmissão em fluxo seja desligado antes de utilizar o dispositivo.

  • Reinicie o PC anfitrião.

  • Certifique-se de que está a utilizar os controladores gráficos mais recentes no PC.

  • Se estiver a utilizar a sua própria compilação do SDK, experimente utilizar a versão lançada oficialmente se isso corrigir o problema.

  • Se o problema persistir, recolha os registos e os comentários dos ficheiros.

Não é possível localizar o microfone

  • Verifique primeiro se a matriz do microfone é enumerada no Gestor de Dispositivos.

  • Se um dispositivo for enumerado e funcionar corretamente no Windows, o problema poderá ser que, após a atualização de firmware, o Windows tenha atribuído um ID de contentor diferente à Câmara de Profundidade.

  • Pode tentar repô-lo ao aceder a Gestor de Dispositivos, clicar com o botão direito do rato em "Matriz de Microfone do Azure Kinect" e selecionar "Desinstalar dispositivo". Uma vez concluído, desencaixe e volte a ligar o sensor.

    Matriz de Microfone do Azure Kinect

  • Depois disso, reinicie o Visualizador do Azure Kinect e tente novamente.

Problemas de atualização do Firmware do Dispositivo

  • Se o número de versão correto não for comunicado após a atualização, poderá ter de ligar/desligar o dispositivo.
  • Se a atualização de firmware for interrompida, poderá entrar em mau estado e não conseguir enumerar. Desencaixe e volte a encaixar o dispositivo e aguarde 60 segundos para ver se consegue recuperar. Caso contrário, execute uma reposição de fábrica

Problemas de qualidade da imagem

  • Inicie o visualizador do Azure Kinect e verifique o posicionamento do dispositivo quanto a interferências ou se o sensor está bloqueado ou se a lente está suja.
  • Experimente diferentes modos de operação para restringir se o problema estiver a ocorrer no modo específico.
  • Para partilhar problemas de qualidade de imagem com a equipa, pode:
  1. Colocar a vista em pausa no visualizador do Azure Kinect e efetuar uma captura de ecrã ou
  2. Gravar com o gravador do Azure Kinect, por exemplo, k4arecorder.exe -l 5 -r 5 output.mkv

Carimbos de data/hora inconsistentes ou inesperados do dispositivo

As chamadas k4a_device_set_color_control podem induzir temporariamente alterações de temporização no dispositivo que podem demorar algumas capturas a estabilizar. Evite chamar a API no ciclo de captura de imagens para evitar repor o cálculo de temporização interna com cada nova imagem. Em vez disso, chame a API antes de iniciar a câmara ou apenas quando precisar de alterar o valor no ciclo de captura de imagens. Em particular, evite chamar k4a_device_set_color_control(K4A_COLOR_CONTROL_AUTO_EXPOSURE_PRIORITY).

Compatibilidade do controlador anfitrião USB3

Se o dispositivo não estiver a enumerar no gestor de dispositivos, poderá dever-se ao facto de estar ligado a um controlador USB3 não suportado.

Para o Azure Kinect DK no Windows, Intel, Texas Instruments (TI) e Renesas são os únicos controladores anfitriões suportados. O SDK do Azure Kinect nas plataformas windows depende de um ID de contentor unificado e tem de abranger dispositivos USB 2.0 e 3.0 para que o SDK possa encontrar a profundidade, a cor e os dispositivos de áudio que estão fisicamente localizados no mesmo dispositivo. No Linux, podem ser suportados mais controladores anfitriões, uma vez que essa plataforma depende menos do ID de contentor e muito mais em números de série de dispositivos.

O tópico dos controladores anfitriões USB torna-se ainda mais complicado quando um PC tem mais do que um controlador anfitrião instalado. Quando os controladores anfitriões são mistos, um utilizador pode deparar-se com problemas em que algumas portas funcionam bem e outras não funcionam. Consoante a forma como as portas estão ligadas ao caso, poderá ver todas as portas frontais com problemas com o Azure Kinect

Windows: Para saber que controlador anfitrião tem aberto Gestor de Dispositivos

  1. Ver -> Dispositivos por Tipo
  2. Com o Azure Kinect ligado, selecione Câmaras-> Câmara 4K do Azure Kinect
  3. Ver -> Dispositivos por Ligação

Resolução de problemas da porta USB

Para compreender melhor que porta USB está ligada no PC, repita estes passos para cada porta USB à medida que liga o Azure Kinect DK a portas USB diferentes no PC.

A câmara de profundidade é ativada automaticamente para baixo

O laser utilizado pela câmara de profundidade para calcular os dados de profundidade da imagem tem um ciclo de vida limitado. Para maximizar a vida útil dos lasers, a câmara de profundidade irá detetar quando os dados de profundidade não estão a ser consumidos. A câmara de profundidade diminui quando o dispositivo está em fluxo durante vários minutos, mas o PC anfitrião não está a ler os dados. Também afeta a Sincronização de Vários Dispositivos, em que os dispositivos subordinados são iniciados num estado em que a câmara de profundidade está a ser transmitida em fluxo e os fotogramas de profundidade ajudam ativamente a aguardar que o dispositivo principal comece a sincronizar capturas. Para evitar este problema em cenários de captura de Vários Dispositivos, certifique-se de que o dispositivo principal é iniciado num minuto após o primeiro subordinado ser iniciado.

Utilizar o SDK de Controlo de Corpo com Unreal

Para utilizar o SDK de Controlo de Corpo com Unreal, confirme que adicionou <SDK Installation Path>\tools à variável PATH de ambiente e copiou dnn_model_2_0.onnx e cudnn64_7.dll para Program Files/Epic Games/UE_4.23/Engine/Binaries/Win64.

Utilizar o Azure Kinect num sistema Linux sem cabeça

O motor de profundidade do Azure Kinect no Linux utiliza o OpenGL. O OpenGL requer uma instância de janela que requer a ligação de um monitor ao sistema. Uma solução para este problema é:

  1. Ative o início de sessão automático para a conta de utilizador que planeia utilizar. Veja este artigo para obter instruções sobre como ativar o início de sessão automático.
  2. Desligue o sistema, desligue o monitor e desligue o sistema. O início de sessão automático força a criação de uma sessão de servidor x.
  3. Ligar através de ssh e definir a variável DISPLAY env export DISPLAY=:0
  4. Inicie a sua aplicação do Azure Kinect.

O utilitário xtrlock pode ser utilizado para bloquear imediatamente o ecrã após o início de sessão automático. Adicione o seguinte comando à aplicação de arranque ou ao serviço systemd:

bash -c “xtrlock -b”

Documentação de C# em falta

A documentação do Sensor SDK C# está localizada aqui.

A documentação C# do SDK de Controlo de Corpo está localizada aqui.

Alterações ao conteúdo dos pacotes de Controlo de Corpo

Os pacotes MSI e NuGet já não incluem os ficheiros microsoft Visual C++ Redistributable Package. Transfira o pacote mais recente aqui.

O pacote NuGet está de volta, no entanto, já não inclui ficheiros Microsoft DirectML ou NVIDIA CUDA e TensorRT.

Passos seguintes

Mais informações de suporte