playerstage-users

Hi all,
I'm having trouble (understatement... I'm now on about day 7!) getting
playernav working properly.
I can drag and drop the robot icon on the map to set a new localisation
hypothesis, but I don't see any convergence of particles on the map.
In fact, the particles remain completely static unless I command the
robot to move. When I move the robot in gazebo the red localization
circle in playernav expands... but it never ever contracts and so
doesn't converge.
Oddly enough if I set a new localization hypothesis the particles/circle
snaps back to a regular small size (no matter where I put it). After
that it remains static until I move the robot, whereupon the
localization circle gets bigger until the robot stops moving, and then
it's back to static again (no convergence).
Can anyone explain what's going on? Either I'm confused as to what
should actually be happening, or it's not working like it should. I was
expecting the particles to converge to roughly the robot's actual
position in gazebo...
Thanks for your help.
Solly
ps. some other points which might be relevant:
* I can set goals with the planner but no paths are ever found, even
between points right next to each other
* I'm using the same map image for playernav that I use to build the
walls of the room in gazebo (except black/white are reversed), so the
correspondance between the laser readings and the map is excellent.
* I get a couple of error messages from player when I run playernav:
success
Gazebo driver creating 1 device
6665.31.0 is gz_client.c:122 opening /tmp/gazebo-sollyb-0
gz_iface.c:214 opening /tmp/gazebo-sollyb-0/sim.default 060 180
Gazebo driver creating 1 device
6665.4.0 is Gazebo driver creating 1 device
6665.2.0 is Gazebo driver creating 1 device
6665.6.0 is Listening on ports: 6665
accepted client 0 on port 6665, fd 6
MapFile loading image file:
/export/serpent/1/sollyb/code/gazebo/worlds/./room.gif...Done.
MapFile read a 256 X 256 map, at 0.100 m/pix
gz_iface.c:214 opening /tmp/gazebo-sollyb-0/position.robot1 060 304
gz_iface.c:214 opening /tmp/gazebo-sollyb-0/laser.laser1 060 5036
gz_iface.c:214 opening /tmp/gazebo-sollyb-0/laser.laser1 060 5036
warning : Unhandled message for driver device=16777343:6665:4:0 type=3
subtype=2 len=1
warning : failed to forward config request with subtype: 2
warning : Unhandled message for driver device=16777343:6665:4:1 type=3
subtype=2 len=1
warning : failed to enable motors
Wavefront: Loading map from map:0...
Done.
* My config file is:
driver
(
name "gazebo"
provides ["simulation:0"]
plugin "libgazeboplugin"
server_id 0
alwayson 1
)
driver
(
name "gazebo"
provides ["odometry:::position2d:0"]
gz_id "robot1"
)
driver
(
name "gazebo"
provides ["power:0"]
gz_id "robot1"
)
driver
(
name "gazebo"
provides ["laser:0"]
gz_id "laser1"
)
driver
(
name "vfh"
provides ["position2d:1"]
requires ["odometry:::position2d:0" "laser:0"]
safety_dist_0ms 0.1
safety_dist_1ms 0.1
distance_epsilon 0.3
angle_epsilon 5
)
driver
(
name "mapfile"
provides ["map:0"]
filename "room.gif"
resolution 0.1 # 10cm per pixel
negate 1 # using same map as the terrain image in gazebo
)
driver
(
name "amcl"
provides ["localize:0" "position2d:2"]
requires ["odometry:::position2d:1" "laser:0" "laser:::map:0"]
#init_pose [-10.0 1.0 0.0]
#init_pose_var [1.5 1.5 50]
)
driver
(
name "wavefront"
provides ["planner:0"]
requires ["output:::position2d:1" "input:::position2d:2" "map:0"]
)

On Mar 20, 2006, at 4:26 PM, Solly Brown wrote:
>
> I'm having trouble (understatement... I'm now on about day 7!)
> getting playernav working properly.
>
> I can drag and drop the robot icon on the map to set a new
> localisation hypothesis, but I don't see any convergence of
> particles on the map.
>
> In fact, the particles remain completely static unless I command
> the robot to move. When I move the robot in gazebo the red
> localization circle in playernav expands... but it never ever
> contracts and so doesn't converge.
>
> Oddly enough if I set a new localization hypothesis the particles/
> circle snaps back to a regular small size (no matter where I put
> it). After that it remains static until I move the robot, whereupon
> the localization circle gets bigger until the robot stops moving,
> and then it's back to static again (no convergence).
The behavior regarding the pose-setting is correct. When you drag
and drop the robot's pose, playernav re-initializes the particle
filter with that pose and some hardcoded covariance, around 0.5 meter
each in X and Y and 30 degrees in theta. So every time you set a new
pose, you'll get approximately the same-sized particle cloud.
Thereafter, the filter only updates when the robot moves. If it were
to update without moving, it would overcount observations (and likely
overconverge). If you'd like a smaller covariance on the pose-set
action, change the values in the array 'cov' in _robot_button_callback
() in utils/playernav/gui.c. A patch that makes these values
configurable (e.g., via command-line option or men item) would be
happily accepted.
As for the particle cloud growing when you move the robot, that could
be several things, such as a mismatch between the scale of the map
used by amcl and the scale of the map used by Gazebo. On that topic,
a great feature addition to Gazebo would be to support the 'map'
interface and return a 2-D occupancy grid map of the groundplane.
Stage does this now, which relieves the user of specifying the scale
in two places.
Alternatively, your problem could be due to a small change made in
amcl right before the release. Try adding the following options to
the 'amcl' block in your .cfg file:
odom_drift[0] [0.2 0.0 0.0]
odom_drift[1] [0.0 0.2 0.0]
odom_drift[2] [0.2 0.0 0.2]
>
> * I can set goals with the planner but no paths are ever found,
> even between points right next to each other
That sounds very suspicious. Are you sure you've got the right black/
white pixel semantics in the map? For mapfile, white is free and
black is occupied (use the negate option if your image file is
reversed).
>
> * I get a couple of error messages from player when I run playernav:
> warning : Unhandled message for driver device=16777343:6665:4:0
> type=3 subtype=2 len=1
>
> warning : failed to forward config request with subtype: 2
>
> warning : Unhandled message for driver device=16777343:6665:4:1
> type=3 subtype=2 len=1
>
> warning : failed to enable motors
That's okay; Gazebo doesn't support the "enable motors" request
(because its motors are always enabled).
One other thing you might try is giving the robot's odometry
(position2d:0) as input to wavefront, rather than vfh. The latter
should pass through the odometry information, but it wouldn't hurt to
take out the middle-man there.
brian.

Brian,
Thanks for your feedback... it was extremely helpful in pinpointing the
problem. =-)
It turned out that there was a problem with the map, but not the
black/white semantics or the resolution (both were ok). Instead it seems
that playernav doesn't like gif images... at least the ones I generate
with Gimp. Saving the image as a pgm file makes everything work like a
charm.
Haven't found mention in the archives of anyone else having problems
with gif images, so perhaps it's just something wacky about my system.
Thanks again,
Solly
Brian Gerkey wrote:
> The behavior regarding the pose-setting is correct. When you drag and
> drop the robot's pose, playernav re-initializes the particle filter
> with that pose and some hardcoded covariance, around 0.5 meter each in
> X and Y and 30 degrees in theta. So every time you set a new pose,
> you'll get approximately the same-sized particle cloud. Thereafter,
> the filter only updates when the robot moves. If it were to update
> without moving, it would overcount observations (and likely
> overconverge). If you'd like a smaller covariance on the pose-set
> action, change the values in the array 'cov' in _robot_button_callback
> () in utils/playernav/gui.c. A patch that makes these values
> configurable (e.g., via command-line option or men item) would be
> happily accepted.
>
> As for the particle cloud growing when you move the robot, that could
> be several things, such as a mismatch between the scale of the map used
> by amcl and the scale of the map used by Gazebo. On that topic, a
> great feature addition to Gazebo would be to support the 'map'
> interface and return a 2-D occupancy grid map of the groundplane.
> Stage does this now, which relieves the user of specifying the scale in
> two places.
>
> Alternatively, your problem could be due to a small change made in amcl
> right before the release. Try adding the following options to the
> 'amcl' block in your .cfg file:
>
> odom_drift[0] [0.2 0.0 0.0]
> odom_drift[1] [0.0 0.2 0.0]
> odom_drift[2] [0.2 0.0 0.2]
>
>>
>> * I can set goals with the planner but no paths are ever found, even
>> between points right next to each other
>
>
> That sounds very suspicious. Are you sure you've got the right black/
> white pixel semantics in the map? For mapfile, white is free and black
> is occupied (use the negate option if your image file is reversed).
>
>>
>> * I get a couple of error messages from player when I run playernav:
>> warning : Unhandled message for driver device=16777343:6665:4:0
>> type=3 subtype=2 len=1
>>
>> warning : failed to forward config request with subtype: 2
>>
>> warning : Unhandled message for driver device=16777343:6665:4:1
>> type=3 subtype=2 len=1
>>
>> warning : failed to enable motors
>
>
> That's okay; Gazebo doesn't support the "enable motors" request
> (because its motors are always enabled).
>
> One other thing you might try is giving the robot's odometry
> (position2d:0) as input to wavefront, rather than vfh. The latter
> should pass through the odometry information, but it wouldn't hurt to
> take out the middle-man there.
>
> 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@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-users