<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Eitan and Eric,<br>
<br>
I have confirmed that the problem returns when I go back to publishing
my odometry at 20 Hz and the problem disappears when I drop it down to
10 Hz. I created two bag files under the two conditions. The first
file (by date) is at 20 Hz and you can see the robot oscillating all
around one of the goals while the angular velocity exceeds the set
limit of 1.0. The second bag file was collected with odometry running
at 10 Hz and the robot's behavior was flawless. I should point out
that I am connecting to the Serializer board on the robot using
(non-Pro) XBee radios while running ROS on my PC. The radios are
communicating at 19200 baud and are about 10-20 feet apart during
testing.<br>
<br>
I placed the two bag files at the link below:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.pirobot.org/code/debug/">http://www.pirobot.org/code/debug/</a><br>
<br>
Let me know if you need any of my source files as well as I would be
happy to post them.<br>
<br>
Thanks!<br>
Patrick Goebel<br>
Behavioral Sciences<br>
Stanford University<br>
<br>
<blockquote type="cite">Just a brief update,
<br>
<br>
I had stage publish odometry information at 20.0Hz and could not get
the
<br>
commanded velocity to go outside the limits. So, I'm still unable to
<br>
reproduce the problem.
<br>
<br>
-Eitan
<br>
<br>
On Mon, Sep 27, 2010 at 3:36 PM, Eitan Marder-Eppstein <
<br>
<a class="email-address" href="mailto:eitan@willowgarage.com">eitan@willowgarage.com</a>>
wrote:
<br>
<i class="quote"><br>
> Patrick,
<br>
>
<br>
> First off, I'm glad things are working, but I'm also surprised
that the
<br>
> rate at which odometry publishes has anything to do with the
<br>
> base_local_planner respecting maximum velocity limits. I'll try
upping the
<br>
> rate that stage publishes odometry information to see if I can
reproduce
<br>
> this, but our robot also publishes odometry information at 30Hz
and, much
<br>
> like Eric, we don't see this problem. Also, like Eric asked, I'd
love to
<br>
> know if changing the odometry rate back to what it was reliable
causes this
<br>
> failure... I'd just really like to track down what's going on. Its
just a
<br>
> really strange solution to the problem.
<br>
>
<br>
> Thanks a bunch,
<br>
>
<br>
> Eitan
<br>
>
<br>
>
<br>
> On Mon, Sep 27, 2010 at 3:24 PM, Eric Perko <<a
class="email-address" href="mailto:wisesage5001@gmail.com">wisesage5001@gmail.com</a>>wrote:
<br>
>
<br>
>> Patrick,
<br>
>>
<br>
>> Can you confirm that changing just your odometry publishing
rate back to
<br>
>> 20Hz causes the failure? The last person with a similar
problem was unable
<br>
>> to reproduce when he changed his lidar rate back to what it
was previously.
<br>
>> Also, I'm a bit surprised that lowering your odometry rate
fixed things - I
<br>
>> publish odometry at 50Hz and don't see this sort of problem...
<br>
>>
<br>
>> - Eric
<br>
>>
</i></blockquote>
<br>
</body>
</html>