Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Desde hace mucho tiempo que me interesa la robotica, sin embargo he de admitir que nunca he hecho nada al respecto. No es una excusa. No tengo tiempo. El trabajo, la hipoteca, la familia, los hijos, me dejan literalmente un tiempo cero. Pero hay algo mas...
Soy un buen informatico (trabajo en ello desde hace muuuchos años), y sin embargo no estoy para ponerme a aprender a programar un PIC..., No quiero hacer un robot que siga una linea en el suelo. Quiero hacer un robot que me hable, me escuche, me mire a los ojos, que me entienda. Es posible, lo sera algun dia...
¿Porque no hay un entorno (¿no lo hay verdad?) potente para desarrollar robots?. Quiero un entorno robot con una CPU Pentium4 DualCore, con 4 GB de RAM, con un HD de 500GB, y un lenguaje Java corriendo sobre un VM.
¿Porque tengo que volver a desarrollar en Assembler como ya hice hace 20 años, con una memoria mas que limitada?. ¿Porque no juntamos de una vez la IA con la Robotica en entornos potentes de verdad?.
No se..., ya digo que soy nuevo en esto, pero cada vez que veo un proyecto de robotica no entiendo porque seguimos trabajando con esos limites...
¿Me explico bien?. ¿Alguien puede entonces exlicarmelo a mi?.
Respecto a lo que comentaís yo me decantaría por la simplicidad y el minimizar el tiempo de desarrollo, ya que gastar meses para desarrollar un robot es bastante costoso y poder reutilizar componentes sería lo ideal, es trabajo que ya no tendrías que hacer, estaría resuelto. Además un portatil ahora los puedes conseguir por 500 € con 1 Gbyte y 200 Gbytes de disco duro, vamos le instalas Debian y tienes un maquinon.
Sencillamente me ha encantado la idea de la programación orientada a componentes, creo que puede ser potente para este caso.
Como ejemplo para intentar poisicionar el robot en el exterior (sistema GPS) con desarrollar un componente que sea el servicio de gogle maps implementado a través de GPRS, y un componente que te permita obtener las corrdenadas GPS se pordrían hacer muchas cosas. Y obviamente una vez resuelto ya estaría resuelto para todos.
Como este caso seguro que la mayoría se podría analizar de una manera sencilla.
Las comunicaciones entre la plataforma con los sistemas del robot (Llamo sistemas del robot al hardware que realiza funciones físicas, como el movimiento, visión, etc) se realizarían a través de RS-232, USB, otros??? y en caso de que un sistema del robot necesite operar de manera autónoma por aquello del control distribuido y necesidad de tiempo real, ¿Cómo se resolvería todo esto a nivel del framework y la comunicación con el proceso principal del robot?
Juanjo.
La comunicacion PC-Actuador o PC-Sensor depende de la naturaleza del cacharro. Si el sensor trabaja USB pues por USB, si es por RS-232 puedes usar RS-232 o un conversor a USB.
En el robot que os digo (el del video), los motores los controla un microcontrolador que se comunica con el ordenador por RS232 pero viene ya con un conversor a USB para que no haa problema con los portatiles (suelen venir sin puerto serie).
Cada componente es un programa a parte que corre por su cuenta y atiende las peticiones, en tiempo real, de otros componentes, por lo que no hay ningún problema en trabajar en tiempo real.
Opcionalmente puedes usar un gestor de componentes que los arranque, compruebe el estado de cada componente o los apague en tiempo real.
En la foto que os envio podeis ver el robot trabajando sobre el simulador. La ventanita con una lista verde y roja es el gestor de componentes que hice para el laboratorio. Podeis ver que en ese momento los componentes base y camara estaban funcionando y los componentes acpi (controla la bateria), speech (para que el robot hable) y suelo (detector de suelo-obstaculos) estaban parados.
Mientras esperaba que me llegase el robot por correo podía usar el simulador sin ningún problema.
Hola,
No tengo muy claro lo de la programación orientada a componentes. Me da la sensación que es un paso intermedio entre crear unas librerías de componentes (más o menos lo que voy a terminar haciendo yo con la Entrenadora) y los sensores "inteligentes" (con un micro por sensor que únicamente necesite comunicaciones con el micro principal).
S2
Ranganok Schahzaman
La programación orientada a componentes es un paso más allá respecto al uso de librerías: Cuando usas una librería el código de la librería que se ejecute tiene que estar en la misma máquina, con componentes no necesariamente. Cuando usas una librería, tu programa puede hacer que la librería funcione mal si está mal programado, con componentes no (ya que son programas a parte). Cuando tienes un software complejo, por ejemplo el software de un robot, este tiende a ser dificil de entender y mejorar porque es un único programa grande, con componentes tienes unos cuantos programas pequeñitos que se encargan de hacer su trabajo en paralelo.
Digamos que es como el ordenador: cada periférico probablemente tiene un controlador que va por su cuenta y de vez en cuando estos se sincronizan para intercambiar datos. Hay un protocolo (que programando componentes es transparente) que hace que se comuniquen entre sí.
Pero merece sólo la pena cuando trabajas con un robot "de verdad", cuando quieres hacer un siguelineas o algo así el software es mucho más sencillo y no merece la pena hacer eso. Sería como usar programación orientada a objetos con herencia y templates para hacer un programa que muestre por pantalla "hola".
