I know there have been already discussions on this topic, but the conclusion was that if there is more will, this functionality might get merged.
Our story that justifies having a configurable map frame: Our mobile robots have started as GNSS-denied Search&Rescue explorers, so we relied 100% on ICP-based SLAM. Therefore, our map frame has historically always been whatever ICP computes. This complies to REP 105. Now we started taking our robot friends also outside and want to fuse all possible localization sources, including GNSS. To keep backwards compatibility, we want to keep the frame name map to be the ICP-created frame, and we call the GNSS-fused frame gps_odom. Without this PR, there is no way to make this plugin compatible with our codebase (except for silly things like tf rewriting nodes etc.).
I'm open to any suggestions on how to improve or simplify the code, especially the Qt part.
I know there have been already discussions on this topic, but the conclusion was that if there is more will, this functionality might get merged.
Our story that justifies having a configurable map frame: Our mobile robots have started as GNSS-denied Search&Rescue explorers, so we relied 100% on ICP-based SLAM. Therefore, our
mapframe has historically always been whatever ICP computes. This complies to REP 105. Now we started taking our robot friends also outside and want to fuse all possible localization sources, including GNSS. To keep backwards compatibility, we want to keep the frame namemapto be the ICP-created frame, and we call the GNSS-fused framegps_odom. Without this PR, there is no way to make this plugin compatible with our codebase (except for silly things like tf rewriting nodes etc.).I'm open to any suggestions on how to improve or simplify the code, especially the Qt part.
Thanks for the very nice plugin!