[ros-users] erratic gazebo path planning

Tully Foote tfoote at willowgarage.com
Mon May 10 20:06:36 UTC 2010


Hitesh,
As I mentioned in my last email.  Please set both your costmap frames to
"odom". Operating the costmap in the "base_link" frame is not valid.

Tully

On Mon, May 10, 2010 at 10:58 AM, Eitan Marder-Eppstein <
eitan at willowgarage.com> wrote:

> Hitesh,
>
> Sorry to hear that you're having trouble getting things up and running. A
> few things to try:
>
> * Make sure that there are no warnings being printed from the navigation
> stack. You can do this with rxconsole.
> * Run a rostopic echo cmd_vel to see if the navigation stack is publishing
> non-zero velocities. Make sure that the cmd_vel topic is properly connected
> to your robot's base. You can use rxgraph to check if things are connected
> properly
>
> Let me know how things go, we'll figure it out sooner or later.
>
> Hope all is well,
>
> Eitan
>
>
> On Sun, May 9, 2010 at 10:38 PM, hitesh dhiman <
> hitesh.dhiman.1988 at gmail.com> wrote:
>
>> Hi all,
>> Thanks for your reply. Actually we've been trying to get this working on
>> our robot for quite some time now, about a month or so. I think it would be
>> better if I explain the situation to you in detail. Our configuration is as
>> follows:
>>
>> Local and Global costmap Frames:  Local - base_link, Global : odom
>>
>> We are using the simple_navigation_goals package to send goals to our
>> robot.
>> Target frame for the goal: odom
>>
>> The environment is unknown, and we are not using any map.
>> The odometry information is gathered in the form of x, y distance, and yaw
>> angle from the robot, and transformation from odom to base_link is as
>> follows:
>>
>> For distances:
>> x : x_from_odometry - delta_x ,
>> y : y_from_odometry - delta_y ,
>> z : 0
>>
>> For rotation:
>> (0, 0, yaw_angle : yaw_from_odometry - delta_yaw)
>>
>> Here, all the delta values are previous values taken in from the robot.
>> We have a transformation of (000, 000) from base_link to laser, and same
>> for base_link to robot_footprint.
>> While visualizing all this in rviz, we can see that the costmap works,
>> inflated obstacles work, and path planning also works perfectly. For a goal
>> of 2m forward, the path actually curves around obstacles. However, we don't
>> see any local plan, and the robot does not follow the path generated. We've
>> tried changing the parameters, but since the path planning works perfectly,
>> we feel the problem has to be somewhere else.
>> We thought the problem might be with our odometry and velocity data
>> communication with the robot, but we've checked our odometry data and
>> implementation of the velocity commands, and there was no error as such.
>> Initially there was a delay in odom->base_link  and base_link->laser tf,
>> so we tried to do a waitfortransform(odom->base_link) in the
>> base_link->laser tf, and now the buffer for both is 4.014 and 4.007 seconds.
>> The frequency is different for both, (12Hz and 15 Hz).
>> Still no luck.
>> What do you think is the problem here?
>>
>>
>> On Sun, May 9, 2010 at 7:07 AM, Tully Foote <tfoote at willowgarage.com>wrote:
>>
>>> Hitesh,
>>>
>>> These are parameters and you will need to set them appropriately for your
>>> system, they have defaults but there's no other logic.
>>>
>>> If you are not going to be running localization, I would suggest you set
>>> both of them to use odom as their "global_frame".  Using base_link will not
>>> work, that will cause the obstacles to be aggregated in the frame of the
>>> robot, and they won't update as the robot moves past the obstacles.
>>>
>>> Tully
>>>
>>>
>>> On Sat, May 8, 2010 at 12:56 AM, hitesh dhiman <
>>> hitesh.dhiman.1988 at gmail.com> wrote:
>>>
>>>> Hi all,
>>>> Thanks for the help. I checked and compared the costmap parameters file,
>>>> and in our case the laser_marking for base_scan was set to false. Once that
>>>> was set to true, we could see the inflated obstacles and the path planning
>>>> also worked.
>>>> Now, the tf tree for the simulation is as follows:
>>>>
>>>>                                                                       /
>>>> --> /base_laser
>>>>                                                                      /
>>>> /map -----> /odom -------> /base_link ----- /------> /base_caster &
>>>> /base_top
>>>>                                                                     \
>>>>                                                                      \
>>>>                                                                       \
>>>>  --> /base_footprint
>>>>
>>>>
>>>> The next part for us is to run the robot in the real world, but we don't
>>>> have a predefined map. We just want to give the robot a goal of 1m forward
>>>> using simple_navigation_goals in an unknown environment.  We are using the
>>>> robot's actual odometry information.
>>>> So my question is this: in the absence of a /map frame, will /odom be
>>>> the global frame for both global and local costmap? Or will it shift down
>>>> the heirarchy, for example now we have /map and /odom as global frames for
>>>> global and local costmap respectively, will it be /odom and /base_link
>>>> then??
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, May 8, 2010 at 12:57 PM, Anh Tran <anhxuan.tran at gmail.com>wrote:
>>>>
>>>>> Hello Hitesh,
>>>>>
>>>>> Let me elaborate on Anton's reply.
>>>>>
>>>>> 1. You will need several packages from our ua-ros-pkg repository.  It
>>>>> might be easiest to checkout all packages from here (see our wiki pages from
>>>>> same link for instructions): http://code.google.com/p/ua-ros-pkg/
>>>>>
>>>>> <http://code.google.com/p/ua-ros-pkg/>2. Checkout the
>>>>> wubble_navigation package for a demo:
>>>>> http://code.google.com/p/ua-cs665-ros-pkg/source/browse/#svn/trunk/ua_navigation/wubble_navigation
>>>>>
>>>>>
>>>>> <http://code.google.com/p/ua-cs665-ros-pkg/source/browse/#svn/trunk/ua_navigation/wubble_navigation>3.
>>>>> Rosmake wubble_navigation and launch the demos in that package.
>>>>>
>>>>>
>>>>> Checkout this youtube video to see how 2dnav works with our current
>>>>> erratic model: http://www.youtube.com/watch?v=aA0gOd2P5jk
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Anh Tran
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 7, 2010 at 1:20 PM, Antons Rebguns <arebgun at gmail.com>wrote:
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Hi Hitesh,
>>>>>>
>>>>>> We spent some time getting the nav stack working for our erratic robot
>>>>>> both in simulation and real robot. Maybe you can
>>>>>> take a look at this package and see if that works for you.
>>>>>>
>>>>>> You would need ua_navigation stack from
>>>>>> http://code.google.com/p/ua-cs665-ros-pkg/ (specifically look at
>>>>>>
>>>>>> http://code.google.com/p/ua-cs665-ros-pkg/source/browse/trunk/ua_navigation/wubble_navigation/launch/2dnav_wg.launch
>>>>>> launch file) and stuff from http://code.google.com/p/ua-ros-pkg/.
>>>>>>
>>>>>> There are instruction on the wiki how to download and compile
>>>>>> everything, but let me know if you have any questions.
>>>>>>
>>>>>> Anton
>>>>>>
>>>>>> On 05/06/2010 05:08 AM, hitesh dhiman wrote:
>>>>>> > Hi all,
>>>>>> > I'm trying to run the erratic gazebo path planning, using the willow
>>>>>> > garage map provided.
>>>>>> > I'm using all custom parameters. However, the path planning seems to
>>>>>> be
>>>>>> > faltering. It is actually planning a path through the wall, I've
>>>>>> also
>>>>>> > attached a picture showing the path planning.
>>>>>> > Also, the inflated costmap is not being displayed, although the
>>>>>> messages
>>>>>> > are being published and the rviz status says ok.
>>>>>> > Any idea what might be wrong?
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Regards,
>>>>>> > Hitesh Dhiman
>>>>>> > Electrical Engineering
>>>>>> > National University of Singapore
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > ros-users mailing list
>>>>>> > ros-users at code.ros.org
>>>>>> > https://code.ros.org/mailman/listinfo/ros-users
>>>>>>
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>>>>
>>>>>> iEYEARECAAYFAkvkdg0ACgkQ1B2I24nMQmp66QCeOgMh0sQgI465mQfvy4tldGt0
>>>>>> u3QAnjSNBPfRvaQbAz5MorzffBxQ/V2j
>>>>>> =x38F
>>>>>> -----END PGP SIGNATURE-----
>>>>>> _______________________________________________
>>>>>> ros-users mailing list
>>>>>> ros-users at code.ros.org
>>>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ros-users mailing list
>>>>> ros-users at code.ros.org
>>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Hitesh Dhiman
>>>> Electrical Engineering
>>>> National University of Singapore
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Tully Foote
>>> Systems Engineer
>>> Willow Garage, Inc.
>>> tfoote at willowgarage.com
>>> (650) 475-2827
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>>
>> --
>> Regards,
>> Hitesh Dhiman
>> Electrical Engineering
>> National University of Singapore
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100510/53657284/attachment-0003.html>


More information about the ros-users mailing list