Navegação com mapeamento

[Marvin]

Interessante a ideia e desde que entrei neste "mundo" que penso em como fazer com que o meu "bot" me vai patrulhar a casa sem andar aos "s"....

Tal como diversas pessoas tambem acho que a arduino nisso é bastante limitada (o tamanho da memoria é um dos muitos problemas) então eu pergunto... alguem já experimentou uma coisa destas? http://beagleboard.org/

Não é demasiado cara e tem um poder de processamento interessante, pode armazenar dados (criar o tal mapa) e comunicar por porta de serie com arduino para controlar os motores, etc... tem linux logo permite enfiar para la javas e afins... só uma ideia.

Sorry se for muito offtopic.

Agora para colocar "on topic" eu ja fiz alguns projectos utilizando windows mobile, tenho a certeza que conseguia coloca-lo a falar com a arduino sem grandes stresses (desde que tivesse o shield bluetooth) e fazer esse "mega cerebro" com o pda. So tenho de confirmar se as bibliotecas que preciso existem na framework para o windows mobile...

[Marvin]

Confirmei este fim de semana que .net compact framework (windows mobile 6) permite + - facilmente a comunicação bluetooth, portanto o emparelhamento de um pda com WM6 e uma arduino é relativamente simples.

Em teoria (pois não tenho nenhum modulo BT para ligar a arduino), é possivel ter um veiculo com boas capacidades de processamento (incluindo capacidade de processamento de imagem) de forma "simples" e barata. A framework que estou a trabalhar agora em C# vai contemplar a compact framework para desenvolvimento rapido.

[Njay]

Um simples mega168 tem imenso potencial. A principal limitação dos microcontroladores de 8 bits é a memória, embora também os haja (por exemplo AVRs ou PICs de 40 pinos) que têm interfaces de memória onde podemos ligar 64KBytes ou mais. Para memória persistente ainda podemos ligar-lhes uma EEPROM externa, dataflash ou um simples SD card. Processar video nesta máquina claro que é para esquecer; no entanto desculpem a sinceridadade, mas até que qualquer um de nós chegasse ao ponto de fazer um robot com processamento de video... a não ser, claro, que seja só usar uma aplicação já feita.

Ainda não vi nenhum robot "simples" de 2 rodas motrizes com sensores de distância ultra-som e infravermelhos e um servo para o sensor ultra-som e comunicação rádio sem fios que não se faça na boa num mega8 (metade da memória de um mega168). Este outro aqui tá giro, leva um mega8 e controlado sem fios:

http://hackaday.com/2010/03/01/biped-walks-with-eight-servos/

Um AVR num arduino é só 18x mais rápido (22.6x se o levarmos à velocidade máxima) que um ZX spectrum, e nele fizeram-se jogos bem fabulásticos em todos os aspectos. Há muito a aprender e imenso "sumo" a espremer de um compilador de C/C++. Aprendam muito bem C e um pouco da architectura das máquinas que programam que passam logo a meter o dobro das coisas no mesmo espaço.

[msaleiro]

mas até que qualquer um de nós chegasse ao ponto de fazer um robot com processamento de video...

Eu estou a fazer isso para a tese de mestrado  E sem aplicação já feita.. Código para processamento feito de raíz Quando puder e tiver alguns resultados meto por aqui qq coisa

[Marvin]

NJay concordo com tudo o que dizes, mas pelo que percebi este post falava de como aproveitar o processamento de gadjets potentes que temos para fazer coisas "fantabulasticas". 

Pelo pouco que percebo de electronica (mas estou a tentar aprender) dá para fazer imensas coisas com processadores "fracos", mas se juntar-mos uma data de pic's com pouca memoria que comuniquem entre eles, temos coisas poderosas. Filosofia do processamento distribuido levada para a electronica.

Eu, se calhar, sou dos poucos que quer fazer processamento de imagem num robot "pequeno" sem recorrer a processamento central (aka pc). O meu pda actual ja consegue fazer isso, se ele conseguir guiar um pequeno robot autonomamente ja faço coisas mto interessantes com um "simples" robot.

[Marvin]

mas até que qualquer um de nós chegasse ao ponto de fazer um robot com processamento de video...

Eu estou a fazer isso para a tese de mestrado  E sem aplicação já feita.. Código para processamento feito de raíz Quando puder e tiver alguns resultados meto por aqui qq coisa

Isso é interessante, eu durante esta semana vou colocar aqui o que ando a fazer nessa area (a.k.a. my weekend project).

Já agora, a tua tese tem alguma coisa a ver com reconhecimento facial?

[msaleiro]

Não, mas tenho um colega que ainda há uma ou duas semanas apresentou a tese dele sobre reconhecimento de expressões faciais. Consegue detectar as caras nas imagens e depois através da extracção de uma série de keypoints extraídos utilizando modelos corticais consegue reconhecer a expressão facial, indicando se a pessoa está contente, triste, zangada, surpreendida, etc. Se quiseres ter uma ideia do que ele fez podes ver aqui uma coisa resumida do que ele foi apresentar à Alemanha: http://w3.ualg.pt/%7Ejrodrig/papers_pdf/BCCN2009.pdf

Existem métodos bastante mais simples, mas no laboratório onde eu estou tentamos sempre aproximar o que fazemos a modelos biológicos, de modo que para além de processamento de imagem temos também que andar a estudar psicologia, neuropsicologia, etc. Não te aconselho seguir por aí, que isso é complexo demais para o que tu queres fazer, que provavelmente será alguma coisa simples e restrita.

Por exemplo no meu caso tenho k desenvolver um sistema de visão activa para navegação de um robot que permita dar lugar à cognição a nível da visão, ou seja, utilizar estruturas de memória a curto e longo prazo,(STM - Short Term Memory e LTM - Long Term Memory),  mapas de saliência, foco-de-atenção, etc etc. Mais uma vez será baseado em sistemas biológicos.

Mas se procurares por "face detection image processing" no google encontras muitas coisas mesmo.

A melhor maneira é começares por um filtro para detectar a cor da pele, depois podes fazer a detecção com base em matching com outras faces que tenhas em biblioteca, ou utilizares um algoritmo como o SIFT ou o SURF para extrair um conjunto de keypoints da face e depois fazer o matching com base nos keypoints. Boa sorte com isso, depois fala-nos dos teus resultados

Desculpem o offtopic...

[Marvin]

Obrigado!

Eu estou bastante interessado nessa area, talvez mesmo para seguir a area de investigação, mas ainda é cedo tenho de acabar o curso primeiro

De momento estou a usar Haar cascade (utilizando como base o OpenCV) para fazer o reconhecimento facial que por sua vez utiliza algumas das tecnicas que falas. Ja treinei alguns modelos para reconhecimento, mas não tenho tido muito sucesso devido a falta de tempo para as iterações (pois isto não é,por enquanto a minha actividade principal)

Durante esta semana ja coloco cá o projecto que ando a fazer com isto, por enquanto ainda só detecta faces e faz "tracking" das mesmas.

O teu projecto parece realmente interessante, tenho pena de ter começado tão tarde o meu curso superior, mas pode ser que ainda vá a tempo de fazer investigação nessa area.

[msaleiro]

Sim, conheço essa técnica, que também já usei o OpenCV e por acaso até a experimentei para fazer tracking da face. O OpenCV por acaso permite fazer muita coisa utilizando as funções da biblioteca
Eu por acaso tive sorte que na minha licenciatura tive uma cadeira de Processamento Digital de Imagem e no mestrado tive outra de Visao Computacional. Quanto à investigação, felizmente tive a oportunidade de ingressar no VisLab, que faz parte do pólo do Algarve do Instituto de Sistemas e Robótica É uma área muito interessante, com muito para fazer, e com relativamente pouca gente a investigar. É também uma área com grande potencial para o ramo empresarial, apesar de ainda não haver muitas empresas a trabalhar nesta área.. quem sabe um dia...

[senso]

Um simples mega168 tem imenso potencial. A principal limitação dos microcontroladores de 8 bits é a memória, embora também os haja (por exemplo AVRs ou PICs de 40 pinos) que têm interfaces de memória onde podemos ligar 64KBytes ou mais. Para memória persistente ainda podemos ligar-lhes uma EEPROM externa, dataflash ou um simples SD card. Processar video nesta máquina claro que é para esquecer; no entanto desculpem a sinceridadade, mas até que qualquer um de nós chegasse ao ponto de fazer um robot com processamento de video... a não ser, claro, que seja só usar uma aplicação já feita.

Ainda não vi nenhum robot "simples" de 2 rodas motrizes com sensores de distância ultra-som e infravermelhos e um servo para o sensor ultra-som e comunicação rádio sem fios que não se faça na boa num mega8 (metade da memória de um mega168). Este outro aqui tá giro, leva um mega8 e controlado sem fios:

http://hackaday.com/2010/03/01/biped-walks-with-eight-servos/

Um AVR num arduino é só 18x mais rápido (22.6x se o levarmos à velocidade máxima) que um ZX spectrum, e nele fizeram-se jogos bem fabulásticos em todos os aspectos. Há muito a aprender e imenso "sumo" a espremer de um compilador de C/C++. Aprendam muito bem C e um pouco da architectura das máquinas que programam que passam logo a meter o dobro das coisas no mesmo espaço.

Eu disse arduino e não avr, porque estou ciente disso, a questão é que o arduino por ser mais simples de usar que puro c num avr, perde muita potencialidade, pois só para fazer um bit wigle devido ás bit masks usadas o avr tem de fazer mais de 40 ciclos de relógio para fazer uma coisa que devia ser feita num ciclo, e para mais existe avr-gcc e incorporado com o avr studio, sendo tudo gratuito muitas pessoas podem fazer o salto de arduino para c facilmente e começam a surgir muitos bons tutoriais sobre isso na internet para facilitar as coisas ainda mais.

Coisas giras essas de que estão a falar 

[vicardosof]

Voltar ao assunto original do tópico...

Seria possível descobrir a posição apenas como se estivesse numa função.
O robot teria as coordenadas X e Y e faria cálculos matemáticos para obter a partir de um ciclo do motor, o quanto andou e para qual X ou Y se movimentou.

Isso seria algo louco ou correcto? Os cálculos matemáticos seriam suportados pelo arduino ou mais facilmente por um PC conectado com o arduino?

[ngoncalves]

"Voltar ao assunto original do tópico...

Seria possível descobrir a posição apenas como se estivesse numa função.
O robot teria as coordenadas X e Y e faria cálculos matemáticos para obter a partir de um ciclo do motor, o quanto andou e para qual X ou Y se movimentou.

Isso seria algo louco ou correcto? Os cálculos matemáticos seriam suportados pelo arduino ou mais facilmente por um PC conectado com o arduino?"

As contas dependem do tipo de locomoção que o robot usa. O mais simples, duas rodas motoras no mesmo eixo (a locomoção tipo tanque, ou em termos mais técnicos "cinemática tipo uniciclo " ou "unicycle drive") o modelo é:

    x_1    = ((v_d + v_e)/2 * cos(theta))*dt + x_0
    y_1    = ((v_d + v_e)/2 * sin(theta))*dt + x_0
    theta_1 = ((vd - v_e)/D)*dt + theta_0

   em que:

      x_0 é a posição inicial em x
     
      y_0 é a posição inicial em y
     
      dt é intervalo de tempo entre duas medidas consecutivas
     
       x_1 e y_1 são as novas posições do robot
     
      theta é a orientação do robot
     
      v_e é a velocidade da roda esquerda (em m/s)
     
      v_d é a velocidade da roda direita (em m/s)
 
       D é o largura do eixo
 
            As equações têm esta forma, mas é possível que tenham gralhas (sinais trocados ou falta de constantes)

    A única dificuldade para o arduino seria calcular o seno e o coseno, mas isso pode-se ter numa tabela. Se o robot andar devagar (algumas dezenas de cm/s) então o Arduino não deve ter dificuldade em fazer estas contas.

[senso]

Usando esse sistema, o melhor para manter um erro baixo será usar encoders em cada motor para o arduino saber exactamente quanto é que cada roda girou, mas para pequenas distâncias os erros acumulados devem ser relativamente baixos

[ngoncalves]

Sim, esta forma de calcular a posição do robot está sujeita à acumulação de erros na medição das velocidades. Também dá problemas se as rodas deslizarem (isto é patinarem).

Uma forma simples de evitar estes problemas é rodar as rodas sempre a uma velocidade constante (basta apenas ligar/desligar os motores). Mas claro, o robot vai andar um bocado aos solavancos.

Uma outra forma é colocar um sonar a apontar para o chão a um ângulo de 45º e a uma altura apropriada (uns 40 cms). A velocidade do robot pode ser estimada através do efeito de doppler, porque a frequência da onda de sonar recebida vai variar consoante a velocidade do robot. Novamente o arduino consegue fazer estas contas utilizando uma tabela (x desvio da frequência -> y velocidade de m/s). Mas para fazer as correcções a coisa já fica muito mais complicada. Aqui o melhor é enviar para o PC os dados e deixá-lo fazer as contas.

[microbyte]

E porque não utilizar o sistema óptico de um rato?