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?.
Estoy de acuerdo contigo en que lo mejor es usar los mínimos recursos posibles. El caso es que en la robótica movil se presenta un importante problema de ingeniería de software.
Tu tienes toda la pinta de ser teleco ( 😆 ), así que te pongo de ejemplo el modelo OSI. Hay veces que introducir complejidad es necesario para resolver problemas que también son complejos. Por otra parte, al reusar componentes (código) ya hechos se fortalece la estabilidad y fiabilidad del sistema.
Respecto a Ice, el uso de esos plugins no es necesario. Al igual que en el modelo OSI, todo depende de qué necesites. Al igual que puedes establecer comunicación en la capa tres del modelo OSI si estás en el mismo segmento de red sin necesidad de usar TCP, puedes usar sólo los servicios básicos de Ice sin plug-ins. Sin embargo, para algunas cosas esos servicios sí son interesantes.
Yo creo que es más importante hacer las cosas de forma fácil (o hacerlas simplemete) que hacerlas aprovechando los recursos al 100%. La razón es que lo más probable es que si en un principio intentas hacer las cosas perfectas nunca lo consigas. Creo que es mejor preocuparse por hacerlo, y una vez esté hecho tratar de minimizar los recursos.
Como dije antes, el problema en robotica está en hacer las cosas. ¿Para qué te vas a preocupar de consumir pocos recursos mientras no hagas algo que consuma los recursos del ordenador que tienes? En el laboratorio trabajamos con Ice y la sobrecarga de usar Ice debe rondar el 2% de los recursos consumidos, sin embargo, hace la vida muchisimo más facil y el ciclo de desarrollo extraordianriamente más rápido.
Sin usar componentes tienes un programa monolítico cuya facilidad de lectura y depuración, y SOBRE TODO, escalabilidad dejan muuuucho que desear.
Se me olvidó, Ice también corre en windows perfectamente y soporta muchos lenguajes de programación que se pueden usar a la vez.
Para que hablemos un mismo idioma, tendremos que ver la arquitectura tecnológica para robots como un modelo máximo y más completo posible, eso no significa que se tenga que utilizar todos sus componentes. Por el contrario, el modelo sirve com odice la palabra "modelo" (un ejemplo) sobre el cual inspire el diseño de un robot (parte física, lógica, etc.) utilizando solamente algunos componentes necesarios para un diseño u otro, optimizando qué debe llevar y qué no, según lo que se desea hacer, sea un robot móvil (como los Pioneer) o si alguien se anima por un robot humanoide a escala, o cualquier otra cosa.
Lo curioso es que con algo así, se puede hacer un robot simple con pocos conocimientos, y por otro lado, se puede hacer un robot muy especializado y además compatible.
La pregunta entonces es ¿queremos hacer robots compatibles?, ¿universales? que ante un nuevo dispositivo ya no sea tan compleja su integración, o ante un ambiente de interacción con otros robots o con domótica, tampoco resulte un enorme desafío. Esa es la idea.
Mirad esto: http://youtube.com/watch?v=YP0WNwUbbQQ
Ese es el robot que os digo. Los alumnos de la asignatura consiguieron tener un robot que evadía obstáculos y daba vueltas por ahí . Esto es gracias al diseño orientado a componentes: tenían un componente base, componente cámara y y componente detector de suelo. Ellos solamente tuvieron que concentrarse en usar los componentes de los que disponían.
Además, si cometían un error, el único componente que se cargaban era el suyo, por lo que la caza de errores es mucho más fácil.
como se nota que le estamos dando vueltas a este asunto 😉
se me olvidaba mencionar que también existe la oportunidad de comenzar tomando en cuenta las necesidades de la Sociedad (personas) como enfoque central de diseños, que con ARDE se pueda recoger estas necesidades por entrevistas en diferentes lugares donde se mueve, y por el foro.
Eso implica que una arquitectura modelo de robot no crecerá por su dimensión tecnológica, por el contrario, primero por las reales necesidades (aunque sea a través de un juego), y entonces mirar bien cuáles tecnologías son merecedoras de entrar de forma modular al modelo. A partir de modelos así, apostaría que se diseñarían mejores robots, desde creaciones simples hasta humanoides de servicio.
