Com o aproximar da competição iniciam-se as longas tardes de trabalho para ter tudo pronto a tempo.
A PS3Eye já foi colocada no robot com a altura necessária para encontrar o farol, a bateria e o carregador também já se encontram fixadas na base bem como as placas com os drivers do motor.
Falta ainda finalizar algumas placas e testar o funcionamento em conjunto bem como alguns pequenos ajustes na código que sempre acontecem nesta altura.
Em suma foi uma tarde de muito trabalho e até 15 de Maio teremos muitas mais..
Para mais informações sobre a competição microrato podem aceder ao site MicroRato.
A forma final do StuartLittle começa a ganhar forma. Nesta última atualização, foram adicionados os suportes para os seis sensores de distâncias por ultrasons. Para tal, usou-se uma calha de alúminio com a largura aproximada do HC-SR04, na qual se fizeram dois furos com o diâmetro do emissor e receptor de ultrassons no sensor. Resta agora fixar os sensores aos respetivos suportes, provávelmente pelos dois furos descritos anteriormente. Existem, contudo, suportes no mercado apropriados a este tipo de sensores. A par desta modificação, foram colocado dois sensores de chão que servirão à deteção da àrea do farol, quando o robo estiver a efectuar a sua prova. Foram colocados por baixo da chapa inferior de modo a ter-mos uma curta distância entre os LED’s emissor/receptor e o chão.
Aqui ficam algumas imagens do estado actual da base rígida do robo:
Falta apenas adicionar o poste central que suportará uma chapa de 10×10 onde se encontrarão o módulo UI e os servos bem como a câmrera PS3Eye.
Com o aproximar da competição, a estrutura física do StuartLittle começa a tomar forma. Nesta última actualização, mostramos as duas chapas de alumínio juntas assim como os motores e as duas rodas. Nesta altura já podemos ter uma ideia de como melhor posicionar os sensores de distância para detectar obstáculos , de área do farol, e dos restantes módulos. A parte superior (tudo e base dos servos) ainda está em estudo pelo que ainda não foi fixa à restante estrutura.
Para a próxima actualização contamos já ter adicionado mais módulos para começar a fazer os respectivos testes.
Cumprimentos,
Num post anterior apresentou-se o driver para cada um dos dois motores do nosso StuartLittle. Cada driver é controlado por um sinal de PWM que fará com que o motor rode com mais ou menor intensidade. Também será possível alterar o sentido de rotação dos motores. Para tal, escolheu o micro-controlador da Microchip: dsPIC33FJ versão TQFP de 44 pinos. Este dispositivo apresenta características bastante atrativas para o controlo de motores (Motor Control PWM (3 geradores de duty-Cycle) e 2’s QEI). Alguns aspectos, bem como o esquemático no eagle já estão definidos:
- Comunicação I2C com a Raspberry PI (operação como slave)
- Sinal PWM para velocidade e sinais High/Low de sentido de rotação para cada driver L298
- Interface de encoding em quadratura: Fase A e B para cada motor/roda
- LED’s de power geral e de intensidade de PWM para cada motor
O elemento menos comum nesta lista é talvez a QEI (Quadrature Encoder Interface). Este módulo (disponível em outros micro-controladores de 16 bits) permite, quando ligado a um encoder mecânico ou óptico, dar informação acerca da direção da rotação e do número de revoluções realizadas. Tipicamente, são obtidos 3 sinais: Fase A, Fase B e Index (Opcional). Se a fase A está em avanço em relação à fase B, o sentido de rotação é positivo, ou CW (para a frente) e, em caso contrário, o sentido de rotação é considerado negativo ou CCW (para trás). O sinal index toma o valor ‘1’ quando é percorrida uma revolução completa e serve para obter uma referência da posição absoluta. Os sinais em quadratura (Fase A e Fase B), podem adquirir apenas as seguintes combinações (em sequência): 01 00 10 11. Para esquematizar o funcionamento segue-se um diagrama extraído do datasheet da secção QEI do micro-Controlador:
O encoder em si seremos nós a construí-lo uma vez que os encoders comerciais ou são caros ou não cumprem as necessidades que queremos. Brevemente apresentaremos aqui a nossa solução e os resultados obtidos.
A nível de programação teremos de usar a informação dada pela QEI de modo a ter maior controlo sobre os motores no trajecto em direcção ao farol, de modo a que a velocidade efetiva do robo seja a mais aproximada da velocidade ordenada.
Cumprimentos,
O seguinte esquema estrutural exemplifica os diferentes barramentos de comunicação que serão utilizados no nosso robot:
Assim, de modo a conseguirmos comunicar com os diferentes módulos que constituem o nosso robot, é necessário que a Raspberry Pi tenha acesso ao barramento I2C.
Para esse efeito várias soluções foram colocadas em cima da mesa, de entre as quais a utilização de um outro módulo que intermediasse a comunicação entre os diferentes módulos e a Raspberry Pi. No entanto, dado que esta possui um módulo de comunicação I2C, decidimos utilizar o mesmo, aproveitando ao máximo as suas capacidades ao mesmo tempo que reduzíamos a necessidade de mais um módulo.
Para habilitar a utilização deste módulo foi necessário retirar os drivers do módulo I2C da blackList, dado que a distro que estamos a utilizar, a Raspbian “Wheezy” já traz os drivers instalados de origem. Para isso bastou correr o comando:
sudo nano /etc/modprobe.d/raspi-blacklist.conf
e adicionar um # no inicio da linha:
blacklist i2c-bcm2708
ficando:
#blacklist i2c-bcm2708
Bastando apenas por fim gravar o ficheiro.
É necessário também adicionar o módulo à lista de módulos que são iniciados a cada boot da Raspberry Pi:
sudo nano /etc/modules
Adicionar numa linha as palavras : i2c-dev e gravar o ficheiro. Assim, temos a certeza que cada vez que iniciamos a Raspberry Pi podemos utilizar o módulo I2C.
De modo a que a utilização do módulo I2C seja ainda mais facilitado, deve-se instalar o conjunto de funções I2C-tools através do comando:
sudo apt-get install i2c-tools
Depois da instalação do software necessário é altura de meter mãos à obra e testar se o módulo I2C funciona. Num próximo post mostraremos as ligações e o teste que realizamos de modo a provar o funcionamento do módulo I2C na Raspberry Pi.
Neste post iremos mostrar-vos como vamos distribuir os diferentes processos no Linux e como vamos implementar a comunicação entre eles.
A sincronização e passagem de mensagens entre os processos pode tornar-se algo complexo. Por isso decidimos usar a alternativa open-source ROS (Robot Operating System), que é um conjunto de ferramentas, algoritmos e utilidades prontos a utilizar para robótica. A linguagem de programação usada é o C++.
No nosso robot, teremos basicamente 3 processos a correr: vision, agent e hwcomm.
Vision
É o processo responsável por abrir comunicação com a câmara USB, processar a imagem e enviar uma mensagem de sincronismo para o hwcomm.
Hwcomm
Ao inicializar o processo, este abre comunicação com o canal I2C da Raspberry Pi. Durante a execução, ao receber a mensagem de sincronismo da visão, o hwcomm começa por recolher a informação de todos os sensores instalados no robô para depois preencher estruturas partilhadas e enviar uma mensagem de sincronismo com esta informação para o agent.
Agent
Neste processo encontra-se toda a Inteligência Artificial do robô. Utiliza a informação da visão e a informação dos sensores para tomar uma decisão. No fim, envia uma mensagem de sincronismo para o hwcomm, que enviará informação para os actuadores.
Implementação
Em termos de implementação específica do ROS, e usando a linguagem adequada, o que temos na prática são 3 processos que se registam como 3 nodes. O node vision publica mensagens do tipo VisionInfo.msg num topic /vision.
Os restantes nodes (agent e hwcomm) são Subscribers deste topic, sendo que o primeiro recebe a VisionInfo.msg para guardar informação referente ao farol e o segundo faz uso da mensagem apenas para fins de sincronismo e despoletar o início da leitura de todos os sensores.
O hwcomm, ao concluír a leitura de todos os sensores, publica uma mensagem HWInfo.msg no topic /hw, que contém toda a informação dos sensores. O node agent é Subscriber deste topic e utiliza a mensagem recebida para iniciar todo o tratamento de dados e tomada de decisão.
No fim da tomada de decisão, o agent publica uma mensagem AgentInfo.msg no topic /agent, que é tratado pelo node hwcomm como um conjunto de dados a enviar para os actuadores.
Conclusões
Esta abordagem torna fácil a distribuição do uso do CPU na Raspberry, que como já dissemos, é um recurso escasso e concorrido.
O ROS irá permitir ainda agilizar o processo de debugging, uma vez que nos permite, estando ligados na mesma rede da RaspberryPi, subscrever qualquer um dos tópicos acima a partir de um computador externo. Assim, torna fácil a implementação de ferramentas gráficas para, por exemplo, a visualização dos valores dos sensores.
Neste post, iremos explicar a forma como vamos usar a câmara para detectar o farol. Tendo uma câmara, poderíamos usá-la para localização absoluta no labirinto, mas não iremos fazê-lo. Vamos antes usá-la para detectar o farol, substituíndo assim os sensores infra-vermelhos convencionais.
A câmara escolhida foi a PS3Eye, uma vez que se encontra facilmente a bom preço pela net (eBay, claro está) e há drivers para unix bastante elaborados, que incluem o controlo dos diferentes parâmetros da aquisição de imagem.
No entanto, a câmara original tinha 2 problemas principais: ângulo de visão reduzido e filtro de infra-vermelhos (bloqueia os infra-vermelhos e deixa passar a luz visível).
Isto levou-nos a realizar pequenos moddings na câmara. O primeiro problema foi ultrapassado através do uso de uma lente diferente, com Field of Vision superior. O segundo foi mais complicado, tendo nós de filtrar a luz visível e deixar passar na gama IV. Para este efeito de filtragem, testámos várias soluções tendo escolhido usar um filme de fotografia antigo, virgem e revelado. O filtro foi introduzido e fixado entre o CCD e a lente e esta última acoplada ao suporte original.
Depois do hardware, vamos ao software!
O processo “vision” que irá correr na Raspberry encontra-se em estado de desenvolvimento final, já nos sendo possível detectar o farol com precisão considerável. O ângulo de visão da nova lente ronda os 100º, o qual é possível expandir através do uso de um sistema de PAN baseado num servo. Com este sistema, poderemos detectar o farol numa gama superior a 300º em torno do robô. O objectivo principal é manter o farol visível sempre que possível.
A figura seguinte é um screenshot do processo de visão, onde se pode ver a detecção farol em tempo real, com a câmara a cerca de 1 metro do farol.
Quando falamos de sistemas de tempo real, os recursos são tipicamente escassos. No que diz respeito à Raspberry, a maior limitação é mesmo o CPU, ou melhor, a sua velocidade. Torna-se fulcral a monitorização do tempo de processamento de forma a que cada ciclo do software execute numa janela temporal entre 2 frames consecutivas da câmara, para que não haja perda de frames.
O algoritmo usado para detectar o farol foi desenvolvido propositadamente para o efeito e executa em 2 a 3 milisegundos num PC razoável. Já na RaspberryPI, o tempo ronda os 20ms, o que é um tempo não desprezável. Contudo, se tomarmos a decisão de trabalhar a 15FPS (66ms/ciclo), o que é suficiente, dado o meio pouco dinâmico, este tempo é aceitável.
Para além disto, ao visualizar a janela na Raspberry, o CPU é usado para renderizar o ambiente gráfico, logo roubando ciclos para o processamento da imagem. Pensamos que ao adicionar a opção de processamento sem renderização e correr os processos sem o ambiente gráfico, o desempenho pode melhorar significativamente.
Estamos assim um passo mais próximos de concluir o nosso Stuart Little!
UPDATE 1: Depois de adicionada a opção de correr o processo de visão sem visualização, o processamento demora cerca de 1-4 ms.
Com o aumento de módulos já definidos chega então a necessidade de estabelecer o chassis do nosso robo para começar a ter uma ideia do aspecto final. A partir dos esboços efectuados já à algum tempo e de umas planificações da disposição dos módulos na base, foi feito um molde em cartão à escala real para transpor em duas chapas de alumínio. A partir deste momento baseámo-nos nas regras respectivas ao dimensionamento dos robos da edição do MicroRato 2012 que terão de ser cumpridas. Os elementos mais críticos são os 2 motores e as 2 rodas (off-road) que irão ser usadas e serão dispostas lado-a-lado. Assim, mostramos em estreia absoluta as primeiras fotografias da base:
Onde já possível a ver a existência dos suportes para cada motor DC.
Fica para trabalho futuro a inclusão de ligações (varão roscado e porcas) para unir as duas chapas, bem como a inclusão de esferas estabilizadoras para nivelar o robo.
Novo ano, novo update sobre a placa de alimentação..;)
Após um trabalho “árduo” no desenvolvimento da placa de alimentação no Eagle, trazemos aqui uma simulação, usando o eagle3D e o programa Pov-Ray, do aspecto final da placa de alimentação.
A placa será de dupla face para aumentar a área dos planos de massa de modo a aumentar a superfície de dissipação de energia para manter a temperatura do conversor dc-dc, ligado ao plano de massa através da thermal pad, em valores aceitáveis. O layout dos componentes seguiu as recomendações presentes no datasheet do conversor dc-dc tendo o cuidado de conseguir que o tamanho da placa fosse o menor possível. Na imagem podem observar-se vários conjunto de vias, furos metalizados que atravessam a placa, espalhados pela placa. Estes conjuntos de vias são importantes para partilhar a temperatura entre os planos de massa, o superior e o inferior. No final conseguiu-se uma placa de tamanho 62×32 mm o que está dentro das nossas expectativas.
O próximo passo será o fabrico da mesma e a assemblagem dos componentes na placa. Mostraremos aqui os resultados finais bem como os testes intensivos de modo a comparar as simulações iniciais e os resultados finais.
Depois de muita pesquisa acerca dos conversores dc-dc, na configuração buck (tensão de saída menor que a tensão de entrada) encontramos o ic TPS54294 da Texas Instruments que, em contraste com o escolhido anteriormente, apenas pode fornecer 2A nas duas saídas de tensão mas que, no entanto, é possível simular na ferramenta SwitcherPro™ da TI permitindo saber de antemão, através de simulação, todos os componentes necessários chegando mesmo a fornecer um esquema do circuito ideal a utilizar consoante as tensões de saída pretendidas. E como é sempre melhor seguir o conselho dos profissionais na matéria, para 3.3V e para 5V de saída do conversor este foi o esquema que a aplicação nos “presenteou”:
Explorando melhor as capacidades de simulação do programa conseguimos obter as simulações em termos de eficiência para uma gama de valores de corrente de saída bastante alargada. É de realçar a percentagem de eficiência na gama entre os 700mA e os 1500mA, pois devido à utilização da Raspberry Pi, é nesta gama que esperamos o consumo de corrente na saída de tensão de 5V.
Eficiência para 5V para uma tensão de entrada minima de 8V (linha azul) e para uma tensão de entrada máxima de 12V (linha verde):
Na gama anteriormente referida temos eficiência entre 93% e 95% o que nos parece bastante aceitável.
Para a saída de 3.3V a eficiência para uma tensão de entrada minima de 8V (linha azul) e para uma tensão de entrada máxima de 12V (linha verde):
Neste caso a corrente de saída dependerá muito do número de módulos utilizados sendo que uma estimativa aceitável seria de 500mA o que resulta numa eficiência na ordem dos 90% o que também nos parece muito aceitável.
Depois de todas estas simulações é agora altura de proceder à elaboração da placa, montagem e testes, de modo a comparar estas simulações com o desempenho real da placa.
CodeName: StuartLittle 