Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
He leido que AMD tendrá procesadores de 12 núcleos en el 2012, Intel vá más allá y prevé procesadores con miles de cores.
Por otro lado los sistemas operativos y lenguajes de programación no están especialmente pensados para trabajar con estos micros (windows no soporta más de cuatro, linux parece que se salva), y lo peor es que los programadores que a duras penas pueden estar al día con la evolución actual, pueden quedar todos obsoletos de golpe. Es duro esto ¿no?
Yo ante esto, mientras se arregla el follón propondría tratar de hacer una red inteligente: consiste en hacer ejecutables que se comuniquen entre sí por tcp-ip, así varios ordenadores corriendo programas de inteligencia artificial podrían compartir información. No hace falta que corran el mismo programa, puede ser que cada programador haga correr el suyo a ver cual es mejor concentrando información. El fin último es alimentar el sistema con ciertas acciones y que el sistema empleando inteligencia distribuida trate de averiguar por interpolación el resultado. Los programas que den un resultado más acertado ganan puntos, los demás mueren (selección natural)
Cada ejecutable es una neurona, pudiendo haber más ejecutables que núcleos.
Un ejecutable centralizado "evalúa el sistema", asignando puntos o matando neuronas inservibles.
Ahora bien ¿podrían varios programas corriendo en un mismo PC intercambiar información por tcp-ip como si pertenecieran a redes externas?
bis
El uso de componentes sirve para que todos los núcleos estén activos, pero también sirve para distribuir el cómputo entre distintas máquinas.
Uso distintos ejecutables, alguno de los cuales tiene más de un thread.
He hecho una galería de imágenes para subiros esta imagen. Os pongo la explicación literal que lleva la foto:
""
*MUCHO POR MEJORAR*
Captura del laser visual. A la izquierda, managerComp, con los componentes: todos menos FLOOR y joystick están en el ordenador personal, el resto están en el portatil del robot. A la derecha, la cámara izquierda del robot.
En el centro hay dos imágenes, en la de arriba: el canal rojo es relativo a la decection de obstáculos por histograma de color, el canal verde es la detección por estéreo. La imagen de abajo es la salida binaria de obstáculos, tiene sobrepuesto la salida del laser.
""
http://www.webdearde.com/modules.php?na ... e&pos=-303
Más en http://robexarena.com y http://robocomp.wiki.sourceforge.net/ . Ambos proyectos están maduros pero tienen mucho que mejorar, si alguien se anima a colaborar...
joviwap: ¡Dejate de suscripciones y pásate a Ice a pelo! ¿Probaste managercomp? Es lo de la izquierda de la foto.
Muy interesante lo de luisj, (imagino con qt)
Asi resolveriamos el empleo de multicores en un pc, lo suyo seria poder comunicar con otros pcs para comunicaciones más lentas.
Varios robots con cpus con un par de nucleos trabajando a tope con vision podrian ser manejados por un ordenador central que decidiria las operaciones de mas inteligencia
Lo suyo es decidir un interfaz comun para que cada uno pueda ensayar sus algoritmos.
En un robot imagino cada componente podria ser un sensor (por ejemplo), y luego un componente central manejaria todos los demas modulos.
Si se hace un upgrade de la CPU a otra de mas cores, algunos componentes que comparten un core se irian a cores distintos.
Estamos haciendo un texto sobre programación orientada a componentes en robótica. Cuando lo tengamos medio terminado os lo paso.
luisj ¿usas threads o ejecutables?
joviwap: ¿Tu qué tienes hecho? ¿Hay algo visible? Lo digo por ver si estamos reinventando la rueda...
luisj, si tengo cosas hechas, pero no puedo enseñarlas porque son del trabajo y podría tener problemas de propiedad intelectual.
De todas formas puedo hablarte de las herramientas que uso, aunque ya las conoces. Son Player, Stage y Orca. En particular una de las aplicaciones que viene con orca, orcaview2d. Te permite ver tu robot en un entorno en 2 dimensiones, y tiene una serie de interfaces estandar que es capaz de representar graficamente. Es realmente muy útil para comprobar que tus algoritmos hacen lo que deben de una forma muy práctica.
Estoy observando muy de cerca vuestro proyecto. Lo veo muy completo, aunque you habría elegido player como base de drivers para hacerlo más compatible. Otro punto, es que para utilizarlo como base de un proyecto lo veo flojo por dos motivos:
- No teneis interfaces estandarizadas y bien definidas, sino que las creais conforme las necesitais, o eso creo.
- Os faltan herramientas para esas interfaces, o si existen, falta documentación.
Solo una pregunta con respecto a esto último, el "managercomp" sería posible visualizar los componentes de orca con esta utilidad?
Un saludo.
joviwap:
Lo de añadir Player para controlar bases lo tengo en mi lista de cosas pendientes, es muy buena idea.
Lo de que las interfaces cambien es muy cierto, pero eso sucede con los componentes que son poco genéricos, baseComp y camaraComp muy raramente cambian.
No entiendo a qué te refieres con herramientas para los interfaces. Tenemos visorComp, que se conecta a varios interfaces y muestra información de los mismos. No se si es a eso a lo que te refieres.
Lo de la falta de documentación es debido a que somos pocos en el proyecto y no hay tiempo. Deberíamos solucionar ambas cosas.
El managerComp funciona con cualquier componente que ofrezca una interfaz Ice. Las comprobaciones las hace mediante llamadas a ice_ping, por lo que cualquier componente que responda a eso funcionará, es decir, todos. Eso sí, managerComp no va sobre windows.
Te agradecería mucho que hicieses las propuestas que has comentado en el foro de robexarena.com para que los demás integrantes del proyecto lo vean y te puedan responder. Es que soy siempre yo el que les da las quejas y me están cogiendo manía. 😉 Seguro que se genera un bonito hilo a raíz de eso.
Saludos
