LusoRobótica - Robótica em Português
Robótica => Discussão geral sobre robótica => Tópico iniciado por: Marvin em 04 de Julho de 2012, 12:21
-
Tenho acompanhado os controladores de voo para quads do mercado e open source e tenho reparado que praticamente todos se baseiam na atmega328p.
A resposta mais obvia é porque a arduino praticamente se tornou num standard, mas daí a ser o melhor para uma aplicação que precisa de tantos calculos para ser efectiva e uma velocidade de processamento superior eu acho que é um pouco limitada.
Gostava de lançar a discussão dos pro's e contras's de se fazer uma controladora de quads (e hexas e uav's etc) de baixo custo baseada em tecnologia 32bits com um sistema operativo.
Será que existe interesse? Overkill?
-
Tenho acompanhado os controladores de voo para quads do mercado e open source e tenho reparado que praticamente todos se baseiam na atmega328p.
A resposta mais obvia é porque a arduino praticamente se tornou num standard, mas daí a ser o melhor para uma aplicação que precisa de tantos calculos para ser efectiva e uma velocidade de processamento superior eu acho que é um pouco limitada.
Gostava de lançar a discussão dos pro's e contras's de se fazer uma controladora de quads (e hexas e uav's etc) de baixo custo baseada em tecnologia 32bits com um sistema operativo.
Será que existe interesse? Overkill?
Tens o OpenPilot que usa um ARM de 32Bits por exemplo, entre outros. Colocar um sistema operativo (suponho que estejas a falar de algo mais completo e não por exemplo um freertos) é que pode fazer com que percas o controlo temporal das tarefas.
-
Tens o OpenPilot que usa um ARM de 32Bits por exemplo, entre outros. Colocar um sistema operativo (suponho que estejas a falar de algo mais completo e não por exemplo um freertos) é que pode fazer com que percas o controlo temporal das tarefas.
Eu conheço tambem o OpenPilot mas esta sempre sem stock e pareceu-me caro quando o vi pela 1ª vez, mas dadas as caracteristicas se calhar não é.
O sistema operativo era mais para poder correr coisas como processamento de imagem e afins mas de facto não faz muito sentido e de facto perdes o controlo temporal. Mas seria interessante em especial para permitir programar com outros tipos de linguagem e facilitar o multithreading por exemplo.
Pode ter sido um devaneio, mas imagino que se conseguissemos que um unico processador conseguisse lidar com as comunicações, gps, sensores e ainda ter memoria e processamento suficiente para outras coisas como reconhecimento de padrões etc a um custo acessivel podia ser interessante.
Mais opiniões são bem vindas.
-
A unica coisa que precisa de calculos intensivos é o IMU, e até mesmo o IMU com código inteligente num atmega328p corre a 100Hz, se pensares que uma taxa de refrescamento muito maior que isso apanhas ruido dos sensores, e muitos dos sensores nem são capazes de mandar dados novos a 100Hz, não é preciso um micro assim tão potente quanto isso.
-
A unica coisa que precisa de calculos intensivos é o IMU, e até mesmo o IMU com código inteligente num atmega328p corre a 100Hz, se pensares que uma taxa de refrescamento muito maior que isso apanhas ruido dos sensores, e muitos dos sensores nem são capazes de mandar dados novos a 100Hz, não é preciso um micro assim tão potente quanto isso.
Tens toda a razão tinha-me esquecido do proprio refrescamento dos sensores, portanto não faz muito sentido uma placa controladora mais q um atmega328p.
-
E um RB pi para isso? Com camara incorporada para análise de imagem e com IMU e as tretas todas?
Overkill?
-
E um RB pi para isso? Com camara incorporada para análise de imagem e com IMU e as tretas todas?
Overkill?
Era essa a minha ideia original, mas tal como o Metro indicou, poderiamos perder o controlo temporal das tarefas por problemas no SO.
Mas em vez de RB pi era desenvolver mesmo algo de raiz baseado que fosse apenas uma board.
Talvez o caminho seja uma board com 2 processadores distintos com funções distintas... ou não...
-
A unica coisa que precisa de calculos intensivos é o IMU, e até mesmo o IMU com código inteligente num atmega328p corre a 100Hz, se pensares que uma taxa de refrescamento muito maior que isso apanhas ruido dos sensores, e muitos dos sensores nem são capazes de mandar dados novos a 100Hz, não é preciso um micro assim tão potente quanto isso.
Não é bem assim senso, por exemplo no OpenPilot tens o controlador, se não me engano, a correr a cerca de 1khz e notas bastante diferença com refrescas os ESC's a 100hz ou 400Hz, se a informação gerada pelo controlador não fosse útil não notavas esta diferença.
-
E um RB pi para isso? Com camara incorporada para análise de imagem e com IMU e as tretas todas?
Overkill?
Era essa a minha ideia original, mas tal como o Metro indicou, poderiamos perder o controlo temporal das tarefas por problemas no SO.
Mas em vez de RB pi era desenvolver mesmo algo de raiz baseado que fosse apenas uma board.
Talvez o caminho seja uma board com 2 processadores distintos com funções distintas... ou não...
Pois provavelmente seria o que ia acontecer.... também já me tinha lembrado disso...mas não sei...
-
A unica coisa que precisa de calculos intensivos é o IMU, e até mesmo o IMU com código inteligente num atmega328p corre a 100Hz, se pensares que uma taxa de refrescamento muito maior que isso apanhas ruido dos sensores, e muitos dos sensores nem são capazes de mandar dados novos a 100Hz, não é preciso um micro assim tão potente quanto isso.
Não é bem assim senso, por exemplo no OpenPilot tens o controlador, se não me engano, a correr a cerca de 1khz e notas bastante diferença com refrescas os ESC's a 100hz ou 400Hz, se a informação gerada pelo controlador não fosse útil não notavas esta diferença.
Mas isso convem teres esc's com código diferente, porque os ESC's para RC têm filtros nas entradas que limitam a taxa de refrescamento a pouco mais de 100Hz, mas com outro código, ou com ESC's a falar por i2c tens ganhos notórios, mas isso é porque os motores te respondem mais rapidamente aos comandos.
Uma RPi a fazer processamento de imagem arrasta-se um bocadinho, que já apanhei um blog de alguem, até a ler mp3's se engasga, quanto mais com openCv..
-
Mas respondem mais rápido e de maneira diferente porque o controlo lhe manda valores diferentes, isto porque, os valores dos sensores não estão a ser os mesmos.
-
Que sensores estás a falar?
Supostamente o bleeding edge ainda é usar sensores analógicos com adc's muito bons, mas só conheço os giroscópios da AD, que custam uns 600€ cada um e é preciso usar várias pcb's para os deixar na vertical.
De resto, os sensores tipicamente têm refresh rates no máximo de 1kHz, ou pouco mais e ai apanhas mais ruido induzido pela vibração dos motores e ruido inerente ao funcionamento dos sensores MEMS, mesmo com os ardupilot e companhia, usar ESC's com outro software para responderem directamente aos comandos e não os passarem por um filtro passa baixo torna os quads/tris/hexas/octos mais estáveis e mais rápidos a responder aos comandos.
A vantagem de um micro de 32 bits, começa a ser acima de tudo o preço, que em quantidades os torna mais baratos que um micro de 8 bits, mas têm o "contra" de terem pinos muito mais fracos no que toca a limites de corrente e transientes de voltagem, são mais frágeis basicamente, e como ainda são relativamente recentes no mundo do hobby não á tanta informação.
-
Pelo que percebo vai sempre existir um bottleneck que são os sensores da IMU que dificilmente chegaram aos MHZ.
Mesmo que aceleres a velocidade de resposta dos escs em periodos de extrema turbulencia iras sempre ter problemas.
A grande questão é, será que um quad ou hex necessitam dessa precisão para uma navegação e utilização normal?
Estruturalmente um "mini" multirotor não aguenta muito a turbulencia acima de uma certa altitude mas para movimentação de precisão em espaços confinados ele proprio cria muita turbulencia por isso tenho as minhas duvidas.
Alguem já testou um openpilot?
-
Na UAVision usam um ARM 32bit + DSP de 16bit. Overkill? ;D
http://www.uavision.com/index.php?option=com_content&view=article&id=167&Itemid=27&lang=pt (http://www.uavision.com/index.php?option=com_content&view=article&id=167&Itemid=27&lang=pt)
-
Na UAVision usam um ARM 32bit + DSP de 16bit. Overkill? ;D
http://www.uavision.com/index.php?option=com_content&view=article&id=167&Itemid=27&lang=pt (http://www.uavision.com/index.php?option=com_content&view=article&id=167&Itemid=27&lang=pt)
Pois, la esta, essa board muito possivelmente é que trata tb do sinal da camara e outros sensores que não apenas os de navegação e estabilização...
mesmo assim pode ser overkill...
Numa outra nota, alguem sabe se a uavision esta a ter sucesso? ou seja tem vendas e o mercado esta a crescer?
-
Na UAVision usam um ARM 32bit + DSP de 16bit. Overkill? ;D
http://www.uavision.com/index.php?option=com_content&view=article&id=167&Itemid=27&lang=pt (http://www.uavision.com/index.php?option=com_content&view=article&id=167&Itemid=27&lang=pt)
Não fazia ideia que houvesse uma empresa a desenvolver UAV em PT, muito bom :)