I would expect the transform from earth->map to be a constant. Any movement of the robot has no effect on the relationship of those 2 frames.
Originally posted by Mike Scheutzow with karma: 4903 on 2021-07-08
This answer was ACCEPTED on the original site
Post score: 1
Original comments
Comment by jacklu333333 on 2021-07-09:
Hi, thank you for your reply. You point out my blind spot about the relationship of earth->map frame. It should be constant since the map->odom, the rotation measurement would be here.
In that case, I am wondering how can I publish the earth->map relationship at the initial state dynamically since we cannot always assume the North is match to y-asix (for xyz to enu configuration).
Once again thank you for the clarification.
Comment by Mike Scheutzow on 2021-07-09:
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.
Comment by jacklu333333 on 2021-07-12:
Thank you for the clarification.
In that case, wouldn't the earth frame a little bit ineffective in most cases since it is always static?
The only case we can apply the earth frame will be when there are multiple robots to do multi-session mapping, in addition, we need to calibrate the orientation of each robot in advance or read once at the beginning.
Is my understanding correct?
Comment by Mike Scheutzow on 2021-07-12:
It's not clear on what you are trying to accomplish. Are you trying to 1) create a single, combined map or 2) keep a unique map for each robot and be able to convert between the different map's coordinate systems or 3) something else.
Comment by jacklu333333 on 2021-07-12:
I think it's more close to 2. Since I want to map the environment as a global map. With the information given by you, I think I can make it work. Thanks a lot.
I am just curious about the necessity of earth frame. Since I can just rotate the map at the mapping session so that XYZ will match to the ENU, in that case, the REP:105 seems unnecessary to define the earth frames, right?
Comment by Mike Scheutzow on 2021-07-12:
Since I can just rotate the map at the mapping session so that XYZ will match to the ENU
REP:105 is showing a general architecture. If you choose to transform a rotated map, or somehow pre-initialize the mapN frame so the axes are what you want, then each earth->mapN transform is the Identity transform. Which approach is easiest depends on what you know, and when you know it.
Comment by jacklu333333 on 2021-07-13:
I got it. Thank you for your time and the detailed explanation.
Comment by xdzye on 2023-01-18:
@Mike Scheutzow
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/earth_frame?