- if "landed" and "maybe_landed" states are false then both the "hit_ground" and the "low_thrust" condition need to be true in order to detect landing
- ground contact MC NAN setpoint workaround
- ground contact additionally check acceleration setpoint
- schedule with vehicle_local_position updates (most updates require valid local position)
- don't allow LNDMC_Z_VEL_MAX to exceed MPC_LAND_SPEED
- ground contact horizontal movement checks default to failed if estimates aren't available
- always check system field for validity
- reject any data outside of "servo position" valid range from Spektrum specification
- properly support XPlus channels (12+)
- debug message if channel count changes
- log full sensor_combined by default for now
- small decrease to input_rc rate (manual_control_setpoint is no longer filtered)
- sensor_correction can be logged at full rate (low publication rate)
- this is to prevent vtol_att_control running at absurdly high rates (kilohertz) from every single actuator controls publication from both the multicopter and fixed wing controllers
- I don't really like this solution, but it works for now until there are larger VTOL architectural changes in place
- 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
- 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.
- 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
* 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
- cleanup failover related messaging
- store previous failover count to prevent unecessary checks
- check for parameter update initially to minimize work after fetching
fresh sensor data
Daniel Agar