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.