[ros-users] Fwd: erratic gazebo path planning
hitesh dhiman
hitesh.dhiman.1988 at gmail.com
Tue May 11 02:41:43 UTC 2010
---------- Forwarded message ----------
From: hitesh dhiman <hitesh.dhiman.1988 at gmail.com>
Date: Tue, May 11, 2010 at 10:21 AM
Subject: Re: [ros-users] erratic gazebo path planning
To: ros-users at code.ros.org
Hi Eitan and Tully,
Thanks for the help...
Tully, both the costmap frames have been changed to 'odom' since your
previous mail...
I realized that /move_base/feedback was showing negative values when the
robot travels forward! The issue was with the odometry information. I
removed all the delta_x etc, and now I'm passing the exact x,y and yaw
values. The /move_base/feedback seems to be working and showing correct pose
information.
I can also see the local plan working, and the odometry and footprint also
work correctly in rviz.
So it is a step forward, definitely, and the robot has started following the
path. Almost.
I can see the robot following the path for about 1m and the local plan works
with the robot.
After this the robot just stops. In rviz, i can see the robot footprint has
moved further on the path, but the local plan is stuck somewhere behind.
Rviz shows that no new messages are being published over the local planner
node. The velocity commands are also (0,0).
I don't have the rviz screen capture, but i've created a simple picture to
show it. (The odometry works with the footprint, but was hiding the local
path so i disabled it in rviz.)
Since the planner works from the start, it shouldn't entirely stop just
midway.
I also noticed that the laptop runs at about 100% cpu most of the time(Its a
2.2GHz core2duo and 3gb ram)...could it be that our processing speed is
slow? Since the velocity commands are subscribed to and sent to the robot in
a loop, my guess is that the node will keep sending them with the most
recent values in callback.
On Tue, May 11, 2010 at 4:06 AM, Tully Foote <tfoote at willowgarage.com>wrote:
> 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
>
> _______________________________________________
> 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
--
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/20100511/d40d0c1f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Planner.jpg
Type: image/jpeg
Size: 26520 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100511/d40d0c1f/attachment-0005.jpg>
More information about the ros-users
mailing list