[ROS, Decision] How to provide non-Gaussian with vanilla ROS msgs?

[dehann]

ROS SLAM does not really cater for non-Gaussian. So what is the best way to be vanilla, but strawberry and blueberry too?

See Wiki for ROS here

• https://github.com/JuliaRobotics/Caesar.jl/wiki/ROS-PoC

Also related,

• ROS Integration #227
• Return types: Standardize DFG Graph CRUD return types DistributedFactorGraphs.jl#134
• PPE: DFGVariable softtype field has abstract type DistributedFactorGraphs.jl#149

[dehann]

https://github.com/jdlangs/RobotOS.jl/blob/master/test/services.jl

[dehann]

Caesar.jl/examples/ros/ServiceExample.jl

Line 19 in 36ed37f

function add_node(req::AddNodeRequest)

[pvazteixeira]

See also:

• geometry_msgs
• sensor_msgs

These are some of the most relevant ROS message type definitions that use the standard assumption of Gaussian measurement noise

[dehann]

Should we develop our own messages and then also populate the existing vanilla interface with printouts saying that those are the reduced Gaussian-only "wrapper" versions. That will allow people to try the new message types after trying out the conventional Gaussian only types. There might be cause to support only new non-Gaussian msg types, but lets start from the familiar stuff and work our way up. Same amount of development on the Julia side to support ROS msgs anyhow.