Patrick,

I took a look at your bag files and have discovered a pretty serious looking problem with your odometry at 20Hz. When plotting your reported angular velocity (rxplot /odom/twist/twist/angular/z), I noticed many large spikes in it (faster than -25 at one point... that's a _crazy_ number of radians/sec :) ); this type of noise is definitely not a good thing and might be throwing off the navigation stack (pretty sure it assumes you have well-behaved odometry data). Since that magnitude of spike isn't present in the 10Hz version, you may want to make sure that your velocity calculations are not making assumptions about loop closure rates for their dt. For example, if every once in a while, due to timing problems you actually see 2-3 dt worth of angle change in a single loop and then divide by dt, you will get a completely incorrect velocity; I saw behavior just like that on my real-time controller when we accidentally stuck some non-deterministic code in the real-time loop.

Also, the -o flag for rosbag record can be handy when sharing bag files - it can give a descriptive prefix to the bag file, such as 'odometry_at_20_hz...'. See http://www.ros.org/wiki/rosbag/Commandline#record for details.

Hope that helps.

- Eric

On Mon, Sep 27, 2010 at 7:46 PM, Patrick Goebel <patrick@casbs.stanford.edu> wrote:
Hi Eitan and Eric,

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.

I placed the two bag files at the link below:

http://www.pirobot.org/code/debug/

Let me know if you need any of my source files as well as I would be happy to post them.

Thanks!

Patrick Goebel
Behavioral Sciences
Stanford University

Just a brief update,

I had stage publish odometry information at 20.0Hz and could not get the
commanded velocity to go outside the limits. So, I'm still unable to
reproduce the problem.

-Eitan

On Mon, Sep 27, 2010 at 3:36 PM, Eitan Marder-Eppstein <
eitan@willowgarage.com> wrote:

> Patrick,
>
> First off, I'm glad things are working, but I'm also surprised that the
> rate at which odometry publishes has anything to do with the
> base_local_planner respecting maximum velocity limits. I'll try upping the
> rate that stage publishes odometry information to see if I can reproduce
> this, but our robot also publishes odometry information at 30Hz and, much
> like Eric, we don't see this problem. Also, like Eric asked, I'd love to
> know if changing the odometry rate back to what it was reliable causes this
> failure... I'd just really like to track down what's going on. Its just a
> really strange solution to the problem.
>
> Thanks a bunch,
>
> Eitan
>
>
> On Mon, Sep 27, 2010 at 3:24 PM, Eric Perko <wisesage5001@gmail.com>wrote:
>
>> Patrick,
>>
>> Can you confirm that changing just your odometry publishing rate back to
>> 20Hz causes the failure? The last person with a similar problem was unable
>> to reproduce when he changed his lidar rate back to what it was previously.
>> Also, I'm a bit surprised that lowering your odometry rate fixed things - I
>> publish odometry at 50Hz and don't see this sort of problem...
>>
>> - Eric
>>


_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users