[Jde-dev] tickect #256 NaoOperator
Francisco Rivas
fm.rivas en alumnos.urjc.es
Lun Mayo 11 12:20:07 CEST 2009
Buenas,
Adjunto el parche para solucionar lo que me has dicho, pensaba que ya
lo habia quitado, pero se ve que no, también he comprobado si
ptencoders exporta clock, ya que hay algun driver que no lo hace
(gazebo por ejmplo) y otros si.
Otra cosa que he tenido que cambiar es que tomaba la v y w de un
schema virtual MotionMotors (el que da NaoBody para el movimiento) lo
he llamado motors que es como se llama en los demas drivers de JDE,
pero lo tendre que modificar el driver de NaoBody ahora lo mando.
Lo he probado para manejar el pioner a través de gazebo y funciona.
Otra cosa que he quitado del schema es la elección entre las dos
formas de andar, ya que finalmente solo va a tener una y esto tiene
dependencias directas del driver NaoBody.
Un saludo.
JoseMaria <jmplaza en gsyc.es> ha escrito:
> Francisco,
>
> enhorabuena, está muy bien el esquema!. Lo he incorporado al svn y
> añadido las dependencias de autotools. Algunas cosas a limar:
>
> Ahora mismo este esquema tiene grabada a fuego su dependencia del driver
> naobody y de una manera "ilegal": revisa del fichero configuración una
> sección que no es del esquema, la de ese driver naobody, y eso es feo.
> Para mantener un diseño limpio y ortogonal, si el esquema necesita su
> configuración específica, entonces habrá que dársela con una sección
> propia en el fichero, entre:
> schema naooperator
> blabla
> end_schema
>
> Un mejor diseño sería que este esquema simplemente usara los interfaces
> que necesite (varcolorXXX, motors, ptmotors, etc...) con independencia
> de quien se los proporcione. Por ejemplo algún día terminaremos el
> soporte para el Nao en Gazebo y entonces será el driver gazebo quien
> proporcione esos interfaces. Vamos, que en vez de coger las distintas
> fuentes posibles analizando una sección del fichero de configuración que
> no es propia, el esquema debería cogerlas importando interfaces y viendo
> si fallan o no. Si el driver naobody está presente y proporciona esos
> interfaces, mejor que mejor, pero también abres la puerta a que sean
> otros drives quienes lo hagan. Por ejemplo me vendría bien para probar
> naooperator con el robot pioneer, que no tengo webots instalado.
>
> Bien por la sección del manual que describe este esquema [1]. Tal vez la
> enriquecería mencionando que interfaces necesita el esquema para
> funcionar. Así empezamos a explicitar las interdependencias de unos
> componentes con otros.
>
> Ánimo,
>
> JoseMaria
> [1] http://jde.gsyc.es/index.php/Manual#NaoOperator
> On Fri, 2009-05-08 at 14:16 +0200, Francisco Rivas wrote:
>> Buenas a todos,
>>
>> con relacion al ticket #256 adjunto el codigo del NaoOperator.
>>
>> ----------------------------
>> Francisco Miguel Rivas Montero
>> http://jde.gsyc.es/index.php/Frivas-pfc-itis
>>
>> _______________________________________________
>> 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
>
>
>
----------------------------
Francisco Miguel Rivas Montero
http://jde.gsyc.es/index.php/Frivas-pfc-itis
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre : pathoperator.tar.gz
Tipo : application/x-gzip
Tamaño : 10392 bytes
Descripción: no disponible
Url : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20090511/4c0ff690/attachment.bin
More information about the Jde-developers
mailing list