Yeah, this is annoying because of the need to balance existing ROS conventions with the (much older) conventions used throughout the marine domain.
I don’t love decorating all of our frames with _ned and _fsd/_frd (I’m not actually sure whether more people say forward-right-down vs. forward-starboard-down), but I think it may be important in order to avoid confusing people encountering this project coming from the ROS robotics side, rather than the maritime side.
The most important bit to me is to have the expectation that a marine TF tree will have an equivalent to /odom that is NED, and an equivalent to /base_link that is FSD. Right now, I’m just using /odom and /base_link for those, but you might convince me to migrate (or at least adopt a different convention for my next project.) @evan-palmer – maybe the next step is to propose a standardized TF tree, and get reactions to it?
I haven’t thought about tides enough in this context to opine on Roland’s proposed frames for dealing with them. In the applications I’ve worked in for underwater robots, we used pressure-depth for depth in real-time control, converting to WGS84 in post-processing if the application required it. I’ve also worked on a number of non-ocean robots, where sea level and tides didn’t come into it, and pressure-depth was all that was available.
I’m jealous of Roland’s ability to convert to lat/lon in real time =) For all the underwater vehicles I’ve worked on, our real-time on-robot coordinates were in an odom frame, which was again converted to lat/lon in post in a re-navigation step using USBL and other data. (If necessary and if USBL was available.)