A constant large value in the (signed) normalized innovation test ratio is a sign
of bias in the state estimate. This metric can be used to trigger a
covariance boost or reset
Some receivers are initializing to some heading and then resetting to
the correct one after a couple of seconds. EKF2 should detect that and
reset to the new value
The following exception occurs in some rare cases (but only with make build: NO_NINJA_BUILD=1 px4_sitl_default):
Traceback (most recent call last):
File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 79, in <module>
save_compressed(filename)
File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 33, in save_compressed
with open(filename, 'r') as content_file:
FileNotFoundError: [Errno 2] No such file or directory: '/__w/PX4-Autopilot/PX4-Autopilot/build/px4_sitl_default/component_general.json'
make[3]: *** [src/lib/component_information/CMakeFiles/component_information_header.dir/build.make:68: component_general.json] Error 1
- naming consistency (estimator prefix as "namespace")
- only publish if baro is available and bias is changing as a small logging optimization
- avoid unnecessary copying (get const reference to status directly)
- trivial code style fixes
This reverts commit 446598d00359d42acef2619c157a493d2997edd5.
The first warning was due to a race condition that is fixed by the previous commit;
don't omit the first warning anymore
Only modify the _setpoint for takeoff when there is a new uORB message
to avoid a race condition where both vel_sp(2) and accel_sp(2) can be
NAN at the same time.
- this avoids any jitter in the integration timespan from impacting the vibration metrics
- vehicle_imu_status vibration metrics are not consumed by anything
(yet), so changing the scaling of the metric shouldn't matter
This reverts the behavior for offboard velocity setpoint.
Back in v1.11, the velocity input in NED_BODY was assumed to be in the
world frame but rotated by yaw to the vehicle frame. With the current
state the frame is completely fixed to the body. While this might be
technically correct, it doesn't seem much intuitive for multicopters
and breaks the MAVSDK offboard velocity API.
So as an example, with a velocity setpoint of 5 m/s forward, the drone
would in
- v1.11: fly forward with 5 m/s
- v1.12: start to fly forward by pitching down but then descend rapidly
as the forward velocity would translate to a setpoint in Z into the
ground as it is pitched down.
This commit restores the behavior to what we had previously.
Forward message to other mavlink channels only if it is broadcast or the target component was seen on this link before (at least one message was received)
- minor scheduling improvements
- if expected number of samples larger than expected adjust timestamp sample and save sample for next iteration
- when scheduling via data ready interrupt (with no FIFO watermark) count continuously without clearing
