drone.telemetry.flight_mode returns UNKNOWN for many Ardupilot flight modes

[HB-Stratos]

I've been working with Ardupilot and MAVSDK to write some data display code. While writing this, I noticed that MAVSDK can not identify most Ardupilot flight modes. Most other telemetry packets I have tested appear to work as expected (minor notes that rc signal strength was unknown with SITL and that imu() never returned (which may be a config issue on my end)).

I assume this is due to the functionality for them not being implemented, or am I doing something wrong here?

If this is missing functionality, how could I help to implement this?

I did some quick testing with Mission Planner SITL in Plane mode, and this is what I found:

Known modes:
[ mavsdk name (ardupilot name) ]
MANUAL
STABILIZED (STABILIZE)
ACRO
ALTCTL (AUTOTUNE) [possible wrong identification?]
MISSION (AUTO)
RETURN_TO_LAUNCH (RTL)
HOLD (LOITER)

Unknown modes:
TAKEOFF
CIRCLE
TRAINING
FBWA
FBWB
CRUISE
AVOID_ADSB
GUIDED
[ quadplane modes could not be tested with SITL ]
[ thermal could not be tested with SITL ]

[JonasVautherin]

The flight modes MAVSDK (main branch) knows are defined here, and they are translated between the different autopilots (PX4 and the flavours of Ardupilot) here.

Some modes are not defined (e.g. TRAINING or CRUISE), but others are (e.g. GUIDED).

They have been contributed by people who needed them at some point (so that they could actually test that it works). If you are willing to try it, we'd be happy to get contributions! That will have to be done in MAVSDK-C++ though, as MAVSDK-Python is just a wrapper around it.

[HB-Stratos]

That looks doable, though I have to say I'm a bit intimidated by having to set up a c++ build env. What would that have to look like to be able to go from making a change to the c++ lib to seeing the change in python with updated autocomplete?

I am cautiously interested in adding more ardupilot flight modes as well as expanding the MissionItem spec to contain all possible types of ardupilot mission item types as I need things like LOITER_TURNS. I would like to implement this straight into mavsdk instead of having to maintain a custom thing ontop, if this is possible without too much of a headache.

[JonasVautherin]

I would say just cmake and the normal compiler requirements, and then you should be able to run something like this:

cmake -DCMAKE_INSTALL_PREFIX=install -Bbuild -S.
cmake --build build --target install

It should build and install MAVSDK into ./install. Then you can build examples with something like this:

cmake -DCMAKE_PREFIX_PATH="$(pwd)/install" -Bexamples/build -Sexamples
cmake --build examples/build

Note that CMAKE_PREFIX_PATH in the second block points to the "install" directory of the first block (i.e. where MAVSDK was installed locally). We have documentation somewhere, but I generally like to look at what the CI does (because this never gets out-of-date, and I don't mean only for MAVSDK 😅): https://github.com/mavlink/MAVSDK/blob/main/.github/workflows/linux.yml#L159-L171.