Robô autônomo Wallace - Parte 4 - Adicionar Sensores de Distância IR e "Amp": 6 etapas

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:38

Olá, hoje começamos a próxima fase de aprimoramento dos recursos de Wallace. Especificamente, estamos tentando melhorar sua capacidade de detectar e evitar obstáculos usando sensores infravermelhos de distância, e também aproveitar a capacidade do controlador de motor Roboclaw de monitorar a corrente e transformá-la em um "sensor" virtual (software). Por fim, veremos como navegar sem SLAM (localização e mapeamento simultâneos) (por enquanto), já que o robô ainda não possui sensores IMU (unidade de medida de inércia) ou ToF (tempo de vôo).

Por navegação, inicialmente serão apenas dois objetivos principais:

1. evitar obstáculos
2. reconhecer quando ele está preso em algum lugar e não está fazendo nenhum progresso. ("progresso" significa que avançou alguma distância significativa)
3. um possível terceiro objetivo poderia ser tentar alinhar-se diretamente a uma parede.

Este projeto começou com um kit de robô e fazendo com que os movimentos básicos funcionassem usando um teclado e conexão ssh.

A segunda fase era adicionar circuitos de suporte suficientes para preparar a adição de muitos sensores.

No Instructable anterior, adicionamos vários sensores acústicos HCSR04 e o robô agora pode evitar obstáculos enquanto se move pelo apartamento.

Embora se dê bem na cozinha e no corredor, com superfícies planas e sólidas, é totalmente cego ao se aproximar da sala de jantar. Ele não pode "ver" as pernas da mesa e da cadeira.

Uma melhoria pode ser acompanhar as correntes típicas do motor e, se os valores saltam, o robô deve ter atingido alguma coisa. É um bom "plano B" ou mesmo C. Mas isso realmente não o ajuda a navegar pela área de jantar.

(Atualização: na verdade, por enquanto, o monitoramento de corrente é o plano A ao reverter, pois removi temporariamente os sensores da parte traseira).

O vídeo para esta seção constitui a fase final dos sensores para evitar obstáculos.

O que você vê no vídeo são seis sensores acústicos HCSR04 frontais e dois sensores Sharp IR. Os sensores IR não entraram muito no vídeo. Seu forte é principalmente quando o robô se encontra na área de jantar de frente para as pernas da mesa e da cadeira.

Além dos sensores, o monitor de corrente entrou em ação especialmente durante a reversão, caso esbarre em alguma coisa.

Finalmente, ele utiliza o histórico dos últimos 100 movimentos e algumas análises básicas para responder a uma pergunta:

"Tem havido progresso real recentemente (ou está preso em alguma dança repetitiva)?"

Então, no vídeo, quando você vê um avanço-reverso repetido, então ele se transforma, significa que ele reconheceu o padrão de avanço-reverso e, portanto, tenta outra coisa.

O único objetivo programado desta versão do software era tentar fazer um progresso contínuo para a frente e tentar evitar obstáculos.

Etapa 1: adicionar circuitos de suporte (MCP3008)

Antes de podermos adicionar os sensores IR, precisaremos do circuito de interface entre eles e o Raspberry Pi.

Adicionaremos um conversor analógico-digital MCP3008. Existem muitos recursos online sobre como conectar este chip ao Raspberry Pi, então não vou entrar muito nisso aqui.

Essencialmente, temos uma escolha. Se a versão dos sensores IR opera a 3 V, o MCP3008 também pode, e podemos então conectar diretamente ao Raspberry.

[Sensor IV de 3 V] - [MCP3008] - [Raspberrry Pi]

No meu caso, no entanto, estou executando principalmente 5V, o que significa um deslocador de nível bidirecional.

[Sensor IV de 5 V] - [MCP3008] - [Barramento bidirecional de 5 V para 3 V] - [Raspberry Pi]

Nota: Há apenas uma saída de sinal do sensor IR. Ele vai diretamente para uma das linhas de sinal analógico de entrada do MCP3008. Do MCP3008, existem 4 linhas de dados que precisamos conectar (por meio do barramento bidirecional) ao Raspberry Pi.

No momento, nosso robô vai rodar usando apenas dois sensores IR, mas poderíamos facilmente adicionar mais. O MCP3008 oito canais de entrada analógica.

Etapa 2: montar sensores infravermelhos

A Sharp fabrica vários sensores infravermelhos diferentes, e eles têm diferentes alcances e área de cobertura. Por acaso, encomendei o modelo GP2Y0A60SZLF. O modelo escolhido afetará o posicionamento e a orientação do sensor. Infelizmente para mim, não pesquisei exatamente quais sensores obter. Foi mais uma decisão do tipo "quais eu posso conseguir em um prazo e preço razoáveis de uma fonte confiável, dentre as que eles oferecem".

(Atualização: no entanto, isso pode não importar, já que esses sensores parecem ficar confusos com a iluminação ambiente interna. Ainda estou explorando esse problema)

Existem pelo menos três maneiras de montar esses sensores no robô.

1. Coloque-os em uma posição fixa, na frente, ligeiramente afastados um do outro.
2. Coloque-os em um servo, na frente, ligeiramente afastados um do outro.
3. Coloque-os em uma posição fixa, na frente, mas nos cantos mais à esquerda e mais à direita, angulados um em direção ao outro.

Ao comparar a escolha # 1 com a escolha # 3, acho que a # 3 cobrirá mais da área de colisão. Se você der uma olhada nas imagens, a escolha # 3 pode ser feita não apenas para que os campos do sensor se sobreponham, mas também podem cobrir o centro e além da largura externa do robô.

Com a escolha nº 1, quanto mais separados os sensores estão angulados um do outro, maior será o ponto cego no centro.

Poderíamos fazer o # 2 (adicionei algumas imagens com servo como uma possibilidade) e fazer uma varredura e, obviamente, isso pode cobrir a maior parte da área. No entanto, quero atrasar o uso de um servo o máximo possível, por pelo menos dois motivos:

• Usaremos um dos canais de comunicação PWM no Raspberry Pi. (É possível melhorar isso, mas ainda …)
• O consumo de corrente com o servo pode ser significativo
• Adiciona mais hardware e software

Eu gostaria de deixar a opção de servo para depois quando adicionar sensores mais importantes, como Time-of-Flight (ToF), ou talvez uma câmera.

Existe uma outra vantagem possível com a opção nº 2 que não está disponível com as outras duas opções. Esses sensores IR podem ficar confusos, dependendo da iluminação. Pode ser que o robô obtenha uma leitura de um objeto que está iminentemente próximo, quando na verdade não há nenhum objeto próximo. Com a opção nº 3, uma vez que seus campos podem se sobrepor, os dois sensores podem estar registrando o mesmo objeto (de ângulos diferentes).

Então, vamos com a escolha de canal nº 3.

Etapa 3: hora de testar

Depois de fazer todas as conexões entre o Raspberry Pi, o MCP3008 ADC e os sensores Sharp IR, é hora de testar. Apenas um teste simples para verificar se o sistema está funcionando com os novos sensores.

Como nos Instructables anteriores, uso a biblioteca wiringPi C tanto quanto possível. Facilita as coisas. Algo que não é muito óbvio, analisando o site wiringPi, é que há suporte direto para o MCP3004 / 3008.

Mesmo sem isso, você pode apenas usar a extensão SPI. Mas não precisa. Se você der uma olhada no repositório git de Gordon para wiringPi, você encontrará uma lista de chips suportados, dos quais um deles é para MCP3004 / 3008.

Decidi anexar o código como um arquivo porque não consegui exibi-lo corretamente nesta página.

Etapa 4: Um Sensor Virtual - AmpSensor

Quanto mais maneiras diferentes você puder fazer com que o robô receba informações sobre o mundo exterior, melhor.

O robô tem atualmente oito sensores acústicos de sonar HCSR04 (eles não são o foco deste Instructable) e agora tem dois sensores de distância Sharp IR. Como afirmado anteriormente, podemos tirar proveito de outra coisa: o recurso de detecção de correntes motoras do Roboclaw.

Podemos agrupar essa chamada de consulta ao controlador do motor em uma classe C ++ e chamá-la de AmpSensor.

Adicionando alguns "smarts" ao software, podemos monitorar e ajustar o consumo de corrente típico durante o movimento direto (para frente, para trás) e também movimentos rotacionais (esquerda, direita). Uma vez que conhecemos essas faixas de amperes, podemos selecionar um valor crítico, de modo que se o AmpSensor obtiver uma leitura de corrente do controlador do motor que exceda esse valor, saibamos que os motores provavelmente estolaram e isso geralmente indica que o robô bateu em algo.

Se adicionarmos alguma flexibilidade ao software (argumentos de linha de comando e / ou entrada de teclado durante a operação), então podemos aumentar / diminuir o limite de "amplificadores críticos" enquanto experimentamos, apenas deixando o robô se mover e bater em objetos, ambos em linha reta ou durante a rotação.

Como nossa parte de navegação do software conhece a direção do movimento, podemos usar todas essas informações para, talvez, parar o movimento e tentar inverter o movimento por um curto período antes de tentar outra coisa.

Etapa 5: Navegação

O robô atualmente é limitado no feedback do mundo real. Ele tem alguns sensores de curta distância para evitar obstáculos e tem uma técnica de fallback para monitorar o consumo de corrente caso os sensores de distância percam um obstáculo.

Não possui motores com encoders, e não possui IMU (unidade de medida inercial), o que torna mais difícil saber se está realmente se movendo ou girando, e em quanto.

Embora seja possível obter algum tipo de indicação de distância com os sensores atualmente no robô, seu campo de visão é amplo e imprevisível. O sonar acústico pode não refletir de volta corretamente; o infravermelho pode ser confundido por outra iluminação, ou mesmo por múltiplas superfícies reflexivas. Não tenho certeza se vale a pena tentar rastrear a mudança na distância como uma técnica para saber se o robô está se movendo, em quanto e em qual direção.

Eu escolhi propositalmente NÃO usar um microcontrolador como um Arduino porque a) Eu não gosto do ambiente psuedo-C ++, b) e que muito desenvolvimento irá desgastar a memória de leitura e gravação (?), E que eu precisaria de um computador host para desenvolver (?). Ou talvez eu simplesmente aconteça como o Raspberry Pi.

O Pi rodando Raspbian, no entanto, não é um sistema operacional em tempo real, então entre as instabilidades desses sensores e o sistema operacional 'não lendo exatamente todas as vezes, eu senti que o propósito desses sensores era mais adequado para evitar obstáculos e não medição de distância real.

Essa abordagem parecia complicada e sem tantos benefícios, quando podemos usar sensores ToF (tempo de voo) melhores (mais tarde) para esse fim (SLAM).

Uma abordagem que podemos usar é manter algum tipo de registro de quais comandos de movimento foram emitidos nos últimos X segundos ou comandos.

Por exemplo, digamos que o robô está preso virado para um canto diagonalmente. Um conjunto de sensores informa que está muito perto de uma parede, então ele gira, mas o outro conjunto de sensores informa que está muito perto da outra parede. Acaba repetindo apenas um padrão lado a lado.

O exemplo acima é apenas um caso muito simples. Adicionar um pouco de inteligência pode apenas elevar o padrão repetido a um novo nível, mas o robô permanece preso no canto.

Exemplo, em vez de girar para frente e para trás no lugar, ele gira em um sentido, faz o reverso momentâneo (que então limpa as indicações de distância crítica) e, mesmo se girar na outra direção, ainda avança em algum ângulo de volta para o canto, repetindo um padrão mais complicado de essencialmente a mesma coisa.

Isso significa que realmente poderíamos usar um histórico de comandos e dar uma olhada em como explorar e usar essas informações.

Posso pensar em duas maneiras muito básicas (rudimentares) de usar a história do movimento.

• para o último número X de movimentos, eles correspondem ao padrão Y. Um exemplo simples poderia ser (e isso aconteceu) "FORWARD, REVERSE, FORWARD, REVERSE,…..". Portanto, há esta função de correspondência que retorna TRUE (padrão encontrado) ou FALSE (não encontrado). Se TRUE, na parte de navegação do programa, tente outras sequências de movimento.
• para o último número X de movimentos, há um movimento geral ou líquido para frente. Como alguém pode determinar o que é um movimento real para a frente? Bem … uma comparação fácil é que para os últimos X movimentos, "FORWARD" ocorre mais do que "REVERSE". Mas esse não precisa ser o único. Que tal isso: "RIGHT, RIGHT, LEFT, RIGHT". Nesse caso, o robô está tendo que virar à direita para sair de um canto ou porque se aproximou da parede em ângulo, o que pode ser considerado um avanço real. Por outro lado, "ESQUERDA, DIREITA, ESQUERDA, DIREITA …" pode não ser considerado um progresso real. Portanto, se "RIGHT" ocorrer mais do que "LEFT", ou "LEFT ocorrer mais do que" RIGHT ", então isso pode ser um progresso real.

No início deste Instructable, mencionei que um possível terceiro objetivo poderia ser quadrar ou alinhar a uma parede. Para isso, entretanto, precisamos mais do que "estamos próximos de algum objeto". Por exemplo, se pudermos obter dois sensores acústicos voltados para a frente (não o foco deste artigo) para dar respostas razoavelmente boas e estáveis em relação à distância, obviamente, se um relatar um valor muito diferente do outro, o robô se aproximou da parede em um ângulo, e pode tentar alguma manobra para ver se esses valores se aproximam (de frente para a parede).

Etapa 6: Reflexões Finais, Próxima Fase …

Espero que este Instructable tenha dado algumas idéias.

Adicionar mais sensores apresenta algumas vantagens e desafios.

No caso acima, todos os sensores acústicos funcionaram bem juntos e foi bastante simples com o software.

Depois que os sensores infravermelhos foram introduzidos na mistura, ficou um pouco mais desafiador. A razão é que alguns de seus campos de visão se sobrepuseram aos dos sensores acústicos. Os sensores IR pareciam um pouco sensíveis e imprevisíveis com as mudanças nas condições de luz ambiente, ao passo que, é claro, os sensores acústicos não são afetados pela iluminação.

E então o desafio era o que fazer se um sensor acústico está nos dizendo que não há obstáculo, mas o sensor IR sim.

Por enquanto, após tentativa e erro, as coisas terminaram nesta prioridade:

1. sensor de amp
2. Sensor de infravermelho
3. sensor acústico

E o que fiz foi apenas diminuir a sensibilidade dos sensores IR, para que eles detectassem apenas objetos muito próximos (como pernas de cadeiras iminentes)

Até agora, não houve necessidade de fazer nenhum software multi-threading ou direcionado a interrupções, embora eu ocasionalmente encontre perda de controle entre o Raspberry Pi e o controlador de motor Roboclaw (perda de comunicações seriais).

É aqui que o circuito de parada de emergência (consulte os Instructables anteriores) normalmente entraria em uso. No entanto, uma vez que não quero (ainda) ter que redefinir o Roboclaw durante o desenvolvimento, e o robô não está indo tão rápido e estou presente para monitorá-lo e desligá-lo, não conectado ao E-Stop.

Eventualmente, o multi-threading provavelmente será necessário.

Próximos passos…

Obrigado por chegar até aqui.

Obtive alguns sensores VL53L1X a laser infravermelho ToF (tempo de vôo), então esse é provavelmente o tópico do próximo Instructable, junto com um servo.