Rudder arming up - test PR for CodeQL scanning #13
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
.... which strikes me as sketchy if the camera is on a mount or not mounted along the lines of the aircraft axes
The HolybroG4_GPS accidentally got assigned the same ID when it was introduced. The CarbonixL496 was obscure enough to delete entirely and reassign the ID to the HolybroG4_GPS.
this allows the sim_arming_pos.lua screen to be used to setup screnarios for testing the glider model
the driver supports three different compasses with similar names
we had a deadlock between the mutex in HAL_ChibiOS CAN layer and the MAVLinkCAN object the deadlock arose because the low level CAN layer holds the HAL CAN mutex before it calls up to the MAVLinkCAN frame callback on the mavlink side, it took the MAVLinkCAN mutex before calling down to the CAN send layer, this meant it took the 2 mutexes in the opposite order the symptoms were: - failure to boot if we have active MAVCAN during reboot as we deadlock during the scheduler delay callback - deadlock during heavy MAVCAN usage
relying on failsafe means that we first feed in several bind-time values into these routines, which isn't good
this could never have worked
the arm/disarm cases were identical, so reuse the code
stops uwarning the user instantly
we do not run the arming checks if ARMING_CHECK is zero
this was ineffective as Blimp was not enforcing the parameter. We do now
as required by PR feedback (ArduPilot#16091) and my DevCall decision.
it was decided that your throttle-is-zero check was really part of the gesture and thus belonged in RC_Channels, not in AP_Arming.
it was decided that your throttle-is-zero check was really part of the gesture and thus belonged in RC_Channels, not in AP_Arming.
as determined at DevCall
as determined at DevCall
- does it really matter if the user does this when they can just throttle up to take off? - stops spreading oymode stuff through the code - kind of weird doing this in Arming anyway
peterbarker
force-pushed
the
pr/rudder-arming-up
branch
from
be42b69 to
2f65c15
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.