Expand Offboard Control with external UDP Command Handling and Examples

[alireza787b]

This pull request significantly broadens the offboard control capabilities of MAVSDK-Python by introducing an easy mechanism for receiving and processing drone control commands via UDP. The new receiver.py script and ControlPacket class facilitate the integration of control commands from external sources, even different languages or technologies (such as image processing systems). These enhancements are particularly useful in scenarios where MAVSDK does not directly manage the command generation process, allowing for a highly flexible, system-agnostic approach to drone command and control.

Features
Universal Command Reception (receiver.py): Acts as a bridge to receive control commands via UDP, enabling integration with systems that do not natively interface with MAVSDK or are written in different programming languages.
Control Packet Class (control_packet.py): Ensures structured and efficient handling of incoming control data, allowing for clear and straightforward integration with external command sources.
Example Scripts: Includes examples demonstrating various control modes (attitude, body velocity, attitude rate, position NED circle), providing a practical reference for developers to implement similar functionalities.
Files Added
attitude_rate_sender_example.py: Sends attitude rate commands demonstrating real-time control adjustments.
attitude_sender_example.py: Manages drone attitude, showcasing precise orientation control.
body_velocity_sender_example.py: Facilitates body velocity commands, tested and verified on an actual drone.
control_packet.py: Implements the packet structure essential for decoding and executing UDP-transmitted commands.
position_NED_circle_sender_example.py: Illustrates complex path control through position commands in NED coordinates.
receiver.py: Central component for receiving UDP commands and integrating them with MAVSDK for drone operation.

Consultation and Decision Points
I need your Feedback on the following considerations to ensure optimal integration within the MAVSDK-Python ecosystem:

Integration Approach:
Should the receiver.py and ControlPacket class be directly included in the MAVSDK-Python core, or maintained separately with a reference link in the main repository?
Handling of GUI Examples: Given the GUI examples utilize Pygame and are optimized for both touch and traditional inputs, is it advisable to host these examples separately to maintain MAVSDK-Python’s lightweight dependency footprint or keep it included in this official examples folder?

Additional Information
Testing Details:
All example scripts have been validated in a simulated (SITL) setup, except for the body_velocity_sender_example.py which has also been tested on a real drone.
Documentation: Each component is thoroughly documented to assist users in understanding and utilizing the new functionalities.

[julianoes]

Thanks @alireza787b, that's very cool. I'll look into it asap and give more feedback.

[julianoes]

Ok, sorry for the delay @alireza787b.

So if I understand it correctly, you have wrapped MAVSDK's offboard API in some sort of UDP API, slightly more high level, and then built a very a nice pygame example around that.

I'm afraid I don't think that's quite in the spirit of MAVSDK which already tries to be multi-language by implementing a gRPC API/server, and would be rather confusing for a reader looking for a simple and canonical ways how to use MAVSDK-Python.
As such, I would suggest to:

1. Either, simplify the example to directly work with MAVSDK-Python, so that it is an actual MAVSDK-Python example, so removing the additional abstraction/API.
2. Or, host it somewhere else, e.g. on your personal GitHub as your approach for a pygame example using MAVSDK-Python.

That being said, I do appreciate that some of the APIs might be too complex and we have to think about simplifying some of them, or adding additional ones that are higher level and automatically take the current state into account and allow relative commands such as "go one meter forwards".

[alireza787b]

Thanks for getting back to me and for your thoughtful feedback.

I completely agree that it might be confusing for users looking for straightforward MAVSDK-Python examples. The main goal of my implementation was to enable command control from various sources, potentially running on a node without MAVSDK or even on different platforms, not necessarily on the drone itself.

Based on your suggestion, it seems like hosting this as a separate repository might be the best approach. This way, it can serve as an example of integrating MAVSDK-Python with external systems using UDP, without adding complexity to the core MAVSDK-Python project.

Would you recommend this as the way forward, or do you think there are adjustments that could make it fit better within the existing MAVSDK-Python examples?

[JonasVautherin]

I personally think it makes total sense to host it in a separate repo. That way you @alireza787b keep control over it and have the freedom to make it evolve the way you want.

And it is a really cool example! 😎

[julianoes]

I'd say, if it didn't have the additional API layer but was just an example directly using MAVSDK-Python, I would have it hear. So it's up to you which architecture you prefer.

[alireza787b]

Yes, I agree. Hosting the current implementation as a separate repository makes sense, and I appreciate the positive feedback on the example! 😎

I also think it's a good idea to add an example that directly uses MAVSDK-Python without the additional API layer.

In that case, how would you recommend handling the Pygame dependencies? Should we instruct users to install Pygame separately in the example comments, or is there a preferred method to include such dependencies in the MAVSDK-Python examples?

[julianoes]

I think adding a comment at the top of the file indicating the dependencies would be ok. It's just install pygame with pip, or is there more?

[alireza787b]

It's only pygame basically. It also needs socket and sys.
so I will edit it next week just for a demo with the native mavsdk offboard command