Custom messages

[StefanCaldararu]

Continuation of some previous discussions. Discussion about usage of custom message types, and that there are duplicate message types in chrono_ros_msgs and art_msgs

[AaronYoung5]

So I realized the actual best solution (imo) is for the simulation to publish the same message types as the AS expects. With chrono_ros_bridge, we don't do this cause it'd mean creating branch/fork of the repo since it's a submodule. With the new Chrono::ROS, this is directly supported in the Chrono::Python interface, and would be implemented directly in the .py files we've been using.

Until we merge Chrono::ROS, we can merge the existing conditional message type logic code, maybe with a small # NOTE: ... so we remember to change this in the future when Chrono::ROS is merged. Sound okay?

[StefanCaldararu]

Yes this sounds like a good solution to me. This also means that for ART, everything in the dev container is simulation/reality agnostic, right? That's definitely something we want, and is not possible if the simulation is not giving the same message types as reality.

[StefanCaldararu]

The reason I was no longer against the custom message types is I wasn't able to find any standard message types that directly match our messages. After doing some more thinking, IMO this is still needed for the VehicleInput messages, but I don't think VehicleState should be passed to the A-Stack from Chrono. In the spirit of keeping simulation and reality the same, in reality the A-Stack doesn't have access to the true state of the vehicle. I think all communication should be done via sensor standard message types (e.g. NavSatFix, imu, maybe odometry). As mentioned above this helps keep the entire dev container simulation/reality agnostic. Thoughts?

[AaronYoung5]

Ya def agree. With the new Chrono::ROS, the demos themselves will be able to publish the custom ROS messages directly so I think this solves the issue.

From a debugging perspective, tho, having ground truth is helpful. Like say a controls guy wants to test code, he doesn't wanna have to run perception + localization (probably) to reduce testing time, so being able to circumvent the other nodes makes sense. But ya, then I guess the simulation would just publish the stuff the control node would take so wouldn't need custom messages for ChVehicle. lol i just talked myself out of it but I'm gonna leave it here idk