[Jde-dev] software reutilizable

Sab Ago 29 21:33:23 CEST 2009

Hola,
Continuando esta interesante conversación, comentaré las cosas que he subido
recientemente (muchas siguiendo ideas que se comentan aquí) y añadiré mis
ideas sobre el futuro de jderobot. Una vez discutidas las ideas de todos los
que participen, podremos hacer el roadmap de jderobot.

Siguiendo con la idea de un sistema orientado a componentes, la linea
principal a seguir es conseguir que nuestro software sea mas reutilizable,
en principio desde su unidad mas básica: el esquema. Hacer que un esquema
sea utilizable como una librería que se accede con un API conocido es algo
que a día de hoy está casi implementado en 4.3. La idea para 4.4 es que esto
sea una cosa fácil de hacer, de modo que un tercero pueda cargar, por
ejemplo, el esquema pantilt y mediante su API manejarlo tal y como haría con
una librería. Parte del código que he subido va en esa linea. El ejemplo
randomwalk es justo eso, un programa que usa "motors" y "laser" sin
importarle mucho que hay detrás.

Reorganizar el código de manera que desacoplemos funcionalidad de
envoltorio, también es algo interesante a seguir. No sólo nos facilitará el
entender mejor nuestro software, si no que lo hará mas fácil de usar por
otros, cosa que redundará en nuestro beneficio en cuanto a que nuestro
software será probado por terceros, obteniendo información sobre errores,
fiabilidad, rendimiento... Para conseguir esto, primero tenemos que dejar
bien claro, que es el "envoltorio". Es decir, definir claramente el API de
jderobot. Una vez hecho esto, iremos viendo que cosas son funcionalidad pura
y entonces moverlas a librerías.

En cuanto a los puntos que comentas:

(0)
Que todo sea un proceso tiene sus pros y sus contras. Sin duda no es algo
fácil de apañar y dado que con ICE esto cambia completamente no veo la
necesidad de hacer nada. El uso de la tabla de símbolos me parece una buena
solución. De echo la implementación de interfaces que he subido hace uso
extensivo de ella.

(1)
Tanto el esquema como el interfaz están definidos en el código que he
subido. Ambas estructuras de datos tienen un API definido. Además para los
interfaces hay definidas macros que son capaces de generar todo el código de
los nuevos interfaces que creemos. De esta manera todos funcionarán igual,
siendo estandar la manera de usarlos. En parte he tomado algunas ideas de
ICE, por lo que una vez pasemos a este algunos conceptos serán similares.

(2)
El tema gui es complicado y dado que no vamos a cambiar nada con respecto a
(0) mejor no tocar mucho. Sólo una idea, podemos hacer que un esquema
exporte todo aquello que le gustaría pintar en un interfaz. Sería un
interfaz de depuración/visualización. Después bastaría que alguien en el
proceso se encargue de pintar todo lo que queramos.

(3)
Totalmente de acuerdo con lo que dice José María. El asunto fps se rompe,
aunque podemos hacer que cada esquema recoja sus propias métricas de
rendimiento. Supongo que esto habrá que pensarlo un poco mas, de modo que
valga para cuando pasemos a ICE.

Comentarios?

Sludetes,
David

2009/8/5 JoseMaria <jmplaza en gsyc.es>

> 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
>
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20090829/af518221/attachment.htm 