Add an OdometryWithAcceleration message

[tfoote]

As needed by REP 147 discussion: Pull request and discourse thread

[jack-oquin]

Where was OdometryWithAcceleration discussed? I can't find it.

[tfoote]

In the Odometry Interface section:
https://github.com/ros-infrastructure/rep/pull/118/files#diff-e8b2a6cd0db2e7cabfdc8477d55e3f3bR295

[TSC21]

@tfoote is this going to be merged soon? This is an interesting approach that we probably want to explore on MAVROS.

[tfoote]

I would like to merge this soon. I think it would be rushed to push this out before the melodic release as I'd like to cross reference it with the update for REP 145 from #101 though looking at that now. It's really for the raw measurements, whereas the reported odometry should be fully fused.

But since this is a pure addtion we can add it out of cycle as well as can backport it so I'm not going to push to get it into melodic before the release next week.

@TSC21 If you are thinking about picking it up. I'd love it if you would copy the message and try it out locally to get feedback on the structure. And if it suits your needs that would be great to know that the message in this format is working.

[TSC21]

@tfoote this is of most interest for us developers as we are aiming to push it further for interfacing ROS with PX4 (if you are interested, have a look of what is being done in PX4/PX4-Autopilot#9301). This would probably be tested, in a first stage, on simulation, and then move forward with its support both ROS and PX4 estimators. PX4 Pro would probably be the best autopilot to be in the vanguard for testing and pushing this forward.

[tfoote]

Thanks for the link. I've subscribed to that ticket. I hope to have some more support for a specific effort to push more standardized messages soon.

[TSC21]

@tfoote any updates regarding this?

[m-naumann]

We are also using an identical message for quite a while since it's very useful: https://github.com/fzi-forschungszentrum-informatik/automated_driving_msgs/blob/master/msg/MotionState.msg

I would recommend to also clarify the treatment of unknown/incomplete covariance information.

Further, I'd suggest to keep the term twist as it's actual values are in the twist member within the TwistWithCovariance anyway, along with the covariance.

I could provide a PR if you like.

Edit:

I also just saw a bug in line 9 of the new message, it should be AccelWithCovariance instead of twist, and I'd also name it accel as within this message, like above

[m-naumann]

I just fixed these issues in #146