I want to change the horizontal speed of my Arducopter Quad during automated mission execution. Firmware is latest 3.1. The mission is very simple (first number is mission item sequence):
0: DO_SET_HOME (it always should be sequence zero, right?)
1: NAV_WAYPOINT
2: DO_CHANGE_SPEED to 2 m/s
I’m expecting my copter to fly towards waypoint with 2 m/s speed, but instead it always flies with the speed defined by WPNAV_SPEED global parameter. I tried all the combinations of the WAYPOINT/CHANGE_SPEED commands, like reversing the order, adding of dummy waypoint before and after the change speed command, just everything i can imagine, but still - change speed is ignored. Is it a known bug which is still in 3.1 FW? Or maybe someone could help me telling what I’m doing wrong and provide a valid sequence?
Other related questions:
Official Mavlink documentation stays that Param1 of DO_CHANGE_SPEED command is a speed type (air/ground), but ArduCopter code uses param1 as a speed value:
BTW, MissionPlanner also suggests param1 is a speed value and does not tell anything about speed type. So where is the truth? Or it is just a bug?
Anyone could explain what does “dummy waypoint” mean? It is about “DO_xxx commands currently need a dummy waypoint placed after the command”. When I tried to insert a waypoint with all zeros, my Quad started heading towards the equator… So I used a copy of next waypoint as a dummy one. This seems to help a little bit for DO_SET_ROI command to work properly in some situations.
As I see from the forums, there is a lot of confusion caused by the automated mission execution logic implemented in Ardupilot. Maybe someone from Ardupilot development team could give some reference examples of various scenarios, like how to user change speed, roi, delays, jumps and so on.
ahanin,
The do-set-speed should work but I think it will only take effect after you pass the next waypoint. That’s not ideal but that’s the way it is at the moment. We can probably make it take effect immediately in a future release (feel free to raise an issue on the issues list) although we’re quite limited on the improvements we can make for the APM2…for pixhawk the sky’s the limit.
So we have “do” commands and “navigation” commands. the do commands must always be between two navigation commands which is why you need a dummy waypoint if the “do” command is right at the end of a mission. This was apparently done on purpose in the early days of arduplane (which was the original source of arducopter) but will certainly be resolved in a future release.
Hi rmackay9,
Thanks for your response. Well, I have tried a mission with a lot of waypoints and change speed is put after every waypoint (distance between waypoint is big enough), so it is always surrounded by navigation commands as needed. Every change speed command sets speed to different value, but the result is strange - few first waypoints (more than 2) are flown with default speed (i.e. WPNAV_SPEED), then somewhere in the middle of the mission speed is changed to the value of the last change speed commands and this speed then stucks even if I re-run the mission again without arming-off the copter. So complete mess, I would say… I spent days and flown almost hunderd (!) missions with different sequences and just can say that change speed command does not work almost at all. This is true for both 3.0.1 and 3.1 FW.
Meanwhile, MAV_CMD_DO_SET_ROI command is definitely fixed in 3.1 and work flawlessly the way I expect. But even if I put change speed command before or after the MAV_CMD_DO_SET_ROI command, then ROI still works fine, but speed - doesn’t. And also MAV_CMD_CONDITION_YAW works great, even when it is mixed with ROI commands, so definitely my command sequence looks to be right and it is just change speed that does not work.
I’ll then try to raise a bug about it if noone objects.
So I used a copy of next waypoint as a dummy one. This seems to help a little bit for DO_SET_ROI command to work properly in some situations.