Question about Groundplane in Gazebo vs. Rviz

[Steve " 'dillo" Okay]

I've constructed a URDF of my robot that loads into Gazebo successfully. It sticks to the ground and I can teleop it and programmatically have it navigate around the world I've built for it inside Gazebo. The laser_plugin works and the robot is able to detect and respond to objects it encounters in the world.

When I look at it in Rviz though, it's sticking through "the floor". When I bring up a map I've made in the world using gmapping, all the obstacles and features show up on the map, but again, the bottom half of the robot is below the floor, so it ignores all the features it just mapped out when I send it a "2D Nav Goal". It then proceeds to wander through walls trying to get to the goal.

The place where the robot is intersecting the floor is right at the Z coordinate for base_link, which seems suspicious and like it's screaming the answer to this problem out at me, but I can't figure it out. I've posted this also to Gazebo Answers, but I know there's a fair number of ROS-heavy brains here too, so I'm just trying to cover all the bases.
I'm happy to post/send a URDF to interested parties, but didn't want to spam the group right off.
Thanks,
'dillo

[Patrick Goebel]

Hey 'dillo,

Say your base_link is a box. By default, the z=0 coordinate of the box
in RViz will be at the center of that box. So to elevate the robot so
that the bottom of the box is level with the ground, you typically add
another link to your URDF called base_footprint and then a fixed joint
from the base_footprint to the base_link with a z component = 1/2 the
height of the box/base. If your robot has wheels, then you figure the z
component of the base_footprint->base_link joint from the wheel radius
and the wheel's z-offset from the center of the base.

The details are left as an exercise for the reader. :)

--patrick

[Steve " 'dillo" Okay]

I just wanted to get back to everybody on this. I managed to fix it.
I do, in fact, have a robot that does very much look like a box.
I added the base_footprint link as a "naked" link w/ no geometry or other tags,
and then added a joint w/ base_link as the parent and base_footprint as the child.
I then went into the various *_costmap.yaml and *planner* yaml files and edited those to use base_footprint as the robot_reference frame.
My 'bot is now happily rolling on the floor and not under it :)

Thanks!

[Rohan Agrawal]

Add on question since you got it working,

Should the odom tf publisher go from /odom to /base_link or from /odom to /base_footprint?

Rohan

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To post to this group, send email to hbrob...@googlegroups.com.
Visit this group at https://groups.google.com/group/hbrobotics.
For more options, visit https://groups.google.com/d/optout.

--

Rohan

[Ralph Gnauck]

I have always set the transforms like this:

map -> odom->base_footprint->base_link-> <rest of robot parts...>

map, odom and base_footprint all have Z=0 (unless you are actually doing nav in 3d)

base_link is vertically above base_footprint.

I usually make base_link  the center of the drive axle, the place the robot will rotate about at the height of the wheel center (assuming a differential base).

See also ROS REP105 about transform frames, although they don't mention base_footprint

REP 105 -- Coordinate Frames for Mobile Platforms (ROS.org)

REP 105 -- Coordinate Frames for Mobile Platforms (ROS.org)

Ralph

---

From: Rohan Agrawal <send2...@gmail.com>
To: HomeBrew Robotics Club <hbrob...@googlegroups.com>
Sent: Friday, February 3, 2017 7:45 PM
Subject: Re: [HBRobotics] Question about Groundplane in Gazebo vs. Rviz

[Steve " 'dillo" Okay]

On Friday, February 3, 2017 at 7:46:02 PM UTC-8, Rohan Agrawal wrote:

Add on question since you got it working,

Should the odom tf publisher go from /odom to /base_link or from /odom to /base_footprint?

Interestingly enough, looking at the tf-tree in rqt shows it still goes /map->/odom->base_link, which, I think, makes sense.
<collision> tags in your URDF/SDF keep your robot/object "above ground" in Gazebo, but that doesn't get transmitted via a topic or service.
So I think this is all about providing a Z-axis reference to other tools/systems interacting w/ Gazebo and doesn't have anything to do w/ pose or orientation.

I did try parenting the base_footprint_joint to base_footprint early on, but that led to a dual-rooted transform tree and an orphaned /odom.

'dillo

[Patrick Goebel]

Hi Ralph,

When you place the base_link frame at the center of the drive axle, does the move_base planner actually plan rotations around that point?  Or does it plan rotations around the center of the base_footprint frame?

--patrick

-- 
The Pi Robot Project
http://www.pirobot.org/wordpress

[Ralph Gnauck]

Hi Patrick,

I set the 

robot_base_frame: /base_footprint

parameter in local_costmap_params.yaml and global_costmap_params.yaml (and any other nodes that need to use this frame)

to tell the planner etc to use the base_footprint.

The rational for this is as follows:

The frames used in navigation are map->odom->base_...

As I am working in 2D it is simpler to keep everything planar and attached to the ground, so keeping map, odom and base_... with z=0 makes this simple.

Since base_link is supposed to be the main reference point on the robot, I like to think of this as independent of what I am doing with the robot, so the robot model could be used in other ways and this would still be a useful point.

Therefore I set base_link as the center of the axle and at a height at the center of the wheel.

This is then a useful reference for any rotation, around Z or to rotate the robot in roll or pitch if I was going beyond 2D.

However this now means that base_link frame no longer has z=0 when the robot is on the ground, so I add another virtual frame called base_footprint below base_link so that base_footprint does have z=0 when the robot wheels are on the ground.

Then by telling all of the nav nodes to use base_footprint as the robot_base_frame it means all the nav stuff happens with z=0 and then the robot just sits above the base_footprint and follows it around due to the base_footprint -> base_link tf.

A note on Transforms and publishers:

Ok so where do the TFs for all this come from:

First the easy simple version ( yea- like anything is easy and simple in ROS - LOL):

map = global frame (root of TF tree)

map-> odom : this is generated by gmaping or amcl (or what ever nav or mapping nodes you are using).

If you are not doing mapping or nav and just tele-op, ignore map, then odom becomes the root of TF tree.

odom->base_... : This is usually created by the base driver node, for most simple robots this is based on the wheel odometry, the origin=0,0,0 is just the starting position of the robot, the x,y,z, roll,pitch,yaw are then just integrated from the wheel odometry based on dead reckoning.

Generating odom->base_... is simpler if base_... has z=0, then just the x,y cords need to be generated, and the z rotation is around the base_... frame z axis, this is a good reason for using base_footprint if base_link does not have z=0 when the robot is on the ground.

base_footprint->base_link : this can be in the URDF or just a static_transform_publisher in a launch file.

base_link-> <rest of robot> : usually defined in URDF

Note: to publish TFs for the joints in the URDF use the robot_state_publisher node.

Now the more complex version I know some people are starting to try:

To get more complex some robots are now using IMUs and GPS, this changes how things get done.

IMU:

First to use an IMU it is common to use the robot_localization package to integrate it with the odometry, this changes how odom->base_... gets published.

odom->base_... : now gets published by the robot_localization node, so the base_driver must be told to not publish this TF anymore, most drivers have a param that can tell it to stop publishing the odom tf. Base driver still publishes an odom message (but now to odom_raw topic, not odom) and the robot_localization node gets this and the imu messages, integrates them and generates a new filtered odom message and the odom->base_... TF.

All of the nav, tele-op etc nodes need to make sure they are now also listening/publishing to the new correct set of topics and TF frames.

GPS:

using a GPS changes how the map->odom tf gets published, it requires a second instance of the robot_localization node (assuming you are already using one to integrate an IMU).

I will not go into to much detail as I have never done this so don't want to miss lead anyone. I have not looked at how this is used in conjunction with other mapping or nav nodes.

Other Notes on robot_localization:

Using the robot_localization node is really a big step in complexity for your robot. As well as the TF related changes noted above the node really only works properly if the data in the messages and the params set on the robot_localization nodes are properly configured including proper and meaningful sensor data co-variance matrices.

Without this data you will probably get worse results than not using the data at all.

You can try to guess these values - put small values ~ 0.01 etc on the diagonal elements of these matrices - but your results may vary.

It is best to actually perform measurements of the variance of each param (at least the ones you are using) and use these.

I think it is this part that makes this hard for most novices (myself included) and is beyond the scope of this message. Probably best left for another advanced training class from SV-ROS.

I hope this will help some of you that are working on this - most likely I have just confused you more, sorry - thats just the way ROS is 8>), good luck.

Ralph

---

From: Patrick Goebel <pat...@pirobot.org>
To: hbrob...@googlegroups.com
Sent: Saturday, February 4, 2017 7:29 AM

[Michael Wimble]

Thanks very much for the help. Now if you’d like a free dinner, come spend a couple hours with me and my bot and further de-confuse me.

[Mark Johnston]

Ralph:  This is a GOLDEN post.   Clear and with logic explained along with practical reasons for this approach.  Thank you so very much.   A true cut and paste long term keeper.  Thanks.

[Patrick Goebel]

Hi Ralph,

Thanks for your reply--I agree with Mark that this is an awesome explanation and should be preserved somewhere--maybe on the ROS Wiki?

--patrick