ArduPilot: Prevent std::future_error in takeoff, and return attitude in euler angles #2212
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses 2 issues when using MAVSDK with ArduPilot. These were tested on ArduPilot SITL Copter-4.4.4, using MAVSDK v2.0.1.
Takeoff crashes if the switch to Guided mode fails
Observation
When ArduPilot SITL starts up, it takes time before the GPS initializes and for the UAV to obtain a position estimate. During this time, if the takeoff command is given, an unhandled std::future_error exception is thrown.
Cause
Within Action_Impl::takeoff_async_apm, if set_flight_mode_async fails, it triggers the callback to set a failed result. However, it still calls send_takeoff_command, which triggers the same callback, and tries to set another result value for a fulfilled promise.
Fix
Just don't call the send_takeoff_command if switch to Guided mode fails.
NaN values received for attitude in euler angles
Observation
The values received for roll, pitch, yaw in the telemetry are NaN.
Cause
In TelemetryImpl::process_attitude, the values are extracted from the received telemetry message and correctly populated into a Telemetry::EulerAngle struct. However, this struct is then never used again. Instead, it grabs the quaternion version, and does a conversion to euler angles. I'm not sure what the actual reason causing the NaN is, but it's probably somewhere in the conversion.
Fix
Use the Telemetry::EulerAngle struct that was populated.