Ok! I think it’s ready for submission, but I’d like to test an example script for inclusion with the PR, and I didn’t quite finish that today. Thanks to @iampete, of course, for a little guidance earlier as well!
1 Like
For some reason change speed is bugged since ages. It just works random. What i find sometimes helps is using not round numbers for speed. Try 10.2 or something similar.
This bug is present since at least 3 years ago.
Does anyone know if this bug has been fixed yet? I don’t recall seeing it in the release notes - but I’ll admit I haven’t been looking for it.
Creating a test photo mission today, I noticed a couple of things that may or may not be related.
- The mavlink command for do_change_speed has a new parameter compared to the docs in the wiki. The first parameter is now “type” - and the default value is “0” which is “airspeed.”
I have no idea how this may affect copter missions - that do not have airspeed sensors.
- The Mission Planner “AUTO WP - SURVEY GRID” feature for polygons, does not automatically add the do_change_speed command per the selections for the survey - as it used to.
Any news About it ?
New Firmware solve the problem?
I’m also having this problem.
Pretty scary when the drone takes off at 15/ms 2Mtrs above a field…totally ignoring it being set to 1/ms… It appears to ignore mission speed randomly. I’ll try the above workaround eg WP set at 0 0 0 0 0 0 0 and keep fingers crossed!!
Currently using Ardupilot 1.3.8375
Ardupilot 1.3 does not exist. That is your mission planner version 
Please update to ArduCopter 4.3.4-rc1 or newer
My bad. I meant Ardupilot Mission Planner 1.3.79 Build 1.3.8375! Not sure what the firmware on AC is except it was updated to the latest 3 weeks ago.
Anyway. I’ve found that this is a known bug Copter 4.2.x can't accept DO_CHANGE_SPEED in auto mission - #4 by rmackay9
Thanks for your reply though 
Please note also that option “DO_DIGICAM_CONTROLL” changes everything. Because of photo waypoints copter fly much slower.
@norim We don’t set DO_DIGICAM_CONTROLL so doesn’t affect our missions. But it does appear to be a bug, hopefully fixed in next release, fingers crossed
@vinnyferrari I’d be scared to set a WP with 0 ALT? Are you sure that’s not going to result in crash? yikes
If a waypoint command’s altitude is set to zero then it will use the vehicle’s target altitude at the moment it started the command. So if the vehicle is flying at 30m and it starts a waypoint command with the altitude field set to zero, it will fly at 30m.
Interpreting “0” as “current altitude” is a long standing feature but I also always set the altitude to the specific value that I want the vehicle to fly at.
Re the issue that @norim brings up, the do-digicam-control command is not directly related to the vehicle flying slower than expected. The issue is that we have a slight shortcoming in our waypoint navigation code which means the vehicle will fly slowly if waypoints are placed too close together.
@rmackay9 Thanks for the reply. That makes sense, please also note that in our case, sometimes the mission speed is excepted and sometime snot! that’s been the confusing part. We use both Solex and QGC, the waypoints speed in RC QGC are correct too, so its the Pixhwk that’s that following the syntax (Im assuming) PS We’re using Herelink system
OK, so the issue with do-change-speed is that it must appear after the first waypoint command. I guess this is discussed above already but in any case, it is on the list to fix, sorry for the troubles!
1 Like
Is this really a problem though? With a DO_CHANGE_SPEED command it will run at that speed until another change speed command is issued. So set the WPNAV_SPEED at what you want to run until WP1 then set speed commands as you like after that. Perhaps there is a use case I’m not considering?
Maybe this is that use case:
- User sets WPNAV_SPEED to a default, somewhat slow speed for survey or sprayer missions.
- Vehicle runs out of battery and executes a mid-mission RTL.
- User makes a slight modification to the mission to resume in the middle and sets a faster travel speed via DO_CHANGE_SPEED after takeoff followed by another DO_CHANGE_SPEED as the pattern is resumed.
- Faster speed is not accepted and user loses valuable flight time to slow speed.
1 Like
Ah OK. Resume a mission at speed from take-off. That makes sense.
The point is, it doesn’t obey any or rather randomly obeys the Do_Speed change
For our case we rarely fly faster than 2ms (boring I know lol) so changing the settings for WPNAV_Speed to 2ms might override to a default. Our issue is that because the speed set via simple grid, which is set to 2 is ignored. As soon as we start a mission. Which is only WPs and an Alt (we arm and loiter to a rough closer location before auto) once in auto the drones takes of at 15ms! And we’re only 2m alt so that’s scary! 
I’m not following why that would be the case.
If WPNAV_SPEED is set to 200 (2m/s) then that’s the speed it will start at when it begins the mission. Any DO_CHANGE_SPEED commands after that should take effect.
It’s not random really…
Maybe provide a log of a scary case. I of course believe you but it doesn’t quite match with what I think AP’s behaviour is.
1 Like