I have been testing all of the MAVLink navigation commands with a Dronekit Copter SitL (firmware version 3.3), using my own scripting on top of PyMavlink. When uploading missions, if I include a MAV_CMD_NAV_LOITER_TIME waypoint, the firmware seems to ignore any value I give it for the “radius” parameter (param 3 in the MAVLink documentation), and always sets it to 1.0 instead. When following the mission, the copter simply goes to the waypoint, and waits for the amount of time specified by the “time” parameter, then moves on (it doesn’t orbit the waypoint at all).
I’ve confirmed that this isn’t an error in my own scripting; if I make an identical mission solely using QGroundControl, and set the radius to say 10.0, then upload, then the same behaviour is seen. In fact, even if you just upload the mission from QGroundControl, then immediately re-download from the Copter, you will see that the radius parameter has been overridden to be 1.0. This shows that the error is almost certainly on the vehicle end, and not PyMavlink/QGroundcontrol . I guess it could possibly be a bug in MAVLink itself as well, but I don’t have the sufficient understanding to test that.
Below is the argument mapping for MAV_CMD_NAV_LOITER_TIME from the MAVLink documentation, for reference.
1: Time | Loiter time. | min:0 | s
2 | Empty | |
3: Radius | Radius around waypoint. If positive loiter clockwise, else counter-clockwise. | | m
4 | Forward moving aircraft this sets exit xtrack location: 0 for center of loiter wp, 1 for exit location. Else, this is desired yaw angle. NaN for unchanged. | |
5 | Latitude | |
6 | Longitude | |
7 | Altitude
Unfortunately I can’t currently test on a later firmware version, and so I decided to report here first rather than GitHub, but if anyone is able to check this issue on a later version that would be great. Just following the same process as I did through QGroundControl would be enough.
Thanks,
Tom