Re: [ros-users] TrajectoryPlannerROS does not take parameter

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
Delete this message
Reply to this message
Author: User discussions
Date:  
To: User discussions
Subject: Re: [ros-users] TrajectoryPlannerROS does not take parameter
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 <
> 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 <>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
>>
>> On Mon, Sep 27, 2010 at 5:55 PM, Patrick Goebel <
>> > wrote:
>>
>>> Hi Eitan,
>>>
>>> No sooner had I sent you that last message that it occurred to me to try
>>> a slower odometry publishing rate on my base controller. I had it set
>>> to 20 Hz but took it down to 10 Hz and now everything is working
>>> beautifully. So I guess the difference between the real robot and the
>>> simulation is that the simulation can keep up with (almost) any rate.
>>> In the meantime, I am tickled to finally have all this working so thanks
>>> again for your help!
>>>
>>> Patrick Goebel
>>> Behavioral Sciences
>>> Stanford University
>>>
>>> > Patrick,
>>> >
>>> > There are two things to try:
>>> >
>>> > 1) Record a bag file of the problem on the robot. Just record
>>> everything
>>> > since it should only take a couple of seconds to see the problem from
>>> > what
>>> > you've been saying. If you send me the bag, I can try to track down
>>> > what's
>>> > going on that way.
>>> >
>>> > 2) Reproduce the problem in simulation. If you can get this to happen
>>> in
>>> > stage in a reproducible manner, that would make it super easy to track
>>> > down.
>>> > You can use the navigation_stage
>>> > (http://www.ros.org/wiki/navigation_stage)
>>> > package as a starting ground, make whatever modifications you want,
>>> > and post
>>> > a patch. I tried this in the morning with your configuration files to
>>> > attempt to reproduce the result, but didn't have any success.
>>> >
>>> > I'm still a bit baffled about my inability to reproduce this in
>>> > simulation
>>> > as I don't see what would be different between that and a real robot.
>>> > Perhaps the bag file will help. I'll also take a pass over the code
>>> > again as
>>> > well to see if there's something glaring that jumps out at me.
>>> >
>>> > Hope all is well,
>>> >
>>> > Eitan
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>>
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>> _______________________________________________
>> ros-users mailing list
>>
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>