-
Notifications
You must be signed in to change notification settings - Fork 988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin for TUNNEL messages #1625
Conversation
I've fixed the cog generation now, and I've added a check on the payload length, so I don't try to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Thanks!
Hmm, i'm thinking, what if make Tunnel.payload dynamically sized, then we could remove Tunnel.payload_length (as we have it in payload.size()). |
That's absolutely an option. So the error handling would then be:
and
The only downside I can see is that the mavros and mavlink messages would be less similar, so the user of the plugin needs to figure out that payload_length is just encoded in the array size and not in a separate field. |
I think first option better. In my opinion payload_length makes handling of that message harder, and only needed for mavlink to express dynamically sized payload. |
{ | ||
static constexpr auto max_payload_length = | ||
sizeof(mavlink::common::msg::TUNNEL::payload) / | ||
sizeof(mavlink::common::msg::TUNNEL::payload[0]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since payload is std::array
i think better to use ::size()
.
I wanted to use MAVLink TUNNEL messages to communicate between ROS and some hardware connected to the FCU. I made a MAVROS plugin that forwards tunnels between ROS and the FCU, in both directions, and a Tunnel message in mavros_msgs that mirrors the MAVLink message.
One thing I'm not sure about is how to best deal with the variable length payload field. In MAVLink, it's defined as a 128 size array, but I suppose the serializer makes sure to avoid sending a bunch of zeros if only some of the size is used. I've made it a
uint8[128]
in ros to enforce the maximum size, but I think that might mean the ROS messages always send the full 128 bytes. I could make ituint8[]
, but then I would need to handle the max size somewhere. (Maybe just a comment in the message definition, and a check in the plugin when it copies between the ROS and MAVLink messages?)