Brian,
    Thanks a ton for the tip, it took care of the timeout problem. However the localizeproxy problem still remains. It seems that no matter where I place the robot in the mapped environment, the localizeproxy always returns 0 as the number of hypothesis'. I ran the test_localize program that you posted online at

 http://www.koders.com/cpp/fidA9A5898AB36EE7608D7BA7058654628499820D5C.aspx

and got the following error message

DRIVER:amcl
waiting for the localization system to start up ... pass
setting the pose ...pass
getting the number of particles.. fail

which means that localize proxy is getting a negative number of particles, would you have any insight as to why this might be happening? I viewed the mapfile, and it seems fine and there was no error while building the map. Im finding it difficult to localize the problem (no pun intended).
                 Lovekesh
                                                        

                                   
                   




On 2/28/06, Brian Gerkey <brian@gerkey.org> wrote:

On Feb 23, 2006, at 11:37 PM, Lovekesh Vig wrote:

> Hi,
>  I was trying to utilize the plannerproxy with the wavefront driver
> for global path planning but seem to be running into an error. When
> I invoke the plannerproxy.SetCmdPose() function  from the  client
> for the first time player builds the cspace from the map but then
> on the client side I get the following error
>
>
> 'got unexpected zero length reply'

You might be hitting a timeout on the request if the cspace
generation takes a long time.  The wavefront driver caches the cspace
info in the file player.cspace, so this should only be a problem the
very first time you try to plan a path.  In fact, what you can do is
start player once with the wavefront driver 'alwayson' just to
generate the player.cspace file.  Then you'll have the cspace info
ready immediately (assuming the map doesn't change).

> on subsequent runs the start_x, start_y ,start_theta values change
> every time, even though the robot is stationary and there is no
> change in the environment, which implies the localize proxy is not
> working properly and is giving a diferent reading each time.

Has the localization system converged to an obviously dominant
hypothesis?  If the particles are distributed over a large area, then
there's no telling what pose estimate you'll get.  On the other hand,
I don't think that the pose estimate should change when the robot
doesn't move....

        brian.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Playerstage-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users