[Jderobot] Componentes en testing

[Luis Roberto Morales]

Buenos días,
tras las últimas modificaciones, el estado actual del teleoperador es el
siguiente:

   - Al cerrar manualmente las ventanas se llama a los manejadores
   adecuados, es decir, a las casillas de selección en el caso de las ventanas
   de interfaces y a la función de salida en el caso de la ventana principal.

   - Al perderse la conexión de una interfaz, automáticamente la ventana
   para esa interfaz se cierra si está abierta.

   - Si una conexión no es posible al solicitar una interfaz, la ventana no
   se abre. Un problema sin resolver todavía es que la casilla de selección se
   queda marcada, lo que obliga a seleccionarla dos veces para volver a
   intentar la conexión.

   - En el caso de la interfaz de motores, el teleoperador manda rangos
   [-100;100] pero muestra el valor devuelto por el propio motor, es decir,
   que si al enviar 80, el controlador del motor interpreta 0.5m/s y lo
   devuelve correctamente, teleoperador mostrará 0.5 m/s.
   Este sistema permitiría que aun usando "a" (interpretación del rango del
   teleoperador por parte del driver), el usuario tenga noción de la velocidad
   que está utilizando el motor.

   - Se han limpiado los CMake tanto principal como de la carpeta build del
   teleoperador; ahora deberían funcionar coherentemente a la estructura
   actual de jderobot. Además, ya no hay gearbox por ahí ni tampoco usos poco
   recomendables de los flags del compilador.


Un saludo,
Roberto


El 21 de noviembre de 2013 14:06, JoseMaria <josemaria.plaza en gmail.com>escribió:

> L.Roberto,
>
> sip, el componente teleoperator hay que pasarlo a estable. Si quieres
> métele las mejoras de las últimas semanas, revisa su CMake y su entrada
> en el mediawiki. Con eso lo subimos a estable cuando quieras, que es muy
> útil para teleoperar un robotito tanto real como simulado.
>
> Habías comentado lo del interfaz ICE suyo para V-W. Si bien (a) dejarlo
> como entre +-100 y que sea cada driver oportuno el que traduce eso a
> números razonables para su robot, o bien (b) que el teleoperador envíe
> números absolutos para V-W (m/s y rad/s) y que cada driver sepa a qué
> atenerse con ello.
>
> Por mi parte me gusta más (b). Evita pasar por el convenio "artificial"
> de +-100, aunque tengamos que refactorizar algunas cosillas. También con
> valores en m/s y rad/s un humano sabe si es mucho o poco, mientras que
> un 70 sin más interpretación no da información. ¿Cómo lo veis?
>
> Avanti,
>
> JoseMaria
> On Thu, 2013-11-21 at 12:28 +0100, Luis Roberto Morales wrote:
> > Hola,
> > en el caso de teleoperator, pregunté por la lista de developers si
> > existe algún otro componente que cumpliera su función y, de no ser
> > así, ver qué le faltaría o qué habría que estandarizar para que pasara
> > a estable, pero no he visto ninguna respuesta.
> > Abrí una tarea al respecto en el redmine por si no se decide
> > eliminarlo.
> >
> >
> > Un saludo,
> > Roberto
> >
> >
> >
> > El 21 de noviembre de 2013 10:12, Borja Mon Serrano
> > <borjamonserrano en gmail.com> escribió:
> >         Hola,
> >
> >
> >         Haciendo un ls en el directorio components de la rama testing
> >         tenemos:
> >
> >         alarmgenerator        cameraview_py    naooperator
> >         wiimoteClient
> >         android-teleoperator  CMakeLists.txt   naoserver
> >         wiimoteServer
> >         bgfglab               gazeboserver0.9  playerserver
> >         calibrator            motiondetection  teleoperator
> >         cameraview_icestorm   naobody          visualHFSM
> >
> >
> >         Mi pregunta es, ¿hay algún componente de ahí que se vaya a
> >         conservar? ¿Hay gente trabajando en alguno de estos
> >         componentes?
> >
> >
> >         Por mi parte, yo eliminaría de ahí varios componentes, pero
> >         del resto no puedo decir nada porque no sé si seguirán o no:
> >         gazeboserver0.9 (ya no se utilizan versiones tan antiguas de
> >         Gazebo y éste no funciona con las nuevas), naooperator (está
> >         el naoviewer, que es el mismo componente, en la rama estable),
> >         naoserver (es la versión antigua, con dependencias de BICA y
> >         un servidor de la cámara bastante menos eficiente que el de la
> >         nueva versión), playerserver (no se utiliza nada de Player ya)
> >         y visualHFSM (es la versión antigua, la 3, y ya tenemos nueva
> >         versión en la rama estable).
> >
> >
> >         Lo digo por dos motivos: uno, empezar a eliminar los
> >         componentes que no hagan falta; y dos, eliminar también del
> >         mediawiki aquellas descripciones de componentes que ya no
> >         vayan a estar en jderobot.
> >
> >
> >         Un saludo,
> >
> >         Borja.
> >
> >
> >         _______________________________________________
> >         Jde-developers mailing list
> >         Jde-developers en gsyc.es
> >
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >
> >
> >
> > _______________________________________________
> > Jde-developers mailing list
> > Jde-developers en gsyc.es
> > http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>
> --
> http://gsyc.urjc.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/20131125/8dd9b100/attachment.htm