DAMI-M3 v1.0.0

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.

Visão superior do robot
Visão geral do robot

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.

Visão do terceiro chassi

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

BARD antiga
BARD do M1 com as alterações

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