"MAVSDK" and "Arducopter SITL" incompatibility (and fly_qgc_mission.cpp and QGC incompatibility)

[kripper]

Hi,

I'm the current maintainer of Rosetta Drone 3, a MAVLink implementation for DJI drones.
We are testing MAVSDK to send a QGC mission to Arducopter SITL using fly_qgc_mission.cpp.
We identified at least two issues:

• ISSUE 1: telemetry.health_all_ok() is always false
• ISSUE 2: Arducopter doesn't start the mission but disarms.

Everything works fine sending the mission from QGC to Arducopter SITL instead of using fly_qgc_mission.cpp.

Output of fly_qgc_mission.cpp:

	Waiting to discover system...
	Discovered autopilot
	Waiting for system to be ready	<--- BUG 1: blocks on while (!telemetry.health_all_ok())
	(Waiting disabled by me, for testing)
	System ready
	Importing mission from mission plan: /data/data/com.termux/files/home/imatronix/server/test/p9-quillota.plan
	Found 10 mission items in the given QGC plan.
	Uploading mission...Mission uploaded.
	Arming...
	Armed.
	

Output of arducopter.exe:

	...
	AP: EKF3 IMU0 is using GPS
	AP: EKF3 IMU1 is using GPS
	AP: Terrain: clamping offset 435 to 15
	AP: Arming motors
	ARMED
	Mode AUTO
	AP: Mission: 1 Takeoff
	waypoint 1
	
	(little pause, probably a timeout)
	
	AP: Disarming motors	<--- BUG 2: Unexpected disarm. Why? There is no problem when sending the same mission from QGC
	AP: Mission: 1 Takeoff
	DISARMED

Are this incompatibilities intentional?
How do we make this world better?

IMO fly_qgc_mission.cpp is suposed to send QGC missions, so I would expect it to speak the same language as QGC (or rename it to fly_qgc_mission_in_unintelligible_accent.cpp).

[julianoes]

Regarding the health fields: that was just some proxy that I came up with which tended to work ok with PX4. It's not properly done as it should. It should probably depend on the health.is_armable flag instead which is basically MAV_SYS_STATUS_PREARM_CHECK.
It would probably be a good idea to remove the health_is_all_ok in MAVSDK v2 and recommend is_armable everywhere.

Now when it comes to missions that's a bit harder because various items get interpreted differently, and then the mission transfer is also different, ArduPilot putting home into item 0 and starting with item 1 for the mission while PX4 just starts at 0.

For your exact problem, I'm not sure what exactly it is, but let's try to debug it and fix it.

Are this incompatibilities intentional?

No, just the way things were standardized appropriately or interpreted differently and have developed from there.

How do we make this world better?

There is a two-weekly MAVLink dev call where we discuss what gets added to MAVLink and how PX4 and ArduPilot can slowly become more compatible. However, progress is hard, because often to become more compatible requires changes which would break backwards compatibility or additions of new mechanisms which require implementing or add complexity.

But anyway, let's debug what you're stuck on and go from there.

Any chance you can provide me code or steps how I can reproduce the issue?

[kripper]

Thanks @julianoes,

I got fly_qgc_mission.cpp working with Arducopter SIT.
I had to disable the telemetry.health_all_ok() and set AUTO_OPTIONS = 10 in Arducopter SITL.
More info here.

But this was just the initial test.
Where I really need help is in getting MAVSDK / fly_qgc_mission.cpp to work with Rosetta, which already works fine with QGC.
I will create an issue here: RosettaDrone/rosettadrone#120

[ykhedar]

Hi @kripper, nice work with Rosettadrone!
I think QGC mission from a file would not work as it is. This is because APM expects slightly different mission sequences. As a side not, APM expects first mission item as the home position and second mission item as takeoff. QGC does this conversion when uploading the mission to the autopilot but the example file you mentioned does not.

Please use the MAVSDK integration tests as basis for mission upload to APM SITL. There are two separate tests in this file, one each for PX4 and APM.

See how mission upload, arm and takeoff are executed in a sequence to run the mission with APM in this function: APM Mission Raw Integration test

Also see how the mission plan is created in Create Mission Plan Raw for APM

Hope this helps :)

Best,
khedar

[kripper]

It would probably be a good idea to remove the health_is_all_ok in MAVSDK v2 and recommend is_armable everywhere.

Yes. Having a universal is_armable check that each fight controller knows how to interpret depending on their features and sensors is a good idea.

BTW, when sending the first mission from QGC, we get an error saying that the aircraft is unable to arm even when it 1) sends the ACK to the arm/disarm command, 2) send the ACK to the set-flight-mode command and 3) informs that the flight mode is GUIDED in the next heartbeat.

I think I have seen this also once with arducopter SITL.

I believe QGC then disables the arming check and it works the second time...or we switch the fight mode to auto to get Rosetta actually starting the mission.

This only happens with QGC. With the C++ example, the mission starts flawlessly. Anyway, we should better fix this issue with QGC.

Now when it comes to missions that's a bit harder because various items get interpreted differently, and then the mission transfer is also different, ArduPilot putting home into item 0 and starting with item 1 for the mission while PX4 just starts at 0.

I don't see a problem if the first item is a set-home-location or a take-off.
All models can and should support both sequences.

There is a two-weekly MAVLink dev call where we discuss what gets added to MAVLink and how PX4 and ArduPilot can slowly become more compatible. However, progress is hard, because often to become more compatible requires changes which would break backwards compatibility or additions of new mechanisms which require implementing or add complexity.

Good. On the long term, it pays off.

Congratulations. I admire your work on QGC.
Tomorrow I'll try to replay some logs with QGC.
I was looking for a debugging tool for Rosetta''s ground based "fight controller" (MissionManager) that uses virtual sticks to fly the missions.
I experienced an issue that didn't occur in the simulator, so the logs are crucial.

[julianoes]

BTW, when sending the first mission from QGC, we get an error saying that the aircraft is unable to arm even when it 1) sends the ACK to the arm/disarm command, 2) send the ACK to the set-flight-mode command and 3) informs that the flight mode is GUIDED in the next heartbeat.

I think I see something similar often with PX4 but I never quite tried to get to the bottom of it. Or at least it's a similar "try again and it works on the second try" sort of thing.

[kripper]

Yes, it's like a first time timeout. I believe I've also seen a message saying something like "arm check disabled".
I believe this is on the QGC side.