forked from PX4/PX4-Autopilot
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stable #5
Open
natesimon
wants to merge
8,087
commits into
irom-princeton:stable
Choose a base branch
from
PX4:stable
base: stable
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Stable #5
Conversation
This file contains 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
- gz in PX4/Firmware (5f8f021): PX4/PX4-gazebo-models@2228336 - gz current upstream: PX4/PX4-gazebo-models@6b4ed09 - Changes: PX4/PX4-gazebo-models@2228336...6b4ed09 6b4ed09 2024-02-23 Sergei Grichine - Added IMU sensor noise to the model, to avoid STALE messages (#34) 953e02b 2024-02-22 frede791 - add imu sensor model noise
The gyro bias estimate from EFK2 is really good when at rest and should be used by the yaw estimator to prevent heading drifts due to poor heading observability.
…n VTOL transition (#22842) * FW Position Control: some cosmetical changes Signed-off-by: Silvan Fuhrer <[email protected]> * FW Position Control: disable roll constraining warning in VTOL transition In transitions it is expected that the roll is constrained, and instead of defining an aribitrary threshold let's rather disable the user warning in that case. Signed-off-by: Silvan Fuhrer <[email protected]> * FW Pos C: define magic numbers for roll constraining warning as constants Signed-off-by: Silvan Fuhrer <[email protected]> --------- Signed-off-by: Silvan Fuhrer <[email protected]>
- place upper bound to prevent looping indefinitely (high publish rate, etc)
* vtol_type: enable pusher assist also in Descend mode Signed-off-by: Silvan Fuhrer <[email protected]> * vtol_type: treat Descend as Land for pusher assist Signed-off-by: Silvan Fuhrer <[email protected]> --------- Signed-off-by: Silvan Fuhrer <[email protected]>
If part of the Kalman gain is zeroed, the first step of the joseph update does not produce a symmetrical matrix.
…anded (#22850) Signed-off-by: Silvan Fuhrer <[email protected]>
We had a special handling for RTL triggered in vtol_takeoff state. The idea is to wait until the VTOL Takeoff is completed and only then switch to RTL. On a second thought this special handling isn't really necessary and for the sake of simplicity should be removed. This also removes the side effect of the indicated flight mode after RTL being set to VTOL_Takeoff again. Signed-off-by: Silvan Fuhrer <[email protected]>
Signed-off-by: Silvan Fuhrer <[email protected]>
Signed-off-by: Silvan Fuhrer <[email protected]>
This fixes various edge cases when input is set to both: RC and MAVLink gimbal protocol v2. Specifically: - We no longer immediately reset primary control if there is no update, otherwise this will reset immediately after an commands. - Talking of commands: GIMBAL_MANAGER_CONFIGURE no longer switches control to MAVLink but only an actual incoming setpoint command does. - And incoming setpoint command only triggers UpdatedActiveOnce which means we will check RC again afterwards and if there is big movement switch back to RC. That's the intuitive thing to do until we have better reporting about who/what is in control. - Also, with RC we no longer always set us to be in control but only on major movement.
Backports: stm32h755II backport stm32h7: allow Ethernet MAC without PHY imxrt: imxrt11xx set core clock to 1p15v regardless of ocotp imxrt: Correctly update PLL, bit has to toggled instead of being set
…ess than the interval time after boot (#23384) * SubscriptionInterval: ensure _last_update is never before timer start
Saves 17.3 kilobytes of flash 😮
…, with new features and fixes (#23386) Co-authored-by: Chiara de Saint Giniez <[email protected]>
…elay Signed-off-by: Silvan Fuhrer <[email protected]>
This resets the USARTs' clock source selection to the default, in case it has been changed by the bootloader. This is required if booting from the ArduPilot bootloader which happens to reset the clock selection to PLL. Without this fix, UARTs (including the console) is garbled, so presumably at an invalid baudrate.
- keeps them as local params at init - only allow to set at init
- add answer command logging
…ion is not valid Signed-off-by: Silvan Fuhrer <[email protected]>
Co-authored-by: Weng <[email protected]>
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.
Please use PX4 Discuss or Slack to align on pull requests if necessary. You can then open draft pull requests to get early feedback.
Describe problem solved by this pull request
A clear and concise description of the problem this proposed change will solve. Or, what it will improve.
E.g. For this use case I ran into...
Describe your solution
A clear and concise description of what you have implemented.
Describe possible alternatives
A clear and concise description of alternative solutions or features you've considered.
Test data / coverage
How was it tested? What cases were covered? Logs uploaded to https://review.px4.io/ and screenshots of the important plot parts.
Additional context
Add any other related context or media.