The Player Project

Hi,

I am trying to use the amcl gui to do some debugging, but when adding
the corresponding line to the driver and running player I get this
warning:

field [enable_gui] is defined but not used

and the gui doesn't show. I have recompiled using the --enable-rtkgui a
couple of times but made no difference. I have tried to use the cvs
version but have an "undefined symbol" problem...

I am using Player 2.0.4. with Gazebo 0.7.0 (when I run it, it says 0.9.0
though) on a Ubuntu Gutsy system.

This is my definition of the amcl driver

driver
(
  name "amcl"
  provides ["position2d:2" "localize:0"]
  requires ["odometry:::position2d:1" "laser:0" "laser:::map:0"]
  update_thresh [0.05 5]
  enable_gui 1
)


Help!

Thank you,

Alberto

*update*

This problem does not occur on my Kubuntu PC.

So my solution has been to throw centOS out of the lab :)

Joe

> ------------------------------
> 
> Message: 4
> Date: Wed, 28 Nov 2007 12:00:19 +0000
> From: Joseph Baxter <jlb@...>
> Subject: Re: [Playerstage-users] wavefront cvs 1.61
> To: playerstage-users@...
> Message-ID: <474D5853.7000908@...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Thanks but I still get the same error.
> 
> Looks like I have an exciting afternoon of debugging ahead of me  :( 
> 
> Joe
> 
> Toby Collett wrote:
>> > Message: 1
>> > Date: Wed, 28 Nov 2007 08:32:19 +1300
>> > From: "Toby Collett" <tcollett+player@...>
>> > Subject: Re: [Playerstage-users] wavefront cvs 1.61
>> > To: playerstage-users@...
>> > Message-ID:
>> > 	<97b8070e0711271132r31e48fdcg4d2ecac9e4cef13c@...>
>> > Content-Type: text/plain; charset="iso-8859-1"
>> >
>> > This is very odd, the pointer in msg in line two, is passed directly as src
>> > in line 1, the fact that the address changes implies that their is some sort
>> > of stack corruption
>> >
>> > #1  0x009f30d1 in player_map_data_t_copy (dest=0x71ce7008, src=0xffffffff)
>> > at playerxdr.c:10745
>> > #2  0x009f3158 in player_map_data_t_clone (msg=0xbfaa9614) at playerxdr.c
>> > :10759
>> >
>> > I found a free that shouldnt have been there in the failed to get map case.
>> > This hopefully has fixed the mem corruption/segfault, but may not have fixed
>> > the failure to get the map. Let me know how it goes.
>> >
>> > Toby
>> >
>> >   
> 
> 
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses, which could damage your computer system:
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.
> 
> 
> 
> 
> ------------------------------


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Hello Siyang,


On Thu, 29 Nov 2007, syt wrote:

>
> Hello Everyone,
>
>
> When running this function on the simulation, the time it spends is
> reasonably small, which is good. However, if this function is run to set a
> real robot odometry, it normally takes much longer time. Maybe this partly
> depends on the speed of the CPU?
>
"Any ideas" were asked, so here is my guess:

Drivers behind position2d interface are different in the simulation and
in the real robot. In simulation I guess you can set new value for
odometry when ever you want, but in real robot you would be working in
real time and probably driver have to wait for right moment for update not
to mess motor control algorithm or velocity measurement.

T.Tapio