This reverts the change from #13895 and instead resolves the issue by
increasing the scale factor limit to 1.4
There is an open question as to why some RM3100 compasses show a
different scale factor (by about 1.25 times) to other versions of the
same sensor. As we haven't resolved this properly it seems the correct
thing to do is follow the datasheet but allow for a wider range of
scale factors to cope with the variation between sensors
add filtered second and third harmonics and log them
make sure we use all of the gyro samples available on each axis rather than skipping
separate gyro update from fft start to minimize time in fast loop
add FFT_HMNC_PEAK to allow users to select which noise peak and which axis will be tracked.
make sure the self-test runs once and display the results
report self-test failure reason. make sure self-test runs for all windows.
always give logging a chance to run at IO_PRIORITY
add log message documentation
make sure the engine still runs even when the arming check has been disabled
record last FFT update time and cycle time and fallback to throttle estimate when update is too old
delay for longer in FFT thread between cycles to cope on F4
try really hard to get a viable frequency estimate
change range on MAXHZ/MINHZ to reflect that 50Hz is actually quite dangerous
swap the center peak for one of the shoulders if there is temporarily a closer match with the frequency trend
when FFT is disabled still log harmonic notch frequency
use distance matrix to find most appropriate peak
use a median filter to remove outliers before filtering
discount peaks that are relatively too low in energy
make sure harmonic fit is tracked for both potential targets
convert all gyro buffers to ObjectBuffer<float> for lock-free access
run all FFT steps inside the FFT thread
calculate cycle time and loop delay correctly
drop samples when the ring buffer is full
new dsp peak detection algorithm
add DSP sketch with frequency ascii art
tool to generate gyro data frames from batch sampled DF logs
add generated data from real Y6B flight
allow fft_start() to use ObjectBuffer<float> for lock-free access
allow ObjectBuffer to be resized
This limits the use of the reset to situations where it is a last ditch resort before a lane switch and failsafe.
This will limit false positives for general deployment, but still provide protection from fly-aways at the cost of some increase in reaction time.
This limits the use of the reset to situations where it is a last ditch resort before a lane switch and failsafe.
This will limit false positives for general deployment, but still provide protection from fly-aways at the cost of some increase in reaction time.
fetch item/s by their index, and review wp data, etc.
AP_Mission: ran mission files through approved astyle as they were non-compliant before this( astyle --options=Tools/CodeStyle/astylerc )
UAVCAN rangefinders add themselves to the frontend drivers as the
devices appear. If they turn up before RangeFinder::init() is run then
this prevented init() from scanning for the other rangefinders as
num_instances is non-zero
This also fixes a race condition in updating num_instances in the
UAVCAN backend
GCSs may request this very early on in the boot process, particularly
for SITL.
If we try to send it during a delay callback then we end up dropping it
at the moment - but we'd already sent the ack in response to the
request.
If anything in start_new_log did logging (for example, by sending a
statustext), we end up infinitely recursing.
With the patch:
diff --git a/libraries/AP_Logger/AP_Logger_File.cpp b/libraries/AP_Logger/AP_Logger_File.cpp
index 69b8ef0431..eb422d10f8 100644
--- a/libraries/AP_Logger/AP_Logger_File.cpp
+++ b/libraries/AP_Logger/AP_Logger_File.cpp
@@ -778,6 +778,7 @@ void AP_Logger_File::PrepForArming()
*/
void AP_Logger_File::start_new_log(void)
{
+ gcs().send_text(MAV_SEVERITY_WARNING, "Starting new log");
stop_logging();
start_new_log_reset_variables();
pbarker@bluebottle:~/rc/ardupilot(master)$
We see:
at ../../libraries/AP_Logger/AP_Logger_File.cpp:781
this=0x555555ad9d30, pBuffer=0x7fffff8209d0, size=75, is_critical=true)
at ../../libraries/AP_Logger/AP_Logger_Backend.cpp:372
this=0x555555ad9d30, pBuffer=0x7fffff8209d0, size=75)
at ../../libraries/AP_Logger/AP_Logger_Backend.h:32
this=0x555555ad9d30, message=0x7fffff820b10 "Starting new log")
at ../../libraries/AP_Logger/LogFile.cpp:466
this=0x555555a6d758 <copter+11384>,
message=0x7fffff820b10 "Starting new log")
at ../../libraries/AP_Logger/AP_Logger.cpp:752
this=0x555555a6e708 <copter+15400>, severity=MAV_SEVERITY_WARNING,
fmt=0x5555557d64d0 "Starting new log", arg_list=0x7fffff820be0,
dest_bitmask=1 '\001') at ../../libraries/GCS_MAVLink/GCS_Common.cpp:1847
this=0x555555a6e708 <copter+15400>, severity=MAV_SEVERITY_WARNING,
fmt=0x5555557d64d0 "Starting new log", arg_list=0x7fffff820be0)
at ../../libraries/GCS_MAVLink/GCS.cpp:53
this=0x555555a6e708 <copter+15400>, severity=MAV_SEVERITY_WARNING,
fmt=0x5555557d64d0 "Starting new log")
at ../../libraries/GCS_MAVLink/GCS.cpp:60
at ../../libraries/AP_Logger/AP_Logger_File.cpp:781
this=0x555555ad9d30, pBuffer=0x7fffff820dc0, size=75, is_critical=true)
at ../../libraries/AP_Logger/AP_Logger_Backend.cpp:372
I'm not aware of any instances in the code where this will actually
happen - but it could easily sneak in.
