When setting pos_sp_triplet yaw, also set the yaw valid flag to true

[dusan19]

I ran into a problem when executing a mission with following mission items:

1. Set ROI location (different than the initial drone heading)
2. Takeoff
3. Waypoint
   The following happens: The drone takes off at the takeoff location and hovers there indefinitely instead of going to the next waypoint (mission item 3).
   I observed this using the simulation with a multicopter.

After some debugging I found out that this is the what leads to this behavior:

1. ROI mission item is processed and reports mission item reached
2. Takeoff mission item is processed and takeoff work item is inserted
3. Work item is completed, drone took off, and the actual takeoff nav_cmd type is being processed. In set_mission_item() current nav_cmd is changed from takeoff to waypoint, since the drone took off already, at the same step mission item yaw is set to NAN. Furthermore, set_mission_item() calls mission_item_to_position_setpoint() which sets the triplet yaw valid flag to false since yaw is set to NAN.
4. The drone reaches the takeoff position as nav_cmd is set to waypoint, but the yaw is not reached. mission::on_active() calls heading_sp_update() which sets the mission item yaw to face the ROI location and sets the pos_sp_triplet yaw to the same value. This should ensure that the drone yaws towards the ROI, but the yaw_valid flag is false so this doesnt happen and the yaw setpoint is never reached, which means that the mission item is never reached.

Solution:
Proposed solution is just setting the yaw_valid flag to true when heading_sp_update() updates the heading. This fixed the problem in my case, with a multicopter executing the mission mentioned above.

[julianoes]

Thanks for the fix! I think that makes sense.

@dagar or @MaEtUgR can you double check?

[dusan19]

Hey, can you guys merge this fix if there is no complaints?

[dusan19]

@dagar should the merge go in the other direction (after rebasing)?

[dagar]

It's a merge into the pull request branch to make sure everything still passes CI. Then the entire thing is squashed and merged back to master. Alternatively it could have been rebased, but this is what github let's you do easily through the web interface.