conversion from mavlink::Message to mavros_msgs::Mavlink missing

[1000000007]

For MAVLink v1.0 we were able to use the mavlink c struct for a specific message type , encode it to a mavlink_message_t struct, and then use a convert function from mavros_msgs to put it into a ROS message that could be published to the /mavlink/to topic, e.g.

mavlink_mission_item_t waypoint_msg; // ... fill in message fields mavlink_message_t packet; mavlink_msg_mission_item_encode(255, 1, &packet, &waypoint_msg) mavros_msgs::Mavlink ros_mavlink_msg; mavros_msgs::mavlink::convert(packet, ros_mavlink_msg);

With MAVLink v2.0 the individual message types are now subclass of an abstract base class and it appears that functions for converting those into mavros_msgs::Mavlink structs (or for converting to a mavlink_message_t struct) are missing?

MAVROS version and platform

Mavros: master branch ROS: Kinetic Ubuntu: 16.04

[vooon]

That class is not complete message that can be passed to wire. I do not understand why people want to encode and send Mavlink.msg instead of writing plugin, where you have all required environment.

Why not create plugin that will convert your app dep message to waypoint? That less than 100 LOC.

Will not be done, because to properly finalize mavlink::Message to mavlink_message_t it require deployed mavconn link.

[1000000007]

My conjecture is that some people want to do this because: 1) No matter how easy it may be write a mavros plugin, it's still easier and faster (and less lines of code) to just pack a mavlink c struct, do the conversions to get a mavros_msgs/Mavlink message , and publish on /mavlink/to. 2) For various reasons, they may want to just use the mavros handing of the communication protocol and don't want to be tied to your whole ecosystem.

In any case, it's easy enough to do this accomplish this the old way, so perhaps you don't need to define this sort of functionality for the Message class/subclasses. People will have to cut and paste some of the functionality from mavlink_convert.h, however, because its includes conflict with the mavlink c struct header files.

[TSC21]

For various reasons, they may want to just use the mavros handing of the communication protocol and don't want to be tied to your whole ecosystem.

In that case, you can just use libmavconn. If people just want to pack the mavlink c struct, they don't even need MAVROS.

[1000000007]

Sure, but MAVROS does provide a quick way to hack in a custom message and try things out and people usually take the line of least resistance. It may not be how MAVROS is intended to be used, but I predict people will continue to do so anyways.