[Jde-dev] Path tickect #256 NaoOperator
Francisco Rivas
fm.rivas en alumnos.urjc.es
Vie Mayo 15 12:02:03 CEST 2009
Bueno, parece que ya estan solucionados los problemas que encontró
Eduardo en el schema NaoOperator.
Adjunto el parche sobre la revision 359.
He añadido un nuevo fichero, y que ahora el NaoOperator necesita saber
que es lo que va a usar.
Un saludo a todos.
Eduardo Perdices <edupergar en gmail.com> ha escrito:
> Hola, a ver varias cosas, he conseguido que funcione el esquema pero
> haciendo algunos apaños, en el configure que uso normalmente pongo al
> final "guiresume naooperator", y con eso se abre la interfaz gráfica
> del schema sin necesidad de activarlo. Haciendo eso con tu schema no
> funciona, sin embargo si no pongo eso en el configure y lo activo
> después a mano, ya si que carga bien.
>
> Eso pasa seguro porque al ponerlo en el archivo el schema se carga más
> rápidamente que al hacerlo a mano, y seguramente intentes acceder a
> alguna variable que cojas con myimport antes de que el driver naobody
> te lo de. Normalmente en los schemas, cuando se ha hecho un import se
> pone alguna variable a true, para controlar en el resto del schema con
> ifs si ya se tiene esa variable, en tu caso, como falla al abrir la
> interfaz gráfica, supongo que fallará en la función
> "naooperator_show".
>
> Por ejemplo podría fallar de la siguiente manera:
>
> - Se selecciona el provides ptencoder en el archivo de configuración,
> así que en el "naooperator_parseconf" se pone naohead_runs a true.
>
> - Por alguna razón del sistema operativo, el thread que llame a
> "naohead_show" entra antes en el procesador que el que llama a
> "naooperator_imports".
>
> - En "naooperator_show", como naohead_runs es 1, entra en el if y
> llama a gtk_range_set_value(glade_xml_get_widget(xml,
> "hscale_longitude_speed"),*longitude_speed);
>
> - Segmentation fault porque el puntero a longitude_speed es null todavía.
>
> No digo que pase exactamente eso, pero podría pasar perfectamente, la
> solución es por ejemplo ponerte otra variable que sea "imports_ok" o
> algo asi, y no usar las variables que se necesiten hasta que ese
> imports_ok sea true.
>
> Yo por ejemplo en [1], veras que importo la variable head_val, y al
> hacer el import tengo un head_ok. Siempre que voy a usar el head_val
> compruebo que el head_ok sea true, para que no pase lo que está
> pasando con los tuyos.
>
> Y lo otro que veo es que pillas todas las variables del driver
> naobody, esto si solo usas el naooperator pues puede valer, pero si
> usas varios schemas a la vez puede ser un lio. Por ejemplo puedes
> querer usar dos schemas que quieran usar el driver naobody, que el
> naooperator solo use la función de andar y que todo lo demás lo use el
> otro schema (casualmente mi caso xD). Con esto no sería posible, yo
> creo que lo suyo sería hacer una sección en el configure propia del
> schema naooperator, y ahí seleccionar las cosas que quieres que use el
> naooperator, por ejemplo podría quedar así:
>
> driver naobody
> provides ptmotos
> provides ptencoders
> provides motors
> end_driver
>
> schema naooperator
> uses motors
> end_schema
>
> schema X
> uses ptmotors
> uses ptencoders
> end_schema.
>
> Vamos para poder usarlo así solo habría que cambiar en el parseconf de
> naooperator.c 2 o 3 palabras.
>
> Un saludo.
>
> [1]
> http://svn.jde.gsyc.es/users/eperdes/headtracking/trunk/location/location.c
>
> 2009/5/11 Francisco Rivas <fm.rivas en alumnos.urjc.es>:
>> Buenas.
>>
>> Ya esta solucionado el problema, se hace una comprobacion por separado de
>> ptmotors y ptencoders y se activa solamente lo que sea necesario.
>>
>> Si puedes pruebalo, yo lo he probado con todas los config posibles y no me
>> ha fallado.
>>
>> Un saludo y gracias por avisar el problema.
>>
>>
>> Por cierto el path está sobre la versión del svn, no se si deberia de
>> hacerlo sobre el ultimo que mande....
>>
>>
>>
>> Francisco Rivas <fm.rivas en alumnos.urjc.es> ha escrito:
>>
>>> Vale, es un problema de verificaciones, intenta arrancar todo
>>> (ptmotors y ptencoders) aunque solo este activo el ptencoders, ahora
>>> me pongo con ello, puedes probar poniendo tambien el ptmotors en el
>>> naobody a ver si asi te arranca???
>>>
>>> Un saludo.
>>>
>>> Eduardo Perdices <edupergar en gmail.com> ha escrito:
>>>
>>>> Hola, estoy intentando probar el schema naooperator con la versión del
>>>> svn, pero obtengo un segmentatión fault nada más arrancar, también he
>>>> probado a aplicarle los paths que has subido esta mañana pero pasa lo
>>>> mismo.
>>>>
>>>> El configure lo tengo así:
>>>>
>>>> driver naobody
>>>> provides motors
>>>> provides ptencoders
>>>> end_driver
>>>>
>>>> Y la salida que da es:
>>>>
>>>> jderobot 4.3-$Revision: 310 $
>>>>
>>>> Reading configuration...
>>>> graphics_gtk driver loaded (driver 0)
>>>> Loading GTK support...
>>>> GTK support loaded.
>>>> naobody driver loaded (driver 1)
>>>> naobody: warning! color not provided.
>>>> motors schema loaded (id 0)
>>>> ptencoders schema loaded (id 1)
>>>> naobody driver started up: number 0
>>>> naobody thread in sleep mode
>>>> naobody driver started up
>>>> mastergui schema loaded (id 3)
>>>> mastergui schema started up
>>>> naooperator schema loaded (id 4)
>>>> naooperator started up
>>>> Fallo de segmentación
>>>>
>>>> Tampoco da mucha información, supongo que será algo de punteros, que
>>>> se intenta acceder a algo antes de que se inicie, o falta algo en el
>>>> configure.
>>>>
>>>> Un saludo.
>>>>
>>>>
>>>> 2009/5/11 Francisco Rivas <fm.rivas en alumnos.urjc.es>:
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Jde-developers mailing list
>>>>> Jde-developers en gsyc.es
>>>>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ----------------------------
>>> 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
>>>
>>>
>>
>>
>>
>> ----------------------------
>> Francisco Miguel Rivas Montero
>> http://jde.gsyc.es/index.php/Frivas-pfc-itis
>>
>>
>
>
----------------------------
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 : pathpathnaooperator.tar.gz
Tipo : application/x-gzip
Tamaño : 11284 bytes
Descripción: no disponible
Url : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20090515/b723ed5b/attachment.bin
------------ próxima parte ------------
schema naooperator
uses ptmotors
uses varcolorC
uses ptencoders
uses motors
end_schema
More information about the Jde-developers
mailing list