O DAMI-M1 teve algumas alterações no hardware e começou a ter o esqueleto do software que vai controlar os movimentos do robot.
Hardware
As alterações ao hardware, em parte já estavam presentes. O servo e o sensor de distancia já lá estavam montados à algum tempo. Mas o suporte do sensor ainda estava feito numa calha plástica e os fios de ambos ainda não estavam ligados.
O suporte para um segundo Nano também estava presente. Faltava apenas encaixar o Arduino no sítio.
A outra alteração foi o desenvolvimento de uns novos suportes para os motores dc com o encoder sj01.
A aplicação dos motores com os suportes antigos, já impressos em 3D, não estava adequada.
Como o encoder exige um espaço entre o motor e a base da aplicação, esse espaço não estava bem preenchido com a solução de recurso (um apoio extra impresso a pressa e mal dimensionado) o motor oscilava, e por outro lado começou a fazer um barulho estranho. Por outro lado, estava demasiado grosso e a cabeça do parafuso tocava na roda.
Por isso imprimi em 3D um novo tipo de suporte para aplicar do lado de fora, e que depois de aplicado se revelou a medida e também , talvez devido ao melhor aperto , eliminou o ruído. O parafuso continua perigosamente perto da roda mas pelos vistos já não toca. Em ultima instância pode-se limar a cabeça do parafuso.
Como preparação para dar ao DAMI-M1 uma forma para saber a que distancia se encontra das coisas, instalei um servo SG90 e um sensor de distancia laser VL53L0X da pololu. Para aplicar sensor VL53L0X no SG90 imprimi em 3D o suporte para o fixar.
Neste momento, o servo e o sensor de distancia estão apenas a fazer figura. Antes de integrar os novos componentes na programação irei fazer uma análise dos metodos de controlo, do seu comportamento e dos métodos disponiveis para contornar ou minimizar os seus problemas.
Primeiras observações registadas
Quando liquei o arduino A (o que já existia) por USB ao computador, sem ter a alimentação do robot ligada, o segundo arduino entra em reset consecutivos. Parece que a alimentação do arduino A, sai pelo vin e entra no circuito de alimentação.
Provavelmente deveria por um diodo na entrada do vin de cada arduino para impedir o fluxo de corrente do arduino para o circuito, ou colocar jumpers para ligar e desligar a alimentação do arduino.
Não sei se nao será melhor colocar uma especie de pala superior e eventualmente lateral que evite a poeira.
O cabo da alimentação da BARD está demasiado grande.
Software
O esqueleto do software que vai controlar os movimentos do robot começou a ser construido com base na que considerei a melhor solução na avaliação de abordagens ao controlo de motores DC em robots 2WD de propulsão diferencial, na qual o controlo de direção e da velocidade são ajustadas por PID, e cujo comportamento pode ser observado no video abaixo.
Para o efeito, desenvolvi um programa que permite sequenciar uma serie de movimentos básicos (translações e rotações), introduzindo pelo caminho algumas carateristicas novas, em particular:
- Coeficientes especiais (adaptativos) do PID aplicados ao ajuste da direcção durante a fase do arranque.
- Possibilidade de acelerar e desacelerar pelo controlo do setPoint do PID da velocidade (numero de pulsos por speedPidTimeSample)
- Aceleração inicial com base num maximo de N passos (definivel), com incrementos de 1 pulso por passo, e com N computações por passo
- Retardamento da aceleração inicial de modo a que exista tempo para o ajuste da direcção durante a fase de arranque
- Desaceleração automática por calculo da distancia adequada (relativamente ao destino) face a velocidade actual e desaceleração prevista, usando a equação de torricelli (também deve dar para calcular um limite maximo de velocidade face a distancia total a precorrer)
No que se refere a capacidade de execução de uma sequência de movimentos o programa utiliza o seguinte esquema de armazenamento e códigos de comandos (movimentos).
Estão implementados os movimentos de rotação e translação simples com os seguintes códigos:
- Rotação à esquerda – 31
- Rotação à direita – 32
- Translação em frente – 41
- Translação à retaguarda – 42
A programação é armazenada num array com bodyMoveCmdSequenceMax de elementos com a seguinte estrutura:
typedef struct {
unsigned int cmd;
unsigned long distance; // distance in mm/cm (depends on resolution), angles on degrees
byte setPointStart; // pulses per pidSampleTime
byte setPointTarget; // 5=2,10=4,15=6,20=8,25=10,40=16,60=24,80=32 cm/s
} bodyMoveCmdType;
bodyMoveCmdSequence[] = {{41, 2000, 0, 60}, {31, 180, 10, 10}, {41, 2000, 0, 0}, {32, 180, 0, 0}};
Os comandos são executados sequencialmente um após outro, sem interrupção.
Executando várias vezes o programa sequenciador no robot (sem estar ligado ao PC) para avaliar a qualidade do movimento, notei pela simples observação do movimento do robot que o movimento não era suficientemente retilino. Aparentava curvar ligeiramente para a direita (o que significava a roda esquerda andar mais).
Para obter dados necessários para validar a percepção, liguei de novo o robot ao pc, executei o programa que move o robot para a frente 2M e copiei os dados do monitor serie para o excel para fazer o seguinte grafico.
Suportes impressos em 3D
Suporte para motores dc 120:1 com encoder SJ01
Suporte do VL53L0X pololu para SG90