Hola de nuevo colegas.
Entiendo que va a estar un poco difícil, por lo específico del tema, que sea mucha la gente que haya incursionado en él. De modo que, cuando menos, intentaré ir documentando en este hilo lo esencial de mis próximos pasos al respecto, y el razonamiento que los guía. Si alguien más adelante incursionara en un empeño parecido, quizá le sirva de algo esta referencia. Aún cuando yo no lo lograra, alguien que lo lea sabrá "qué no hacer"...
Por supuesto: abierto en todo momento a opiniones, críticas, ayudas, colaboraciones, etc. Aquí describo el propósito del proyecto, las dificultades que a mi entender entraña, y los pasos que tentativamente creo necesarios para abrirle paso.
1-Objetivo:
Diseñar y construir un sistema de navegación inercial, basado en la fusión de varios sensores: acelerómetro-giróscopo-magnetómetro-barómetro y GPS.
2-Complejidades del proyecto:
El manejo matemático que supone la fusión, donde resalta la realización del filtro Kalman, supone un desafío tanto en el dominio del hardware como en la programación: capacidad de memoria y velocidad del microcontrolador, disponibilidad o implementación de funciones matemáticas, generación y manejo de estructuras de datos complejas (como los cuaterniones, por ejemplo), sin dudas resultan verdaderos desafíos de diseño por delante.
3-Alternativas que considero pudieran manejarse:
a) Discreta: Pudiera integrarse en una misma placa todos los sensores mencionados (incluso hasta el receptor de gps) mediante los chips que implementen estas funciones. Hay disponibles acelerómetros, giróscopos, magnetómetros y barómetros en forma de chips discretos de diferentes fabricantes...
Así, el procesador gestionaría cada uno de estos sensores a través del interfaz I2C o SPI, según el caso, y asumiría la carga de filtrado y procesamiento de todas estas fuentes. No imposible, pero sí complicado.
b) Integrada: La otra opción es utilizar un chip que ya integre varios de estos sensores (los primarios: acelerómetro, giróscopo y magnetómetro -y acepte barómetro externo-). De entrada se ganaría en simplicidad del hardware y simplicidad de comunicaciones.
Los chips de Invensense materializan justamente esta variante, pero van un paso más adelante incluso: ¡implementan un procesador interno que se "echa encima" el procesamiento matemático que supone la fusión de esos sensores!
4-Alternativa elegida:
La integrada, basada en algún chip de Invensense.
5-Problemática de esta alternativa:
Invensense es de las compañías "que quieren, pero a la vez no quieren", y esconden la bola, como suele decirse en la jerga del béisbol. Te venden el chip, pero se guardan la información clave, de modo que solo lo puedes utilizar a un 30% más o menos de su potencial total. En otras palabras: no hacen pública la información para que el usuario maneje el DMP (Digital Motion Processor), que es el procesador interno que verdaderamente hace poderoso a chip.
6-Soluciones posibles:
a) Acuerdo de confidencialidad: Ellos, a través de una especie de acuerdo de confidencialidad, dan unos drivers (no tengo muy claro el alcance de esto todavía, ni para qué plataforma son) que permite abrir el sistema. El problema es que son tan cerrados, que ni siquiera el link está claro en la página para proceder con esto, lo cual yo haría y honraría sin ningún problema.
b) Una combinación de fuentes Open Source y de Hackeo (en el buen sentido del término) usando como base una plataforma abierta que funcione. Me explico:
Lo único que he encontrado "Open Source" en internet respecto a "abrir" el DMP de los chips de Invensense tiene que ver con el MPU-6050, el chip Acelerómetro-Giróscopo contenido en la plaquita azul para Arduino, disponible en MercadoLibre, eBay, etc. Hay algunas referencias importantes para "abrir" el DMP de este chip basadas en librerías para Arduino que son libres.
Mi problema es que yo no he trabajado con micros de Atmel, ni particularmente con Arduino. Y para colmo, ¡soy de los que prefiere el Ensamblador!..
7- Hasta este punto:
Creo que no tengo más opción que adquirir un Arduino, un módulo MPU-6050, replicar alguno de los ejemplos que están en internet y tratar de entender en primer lugar el código. Luego, posiblemente, colgarme en las líneas de comunicación I2C y de alguna forma "grabar" la conversación entre micro y chip, y tratar de entender y reconstruir el diálogo ese después...
Menuda tareíta, ¿no creen?
