0
$\begingroup$

Rosanswers logo

I'm running RTABMap and mapping is working correctly with Lidar, odometry and RGBD sensor data. In order to overlay the generated map with a CAD model, I need to transform the map frame into the CAD models/lab environments custom coordinate system.
I'm using Apriltag markers with known (a priori) coordinates relative to the custom coordinate system and detect them while mapping. The translation part of the transformation from map_frame to my custom coordinate system origin is working fine with the help of Marker/Priors in RTABMap (see original question here). See this for the documentation regarding the parameter in RTABMap. Basically what this param does is, that one can input global coordinates and RTABMap will translate the map_frame according to the local tag detection coordinates and their corresponding global coordinates. Unfortunately, Marker/Priors will not rotate the map_frame into my custom coordinate system, because this is breaking REP105/3 by using custom coordinate systems instead of ROS coordinate system definitions and that's why it is not supported in RTABMap.

Is there a way to add the correct rotation manually while or after mapping by checking for the map_frame orientation and comparing the differences to the fixed custom coordinate system and then applying the right rotation angles?

Or, can I guarantee by modifying the map_framethat a fixed coordinate direction related to my environment is always present in the map_frame, based on the cardinal directions or other constraints? Normally, the direction and origin of the ROS coordinate frame is dependend on the starting angle/direction of the camera.
A small example, I want to achieve that the x-axis always points to the north, y always points to the east etc. while or after the mapping process. This would help, because I would just need to rotate axes in a static transform, because the rotation would be constant with this solution for every scan I do.
For better visualization, I quote this comment from https://answers.ros.org/question/382051/the-relationship-of-earth-frame-and-map-frame/:

If you build a map with rtabmap and save it, you can then calculate the static rotation needed based on where the map x-axis ended up. Doing this dynamically is more difficult: you will need to read the initial magnetic orientation of the robot once before you begin the rtabmap mapping procedure.

I've tried to find out how I can implement it this way by asking the following question under the above mentioned answers.ros post:

Can you explain to me how to calculate the static rotation from RTABMap map_frame to my own custom coordinate system? How do I find out, where the axes of the ROS coordinate system point to after running rtabmap and/or dynamically and how much I need to rotate it to fit my custom coordinate system?
The translation part is already working inside RTABMap with the help of Marker/Priors parameter by setting global coordinates for the known accurate positions of the markers and detecting exactly these markers in local coordinates in the map_frame. This translates the coordinate origin to the right origin of my global coordinate system. Unfortunately, the rotation does not work. Can I do this with the help of your suggestion and export/apply the rotation somehow on to the map_frame while mapping or afterwards?

Unfortunately the thread was locked before and I guess that notifications aren't sent to the users anymore. That's why I quoted it here to give a better context of my thought process and research and to maybe get it answered here as well.

If this should be in seperate posts, I apologize for this and will change it accordingly. I will initially post it like this, because I think all these questions are related closely to each other.

Edit: The RTABMap parameter Marker/Priors supports computing these rotations as well contrary to my belief.

Best regards
xdzye


Originally posted by xdzye on ROS Answers with karma: 15 on 2023-01-19

Post score: 1


Original comments

Comment by Mike Scheutzow on 2023-01-20:\

Marker/Priors will not rotate the map_frame into my custom coordinate system, because this is breaking REP105/3 by using custom coordinate systems instead of ROS coordinate system

Are you using a right-hand coordinate system or not?

If the answer is yes, are you aware that tf2 is designed to easily handle this situation?

Comment by xdzye on 2023-01-20:
Hello Mike, yes - the custom coordinate system is right-handed.

No, im not aware. I was working with tf1 mostly and only recently started using tf2. Can you provide me with a link?

Thank you very much for helping!

Comment by Mike Scheutzow on 2023-01-21:
Feature-wise, tf1 is similar to tf2 - the methods just got cleaned up. You can create a new Frame, publish the transform between it and an existing frame, and you're done. Then tf2 provides methods to convert a pose from one frame to another. So where is your confusion?

Comment by xdzye on 2023-01-22:
My confusion lies in the fact that the rotation between my coordinate system and the ROS coordinate system provided by RTABMap is always different, because the origin and direction of the ROS coordinate system is relative to the camera direction and angle at which the SLAM algorithm is started on the robot. I don't know the transformation itself and need to compute it. Thats why I was asking if there is a way to have a fixed direction for example in cardinal directions so that the rotation is always the same and I can just apply a static transform for all starting points. Otherwise I do have the tf map -> tag from Apriltag package and I also measured world -> tag for some specific tags, which would mean I can compute world -> map with (world -> tag) * (map -> tag)^(-1) for these specific tags, right? Would that be the best solution?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I can compute world -> map with (world -> tag) * (map -> tag)^(-1) for these specific tags, right?

Yes, that is correct. If using c++, you'll probably want to create tf::Transform objects for this calculation; you'll use the setOrigin(), setRotation() and inverse() methods.

https://docs.ros.org/en/api/tf/html/c++/classtf_1_1Transform.html

Would that be the best solution?

Yes.


Originally posted by Mike Scheutzow with karma: 4903 on 2023-01-22

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Mike Scheutzow on 2023-01-22:
Edited to remove my "4x4 matrix" comment. It turns out that internally tf::Transform uses a different representation.

Comment by xdzye on 2023-01-22:
Ok, thank you!

What would be the best to deal with different estimated transforms between different tags/different ROS times? Should I just average them? I'm currently using Python and I noticed inverse() is not defined in that API. Guess I will need to implement my own inverse function or I switch over to the C++ API.

Comment by Mike Scheutzow on 2023-01-22:
For python, look in tf.transformations. This old question #q229329 has inverse example.

For multiple reference points, to get started I'd just average them. If that turns out to give poor results, you could look at some kind of outlier-removal.

Comment by xdzye on 2023-01-22:
Thank you very much. In the meantime I also got it working using Marker/Priors. They actually do support rotation as well, I just set the rotation parameters with wrong values.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.