Hello there,
I’m trying to integrate a MAVSDK application with a Yuneec Mantis Q drone that I recently purchased. This particular application (same one from here) was tested against a px4_sitl running with the gazebo simulator, and even can control the Yuneec Typhoon H480 model.
However, when I try to use it or the takeoff_and_land demo, it notifies that a new system came online and has a camera component but does not actually discover it in the Mavsdk::system() sense and exits.
When I test the Mantis Q with QGroundControl, it is somehow able to correctly connect to the drone. But when I command it to take off, the motors rev up until it’s about to take off and then it generates an error and quits. That may be a separate issue (related to this issue maybe?) but it still remains that QGroundControl know the secret to connect to Mantis Q that the other two applications don’t. Perhaps some kind of maximum supported version or maybe Mantis Q doesn’t use Mavlink 2.0 messages, I don’t know.
If anybody is familiar with Yuneec’s series of drones and can lend a hand, or just has some helpful debugging advice, I’d really appreciate it.
-Mitchell
1 Like
This is the output from running the takeoff_and_land demo:
user@CUSTOM-CONTROLLER-NAME:/path/to/demo$ ./takeoff_and_land udp://:14550
[11:52:10|Info ] DronecodeSDK version: 0.17.0 (dronecode_sdk_impl.cpp:25)
[11:52:10|Debug] New: System ID: 0 Comp ID: 0 (dronecode_sdk_impl.cpp:338)
Waiting to discover system…
[11:52:10|Info ] New system on: 192.168.42.1:14551 (udp_connection.cpp:226)
[11:52:10|Debug] Component Camera 1 (100) added. (system_impl.cpp:400)
No system found, exiting.
So it finds the camera but not the autopilot.
Howe are you connected to the Mantis Q?
I have a USB WiFi adapter that uses the 5GHz band. The Link and IP layers should be fine because I can ping the drone at 192.168.42.1. And from the behavior I’ve seen with QGroundControl as well as the drone’s webpage access the UDP and TCP Transport layer seem fine too
Ok there is the chance that no heartbeat from the autopilot is forwarded.
Therefore, you could try to remove the check for has_autopilot() and just try to continue with the script without that.
As far as I can tell, the example version I’m using (Dronecode SDK v0.17.0) doesn’t include a check for has_autopilot(). I suppose it could be included as a part of this check for discovered_system, and we could just ignore the “return 1;” line. I’ll give it a shot.
// We don’t need to specify the UUID if it’s only one system anyway.
// If there were multiple, we could specify it with:
// dc.system(uint64_t uuid);
System &system = dc.system();
std::cout << “Waiting to discover system…” << std::endl;
dc.register_on_discover([&discovered_system](uint64_t uuid) {
std::cout << "Discovered system with UUID: " << uuid << std::endl;
discovered_system = true;
});
// We usually receive heartbeats at 1Hz, therefore we should find a system after around 2
// seconds.
sleep_for(seconds(2));
if (!discovered_system) {
std::cout << ERROR_CONSOLE_TEXT << “No system found, exiting.” << NORMAL_CONSOLE_TEXT
<< std::endl;
return 1; //comment out this line, live dangerously
}
So I removed the exit condition and extended the wait time to find a system to 5 seconds. Now after the waiting period it continues and in the component callback, finally discovers the autopilot. But now it looks like it’s exhibiting the behavior I saw with QGroundControl, where it always automatically disarms itself (though this way the rotors still don’t even spin)
user@CUSTOM-CONTROLLER-NAME:/path/to/demo$ ./takeoff_and_land udp://192.168.42.6:14550
[01:01:03|Info ] DronecodeSDK version: 0.17.0 (dronecode_sdk_impl.cpp:25)
[01:01:03|Debug] New: System ID: 0 Comp ID: 0 (dronecode_sdk_impl.cpp:338)
Waiting to discover system…
[01:01:03|Info ] New system on: 192.168.42.1:14551 (udp_connection.cpp:226)
[01:01:03|Debug] Component Camera 1 (100) added. (system_impl.cpp:400)
No system found, but continuing in case it doesn’t want to report autopilot heartbeats.
Discovered a component with type 2
[01:01:08|Debug] Component Autopilot (1) added. (system_impl.cpp:400)
Discovered a component with type 1
Vehicle is getting ready to arm
[01:01:08|Debug] Discovered 2 component(s) (UUID: 1900593) (system_impl.cpp:563)
Discovered system with UUID: 1900593
[01:01:09|Debug] MAVLink: info: [logger] file: /fs/microsd/log/sess050/log001.ulg (system_impl.cpp:307)
[01:01:09|Debug] MAVLink: info: Disarmed by init → standby (system_impl.cpp:307)
[01:01:09|Debug] MAVLink: info: (3,27)FUSE OPTICAL FLOW (system_impl.cpp:307)
Vehicle is getting ready to arm
[01:01:10|Debug] MAVLink: critical: no-fly zone unlock status:0 1 0 (system_impl.cpp:307)
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
Vehicle is getting ready to arm
^C
I think there’s some extra component with type 2 that’s on there, since 1 is the autopilot and 100 is the camera. That might be something going on that’s causing this. maybe I have to direct messages to that component as well to handle any special settings?
Looks like you were able to arm but then it auto-disarms because of a no-fly zone lock. I guess that’s one of the custom things on Mantis which makes it non-standard PX4. I’d recommend to talk to someone from Yuneec to find out more.
For posterity: according to @xdw in a direct message, “Sorry, this consumer product [Mantis Q] does not support sdk development, so I can’t continue to help. You can pay attention to yuneec’s industrial-grade products, where we will re-support sdk development.”
So it seems that Mantis Q does not support Mavlink or MAVSDK. If one wants a Yuneec product that may support Mavlink, then one should buy an industrial unit. Unfortunately for the amount of time and budget I have remaining on this project, that option is infeasible
