Módulos de control local
De Proyecto Androide
Voy a tratar de delinear aquí la idea que yo planteo (e insisto siempre) de basar tanto el manejo de la parte motriz como otras tareas dedicadas en módulos de control locales, para descargar tareas al procesador.
En el rubro de las "otras tareas", imagino:
1. Un módulo de equilibrio bien potente que procese la información de los sensores de equilibrio, incorporando quizás alguna otra información, como la de senseo de tacto y presión en las extremidades y, si algún día ponemos un sistema de procesamiento de imagen, algo que le llegue desde este módulo.
2. Un módulo de tacto que preprocese, justamente, la información de fuerza, presión, tacto, etc que llega desde las extremidades y otras partes del cuerpo y dé las informaciones necesarias a requerimiento de otros módulos.
3. Un módulo centralizador de las comunicaciones, que además de controlar el tráfico tenga capacidad de guardar datos, darles prioridades y entender bastante la situación como para dar aviso e interrumpir al CPU cuando sea necesario. De esta manera podremos tener no una, sino varias líneas de bus I2C (si fuera necesario debido a la complejidad y la posibilidad de que ocurran "colisiones"... las pruebas ya nos lo dirán) que desemboquen en este microcontrolador.
4. Finalmente, módulos del área motora capaces de manejar una articulación. Es decir, manejar un servo si es una articulación de un grado de libertad, dos si son dos grados, y así. Este microcontrolador debe tener capacidad de controlar las fuerzas que hace el motor y su posición real, por lo cual deberá poseer convertidores A/D. Y deberá controlar, también, si luego de un tiempo de haber dado la orden la articulación ha llegado o no al ángulo que se espera, lo cual aporta otra realimentación importante que permite conocer las variables de carga mecánica que se le aplican al sistema, además de lo que puedan decir otros sensores, de temperatura y de corriente del motor.
En el caso de los módulos del área motora, si creamos un lenguaje de órdenes único, que transmita ángulos, tiempos y/o vectores de recorrido, un lenguaje no específico para ese motor sino genérico, luego es posible cambiar de motor y de módulo y lograr que el sistema siga funcionando tal cual.
Yo me imagino dos maneras de darle órdenes:
1. decirle que se mueva un x ángulo en un x tiempo (es la opción más simple), o
2. decirle que un punto de su sistema debe moverse determinada trayectoria (un vector o varios) en determinado tiempo (por ejemplo, a la articulación del codo y del hombro se les dice el movimiento en el espacio que debe realizar un x punto físico en su antebrazo).
Para esto último, los módulos del área motora deben tener incorporados parámetros de la geometría de su sistema. Con el otro modo de órdenes (1) no lo necesitan: la geometría la conoce la CPU, que sólo debe envíar órdenes del ángulo de movimiento necesario y de tiempo de movimiento. No sé por qué me parece que esta opción es la más práctica.
--Edu 22:22 14 mar 2008 (ARST)
...como para resumir un poco la idea, no? (nada definitivo, por supuesto)
La configuración modular no solo que descarga tareas a la cpu sino que alivia el trabajo a la hora de programar. Además, creo que lo mejor, al principio, es pensar en separar todo en la mayor cantidad de módulos posible. Total.. después será mas fácil agruparlos convenientemente en función de las tareas y de la capacidad de los micros que usemos.
... y que buen tema lo de la forma de darles órdenes a los módulos.
--Adrian Adrian S.A. 02:49 16 mar 2008 (ART)