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.
Andrew Tridgell
Peter Barker
Henry Wurzburg
Randy Mackay
Michael du Breuil
Tatsuya Yamaguchi
Andy Piper
david sastre
Lucas De Marchi