Câmeras de visão de máquina para entusiastas. Como usar a câmera para navegação offline?

Fizemos uma câmera para detectar AprilTag e ArTag com o mROS. Conecte-se via Uart ou Ethernet.

Tentamos o JeVois e o OpenMV, apreciamos os prós e os contras e montamos nossa câmera.



Procure por tags visuais e a orientação do robô com base nos dados. Estamos desenvolvendo um robô para coletar bolas de golfe no driving range . Agora, no mundo, apenas uma empresa vende um robô para resolver esse problema. O mercado é muito promissor, nos incentivou a transformar o projeto de DIY em uma startup de tecnologia.

Usando o GPS sem RTK para navegar no robô, é difícil obter a precisão necessária para pesquisar corretamente uma base e estacionamento. Usando a cinemática em tempo real, terei problemas ao abordar edifícios. Tentamos várias opções e decidimos fazer nossa própria câmera para procurar uma marca visual na entrada da base.

Parte do desenvolvimento do robô foi o estacionamento na estação de acoplamento para descarregar o compartimento da bola e carregar as baterias. Pensamos durante muito tempo sobre como estacioná-lo, concordamos que o robô encontraria um objeto óptico brilhante e o seguiria.

As tags AprilTag ou ArTag foram escolhidas como destino, dependendo de como elas foram exibidas no campo. Porque não sofremos da síndrome do NIH - a busca por câmeras de visão de máquina com suporte para esses marcadores e com suporte de script diretamente na câmera já começou.

Primeiro JeVois

Do que foi rapidamente encontrado - JeVois , desenvolvido pelo laboratório da Universidade do Sul da Califórnia. Infelizmente, eu tive que fazer um pedido para a Rússia através da Amazon, não havia revendedores internos e, aparentemente, não haverá - aparentemente o marketing e as vendas são realizados pelos próprios desenvolvedores (ficamos surpresos quando tivemos que mudar de Jevois para Jevois inc para comprar uma câmera e, em seguida, procurando um link para o diretório - selecione a câmera em algum lugar no meio de 10 a 12 posições).



As primeiras execuções no computador foram bastante animadoras; em geral, tudo funcionou imediatamente e parecia bastante interessante. No entanto, após os testes de conexão ao painel de controle, quatro sérios problemas ficaram claros:

Os 60-90 FPS indicados nos materiais de publicidade são para resoluções de 160x120 ou 320x240, o que não é de todo adequado para estacionamento - a captura ainda é desejável a uma distância de pelo menos 5 metros. E para que um quadrado caia no grão de 160x120 de 6 a 8 metros - você precisa torná-lo com pelo menos meio metro de tamanho e, ao se aproximar dele, primeiro fecha completamente o quadro e depois para de detectar.

Consumo de 800mA, enquanto a energia é apenas via cabos USB com mini USB, que podem suportar essa corrente sem muita queda de tensão. Foi muito difícil encontrar um cabo com pelo menos meio metro com essas características - foram selecionadas cerca de 15 opções e o resultado não foi muito satisfatório.

A câmera está cega à noite ou pisca durante o dia. O equilíbrio automático funciona além do bem e do mal.

A câmera é resfriada por um ventilador. O ventilador é muito pequeno, a velocidade é alta - ruído de alta frequência ou simplesmente um guincho.

O robô estridente é a última coisa que queremos fazer.

Escrever o código de execução dentro da câmera é um entretenimento separado - instalar o ambiente é um assunto bastante confuso, e montar e fazer o upload para o cartão SD leva pelo menos 2-5 minutos. Sim, não há flash - tudo está no cartão SD.

Conclusão: uma câmera para brincar com entusiastas em ambientes fechados e com boa iluminação. Ao mesmo tempo, seria desejável que os entusiastas fossem estudantes - a interface, a documentação e os métodos de trabalho com a câmera me lembraram vividamente o trabalho de laboratório do aluno, onde quase nenhuma atenção foi dada à conveniência de trabalhar com o sistema e outros excessos. Trata-se de módulos C ++, é claro. Os scripts Python podem ser editados através do Jevois Inventor, mas o FPS também é significativamente menor. Fora das instalações, a câmera nem sobreviveu a duas chuvas, e o ventilador entupiu a sujeira no campo com a velocidade do espaço.

O resultado - não é adequado para uso no robô, mas a possibilidade fundamental de estacionamento foi comprovada.

OpenMV 3 e todas as suas variantes

No momento da primeira pesquisa, ele simplesmente não estava disponível - havia uma campanha no Kickstarter .

Depois que jogamos o suficiente com JeVois e 100 dólares foram jogados no lixo - um vendedor com ações foi encontrado e duas peças foram compradas.

Em geral, as impressões são extremamente agradáveis ​​- uma interface notavelmente pensada no OpenMV IDE, compilação transparente em python, é conveniente assistir o algoritmo funcionar e depurá-lo. No entanto, houve problemas aqui:

• A resolução poderia ser qualquer, mas a AprilTag só pôde ser pesquisada em uma área de não mais que 200x200 pixels. Voltamos ao problema dos grãos, etc. O desenvolvedor recomendou primeiro puxar blobs e, em seguida, examinar os códigos neles. Mas em algo que não seja um plano de fundo simples (idealmente uma parede branca) isso não funciona, a grama verde e o sol brilhante contra o fundo transformam tudo em mingau. Além disso, o FPS cai para um máximo de 5.
• Sensor Omnivision barato + óptica barata = imagem com sabão. Visualmente, isso não é muito perceptível ao exibir um fluxo de vídeo, mas ao exibir quadros individuais, ele é claramente visível.
• Não há cortina de infravermelho, mas há iluminação por infravermelho. [WHAAAAT?]
• Não há proteção contra o ambiente externo. Nem um pouco.

O script foi depurado nesta câmera, várias dezenas de corridas de estacionamento foram feitas. No entanto, depois que o robô rolou de Moscou para São Petersburgo e voltou, a câmera parou de ligar - o regulador de energia foi nocauteado. A ação óbvia foi empacotamento e estabilização de energia. E aqui a coisa mais interessante foi descoberta - o caso com o IP certo para esta câmera simplesmente não pôde ser encontrado, ou foram caixas com tampas transparentes, sem montagens internas e entradas / saídas de cabo apertadas. Como resultado da busca, foram encontradas uma grande quantidade de câmeras de vigilância chinesas baratas com os casos certos. A câmera foi comprada e destruída, uma segunda cópia do OpenMV estava no lugar do quadro, tudo funcionou.
Mas a noite e a noite se tornaram um obstáculo quase intransponível - não há cortina de infravermelho.

Resultados: a câmera é MUITO conveniente para prototipagem, os recursos são limitados, não há proteção contra o ambiente externo (a segunda câmera foi para um freezer industrial e não sobreviveu a -30). Não é bom

E então ficou muito interessante para nós que tipo de placas recebíamos das câmeras chinesas

HiSilicon Clones

Em uma inspeção mais minuciosa, verificou-se que a placa possui um ARM de 2 núcleos, processador DSP, cortina de infravermelho, iluminação infravermelha, um sensor decente da Sony, a placa é coberta com um composto de proteção + compartimento para a rua. Exatamente o que você precisa - resta coletar o software.

Por dentro, acabou sendo um clone do Linux bastante útil do HiSilicon + u-boot.
Eu tive que baixar o SDK de recursos chineses e lidar com assemblies. Em princípio, nada terrível foi encontrado ao longo do caminho, exceto que era necessário consertar vários arquivos dentro do SDK - a distribuição Linux na qual o SDK seria bastante antigo e alguns arquivos de cabeçalho foram alterados desde então. Bem, eu tive que mudar o shell do zsh para o bash. Omitirei os detalhes; para o bem, este deve ser um artigo separado.

Esses recursos ajudaram:

Analisando, conectando-se à câmera

Exemplo de diagrama de montagem de software

Então tudo correu de acordo com o esquema bem conhecido:



Na maioria das vezes, para tirar a foto do sensor, eu terminei o resto em apenas 4 horas, apenas portando o algoritmo depurado do Python para o C ++.
O trabalho com o sensor levou cerca de uma semana e meia. É claro que não há / dev / video0 nesses dispositivos, hardware quase vazio com trabalho direto com memória e portas.
Devemos dizer imediatamente que as amostras do SDK funcionam sem modificação apenas nas placas de depuração desses SDKs, caso contrário, são necessárias muitas edições menores. Por mais engraçado que possa parecer, o principal problema é determinar qual sensor está na câmera, porque os chineses escrevem um na descrição, outro é marcado no quadro, o terceiro modelo é inicializado no software. Por exemplo, a câmera possui um sensor IMX323 na descrição, o quadro é marcado como SC2235, quando iniciado nos scripts init, inicia como AR130 e o software da câmera o inicializa como SC2235P.

As razões para tudo isso são bastante simples: para o usuário final, o IMX323, o SC2235 são todos iguais, a imagem é muito semelhante. O kernel e o rootfs com scripts int foram montados no SDK com alterações mínimas e não se incomodaram com um script de inicialização separado para cada modelo - apenas os parâmetros de inicialização estão corretos e o nome foi deixado como estava. No software para trabalhar com a câmera, a segunda parte da inicialização do DSP com o sensor já foi lançada e o modelo exato da câmera já é crítico lá - portanto, os registros já têm o modelo exato - SC2235P. P - isso é importante, é um sensor diferente em características, que funciona até com uma frequência de barramento ligeiramente diferente e uma resolução diferente em comparação com SC2235.

A segunda parte da busca são folhas de dados sobre sensores, que geralmente não são. Portanto, tive que reconstruir o módulo hi_i2c com a impressão no log via printk e substituí-lo no despejo removido da câmera, gravar o amortecedor de configuração DSP do processador de vídeo e remover as configurações da câmera em funcionamento, além de várias vezes para examinar os drivers do projeto DafangSoftware. Em detalhes, isso desenha 3-4 artigos separados, que pretendo escrever depois do NG.

No final, tudo ficou ainda melhor do que o esperado - trabalho confiante para capturar o AprilTag a partir de 6 metros, mesmo na escuridão quase completa, 25-12 fps, controlador de controle de estacionamento PID, etc.
O resultado - é o máximo para trabalhar em campo, muitas coisas foram levadas em consideração para proteger contra condições externas. A única coisa que não pôde ser totalmente verificada foi o trabalho ao sol, o clima desde outubro se deteriorou.

Ideia para o desenvolvimento

E aqui tivemos uma idéia - temos em nossas mãos um análogo do OpenMV com recursos de hardware e produção em massa muito melhores. Resta levar o trabalho com a câmera para o nível OpenMV, para o micropython, criar um IDE conveniente e verificar novamente como os scripts atuais do OpenMV funcionarão. Além disso, o mRos é completamente portado para lá, e isso imediatamente expande o uso dessas câmeras para sistemas ROS.

Como resultado, planejamos entregar análogos OpenMV em março e mROS até maio.

Para reduzir o preço da personalização da câmera, estamos prontos para oferecer a você. Preencha o formulário e entraremos em contato quando estiver pronto para pedir o primeiro lote.