Tr3s µMouse - Micromouse

[senso]

Fantástico!!!

Só uma pequena duvida, costumo ver filmes desses bichinhos a voar pelos labirintos, será que um atmega tem capacidade de processamento e ram para guardar o labirinto?

[tr3s]

Então não tem! Tem e sobra, conheces projectos como ArduPilot?
São projectos baseados no Arduino (usam o Atmega) para fazer autopilots! Um autopilot precisa de muito mais processamento do que um micromouse!

[senso]

Sim, conheço, e ando até com ideias de montar um quadcopter lá para as férias de verão, são estupidamente interessantes.
Acho que estou sempre a sobre-estimar o poder de processamento de um micro-controlador eheh, pensei é que precisasses de mais ram para o labirinto mas isso depende muito da inteligência que tens para criar algoritmos de mapeamento imagino eu.

[ptrobotics]

Está excelente, bom trabalho!

Já pensaste em colocar um simples optocoplador na roda de forma a contar as revoluções ou um hall efect sensor?
Não será muito mais dispendioso.

[pedro12]

Muito bom, fico à espera de ir vendo o avanço do projecto aqui!!!

Parabéns !!!

[tr3s]

Pois é, é muito fácil cairmos nesse tipo de pensamentos! 
Há algoritmos muito bons para este tipo de "bichinhos", deixo-te aqui com um link bem interessante:

http://en.wikipedia.org/wiki/A-star_search_algorithm



PTrobotics, se for fazível estou interessado em ver disso. Podes dar-me mais orientações sobre esse assunto? 

[zordlyon]

Pois é, é muito fácil cairmos nesse tipo de pensamentos! 
Há algoritmos muito bons para este tipo de "bichinhos", deixo-te aqui com um link bem interessante:

http://en.wikipedia.org/wiki/A-star_search_algorithm



PTrobotics, se for fazível estou interessado em ver disso. Podes dar-me mais orientações sobre esse assunto? 

Ja estudei o Djikstra em profundidade, mas este algoritmo não conhecia e está interessante...


Cumprimentos..

[ptrobotics]

Algumas ideias:

http://en.wikipedia.org/wiki/Rotary_encoder
http://www.seattlerobotics.org/encoder/200010/dead_reckoning_article.html
http://www.sparkfun.com/commerce/product_info.php?products_id=9208
http://www.parallax.com/Store/Sensors/PressureFlexRPM/tabid/177/CategoryID/52/List/0/SortField/0/Level/a/ProductID/90/Default.aspx
http://www.active-robots.com/products/motorsandwheels/wheel-encoders.shtml
http://www.societyofrobots.com/sensors_encoder.shtml

Desculpem os link's, não é SPAM, é bibliografia!

[metRo_]

Quando aos DC com encoders o TigPT que se chegue à frente e isto porquê, o projecto está bem encaminhado, já há trabalho feito e por isso não será desperdício!

Em relação às PCB's há quem tenha feito por cá aqui: http://lusorobotica.com/index.php?topic=3006.msg31318#msg31318 não é tão profissional mas para o que queres parece-me suficiente!

Caso ainda não tenhas visto pesquisa por SLAM na net!

[tr3s]

ptrobotics, muito obrigado pelos links! 
Já tinha analisado alguns até mesmo por sugestão do TigPT. No entanto, desconhecia estes sensores Hall Effect da Melexis! Vão de encontro ao que preciso e procuro! 

Vou já estudar esta opçao! Obrigadíssmo ptrobotics!



metRo_, bem haja  !
Obrigado pelas tuas sugestões. Já fui contactado pelo HUGU e neste momento aguardo uma resposta.
Em relação ao SLAM, obrigado por me lembrares! Já tinha visto há algum tempo atras e não conseguia lembrar-me do nome, pesquisava mas não conseguia chegar lá!

[tr3s]

Bem, estive a investigar o sensor de efeito Hall da Melexis e parece-me bom.
No entanto tenho dúvidas quanto ao seu fincionamento devido à proximidade das rodas, com o motor e à proximidade a que iria estar o iman do sensor. Até mesmo interferencias que este possa ter com o motor. :S

Sinto  que a questão do encoder volta a ficar de pé...

[senso]

Não dá para usar um encoder optico?

[tr3s]

Não dá para usar um encoder optico?

O grande problema do encoder optico é mesmo o espaço que necessita para funcionar.

[msaleiro]

Tr3s, porque não integrar 2 vezes o sinal vindo do acelerómetro para obter a posição? existe uma application note da freescale com código em C já feito e tudo, e existe um video de demonstração no youtube em que fizeram umas espécie de um "rato aéreo" para computador. Já há muito tempo que quero experimentar mas nunca tive tempo de o fazer.. é provável que ao fim de algum tempo acumule erro, mas sempre era um sistema de posicionamento inercial e não ia ser afectado por eventuais deslizes das rodas ou falhas nos encoders ( não estou a dizer k é melhor ou pior.. erros todos os sistemas têm ). Tendo em conta que acelerómetro e giroscópio ja tu tens no robot, se resultar até ficas com o sistema de odometria sem acrescentar mais nada...

Já agora.. eventuais problemas poderiam surgir na operação do robot em planos inclinados..

[metRo_]

Sinto  que a questão do encoder volta a ficar de pé...

Se não me engano o nome encoder não restringe tecnologia por isso até agora falou-se sempre de encoder :p

Tr3s, porque não integrar 2 vezes o sinal vindo do acelerómetro para obter a posição?

Isto tem muitos erros, se com o encoder não é perfeito com isto muito menos, e depois ao integrares também integras o ruído o que te aumenta ainda mais o ruído. Normalmente isto só é usado de para completar uma solução com encoders.