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

map / navigate on a different axis / plane

asked 2021-10-20 07:45:30 -0600

ekptwtos gravatar image

updated 2021-10-29 05:39:18 -0600

Hello everyone,

first of all I would like to thank you for such a great forum, it has helped me solve many issues in the past!

I have questions that could be caused by my luck of understanding how the mapping is performed. What i am trying to do is map a wall as it was the ground.

I have a wall crawler and I would like to add the ability to perform autonomous navigation - on the wall - with it.

Crawler setup: chassis with 4 wheels, depth camera and tracking module mounted in front ( Intel realsense d435i, and realsense t265 ) ROS Version: Noetic running on ubuntu 20.04 Packages: depthimage_to_laserscan, gmapping and move_base - basic stuff.

When testing the crawler on the floor mapping and navigation work fine, but when trying to "map the wall" ( effectively rotate the robot by 90 degrees along x axis ), the occupancy map is filled with black cells, as i am guessing it "sees" the wall but identifies it as obstacle.

Other things I tried:

  • using rtabmap_ros as well but I get pretty similar results
  • adding a world frame in between the map and base of the robot and rotating it by 90 degusing a static tf from map to world ( map -> 90 world -> base )

Can this be achieved using gmapping / rtab or any other package? If so, could you please provide any pointers on what changes I have to make in order to achieve this? If not, can you suggest an alternative approach to tackle that?

EDIT1:

Default setup ( map -> t265 odom -> base ), cameras facing the ceiling and fixed frame in RVIZ set to map

image description

Here is the full tf tree of that setup

Here is the 90 map rotation setup (world -> 90 map -> t265 odom -> base ), cameras facing the ceiling and fixed frame in RVIZ set to world.

image description

Here is the full tf tree of that setup

Thank you in advance for your time and effort you might put in trying to assist me.

Best,

Mike

edit retag flag offensive close merge delete

Comments

Seems that you got a TF initialisation that cause this effect. Your frame "map" shouldn't be rotated. On rtabmap, watch out the parameters that define the height of ground and obstacle, it directly impact the map generation.

TomSon gravatar image TomSon  ( 2021-10-20 08:45:17 -0600 )edit

Hello and thanks for the reply, I have checked the values, but these - as i understand - are good if you have an uneven ground. The only reason i tried to rotate the world frame IRT the map by 90, is because i am trying to "map" the wall, not the floor ( or ground ).

ekptwtos gravatar image ekptwtos  ( 2021-10-21 05:26:16 -0600 )edit

I think you should do 90 world -> map -> odom -> base, so that all mapping stuff will work in standard z->up. rosrun tf static_transform_publisher 0 0 0 0 -1.57079632679 0 world map 100

matlabbe gravatar image matlabbe  ( 2021-10-21 13:42:33 -0600 )edit

oh for some reason i didnt get a notification for your comment! will try this next time i get the chance and post results!

ekptwtos gravatar image ekptwtos  ( 2021-10-26 07:31:33 -0600 )edit

@matlabbe I did try rotating the map WRT the world, however didn't get any different results :-/ Please see updated post!

ekptwtos gravatar image ekptwtos  ( 2021-10-29 05:41:21 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
2

answered 2021-11-03 20:16:50 -0600

matlabbe gravatar image

updated 2021-11-03 20:30:01 -0600

Hi,

You have to make T265 odometry to work in z->up, y->left, x->forward when the camera is looking up. Add the following just here to add 90 degrees pitch in odometry output:

tf::Transform p;
tf::poseMsgToTF(pose_msg.pose, p);
tf::Quaternion q;
q.setRPY(0, 1.57079632679, 0);
p = tf::Transform(q) * p;
tf::poseTFToMsg(p, pose_msg.pose);

When the robot will be moving up on the wall, the mapping part will think the robot is moving forward, then the occupancy grid should match the wall. You can add world->map 90deg transform if you want the resulting map put back in correct orientation. (rosrun tf static_transform_publisher 0 0 0 0 -1.57079632679 0 world map 100)

edit flag offensive delete link more

Comments

Thank you very much! That is exactly what I had been looking for. So if I am getting this right, the orientation of the odometry frame is the catalyst here. With the properly rotated odom frame I could use any of the mapping / navigation packages? Could this be replicated without the t265 by just using the d435i without any odom frame?

ekptwtos gravatar image ekptwtos  ( 2021-11-05 10:43:15 -0600 )edit

Yes, this should work with any other slam packages. The odometry rotation may not be needed if your odometry starts already with zero rotation. The problem here is that T265's VIO aligns always odometry with gravity on start because it uses the IMU. For general visual odometry approaches (without IMU), no rotation would be required, just make sure to initialize the odometry when the robot is already on the wall.

matlabbe gravatar image matlabbe  ( 2021-11-08 09:22:39 -0600 )edit

Question Tools

2 followers

Stats

Asked: 2021-10-20 07:45:30 -0600

Seen: 319 times

Last updated: Nov 03 '21