New ROS Enhancement Proposal for Marine Robotics

Hi all,

I just wanted to say a couple of words on TF discussion.

TL;DR;
My approach have been this: unless otherwise stated a frame is in ‘ENU’, and it is stated to be in ‘NED’ with the _ned suffix. Thank you very much for keeping me in the loop @mabelzhang.

Yup, I do. Because →

I cannot agree more.

On another note;
…which I did not see here being talked about, the robot localization package requires IMU to be in the ENU frame. And If I am not mistaken, that is if it hasn’t changed yet. The big reason why I like to employ the ENU convention is that I’ve been using the robot_localization package for sensor fusion. I see new promising frameworks being developed here and there (i.e. GitHub - locusrobotics/fuse: The fuse stack provides a general architecture for performing sensor fusion live on a robot. Some possible applications include state estimation, localization, mapping, and calibration.), and it wouldn’t surprise me if they also adhere to REP103 and 105.

1 Like

I understand that changing the primary frames of the TF tree would simplify the configuration of marine-specific applications, however, AFAIU, this partially breaks REP103 + 105 where the suffixed frames are supposed to be secondary frames. The main drawback I see is not being able to directly use awesome localization packages/frameworks that would very likely stick to REP103 and 105 as @incebellipipo rightfully mentioned.

That said, at Kraken, we opted to stick with the default TF-tree structure and deal with the extra burden of having the _ned/_fsd as secondary frames so that we do not limit the set of tools/packages/frameworks we may use for localization and mapping.

Does this proposal actually break compatibility with localization/navigation packages? Won’t these packages automatically be doing the necessary transformations and effectively get REP 103 + 105-respecting coordinates? It’s been a while since I’ve used these packages, I think it would be good to evaluate and document the compatibility and/or necessary changes to integrate with these common packages.

I’m not 100% sure they would, maybe so. We are not currently using them either, but I agree with you that an evaluation/documentation would be necessary if changes to primary frames (to use _ned, _fsd) are proposed.

My point is that if we stick to the current (non-sufixed ENU/FLU) primary frames, we are certain to be compatible with such common packages, as long as the handling of the secondary frames is properly done by the user.

Hmm that’s a good point. Let me see if I can pull in someone who knows the answer, without us having to designate someone to test it…

If you keep the tree fully connected it should not matter which one is primary. However, you will have to potentially parameterize several packages to know how to offset their published data.

I would recommend this approach too. Queries are easily resolved when you reference the frame of choice. And any publisher can choose to do the offset onetime if necessary before publishing. There will be many fewer of those than users/subscribers.

6 Likes

Hey folks, I have just submitted a PR that describes the conclusions that were made in this discussion. The PR is available here. I have currently listed it as a draft to give everyone a chance to provide feedback prior to marking it as ready for review.

Thank you everyone for the valuable discussions and work on this!

5 Likes

Looks good!

Thanks for writing this.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.