TODOPIC
Mecatrónica => UAV => Mensaje iniciado por: PCCM en 11 de Junio de 2013, 14:39:33
-
Buenas, Lo que intento realizar es medir desplazamiento de un UAV por medio de acelerómetros, tengo la opción de hacerlo con GPS, pero intento independizarme de datos externos, ya que solo quiero medir desplazamiento(no posición).
Las consideraciones que estoy tomando es que el vuelo sea de aproximadamente 3 minutos, con aceleraciones de hasta 2g. El error acumulativo debido a la integración, sensado, calculo, etc. Deben ser para esos 3 minutos como máximo +-200 metros, si fuera menos mucho mejor.
Debido a la falta de instrumentos para acelerar y probar que los cálculos son correctos, recurro a ustedes, ya que estoy suponiendo comportamientos los cuales no se si son correctos.
Tengo un acelerómetro de 3 ejes, el MPU-9150, tiene más características pero me centro en el acelerómetro.
(http://www.sensorsmag.com/files/sensor/nodes/2012/9417/Invensense_1201-rev.jpg)
Ojo: En siguiente análisis es eliminando el efecto de la aceleración debido a la fuerza de gravedad.
En la siguiente imagen, Descompongo el sensor en los acelerómetros de cada eje para entenderlo mejor:
Aunque el dibujo no es perfecto, los 3 son perpendiculares entre si. Además la nariz del UAV esta en dirección del eje X.
(http://imageshack.us/a/img109/3127/acelejex.jpg)
Donde Xt, Yt,Zt es el eje de la tierra y Xc, Yc, Zc son los ejes del cuerpo
Primero de forma IDEAL si el UAV se dirige de forma horizontal(eje x), fácilmente adquiero la aceleración en el eje X, integro 2 veces y obtengo el desplazamiento, en este caso recorrido=desplazamiento, ya que no realiza ningún movimiento en cabeceo ni guiñada.
Pero cuando el UAV realiza maniobras de guiñada o cabeceo es cuando se me complica, para obtener el desplazamiento en el eje de la tierra, tengo que transformar las aceleraciones del eje del cuerpo al eje de la tierra, para ello utilizo la matriz de rotación para los 3 ejes.
(http://imageshack.us/a/img826/6906/matrizderotacion.jpg)
Ya tengo los ángulos de cabeceo, banqueo y guiñada, el problema es hallar las aceleraciones respecto al cuerpo, ademas estas aceleraciones respecto al cuerpo me sirven para otro sistema de táctica de guiado, por eso la importancia de hallarlos.
Debido a que por ejemplo la aceleración del eje X también depende de la aceleración en el eje Z(debido a la matriz de rotación), un error grande en la lectura de la aceleración en el eje Z, involucraría error en el resultado. calculando la aceleración en el eje X, considerando banqueo y guiñada cero:
(http://imageshack.us/a/img838/9015/acelejexrotado.jpg)
(http://imageshack.us/a/img59/5095/forabreviada.jpg)
Pero como nada es perfecto , imagínense que he puesto el sensor con un angulo de desviación lamda(el de morado) respecto al eje de translación.
(http://imageshack.us/a/img268/9041/acelejexderiva.jpg)
Entonces también el acelerómetro del eje Z estará desviado un angulo lamba.
Y la pregunta es:
Como afecta esta aceleración al acelerómetro de eje Z, el acelerómetro del eje Z me dará la misma aceleración que está censando el eje X?, me dá una aceleración muy despreciable?
Tengo mucha duda en eso, ya que al hacer pruebas acelerándolo en el eje X y dándole diversos ángulos, me daba aprox los mismos valores de aceleración(como dije la aceleración lo hice de forma manual con empujones).Por lo tanto con esa desviación de angulo la aceleración del eje Z me dará el mismo valor que la aceleración del eje X, lo cual sería un gran error en el calculo.
Espero me hayan entendido y puedan ayudarme.
Gracias.
-
Creo haber entendido tu planteamiento y dejame decirte que el sensor que tienes puede hacer todos esos cálculos haciendo uso de:
Acelerometro de 3 ejes
Giroscopio de 3 ejes
Compas
con la unidad que tiene integrada DMP (digital motion processor)
creo que los cálculos que tienes son para yaw pitch and roll, esto lo puedes obtener haciendo uso del DMP y por el momento hay varias opciones para emplearlo en tu proyecto así como diferentes plataformas
tu problema se soluciona haciendo uso no solo del acelerometro, si no empleando un giroscopio y mejor aun el compás magnético cosas que ya tienes en el mismo chip, tienes razón tendrás error cuando el acelerometro este inclinado pero en esa situación haces uso del giroscopio ya que este esta diseñado para medir ángulos y no aceleraciones, lo cual implica modificar tus algoritmos, te diría cuales son pero no los tengo en este momento pero he visto en otros foros que los utilizan
Y respecto a tu pregunta, si inclinas el acelerometro en X y la aceleración sigue solo en el eje X la componente total de aceleración estará en X y en Z, tendrías que usar funciones trigonométricas para obtener el total de la aceleración como en los cursos de física diagramas de cuerpo libre creo que se llaman, no recuerdo bien, si las aceleraciones en X y en Y son iguales es porque esta inclinado un angulo de 45º respecto a la aceleración aplicada pero en otros casos deberían de ser diferentes
-
Gracias por tu respuesta, también leí tu comentario en otro tema acerca del mpu6050.
Ahora me estoy concentrando primero en el cálculo lo más exacto posible de los ángulos de euler o actitud(no entiendo bien la diferencia, según entiendo se diferencia solo por el eje de referencia), ya que los cálculos de posición y velocidad salen a partir de ellos.
Cambié de sensores a una combinación del MPU6050(giroscopio y acelerómetro) con el HMC5883L, debido a que este magnetómetro es 1 grado más preciso que el del mpu9150(según pruebas, obteniendo el azimut con solo hallar el arco tangente de la componente "Y" entre la componente "X", sin hacer ningún filtro).
Primero intente integrar(método del trapecio) la velocidad de los ángulos de euler a partir de la siguiente fórmula:
(http://imageshack.us/a/img845/7392/vww7.png)
donde p,q,r son las lecturas del giróscopio en los ejes de banqueo,cabeceo y guiñada respectivamente.
Partiendo de un eje de referencia de 0 grados para todos los ángulos, el resultado es que después de unos aprox. 20 movimientos(30 segundos aprox) de cabeceo y dejándolo en su posición inicial(0 grados para todo), me daba 20 grados para el banqueo, -5 grados para el cabeceo y 15 grados de guiñada. Pensando que la exactitud para hallar la actitud era muy inexacta, ya que en muchos temas dicen que se debe a la deriva, pero nadie dice en cuanto tiempo o en cuantos movimientos, solo dicen en poco tiempo.
Alguien sabe el tiempo en movimiento para el cual el cálculo de la actitud con solo el giroscopio con las características del mpu6050 diverge?
Por lo que me dices Vtronic, creo que estoy cometiendo muchos errores en la adquisición y mejor sería utilizar el DMP del integrado.
Además la prueba lo hice sin activar el FIFO, y haber sino me equivoco:
El giroscopio lo he configurado según el datasheet con un filtro pasa bajo de 42Hz el cual demora aprox 5ms, osea idealmente debería muestrear cada 5ms? ojo, no tengo conectada la pata de interrupción del sensor. El bucle de mi programa demora aprox 20 ms, osea estaría perdiendo casi 3 muestras por bucle(ya que 1 si lo leo), lo cual en un segundo hago 50 bucles, perdiendo información de 150 muestras en 1 segundo?
Haber si alguien brinda información de como utilizar el DMP.
Gracias.
-
en Youtube puedes encontrar videos en los cuales ya tienen el DMP funcionando y te puedes guiar para saber si en verdad te va a servir, Yo por el momento solo he activado el DMP con acelerometro y giroscopio
con lo del delay en los filtros no he leído mucho así que no te sabría decir con certeza
el DMP lo puedes activar de varias formas usando diferentes herramientas, por el momento he visto que hay librerías hechas para hacerlo funcionar en Arduino y en el MSP-EXP430G2 LaunchPad pero seguro hay mas librerías para otras plataformas, cuando suba un video lo comparto para que puedas evaluar, por el momento haré las pruebas de cabeceo porque no había pensado en eso y si afecta en el proyecto que estoy desarrollando
-
que resultados tuviste con la activación del DMP?, cuando me dices que lo activaste con el acelerómetro y giroscopo te refieres a la fusión de ellos obteniendo los cuaterniones, u obteniendo los datos en crudo nomas. si obtuviste los cuaterniones has hecho la prueba de como te da los ángulos cuando realizas aceleraciones?, osea si se distorciona?, ya que según he leído el DMP utiliza el filtro Mahony el cual hace la fusión de estos sensores para obtener los cuaterniones.
Lo malo de esto es que ante aceleraciones por un periodo largo de tiempo y grandes aceleraciones. el filtro tendrá una referencia del acelerometro con datos errados durante un periodo largo, el cual hará que me de mal el dato de la actitud.
Intente hacer funcionar el DMP para que me entregue los cuaterniones con varios resultados negativos para mi aplicación. debido a que utilizo un dspic33fj32mc204 y no un arduino modifique el código de este lugar:
https://github.com/bzerk/MPU6050_DMP_6_axis_demo_/blob/master/MPU6050_DMP_6_axis_demo_.pde
El resultado fue que funcionaba bien de ves en cuando, no culpo al DMP, derepente es por ciertas configuraciones que estan mal dadas, pero debido a que solo quería ver si me servia hice las pruebas en las veces que funcionaba bien, comportándose como dije antes, que ante aceleraciones largas te da mucha deriva de angulo.
Además el filtro es una caja cerrada, osea me refiero a modificarlo lo cual es diferente a configurarlo, lo cual tampoco se si se podrá.
En resumen llegue a la conclusión que es mejor utilizar mi propio algoritmo, ya que obligatoriamente si quiero obtener la aceleracion de la gravedad para obtener el pitch y roll y apartir de ello corregir al giroscopio, necesito eliminar las aceleraciones indeseadas debido al movimiento lineal, para ello voy a usar un sensor de velocidad, todo ello conlleva a tener los datos en crudo del acelerometro, por ello creo que no me sirve el DMP, pero si lo recomiendo para otros tipos de aplicaciones que no involucren mis problemas, debido a la única ventaja que le veo es de no tener que realizar el algoritmo en tu procesador.
Adjunto el archivo en mplab de mi codigo para el DMP en el DSPIC en el caso alguien quiera probarlo,(te da en angulos de euler, cabeceo, guiñada y banqueo respectivamente), tuve que tranformarlo a partir de los cuaterniones para entender mejor como rotaba:
http://www.4shared.com/rar/KpllR-8Z/dmp.html
-
Hola PCCM.
Una pregunta. Ya que has tenido que pasar la tarea de "reescribir" a tu código modificando otro, ¿por qué no has elegido como punto de partida el que entrega el fabricante? ¿por qué has elegido esa librería del 2011? Entiendo que el código que da el fabricante para el uso del DMP está más actualizado (marzo del 2013) y supongo que estará más optimizado y mejorado que las antiguas versiones.
-
Seguro te referirás a estos archivos:
http://www.invensense.com/developers/index.php?_r=downloads
Tienes razón, mi primer problema fue la dificultad de entenderlo, ya que no sabía como se comía eso de DMP, si es que se programaba, se activaba, configura,etc.
también en el ultimo archivo de los archivos para descargar de invensense hay un link para descargar un código para un pic24,todo bacán te dan archivos actualizados, pero el único archivo fácil de entender fue lo que puse en el link. además mi objetivo era saber como funciona y si realmente me serviría. me tomó todo un día completo entender el código y modificarlo para el dspic33..
y por las conclusiones que explique en mi anterior comentario la desventaja que se tiene para mí utilizar el DMP con salida sea en cuaterniones o euler.
A menos que me esté equivocando en el funcionamiento del filtro en el DMP.
julioJF si has trabajado con el DMP con cuaterniones o euler, has visto ese problema que le pregunto a Vtronic?
-
Que tal, si, me refiero a la fusion con salida en cuaterniones, la aplicación en la que esta actualmente no contiene aceleraciones prolongadas es mas como una especie de pendulo Yo busco mas precisión en movimiento cortos y no prolongados
al principio se distorcionaban tenia un drift bastante grande utilizando el mismo link que tienes de la libreria de arduino pero viendo que no tenia los resultados esperados me enfoque en los archivos de ingenieria inversa que estan en
http://www.i2cdevlib.com/devices/mpu6050#captures
y a partir de ahi saque la pequeña libreria con lo cual elimine el drift que tenia otra cosa que hay que tomar en cuenta es que la calibración no esta incluida en el link que tienes, asi que tienes que dejar el sensor en reposo durante unos 10 a 20 segundos, pueden ser mas, para que auto calibración se realize y se quede estable, lo que puedes hacer es revisar en tu libreria es la comunicación I2C, si algo pude apreciar es que debe ser algo precisa para que todo funcione como debe ser
para el link que contiene el codigo para pic24 se tiene que comprar la tarjeta de microchip :? si no estoy mal
el codigo proporcionado por el fabricante es bastante completo hay opciones para que la salida se de en Euler y no en cuaterniones, es mas estable y el MPU-6050 tambien se usa para controlar los quadrotor, pero seria de profundizar en el tema del DMP
puedo hacer pruebas con lo que tengo pero tengo duda en como hacer pruebas con aceleración grandes y constante por largos periodos de tiempo, lo que puedo agregar es que a como lo tengo funcionando puedo medir cambios muy pero muy pequeños en inclinación
-
Hola, yo ya he hecho alguna prueba con el DMP, pero creo que no es posible que te entregue los ángulos de Euler, creo que te entrega los cuaterniones. En cuanto al drift después de estar moviendo mucho el chip, parece que mejora con la última versión, aunque todavía no lo he comparado. A ver si intento compararlos y os lo comento.
PCCM, ¿te refieres a cómo responde el DMP tras realizar aceleraciones bruscas y un período largo? todavía no he realizado muchas pruebas, intentaré hacerlas y te comento cómo salen. De todas formas yo no utilizo los datos en crudo del acelerómetro y del giróscopo, sólo utilizo los cuaterniones que me da el DMP. De todas maneras cada proyecto tendrá sus exigencias, y lo mejor es probarlo en las condiciones particulares. Yo creo que responde bastante bien pero no sé como será llevándolo en un coche de rally por ejemplo, aunque sería muy interesante hacerlo. Cuando haga más pruebas te cuento.
-
Gracias por responder.
Ya resolví mi duda, son de 3 fuentes.
La primera fuente es de la compañia que vende IMU, INS,INS/GPS ... XSENS, les dejo un extracto del correo:
"The best orientation accuracy is achieved when ‘quasi-stationary’ which means that the average acceleration is zero over a short period of time. For your application this is not true, as the UAV will accelerate for longer periods of time. Then the acceleration of the UAV will be undistinguishable from gravity, which will introduce the error in roll and pitch. The higher the accelerations the bigger the error will be."
------------------------------------------------------------------------------------------------------
La segunda fuente es de una persona que hace UAVs:
"El problema de grandes aceleraciones lo resuelvo con los sensores de velocidad, que con el vector velocidad y los giroscopos corrijo las aceleraciones centrifugas de la señal de los acelerómetros y se me queda prácticamente sólo la gravedad. Si no le conectas los sensores de velocidad pasa lo q dices. Eso lo probé a 500km/h durante una aproximación de un vuelo y como no podía sacar un tubo pitot al exterior en los giros fuertes se notaba"
les dejo en link, sus videos son interesantes, en este video , le pregunto, esta en los comentarios: ---------------------------------------------------------------------------------------
la tercera fuente es de un informe de un doctor de la universidad de bristol:
http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/
En la pagina, esta el informe explicando su algoritmo, además del codigo en C y matlab, en estos codigos se puede comparar el codigo de el con el de Mahony.
En la pagina 24, seccion "Discussion", a partir de la 5ta linea dice:
"In many applications it can be assumed that accelerations due to motion and local magnetic
distortions are present for only short periods of time. Therefore the magnitude of the fi lter
gain B may be chosen low enough that the divergence caused by the erroneous gravitational
and magnetic eld observations is reduced to an acceptable level over the period. The
minimum acceptable value of B is limited by the gyroscope measurement error. In many
applications it may be bene cial to use dynamic values of gains B and C . This will the
infuence accelerometers and magnetometers have on the estimated orientation to be reduced
during potential problematic periods; for example, when large accelerations are detected."
Aqui me dice que para este problema, con su algoritmo puedo hacer que su parametro B sea dinamico y reducirlo cuando tenga largas aceleraciones.
Lo bueno es que te da ya listo para usar, y también opción para manejar los datos en crudo, ya que el filtro se coloca en el microprocesador. otra ventaja que dice en su informe es que se puede trabajar a bajas frecuencias de muestreo a diferencia de los otros algoritmos.
Bien me queda probar este algoritmo o hacerlo como lo que dice la segunda fuente, corregirlo con un sensor de velocidad(tubo de pitot).
Vtronic para el obtener el codigo fuente del pic24 con DMP solo se tiene que seguir los pasos que estan en la parte inferior de la pagina, pero no lo recomiendo porque ese si está muy dificil de interpretar.
-
Lo había pasado por alto gracias y buena investigación la que tienes, muy buenos datos.
-
Hola Vtronic y PCCM. Como veo que entendéis del tema os pregunto a vosotros, que yo ando muy verde en esto y estoy bastante olvidado de las matemáticas.
Estoy haciendo una aplicación para un robot donde quiero saber su posición respecto al eje Z (el eje vertical). Supongo que para eso lo mejor sería tener un magnetómetro, pero me han dicho que son muy lentos y no dispongo de ninguno para probarlo. Me gustaría tener un período de actualización, como mínimo de 10ms. Tengo entendido que por medio de un acelerómetro y/o giroscopio también se puede hacer. Dispongo de un MPU6050. He conseguido calcular los ángulos X e Y haciendo estos cálculos con las lecturas del acelerómetro (copio directamente el código C):
ACCEL_XANGLE = 57.2958*atan((float)ACCEL_YOUT/ sqrt(pow((float)ACCEL_ZOUT,2)+pow((float)ACCEL_XOUT,2)));
ACCEL_YANGLE = 57.2958*atan((float)-ACCEL_XOUT/ sqrt(pow((float)ACCEL_ZOUT,2)+pow((float)ACCEL_YOUT,2)));
El problema es que realmente esos ángulos no me sirven para esta aplicación y querría el Z. Buscando encontré una página donde también daba una fórmula para calcularlo:
ACCEL_ZANGLE = 57.2958*atan(sqrt(pow((float)ACCEL_YOUT,2)+pow((float)ACCEL_XOUT,2))/ACCEL_ZOUT);
Lo he probado y no es nada de lo que busco. No sé muy bien que ángulo me está dando pero no es un giro sobre la vertical.
Realmente no estoy seguro de si se puede llegar a calcular con un acelerómetro de 3 ejes, ya que el eje Z que busco coincide con la gravedad... (perdonadme si digo tonterías, pero tengo las matemáticas muy oxidadas).
Si con el acelerómetro no se puede calcular, ¿debería hacerse con el giroscopio? Me podríais decir qué cálculos hay que hacer? Si es posible que no sean matrices, algo más fácil de entender y aplicar. Lo que comentáis de aceleraciones prolongadas, en mi caso creo que no debería afectarme, pues el robot debería tomar las curvas a una velocidad más o menos constante.
Un saludo.
Perdón, se me olvidaba: el micro que estoy usando es un dsPIC33EP256MU806 y programo en C desde el MPLABX 1.85 y XC16 1.11.
-
Que tal, pues con los calculos no los tengo a la mano por el momento, pero creo que seria mejor calcularlo con el giroscopio
-
Lo que entiendo es que quieres calcular el angulo cuando giras el eje vertical, el cual es aproximadamente paralelo al eje de la gravedad(normalmente llamado azimut, y calculado a partir del norte magnetico), ello lo puedes hacer con un magnetómetro y no es para nada lento, el MPU9150 tiene un magnetometro cuya demora en actualización es aprox cada 10ms si bien no recuerdo, pero tiene una demora considerable, por esto y por otras razones de presición decidi separar el magnetómetro, usando el HMC5883L de forma individual con el MPU6050.
el HMC5883 no necesita un retardo para actualizar los datos, aunque en su datasheet diga lo contrario, en las pruebas lo puedo leer a velocidad del bucle de mi programa.caso contrario con el MPU9150 como mencione antes ya que este tenias que esperar 10ms o sino te leia datos raros.
Con el MPU6050 que tienes no vas a poder calcular el azimut correctamente, ya que el unico sensor que te sirve es el giroscopio, puedes integrar la velocidad angular que te da en el eje Z. y te da el angulo, pero el gran problema es la deriva producida por tal sensor que con el tiempo es acumulativo y el error crecera indefinidamente.
Por ello los giroscopios de tecnologia MENS nunca se usan solos para el calculo de un angulo, sino se complementan con otro tipo de sensores, el cual es como te dije anteriormente es el magnetómetro, la desventaja del magnetómetro es su impresición ya que por ejemplo el HMC5883 tiene una desviacion estandar de 0.5 lo que significa que si lo dejas estatico en un angulo por ejemplo de 50 grados, te va a sensar variando entre 50.5 y 49.5, el MPU9150 su magnetometro tiene una desviacion estandar de 1.
Esa impresión es corregida por el giroscopio, ya que para tiempos cortos es muy preciso, tal fusión se realiza por diversos filtros existentes, los más conocidos que se son el filtro complementario(facil de implementar) y Kalman(un poco mas complejo).
-
Hola, venía siguiendo el post y llegó el momento de comenzar con el MPU6050 (compre el MPU9150 tambien, pero quedará para más adelante).
Aún no me queda claro, despues de haver leido mucho al respecto, es el tema de la activacion del DMP. Por que necesita mucha memoria? hay que realizar cállculos para activarlo? pensé que sería simplemente escrivir algún registro.
PCCM, creo que estamos mas o menos en lo mismo, mi idea es hacer una controladora para mi quad. El micro será probablemente un ARM cortex-m3 para no quedarme corto a medida que crezca el proyecto. por lo que entiendo que comentaste en este tipo de aplicacines el DMP no es lo mejor debido a las aceleraciones que se producen por el propio vuelo, que suelen ser grandes y durante buen tiempo... como resolviste el tema? implementaste algún filtro? compensaste con velocidad? me interesa conocer el avance para no recorrer caminos que ya han probado y no sirven...
Saludos y gracias!
-
Claro, se tiene que escribir a algunos registros para activar el DMP, el problema es que el llenado de esos registros es grande, se tiene que llenar con una matriz de 8*16*16 para la memoria del DMP, y una matriz de 29*9 para la configuración del DMP.
Para activarlo utilizé el dspic33fj32mc204(ROM:32KB, RAM:2KB), y consumió 65% de la ROM y 43% de la RAM, solo para obtener los cuaterniones. y otro problema que encontré, es que al leerlo por el fifo(lo cual es obligatorio en el DMP), solo puedo leer los cuaterniones, pero si quiero leer la aceleración en un eje ya no se puede, pero no te puedo asegurar 100% esto, ya que no se si en arduino con las funciones hechas para el DMP se podrá.
Por no tener un control de la variable aceleración involucrada en el filtro, opte por no usarlo, ya que tenia que corregir la aceleración debido a periodos largos de aceleraciones.
Para un cuadroptero, creo que no involucra este inconveniente, ya que sus movimientos son más suaves. Para la aplicación que estoy realizando es para una aeronave que alcanza los 3 Match y aceleraciones de hasta 8 gravedades durante 10 segundos o menos.
La parte del sensado inercial, para el caso del calculo de la actitud, compré un sensor de presión diferencial(tubo de pitot), para corregir la aceleración:
http://www.digikey.com/product-detail/en/HSCDRRT001PD2A3/480-3335-ND/2601662
Pero aún no lo pruebo, ya que estoy buscando un giroscopo que me entregue de forma precisa la velocidad angular o de frente el angulo. lo malo que para comprar los giroscopos ópticos son demasiado caros, me pregunte unos cuantos y variaban entre 6000 y 16000 dolares.
Estoy comprando estos giroscopos MENS:
http://www.digikey.com/product-search/en?wt.z_cid=ref_hearst_0211_buynow&site=us&mpart=ADIS16266/PCBZ&v=505
Según su datasheet dice que son más precisos que los típicos de tecnología MENS.Los voy a probar ya que solo necesito máximo un minuto de precisión.
El filtro que implemente fue el Complementario, Kalman, DMP(filtro Mahony) y Madgwick, pero como dije todas tienen el error de aceleraciones grandes en tiempos grandes.
Por lo pronto no he más hecho pruebas con el sistema inercial,ya que si no encuentro un giroscopo más preciso tendré que resignarme a realizar correcciones con filtros.
-
Claro, se tiene que escribir a algunos registros para activar el DMP, el problema es que el llenado de esos registros es grande, se tiene que llenar con una matriz de 8*16*16 para la memoria del DMP, y una matriz de 29*9 para la configuración del DMP.
y dichas matrices son valores constantes o son resultados de cálculos? digo, porque se podría usar una memoria externa para almacenar esos datos... no?
Saludos!
-
Si son valores constantes y claro se puede almacenar en una memoria externa.
En la cuarta respuesta cuelgo el código.
-
PCCM te dijo casi todo, son muchos los datos que hay que cargar para activar el DMP pero los valores de aceleración y giroscopio si se pueden leer de la FIFO cuando esta dando la salida en cuaterniones, es una de las razones por la cual la libreria de arduino solo la use de apoyo, tambien me di cuenta que en arduino no leen los 42 bytes de la FIFO de forma continua por lo cual se da un problema de muestreo, según el datasheet, el cual es que lees los primeros valores en un tiempo = 0 y los segundos en un tiempo = 1 para datectar el error o corregirlo se debee de hacer por medio de software, cosa que no pasa si se lee toda la FIFO en una sola lectura, bien aqui ya me desvie y aqui estan los datos que obtuve
PIC24FJ256DA210 Ocupados
RAM Bytes 98,304 3556
Program Memory (KB) 256 27.36
Pero en mi programa manejo dos MPU6050 uno con DMP y en el otro normal, UART a 115k
La estructura de la FIFO cuando se leen los cuaterniones es la siguiente
/* ================================================================================================ *
| Default MotionApps v2.0 42-byte FIFO packet structure:
| | | | [QUAT W][ ] [QUAT X][ ] [QUAT Y][ ] [QUAT Z][ ] [GYRO X][ ] [GYRO Y][ ]
| | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
| | | | [GYRO Z][ ] [ACC X ][ ] [ACC Y ][ ] [ACC Z ][ ][ ]
| | 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
* ================================================================================================ */
Si no me equivoco esa es la salida que se puede leer en la FIFO, siempre buscala anda por la red, Yo probé leer los paquetes y si contenían la información
-
Aprovecho el post para hacerles una consulta.
Esperando la MPU6050 y la 9150 para probarlas empece a jugar con el ADXL345, el L3G42000 y el HMC5883.
De momento va todo bastante bien, exepto por una cosa, cuando quiero medir los angulos de pitch y roll con el acelerometro funciona bien excepto cerca de los 90°. Es decir si hago solo pitch me convierte bien a grados, pero cuando me acerco a los 90° de pitch me empieza a aparecer mediciones de Roll bastantes raras....
Dejo parte de mi código (para la LPCXpresso 1769):
while ( 1 ){
ADXL345_read_data();
x1=((float)accel_X - biasAccelX) * 0.0037;
y1=((float)accel_Y - biasAccelY) * 0.0038;
z1=((float)accel_Z - biasAccelZ) * 0.0038;
R=sqrtf(x1*x1+y1*y1+z1*z1);
x1/=R;
y1/=R;
z1/=R;
//Calculate the pitch in degrees as measured by the accelerometers.
pitchAccel = atan2(y1, z1) * 360.0 / (2*PI);
rollAccel = atan2(x1, z1) * 360.0 / (2*PI);
uart2_printDouble(x1, 3);
UART2_Sendchar('\t');
uart2_printDouble(y1, 3);
UART2_Sendchar('\t');
uart2_printDouble(z1, 3);
UART2_Sendchar('\t');
uart2_printDouble(pitchAccel, 3);
UART2_Sendchar('\t');
uart2_printDouble(rollAccel, 3);
UART2_Sendchar('\r');
UART2_Sendchar('\n');
delay_ms(300);
}
Y adjunto un conjunto de muestras para que vean el efecto....
Alguna idea?
he probado cargar esos datos en excel y usar la funcion atan2 del excel. Me da resultados parecidos, solo que rotados 90°....
Saludos y gracias
-
Parece que en tu algoritmo cada angulo esta dependiendo de una variable de más.
generalmente es:
angulox=atan(X/sqrt(Y^2 + Z^2));
anguloy=atan(Y/sqrt(X^2 + Z^2));
-
elgarbe buen dia,
Leyendo el mensaje anterio tuyo, tengo el mismo problema con este sensor. Exactamente igual me pasa. como lo solucionaste?
-
El problema es que las ecuaciones están pensadas para valores lejanos a 90°. En valores cercanos a los 90° las funciones divergen.
Saludos!
-
hola elgarbe me puedes contestar la pregunta que te hice en el otro subforo http://www.todopic.com.ar/foros/index.php?topic=45073.20