Did you update mission planner as well?
I’m Running 1.3.77.1, i will try again witch a lastest version. I dont remember if i’ve tried with the last.
Thanks for the report. This is a real bug so well done uncovering it! I’ve created an issue here and this is almost undoubtedly caused by a change we made to the takeoff and landing code.
The work around until we have a fix is to add a WAYPOINT command immediately after the TAKEOFF with all zero lat, lon and alt. Then put the DO_CHANGE_SPEED after this all zero WAYPOINT command.
3 Likes
Yes the bug is new for 4.2.0 and is present in all subsequent versions.
I discussed with Leonard and we have a plan to fix it but it will require moving where we hold the latest desired speed from the waypoint controller up into the Auto mode. This is not a huge change but it will require some careful testing.
1 Like
@rmackay9, I am very close to submitting a PR for a Lua binding that interacts with some of these methods (set_desired_speed for Rover and set_speed_xy for Copter) - effectively giving us DO_CHANGE_SPEED functionality in scripting, as we discussed earlier this year. It is implemented much like the guided mode bindings that already exist.
Is the bug fix impactful enough to warrant waiting for it before I submit the PR?
2 Likes
Sounds good. In general our rule is “first person with a PR wins!” so feel free to raise that and I’ll handle any merge conflicts that arise.
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