[ros-users] erratic gazebo path planning
hitesh dhiman
hitesh.dhiman.1988 at gmail.com
Mon May 10 05:38:17 UTC 2010
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100510/2c663ac3/attachment-0003.html>
More information about the ros-users
mailing list