DAMI-M3 v1.0.0
Já tinha iniciado um modelo de robot 2WD com motores de passo, mas não previa dedicar-me ao seu desenvolvimento tão cedo.
A maior atenção dada ao DAMI-M3 foi para compensar a frustração com os motores DC. Que não só teve mais atenção como também herdou a BARD do DAMI-M1 que entretanto desmontei.
Já tinha feito um chassi temporário com umas rodas feitas na impressora 3D, que usei inicialmente como aprendizagem do funcionamento geral do motores de passo 28BJY-48, mas o projecto estava encostado.
Quando voltei a dar atenção a este projecto, pensei em remodelar e pensar em grande.
Por isso quando começei a desenvolver um chassi definivo coloquei um Banana Pi com caixa para comunicar com o exterior e efectuar o processamento do mapeamento e localização.


Entretanto a minha ideia, como vem sendo costume não corre bem. Descubro qualquer coisa que dificulta ou impede a sua concretização.
Neste caso porque verifiquei que o conjunto era muito pesado. Por isso reformulei o chassi, que ficou conforme a imagem abaixo, e coloquei um Raspberry Pi B, sem caixa.
Já anteriormente tinha tentado sem sucesso alimentar um banana pi a partir da bateria comum. Na altura, e porque o cabo usado nao funcionou tambem com o power pack, achei que o problema era do cabo.
Como não podia colocar mais peso, desisti da ideia do Pi e acabei por fazer um chassi mais pequeno, com o tamanho e formato dos chassis 2WD adquiridos a baixo custo já com motores DC.

A BARD também evoluiu, pois ficou com a do DAMI-M1 que modifiquei para as necessidades do DAMI-M3.


Nas alterações a BARD foram previstas ligações para um MPU6050 e para um QMC5883L, que acabaram por não ser usados. O MPU6050 deixava de responder ao fim de poucos segundos e o QMC apresentava leituras tão dispares que tambem desisti dele.
O problema será o ruido gerados pelos steppers, e segundo as informações disponiveis na web, teria que fazer o decoupling com aguns condensadores. Tentei aplicar a solução mas não funcionou.
Descrição dos materiais e aplicação
- Chassi feito com:
- Uma base feita de vidro acrílico branco, cortado com o mesmo formato dos chassis baratos vendidos na net já com rodas e motores DC;
- Dois pedaços de calha plástica em L (2cm), com 13 cm de comprimento, com dois furos cada (para encaixar os sonares) aplicados nas laterais da parte de cima da base a partir da parte da frente;
- Dois suportes para os stepper feitos numa impressora 3D, aplicados na parte debaixo da base;
- Alguns parafusos, anilhas, espaçadores e porcas
- A propulsão deste modelo do DAMI é feita com motores de passo, também conhecidos por steppers, 28BYJ-48 conduzidos por módulos ULN2003.
- Tem uma roda aplicada ao eixo de cada stepper. Impressas em 3D e uns orings a fazer de pneus. Tem ainda uma roda esférica (caster) aplicada a parte de baixo da base, a funcionar como terceira roda;
- Tem dois sensores de distância ultra-som HC SR-04 nas laterais frente, e um sensor de distância laser VL53L1X, montado num suporte feito em impressora 3D num servo SG-90;
- Dois Arduinos Nano, um 168 e um 328P efectuam o controlo do robot coordenados por troca de dados i2c;
- Bateria Lithium 12V / 6800 mA
- Uma board para colocar os arduinos e alguma electrónica simples.
Software
- dami_m3_master_sensor_mod2_v10
- dami_m3_slave_motion_mod2v5
Descrição
Esqueleto de uma arquitectura de exploração de robots com dois arduinos, ligados por i2c, e com tarefas especializadas, um (slave) controla os steppers, o outro (master) que controla os sensores e toma as decisões de movimento.
A arquitetura foi pensada para ser flexivel, e é baseada na execução de comandos, ou sequencias de comandos, que implementam movimentos ou operações.
Eventualmente, conjuntos complexos dessas sequências traduzir-se em comportamentos diversos.
As sequências de comandos podem ser pré programados ou geradas em tempo real.
Nesta implementação da arquitetura o unico comportamento implementado foi o de evitar obstaculos.
Teste de funcionamento
Comentários prévios sobre o comportamento de alguns componentes:
- Servo sg90 – todos os testes anteriores permitiram antever um péssimo comportamento do servo. Nada foi feito para mitigar a falta de exactidão do servo no posicionamento.
- Sensor de distancia VL53L1X – testes anteriores verificaram alguns devios das leituras consoante a distancia do objecto. Nada foi feito para mitigar a falta de precisão das leituras.
O robot teve o comportamento esperado. Desviou-se dos obstaculos. Mas o processo de decisão demonstra fazer escolhas erradas de forma sistemática.
No inicio não me apercebi, mas existiam três problemas maiores de programação.
- Um problema com a aplicação da direcção correcta anos motores no movimento de rotação. O robot rodava sempre para o mesmo lado independementente de o pedido indicar 90 graus ou -90 graus;
- Um problema na odometria que estava relacionado com o sinal do stepsTarget e do stepsToGo. Quando o sinal de ambos era simétrico, logo no loop inicial do movimento a orientação calculada do robot ficava errada;
- Um problema no calculo do angulo escolhido após o processo de decisão, originalmente estava: (90-angulo), passou para (angulo-90);
Melhorias a executar
- Limpar o programa de lixo
- Repensar o nome de variaveis e funções
- Documentar minimamente
- Desenvolver mais comportamentos
- Scan rotate
- Saida de beco
- Remover os HARDCODED
- Melhorar o processo de decisão
- Integração com Processing3 para fazer mapas
- Por 1 ou dois leds como indicadores da bateria
- Estudar o comportamento da bateria