Manual Control Input via UDP

[christianrauch]

This PR adds a new module mc_in_udp that listens on a UDP port for a list of float values that are translated into manual_control_setpoint_s messages and published on uORB topic manual_control_input. It can be used for remote control without MAVLink.

The message format, including a simple example client in Python, is documented in the README.

Changelog Entry

For release notes:

Feature "Manual Control Input via UDP" (mc_in_udp)

Test coverage

Tested with C++ and Python clients using jMAVSim with SITL.

[christianrauch]

How do I fix the issue NameError: name 'default_port' is not defined that is reported by the CI? It's clearly defined as type in_port_t here https://github.com/PX4/PX4-Autopilot/blob/291a561d510347890aefa59f05930c6730f3714b/src/drivers/mc_in_udp/mc_in_udp.cpp#L46 and passes compilation.

[AlexKlimaj]

How is this different than manual control input on UDP over mavlink? Smaller packets?

[christianrauch]

How is this different than manual control input on UDP over mavlink? Smaller packets?

The package size was not the main motivation. But if you want to know, it's between 22 and 46 bytes, depending on how many AUX channels you send.

Compared to MAVLink, this has much fewer dependencies and is easier to set up. See the Python example client.

[dagar]

Could you please change the naming, we've always used mc to consistently mean multicopter.

[dagar]

I personally think most people should be using either mavlink, uxrce_dds, or zenoh for this and if dependencies/complexity are truly an issue we could figure out how to make that more palatable. That being said I'm also not opposed to a super simple standalone example like this, let's just make sure it's not confused with anything else.

• mc should be reserved for multicopter
• could you move this to src/examples (at least initially) and name it something descriptive (eg examples/simple_udp_manual_input)? I want to be careful not to add more confusion if people stumble across things in the code base.

[PetervdPerk-NXP]

Since you're specifying an UDP protocol message. Can you include also the endianness of the bytes and the method to represent the float (ie. IEEE 754).

Different CPU architectures can misread the message because of that.

[christianrauch]

I personally think most people should be using either mavlink, uxrce_dds, or zenoh for this and if dependencies/complexity are truly an issue we could figure out how to make that more palatable. That being said I'm also not opposed to a super simple standalone example like this, let's just make sure it's not confused with anything else.

• mc should be reserved for multicopter
• could you move this to src/examples (at least initially) and name it something descriptive (eg examples/simple_udp_manual_input)? I want to be careful not to add more confusion if people stumble across things in the code base.

I am fine with the renaming. However, I don't think "example" is a good fit. It would be an example for what? I think this module is somewhat similar to rpi_rc_in. This module reads RC channels via shared memory and publishes them on uORB topics without the need for real hardware.

[christianrauch]

Since you're specifying an UDP protocol message. Can you include also the endianness of the bytes and the method to represent the float (ie. IEEE 754).

Different CPU architectures can misread the message because of that.

I added this to the documentation.

[dagar]

I pulled the Mac OS CI change into main. 1cf38e9

[dagar]

I personally think most people should be using either mavlink, uxrce_dds, or zenoh for this and if dependencies/complexity are truly an issue we could figure out how to make that more palatable. That being said I'm also not opposed to a super simple standalone example like this, let's just make sure it's not confused with anything else.

• mc should be reserved for multicopter
• could you move this to src/examples (at least initially) and name it something descriptive (eg examples/simple_udp_manual_input)? I want to be careful not to add more confusion if people stumble across things in the code base.

I am fine with the renaming. However, I don't think "example" is a good fit. It would be an example for what? I think this module is somewhat similar to rpi_rc_in. This module reads RC channels via shared memory and publishes them on uORB topics without the need for real hardware.

It's not the best naming/solution at the moment, but it's more of a place we can keep experiments off to the side until they're fully supported. This isn't being built or tested on any boards, no testing in CI, and for now the "official" recommendation for manual control should still be mavlink, and XRCE DDS.

[christianrauch]

@dagar I renamed the module and moved it to the examples. Is this ok now? Other than this, I am only left with the CI telling me that default_port is undefined: #22406 (comment).

[christianrauch]

@dagar Can you have a look at this again? The remaining CI issue (failed to push ghcr.io/px4/px4-dev:v1.16.0-alpha2-281-ge33137e632: unexpected status from POST request to https://ghcr.io/v2/px4/px4-dev/blobs/uploads/: 403 Forbidden) is unrelated to this PR.

[christianrauch]

@dagar @bkueng Since this PR is adding an example and not touching other files in the project, it should be quick to review. Can you please have a look at this now?

[hamishwillee]

My understanding is that this demonstrates how a driver can monitor the UDP port, parse an input stream, and publish to a uORB topic. It happens to use the example of parsing a MAVLINK_CONTROL message and writing to the manual_control_input topic (defined in ManualControlSetpoint.

Thoughts:

• What does this example show that is not shown in other examples?
• Its an example. Is everything else about the example best-practise - including documentation etc.
• Should the docs of this be in the user guide, along with an explanation of the code?
• Is the example tested - if the interface changes for the uorb topic, when would we find out?
• This is not the way you would normally handle the input of this mavlink message - we do it in the mavlink module. We should spell out what this shows, what it is for, and this limitation.
• ManualControlSetpoint is poorly documented. What is the implication of updating the topic manual_control_input and how does this differ from updating manual_control_setpoint? I.e. is this just what MAVLink does now - update the input - and other code then works with the other possible inputs to set the setpoint topic?

I guess the summary is that this is cool, but we should make sure that we make implications clear and look at ways to make sure we know if it ever breaks.