Skip to content

Add MavlinkDirectServer plugin#2911

Open
julianoes wants to merge 4 commits into
mainfrom
add-mavlink-direct-server
Open

Add MavlinkDirectServer plugin#2911
julianoes wants to merge 4 commits into
mainfrom
add-mavlink-direct-server

Conversation

@julianoes

Copy link
Copy Markdown
Collaborator

This is the server equivalent of MavlinkDirect, so the version that does not require a detected system.

Add a MavlinkDirectServer plugin that mirrors MavlinkDirect but is attached to
a ServerComponent instead of a System. This allows sending (broadcasting)
arbitrary MAVLink messages from a server component without first discovering a
system, e.g. acting as an autopilot or custom sender.

The JSON-to-libmav conversion used when sending is extracted out of
MavlinkDirectImpl into a shared core helper (libmav_conversions) so both the
client and server plugins encode messages identically. This also drops several
unused stub helpers from MavlinkDirectImpl.

ServerComponentImpl gains get_message_set() and load_custom_xml_to_message_set()
accessors, mirroring SystemImpl. The MessageSet is shared per Mavsdk instance,
so loading custom XML affects all systems and server components.

This first step exposes SendMessage and LoadCustomXml; SubscribeMessage follows.

Also bumps the proto submodule for the new mavlink_direct_server.proto.
Add subscribe_message/unsubscribe_message to the MavlinkDirectServer plugin,
reaching parity with the MavlinkDirect client plugin.

Incoming libmav messages are now also distributed to server components via a new
ServerComponentImpl libmav handler (register/unregister/process_libmav_message),
fed from MavsdkImpl::process_libmav_message. This distribution is intentionally
not scoped by system_id: a server component observes matching messages from all
systems, which suits a component sitting on the bus.

Bumps the proto submodule for the new SubscribeMessage RPC.
The autopilot side of the mavlink_direct tests sends telemetry-like messages,
which is naturally a server-component action. Switch those senders from
MavlinkDirect{groundstation_system} to MavlinkDirectServer{server_component},
matching what TelemetryServerTo already does.

This drops the autopilot-side discovery dance (waiting for mavsdk_autopilot
to discover the ground station as a system) entirely. Client send_message
stays covered by the MavlinkDirectServer.SubscribeFromClient test. The
forwarding tests are left as-is since they exercise system-to-system routing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant