New ROS Enhancement Proposal for Marine Robotics

[incebellipipo]

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.

@mabelzhang

I think @incebellipipo likes to configure robots with ENU, and transform everything to NED using a static transform publisher.

Yup, I do. Because →

@rolker

As somone who works with different types of vehicles and wants to be able to have them work together I think it’s important that we stick to REP103. I also want to use as many off-the-shelf ROS components as possible, so yet another reason to respect REP103.

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.

[gpacheco]

@rolker

Also, to better accomodate a system that is primarily ned/fsd, the TF tree could have, I think, the _ned/_fsd suffixed frames as the main nodes and the unsiffixed ones as the add-ons.

@evan-palmer

This makes sense to me. It may be helpful to recommend a default/primary orientation to help with consistency across future projects. If there is a reason to diverge from the recommendation, then we have a documented alternative.

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.

[edvart]

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.

[gpacheco]

@edvart

Won’t these packages automatically be doing the necessary transformations and effectively get REP 103 + 105-respecting coordinates?

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.

[mabelzhang]

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…

[tfoote]

@gpacheco

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.

@edvart

I think it would be good to evaluate and document the compatibility and/or necessary changes to integrate with these common packages.

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.

@gpacheco

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.

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.

[evan-palmer]

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!

[rolker]

Looks good!

Thanks for writing this.