I did find the wp_speed can only be updated from the GCS cmd ID==178 during a mission. This is not exactly suitable in my thoughts. The cmd id==16 contents only have lat, lng, alt and so on, but not the speed cmd included. I don’t know if there is a limitation in the mavlink transmition memory size. But I do like to keep updating my wp_speed in each wp_point.
Say we have a scenario here: We’ve done the mission uploaded and then process an RTL cmd. Before we reach the home position, we want to re-do the mission which may start from after the id==178 cmd for another time. In this case we have to resend the mission to our vehicle and re-start after the mission sucessfully uploaded just in order to update the wp_speed information which may be different from the RTL speed. This is all because we don’t have complete waypoint information in our storage, which is indeed the velocity parms of each waypoint missing.
I’m wondering the flaw in this kind of cmd design in mavlink. Why should’nt we store our waypoint speed together? Just compromised to the buffer size?
Why would you need to re-upload? Just send restart mission command.
You can use do_change_speed cmd to set cruise speed.
According to the QGC UI, if I want to restart the mission after I finished my mission, the my QGC need me to firstly send this mission again to the vehicle and can the mission restart.
I try to rewrite the code in QGC. The mission indeed can restart but we are in the RTL speed still in fly waypoint mission.
I mean the mission storage have no speed information, I want to fix this flaw. Can I tyr to start a pull request to describe my ideas?