[Jde-dev] software reutilizable

Jue Ago 6 01:33:42 CEST 2009

Hola,

Jderobot es un software para robotica/domotica/visión orientado a
componentes. Cada componente, además del código con la funcionalidad
específica (llamemos a esa parte del código "meollo"), tiene una manera
de usar funcionalidad de otros y de proporcionar él mismo la suya a
otros. Esa manera es fijada por la arquitectura software, llamemosla
"envoltorio".

Coincido contigo David en que en muchos componentes (drivers,
esquemas...) el envoltorio y el meollo están muy imbricados. Por ejemplo
muchos drivers además de hablar con el dispositivo hardware tienen el
código que da esa funcionalidad en forma de esquemas virtuales, que es
la norma en jderobot. 

Me parece bien reorganizar el código en esa dirección de separar
claramente el meollo y el envoltorio. 
(a) Por un lado facilitará la evolución hacia jderobot-5, que utilizará
ICE como middleware para conectar unos componentes con otros. Será un
"cambio de envoltorio" sin que cambie el meollo. Los componentes
refactorizados se podrán pasar más sencillamente de estar envueltos en
la piel de jderobot-4.4 a estarlo en la piel de jderobot-5.
(b) Por otro también permitirá interactuar más con otros proyectos
robóticos, tanto cogiendo componentes de otros envolviendolos en
jderobot como hacer que el meollo de nuestros componentes pueda ser
aprovechado en otras arquitecturas.

En el diseño actual de la 4.3 tenemos muchas cosas heredadas de
planteamientos históricos que dificultan la reutilización. Muchos de
ellos desaparecerán con el rediseño global de jderobot-5, con el
middleware ICE como pegamento entre los componentes distribuidos. Repaso
los obstáculos principales que veo:

(0) hebras dentro del mismo proceso.
Hace que haya que cuidar el espacio de nombres. Si todo se enlaza junto
puede haber solapes indeseados de nombres. Por ejemplo que un esquema-B
se defina SU variable velocidad_motor y que otro esquema desarrollado
independientemente también se defina SU variable velocidad_motor. Si no
se tiene cuidado puede dar errores muy divertidos con esa interacción
indeseada. En jderobot-4.3 cada esquema tiene su propio espacio de
nombres disjunto (no se comparte la tabla de símbolos al cargarse el
plugin), y lo que se quiere compartir se hace "a mano" publicando
(exportando) e importando nombres de funciones/variables de otros
esquemas. En jderobot-5 cada componente será un proceso y por tanto con
su propio espacio de nombres independientes, de serie.

(1) el interfaz de variables.
Actualmente cada esquema publica su funcionalidad como un conjunto de
funciones obligatorias (init,terminate,run,stop,show,hide) y unas
VARIABLES específicas compartidas con otros. El modo que tiene un
componente de llegar a datos de otro es de nuevo con la importación del
nombre de sus variables. Y esto es poco reusable, muy específico de jde.
En jderobot-5 todo el interfaz de los componentes será exclusivamente un
conjunto de funciones, que son más fáciles de sobrecargar con código de
acceso local o invocación remota de métodos para acceder a los datos en
cuestión. Middleware 

(2) el interfaz gráfico
En el diseño actual el GUI se considera inherente a todos los
componentes/esquemas, cada uno debe llevar el suyo independiente del
resto. Como todos son hebras dentro del mismo proceso y típicamente sólo
se admite una conexión con el servidor X por proceso tenemos un
problema. En jderobot-4.3 hemos solventado esto creando los servicios
gráficos que ofrecen las funciones de registro/desregistro de callbacks.
Esto permite al programador de un componente escribir sólo su GUI, pero
es muy especifico de jde, ya que los componentes no utilizan
directamente la biblioteca gráfica (GTK, XForms, glut) sino el "servicio
gráfico" graphics_gtk o graphics_xforms. En jderobot-5 la idea es no
poner el GUI obligatoriamente en todos los componentes y el que lo
necesite, al ser un proceso independiente, que lo programe manejando
directamente la biblioteca gráfica oportuna.

(3) motor temporal monohilo.
El modelo actual de componente ofrece una hebra por esquema, que se
detiene periodicamente para respetar la frecuencia nominal. En
jderobot-5 ya no se impone ningún motor o estructura obligatoria de
hilos a cada componente. Cada cual tendrá las hebras que necesite, el
único requisito es que responda a los interfaces que implemente. Al ser
la estructura de hilos libre, podremos incorporar componentes de otros
proyectos con más facilidad.

La refactorización podemos orientarla a separar mejor qué partes son de
la infraestructura, cuales del envoltorio y cuales del meollo en cada
componente. Una idea interesante es poder empaquetar el meollo de cada
componente en una biblioteca que se viste/envuelve con la parte
especifica que le da forma para que pueda ser usado en jderobot-4.4.

A (0) y (2) les veo mal arreglo sin cambiar drasticamente todo. Lo
dejaría para jderobot-5, pues allí ineludiblemente vamos a abordarlo.

A (1) sí, con las cosas que estas haciendo de los interfaces podemos ya
empezar a manejar interfaces funcionales para todos los componentes.
Además de init/terminate/run/stop/show/hide añadiría get_data1,
get_data2, y set_data1, set_data2, etc. para los datos especificos de
los componentes. Este sería el envoltorio de jderobot-4.4 para cada
componente y habría que casar este API con el meollo. La invocación de
estas get_data y set_data de otros componentes empleará la importación
por debajo, pero ya estructuramos el código asumiendo que cuando un
esquema quiere datos de otros invoca la función get_data oportuna.

En cuanto a (3) sí veo factible eliminarlo, restringiendo que los
esquemas simplemente usen las funciones run/stop oportunas, y que debajo
de ellas haya la activación de las hebras que se necesiten.
Probablemente esto lleve a que deje de funcionar el contador de
iteraciones por segundo que pone la arquitectura.  Pero quizá sea
secundario frente a la libertad de hilos que da a los componentes.

Sigamos hablando....

JoseMaria
On Mon, 2009-07-20 at 12:33 +0200, David Lobato wrote:
> Estoy revisando parte del software que contiene el proyecto jderobot,
> con la idea de localizar aquellas partes que podrían ser
> "reutilizable" por terceros.
> La idea es encontrar software que hayamos desarrollado nosotros que
> pueda ser útil para la comunidad open source, independientemente de si
> usan nuestra arquitectura jderobot.
> 
> La primera impresión, es que sólo las librerías colorspaces,
> progeo,... cumplen dicha condición, aun teniendo mucho mas software
> que podría ser útil como por ejemplo el driver de la pantilt, el de
> mplayer, o algunos algoritmos. El problema es que están tan integrados
> en jderobot que no pueden usarse fuera de la arquitectura, resultando
> poco "reutilizable".
> 
> Este problema se describe en [1], donde se comenta que desplazar tanto
> drivers como algoritmos (DA) a librerías independientes de la
> arquitectura puede resultar beneficioso para la reutilización, entre
> otras cosas.
> 
> Creo que el enfoque hacia jde 4.4 debe ser éste, refactorizar parte
> del software que tenemos y extraer la funcionalidad en librerías
> independientes de la arquitectura. Una vez hecho esto, podemos
> intentar participar en algún repositorio open source de software
> robótico, como gearbox [2].
> 
> Cómo lo veis?
> 
> Un saludo,
> David.
> 
> [1] http://www.cas.edu.au/download.php/makarenko07_iros_benefits_of_thin_frameworks.pdf?id=1748
> [2] http://gearbox.sourceforge.net/
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
-- 
http://gsyc.es/jmplaza 
Universidad Rey Juan Carlos