ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

How can I fix my base_link to the z axis?

asked 2022-03-29 12:58:25 -0500

hallalay gravatar image

updated 2022-04-17 09:45:54 -0500

lucasw gravatar image

I am trying to make a self-navigating robot using slam gmapping and the navigationstack. The robot uses a zed stereo camera to navigate. the robot creates good laserscans and can also create maps. However, the tf of my base_link and base_frame drifts away from the map sometimes in the z axis. Im wondering if you could constrain it from not moving in the z-axis, so that even when the camera moves upwards, my program handles it as being on the same level as before.

Because now, as soon as my robot tilts, moves upward or anythin, it gets lost and stops creating a map...

edit retag flag offensive close merge delete

Comments

Please edit your description to tell us the frame names in your transform tree from map down to `base_link. Also tell us what base_frame is, since that is not a standard name. Your problem is most likely that you are not correctly updating one of the parent frames of base_link.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2022-03-29 14:10:20 -0500 )edit

Hi! I'm very new to ros, but i guess your talking about the tree you get from running "tf view_frames"? if that's the case, my tree goes from map-> odom -> baselink which then splits to zed_base_link and base_frame. I'm actully not sure what my base_frame is, I don't think it serves any purpose to be honest...

To give some more information, my base_link isn't restricted to odom when i'm looking at rviz. I assume my laser always should be connected to odom. Odom on the other hand doesn't drift away from the map, so if I could restrict my base_link to odom in one way I guess it would work...?

hallalay gravatar image hallalay  ( 2022-03-29 14:27:29 -0500 )edit

Your TF Tree is typical.Assuming it is solidly mounted on the robot, the TF of your lidar should be a child of base_link.

What do you mean that "my base_link isn't restricted to odom when I'm looking at riviz"?

Mike Scheutzow gravatar image Mike Scheutzow  ( 2022-03-29 18:50:44 -0500 )edit

I mean that my base_link isn't linked to the odom tf. I want them to be linked? connected? Hard to explain, but the tf of base_link should always be on the same place and orientation as odom. If odom moves I want the base_link to move with it, but now they both move independantly.

I have tried to connect them using the "transform publisher" with odom as the parent and base_link as the child, but that doesn't work. I'm sorry if that's a bad description...

hallalay gravatar image hallalay  ( 2022-03-30 03:02:17 -0500 )edit

The base_link frame IS "linked" to odom because base_link declares the odom frame as its parent. You told us that your TF Tree shows that. Is your problem occurring while you do the gmapping, or afterward when you are trying to navigate using the generated map?

Mike Scheutzow gravatar image Mike Scheutzow  ( 2022-03-30 11:30:35 -0500 )edit

It's occurring when I'm doing the gmapping, and that is what I'm struggling with. I have ran the tf tree several times, but it always shows that odom is a parent of base_link... Could there be anything else or should they move together if they are parent and child?

Could include that even though map is parent to odom, map doesn't move with odom either

Could I maybe send a video or anything, if there's anything missing?

hallalay gravatar image hallalay  ( 2022-03-30 11:36:22 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2022-03-30 16:13:17 -0500

Mike Scheutzow gravatar image

updated 2022-03-31 07:50:49 -0500

gmapping requires that your robot independently estimate its current pose as it moves around. The usual way that is done is to integrate the readings from the wheel axel encoders; that updates the pose of the robot's base_link frame. These updates are expected to have z=0, so therefore the base_link z remains at 0.

This estimated robot pose is an important input to the gmapping code. It has to be roughly correct or your map will be very distorted because walls be be "drawn" in the wrong place.

Update: I don't believe gmapping will work without independent sources of robot-pose and scan data. That word "independent" means you can't use data from a single sensor to determine both things. I suggest you look at how the algorithm works - it's not that complicated.

edit flag offensive delete link more

Comments

Ok, I believe my robot estimates comes from the zed cameras pose estimate, which isnt restricted to z=0. I will try to find a way to force it to z=0. But you don't think there is an other solution? fusing base_link to odom, so they always stay on the same position?

hallalay gravatar image hallalay  ( 2022-03-30 16:26:56 -0500 )edit

As my motors don't have any encoders, I can't use that for pose estimation. But the camera does a pretty good job at estimating itself, so if I could just force it to the z-axis It wouldn't be a problem...

Or is it possible to manually define an axis orientation with a command? in that way I could define the base_link z coordinate to always be 0?

hallalay gravatar image hallalay  ( 2022-03-30 16:29:01 -0500 )edit

The gmapping is working "kind of" properly. It does the job if I keep the camera on the same level all the time, but if it runs over a bump things gets weird. But I will look into it a bit more. Thanks!

hallalay gravatar image hallalay  ( 2022-03-31 08:05:12 -0500 )edit

I am extremely stupid. There is a param in the zed common.yaml file that says, "two_d_mode" "if true the z value will be fixed to "fixed_z_value", roll and pitch to zero." Sorry for wasting your time, but you gave me a better understanding for the gmapping node, so it wasn't all wasted haha!

hallalay gravatar image hallalay  ( 2022-03-31 09:59:44 -0500 )edit
0

answered 2022-03-31 12:07:29 -0500

hallalay gravatar image

I am extremely stupid. There is a param in the zed common.yaml file that says, "two_d_mode" "if true the z value will be fixed to "fixed_z_value", roll and pitch to zero."

edit flag offensive delete link more

Question Tools

Stats

Asked: 2022-03-29 12:58:25 -0500

Seen: 173 times

Last updated: Mar 31 '22