Gostaria de saber se existe algum algorítimo que calcule a velocidade de um objeto através do uso de um acelerometro MPU 6050.
Obrigado.
Tags:
Acelerometros não são bons para medir velocidade devido que dependem de calibração em laboratorio.Imagine que seu veiculo tem uma velocidade básica constante de 5km/h (teoricamente,na realidade é quase impossivel).Seu sensor te retorna um valor nulo,visto que ele mede apenas asceleração ou desasceleração.Dessa maneira a velocidade depende qual o ganho do sensor numa fração do tempo.Num veiculo isso varia constantemente.Para medir velocidade,eu sempre prefiro o GPS.
Ok. Obrigado. mas meu problema é peso, não posso agregar mais peso, então teria que usar algo com isso mesmo, bem se alguem souber de algo e puderem me avisar, agradeço.
Mais uns 50 gramas e tenha uma bussola,velocimetro,altimetro com uso de GPS.
O Drone Phantom 2 consegue medir velocidade tanto no eixo X (velocidade horizontal) quanto no eixo Y (velocidade vertical).
Deve usar um acelerometro (eixo Y) e GPS (eixo X). Mas não tenho certeza.
http://labdegaragem.com/forum/topics/dji-phantom-2-quadricoptero?co...
Fernando, Seu projeto deve ser bem interessante.
Será que esses 2 links te ajudam?
http://www.i2cdevlib.com/forums/topic/312-velocity-from-acceleration/
http://www.i2cdevlib.com/forums/topic/106-get-angular-velocity-from...
Obrigado, vou verificar.
Meu problema é peso e velocidade de resposta, um gps resolve, mas creio que a resposta de velocidade não seria em tempo real, teria um delay, e o peso do sensor.
Estou pesquisando, mais uma vez agradeço.
A pergunta é antiga, mas vou dar meus 2 centavos de contribuição.
Matematicamente a velocidade de um corpo é obtido pela integração da aceleração (cálculo integral). A posição de um corpo é obtida pela integração da velocidade. (o caminho contrário seria derivando as funções...)
A formula discreta para isso seria:
Vatual = Vanterior + (Aatual-Aanterior)*(tempo entre as medições)
Ou
V = v + delta(a)*t
Essa é a matemática, PORÉM NÃO É POSSÍVEL UTILIZA-LA com tanta simplicidade. Quando calculamos a integral de uma função contínua, obtemos um resultado matematicamente adequado. Ao fazer isso de forma discreta (analisando instantaneamente em intervalos de tempo definidos - taxa de amostragem), existem erros associados pela aproximação.
Quando temos uma função que não varia muito e uma alta taxa de amostragem, as aproximações podem ser suficientes para representar a curva com bastante precisão.
Mas na eletrônica nem sempre isso é possível - algumas vezes utilizamos filtros (high band, low band, Karman filter, Bayesian filter, etc.).
Estes erros são provenientes não só da aproximação matemática, mas também podem acumular-se por ruídos no sinal, gimbal lock, conversões matemáticas, bias error, erros do próprio acelerometro, etc. Existem teses de doutorado que explicam em detalhes... mas eu paro por aqui (deixo o link abaixo).
Matematicamente, se quiséssemos registrar um posicionamento 3D (3D mapping), seria simples (EM TEORIA). Só fazer o mesmo procedimento para a velocidade, e obteríamos a posição espacial em cada um dos eixos.
Mas o erro advindo da primeira integração iria ser amplificado nesta segunda integração, e as coisas começam a piorar cada vez mais.
Este é o motivo pelo qual temos IMUs com 11DOFF (utilizamos GPS e bussola junto com acelerômetros e giroscópios) e não simplesmente um acelerometro ou um accell+gyro (6doff).
Para quem tiver mais curiosidade, deixo dois materiais para auxiliar o entendimento - e encerro aqui meus 2 centavos. O assunto é complexo e ficaríamos algum tempo discutindo todos os fatores...
https://www.cl.cam.ac.uk/research/dtg/www/files/publications/public...
Mas existem formas de implementar... só precisa saber que existem erros. Dependendo do projeto eles podem ser desprezados, para outros não...
Deixo um arquivo em anexo com informações para referência.
E aqui mais um pouco da explicação da impossibilidade de uso.
Bem-vindo a
Laboratorio de Garagem (arduino, eletrônica, robotica, hacking)
© 2024 Criado por Marcelo Rodrigues. Ativado por