- this lowers the load immediately at boot while still allowing each VehicleIMU instance to properly measure the actual accel/gyro data rates
- for lockstep builds this is ignored and VehicleIMU initially runs with every new sensor_accel/sensor_gyro publication
I changed the input constraint in #15349 but screwed up the usage
because I was convinced it's püass by reference. I'll double check
for sure next time.
- vehicle_air_data won't necessary have an update every iteration and these adjusted throttle values aren't stored
- this only would have worked in the past because the vast majority of systems were using the ms5611 barometer with a publication rate that's faster than the controller
This fixes the takeoff and land CI test where we do a takeoff and land
without RC connected.
In my opinion it does not make sense to go into RC lost failsafe if
a datalink is still available.
Of course, this can be dangerous if someone has a companion computer
connected which gets detected as "data link" but actually has no
connection to the ground station.
During takeoff, Navigator is sending a constant yaw value.
However, there is always a reset at 1.5m of the yaw estimate in EKF2
that is not handled by Navigator that produces a glitch in the rate
controller. Given that in FlightTask, the yaw
is already computed and properly corrected in case of an estimator reset
event, we just ignore the yaw value sent by navigator during takeoff.
- increase rate
- cpu load calculation grab timestamp atomically
- only check one task per cycle (but cycle at a higher rate)
- decrease available FD threshold
- minor cleanup
The acceleration setpoint gets implicitly inherited from the altitude
flight task since #14212. This feed-forward adds an unwanted
acceleration when the right stick is deflected. Instead I'm using it
to command the expected centripetal acceleration when flying
in a circle for better orbit tracking.
For the RC controlled yaw behaviour, we do a yaw setpoint according to
the stick expo. The uncontrolled yaw behaviour behaves undefined.
Switching between yaw behaviours makes the drone stand still for a
moment, which probably can be improved.
* FW attitude control scaling fixes and cleanup
This commit aligns the scaling better with the derivations in
https://dev.px4.io/master/en/flight_stack/controller_diagrams.html#airspeed-scaling
Integrator terms now scale with IAS^2 (all three axes)
To match the roll and pitch controllers:
- Yaw integrator scale is now applied during accumulation, not to
integral value (so now FW_YR_IMAX is respected more intuitively)
- Yaw FF term now scale with IAS instead of IAS^2
Also made a number of small changes to make the three files
(roll, pitch, yaw) 3-way diffable to be clearer about what the
differences among them are.
* Remove unused yaw coordination method
- "Coordination method" open vs. closed code removed, since closed
is never used and not actually implemented.
- No change to behavior
* Remove PX4_WARN messages
Co-authored-by: george <george@campsix.com>
This Commit includes a update of the mavlink submodule
since the CELLULAR_STATUS message was updated, the necessary changes were done together
Add enums
This removes the check for the current position of the VTOL swtich, as arming is already prevented if in transition mode,
plus also if VTOL and in fixed-wing mode (unless CBRK_VTOL_ARMING is set).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- schedule on interval multiple of sensor_gyro publications without increasing the configured integration rate
- IMU_INTEG_RATE add enums to guide appropriate selection
- add average calculation bounds to prevent incorrect calculation and force monitoring again if there are consecutive gaps in data
Matthias Grob