[Jde-dev] Path tickect #256 NaoOperator

Lun Mayo 11 20:08:18 CEST 2009

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
>
>