@dkemxr which log did you presented ?
secon_wrong_speed_2024-06-23 13-07-32.bin or
first_correct_speed_2024-06-23 12-39-42.bin ???
…
Wrong speed.
@Yuri_Rage I can wait a while …please check the logs when you will have access to computer. This are similar 2 flight on one flight DO_CHANGE_SPEED worked on second did not.
@Yuri_Rage did you have time to check the logs. From this flights it is visible for me that DO_CHANGE_SPEED still have problems…
I think the combination of multiple, consecutive, non-waypoint DO commands may be the culprit, but I am unconvinced, and I cannot find a reason for the behavior you’ve observed.
Your mission (attached in full below) contains:
The GCS message order is somewhat curious:
2024-06-23 06:14:37.494 Mission: 1 Takeoff
2024-06-23 06:14:37.496 Mission: 2 ChangeSpeed
2024-06-23 06:14:37.496 Mission: 4 WP
2024-06-23 06:14:37.499 Mission: 3 CondYaw
2024-06-23 06:14:51.414 Reached command #4
2024-06-23 06:14:51.414 Mission: 5 SetCamTrigDst
Your copter’s speed never changes to 25 kph, as you observed.
Interestingly, when I run this exact mission in SITL with 4.5.5-beta1 (the default “stable” build for Mission Planner right now), I get the exact same message order, but I see 25 kph throughout the mission. So the behavior your log shows is not reproducible in SITL + 4.5.5-beta1.
@rmackay9, can you review, please (scroll up to the last Google drive link for the log)? Is there a meaningful change to DO_CHANGE_SPEED between 4.5.4 and 4.5.5-beta1?
Related to this user’s list of annoyances - CONDITION_YAW is wonky because the nav state is reset at each waypoint, causing a “twitch” rather than constant orientation at each waypoint change. I think a similar state reset/integrator clear happens when a speed change is requested via scripting, which causes some weird, almost wandering behavior for both Copter and Rover on speed changes during auto mode. I think you discussed addressing this in 4.6, but it’s worth a reminder.
@norim, of note, if I momentarily select loiter mode and then return to the mission by selecting auto mode, WPNAV_SPEED is obeyed. This is expected behavior, since the DO_CHANGE_SPEED command happens at WP2, and we are resuming the mission at a point beyond the command to change speed.
1 Like
Hi @norim,
I haven’t tested thoroughly but I think the issue is that the vehicle is already above the Takeoff command’s target altitude when the vehicle is switched to Auto mode. This causes the takeoff command to be completed very quickly, so quickly that the do-commands do not have enough time to run.
In the working log we can see the vehicle starts below 30m
In the non-working log we can see the vehicle starts above 30m
EDIT: I’ve created a PR to add a warning to the wiki.
Thanks very much for the report!
2 Likes
@norim, I was able to reproduce @rmackay9’s case in SITL and confirm that DO_CHANGE_SPEED may be ignored if it immediately follows TAKEOFF, and the craft has already achieved TAKEOFF altitude when entering auto mode.
The original bug from 4.2 has been patched, and the fix remains viable. This is indeed a different case with a different cause.
Suggest you handle this edge case by inserting a waypoint after TAKEOFF and before DO_CHANGE_SPEED to ensure the speed change is processed.
For the mission in question, I would make it look like the screenshot below, duplicating the DO_CHANGE_SPEED and CONDITION_YAW commands just after the first waypoint of the photogrammetry mission. Set WP_YAW_BEHAVIOR=2 and remove all subsequent CONDITION_YAW commands.
In this way, you ensure that both speed and yaw are effectively commanded per your intent either immediately after takeoff or if entering the mission from a loiter elsewhere. Removing CONDITION_YAW from subsequent waypoints avoids the annoyance you have regarding yaw behavior during the mission.
(I accidentally left an extra CONDITION_YAW at WP8 - delete that one, too)
2 Likes
Another method that would work is adding a WAYPOINT command immediately after the takeoff with all zero lat, lon, alt and a delay of 1 second.
1 Like