Add UDP port / Auto takeoff and land

[hdiethelm]

Hello, Thanks for the example! I wanted to run it also with jmavsim, so I added an UDP option. For jmavsim, it is also necessary to take off and land, so I added this functionality also. I hope it is useful! There is some duplicated code between udp_port.c and serial_port.c. If you like it better, you can also us the branch udp_version_release which uses inheritance to avoid this but I think it is harder to understand for beginners.

[hamishwillee]

@hdiethelm Thanks very much for taking the time to update the example.

This is a good change. Essentially it now additionally covers "writing a basic MAVLink application using C MAVLink libraries". It somewhat did this before, but that wasn't clearly documented.

I like the fact that

• you can now test against a simulator (ie you don't need a real device). This allows automation of testing the rest of the code.
• Having support for multiple port-types is a more realistic example, and this is not much more complicated than previously
• Our simple udp example while highlighting how to setup UDP and send messages and more generic than this (ie it doesn't assume we're a mavlink application - the code could be for a GCS or whatever), is not a very good example of how to structure a real application.
• takeoff and land is a good example for using an API. Great that you have allowed this as a command line option.

@LorenzMeier What do you think of the idea of changing the focus to be more "basic C MAVLink application" than "CUART example"?

IMO it is good but probably needs more work on the docs, and a rename of the whole project. Also validation against both PX4 and ArduPilot simulators.

[hamishwillee]

@LorenzMeier PS if you like this idea in principle I will properly test and review it. Don't want to give @hdiethelm bad direction :-)

[hdiethelm]

I also started to work with DronecodeSDK, looked at the UDP implementation there and made some fixes im my code. Because the drone is sending always, the tx port can be found automatically. This is not the case when communicating with the GCS. I took some code from mavlink_udp.c example when starting.

The example does not work with the ArduPilot simulator because: -ArduPilot needs first to change in GUIDED mode -Takeoff using MAVLINK_MSG_ID_SET_POSITION_TARGET_LOCAL_NED_LEN does not work -Takeoff can be done using MAV_CMD_NAV_TAKEOFF -When taking off, MAVLINK_MSG_ID_SET_POSITION_TARGET_LOCAL_NED_LEN commands disturb the autopilot. As they are sent always in the actual implementation, this fails. I quickly hacked an example which works with ArduPilot, but it doesn't wit PX4: WARN [commander_tests] Failsafe enabled: no RC WARN [commander] Takeoff denied, disarm and re-try

By the way: DronecodeSDK also doesn't work with ArduPilot: ./takeoff_and_land udp://:14550 Waiting to discover system... [10:07:34|Info ] New device on: 127.0.0.1:36006 (udp_connection.cpp:208) [10:07:34|Debug] New: System ID: 1 Comp ID: 1 (dronecore_impl.cpp:292) [10:07:34|Debug] Component Autopilot added. (system_impl.cpp:339) [10:07:35|Debug] Found 1 component(s). (system_impl.cpp:466) [10:07:35|Debug] Discovered 1 (system_impl.cpp:468) Discovered system with UUID: 1 [10:07:36|Warn ] command unsupported (511). (mavlink_commands.cpp:169) [10:07:36|Warn ] command unsupported (511). (mavlink_commands.cpp:169) Setting rate failed:Command denied

May be there should be two different examples, one for ArduPilot and one for PX4 with some common code.

[hamishwillee]

Thanks very much @hdiethelm . We know the SDK does not "fully" support ArduPilot - I've added an SDK FAQ to make that clear: https://github.com/dronecore/sdk_docs/pull/142 (essentially the SDK is developed "for PX4", funded by companies that have products on PX4. The SDK project is happy to take contributions to support ArduPilot but can't also maintain and test those contributions).

For MAVLink though we should try make examples that can work on any/all MAVLink systems (the problem being that systems implement different messages and services, and that there are cases where the specifications are ambiguous so that systems implementing the same protocol don't interoperate).

This example is primarily designed to show how to set up connections. I lean towards removing the takeoff/land stuff and concentrating on showing messages that will work on any system - e.g. get telemetry data.

On the other hand, if the autopilot specific differences can be clearly identified and separated in the code then it might be OK. Thoughts?