when you have a moving baseline pair of ublox GPS modules and the
rover GPS does not have full fixed RTK lock on the base GPS then we
should not use it as our primary GPS as it's position and velocity can
be badly affected by the attempts of the GPS to gain a fixed lock.
This was observed in a flight with two F9P GPS, where the GPS velocity
data from the rover GPS went way off when it lost full RTK lock. It's
status stayed at 4, so it was selected as the primary GPS
Units are not associated with the CurrTot message. AP_BattMonitor.h indicates the total current consumed is reported in mAh. This change sets the units for CurrTot to Ampere seconds and applies a multiplier of 3.6 to convert the reported mAh value to Ampere seconds.
general scheduler delays could introduce small delays when writing SPort frames to the uart one byte
at the time potentially leading to rx desyncs on the SPort bus.
This fix replaces single byte writes with full frame writes.
The library has around 10ms to repond to polling so to guarantee frame integrity responses taking
longer than 7500us are discarded
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.
Saves 8 bytes per airspeed sensor (2 backends for 8 total), and removes
the unneeded width specifier, which has no impact on used memory, and
saves us 88 bytes of flash because we don't have to do work to shift the
bits around.
AP_Arming tacks on the sub-system bit.
Remove PiccoloCAN's silly nullptr check
Require the library to supply the failure message (no default message)
Remove default cases so authors know to think about places they should
add things.
AP_Arming tacks on the sub-system bit.
Remove PiccoloCAN's silly nullptr check
Require the library to supply the failure message (no default message)
Remove default cases so authors know to think about places they should
add things.
AP_Arming tacks on the sub-system bit.
Remove PiccoloCAN's silly nullptr check
Require the library to supply the failure message (no default message)
Remove default cases so authors know to think about places they should
add things.
AP_Arming tacks on the sub-system bit.
Remove PiccoloCAN's silly nullptr check
Require the library to supply the failure message (no default message)
Remove default cases so authors know to think about places they should
add things.
this fixes a problem where two different locations could both be
mapped to the same disk block in the terrain/*.DAT files. That meant
that pre-filled terrain on the microSD card would sometimes require a
download in flight. It also means that a RTL with loss of GCS could
sometimes fly through a region with no terrain data available
Other changes in this patch:
- allow for a 2cm discrepancy in the lat/lon of the grid
corners. This is needed to allow for slightly different floating
point rounding in tools that pre-generate terrain data to load on
the microSD
- added TERRAIN_OPTIONS parameter to allow the user to disable
attempts to download new terrain data. This is mostly useful for
testing to validate a terrain generator
switched spm_srxl.c to C++ compilation
Correctly set budget for half-duplex writes
Tidy PACKED and other externalities
disable SRXL2 on IOMCU and softserial - SRXL2 is a serial half-duplex protocol-only
fixed buffer overrun in SRXL2 parser
fix bugs in decoder sketch and allow output to SITL
add support for temperature, battery voltage, battery current, flight pack
altitiude, airspeed, attitude and compass, GPS, ESC telemetry based on BLHeli
status messages and QOS packets.
refactor into AP_Telemetry
conditionally compile based on HAL_MINIMIZE_FEATURES
don't initialize spektrum telemetry if there is no RC uart
This allows more channels to be passed to RCInput_UDP protocol while
also allowing less than 8 channels - this is similar to the approach
used by SITL in which the packet size is used to figure out the number
of channels.
- Move macros to functions and improve explanation about logic behind it
- Break code in functions to make it more readable
- Add doxygen comments about functions and how they work in a comprehensive manner
- Improve general code maintainability
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
when a user swaps compasses on AP_Periph we want to immediately
replace it. The compass ordering code was rejecting the new compass
and calling panic as it was out of slots. This changes the AP_Compass
ordering so that when we only have a single compass we operate in a
very simple manner where we always accept the first compass found
this addes the first 4 bytes of the thread name to persistent data. It
also re-arranges the data so that it is more efficiently packed,
allowing us to fit the new field
when both I2C4 and SPI4 are active on a H743 I found that some BDMA
completion interrupts were lost, which resulted in SPI transfer
timeouts. Close inspection of the ChibiOS BDMA, I2Cv3 and SPIv3
drivers did not reveal any issues, but I found that the issue only
happened when the first 4 BDMA streams were used. This change splits
the 4 streams across the first and 2nd half of the BDMA controller,
and that fixes the problem.
This works as there are only 2 peripherals (I2C4 and SPI6) that want
to use BDMA with our current setup. If we ever wish to enable ADC3
(which also uses BDMA) we will need to revisit this issue
glitches are in meters in vicon's frame
fail disables sending of vision-position-estimate messages
yaw is the vicon's heading in degrees. i.e. if vicon's "forward" is
pointing to the east, yaw should be set to 90
if CH_CFG_ST_FREQUENCY not match 1000000U on 16 bit CH_CFG_ST_RESOLUTION
we try to multiply now *= 1000000U/CH_CFG_ST_FREQUENCY; it may overflow 16 bit value.
These appear to have been replaced with instance fields on the UBX1 and
UBX2 messages.
Also mark the Instance field on UBX1, UBX2 as an instance field.
Separate prediction and correction steps are required to provide an up to date yaw estimate using IMU prediction before it may be required by SelectMagFusion() whilst still doing the velocity update after GPS data haw been pulled from the buffer by SelectVelPosFusion()
AP_NavEKF3: Fix typo in comment
AP_NavEKF3: Use uint32_t data type for msec timers
AP_NavEKF3: Misc msec timer fixes
Fix wrapping bug.
Use common timestamp.
AP_NavEKF3: Format fixes - remove tabs
AP_NavEKF3: Fix typing and wrap issue on time comparison
Enables the yaw to be reset in flight to a value estimated from a specialised yaw estimator. This allows faster recovery if taking off with a bad magnetometer and also allows yaw alignment and GPS use to commence in-air when operating without any yaw sensing.
AP_NavEKF2: Add missing accesor functions for default airspeed
AP_NavEKF3: fix failure to arm with EK3_MAG_CAL = 7
AP_NavEKF3: Fix failure to arm when not using magnetometer
AP_NavEKF3: Reduce yaw drift when EK3_MAG_CAL = 7
AP_NavEKF3: Add emergency yaw reset using a Gussian Sum Filter estimate
AP_NavEKF3: Reduce default minimum GPS velocity noise for Copters
Enables fail-safe to be set with more sensitivity and improves tracking accuracy.
Origin values were set using typical GPS performance for receivers on sale 6 years ago. Receiver performance has improved since then.
AP_NavEKF3: Prevent constant mag anomaly yaw resets
Prevents constant magnetic anomaly induced resets that can be triggered when flying with vehicle generated magnetic interference.
Allows for two resets per takeoff. Allowance for two resets is required, becasue a large ground based magnetic yaw anomaly can cause a sufficiently large yaw innovation that two resets in close succession are required.
AP_NavEKF3: Add option to fly without magnetometer
AP_NavEKF3: Rework emergency yaw reset logic
Use a separate external accessor function to request the yaw reset.
Allow reset requests to remain active for a defined period of time.
Tidy up reset function to split out accuracy check.
AP_NavEKF3: Fix vulnerability to lane switch race condition
Prevents the situation where a lane switch results in a lane being selected that does not have the correct yaw. This can occur if the primary lane becomes unhealthy before the external failsafe monitor has time to react.
AP_NavEKF3: Fix EKF_MAG_CAL = 6 behaviours
Fix bug causing the yaw alignment to be performed at startup before the GSF had a valid estimate.
Fix bug causing emergency yaw message to be output for a normal reset.
Fix vulnerability to reported negative yaw variance.
Remove duplicate timer checks.
AP_NavEKF3: Update EK3_MAG_CAL documentation
AP_NavEKF3: Relax yaw gyro bias convergence check when not using mag
AP_NavEKF3: Reduce yaw drift in hover with no yaw sensor
Uses the GSF yaw estimate if available which is better than the EKF's own yaw when no yaw sensor is available.
