Support the widened mavlink_message_t layout and reconstruct CRCs for independent source-width and targeting flags. Share PARAM_SET header decoding so consumers use the correct layout threshold. Retain older layouts and test flag combinations, reduced payload storage and invalid frames.
guided_above_terrain_posvelaccel_sub.lua integrates its position target
forward by the time since the last callback. When a callback arrived
later than 2/RUN_HZ it substituted 1/RUN_HZ for the real interval:
if (dt > 2.0 / RUN_HZ) then
dt = 1.0 / RUN_HZ
end
so a callback 243ms late advanced the target by 50ms and the remaining
193ms was discarded. The position target then falls behind the clock,
and the vehicle - which tracks that target accurately - covers less
ground than the commanded speed implies.
Measured from a failing Sub.GuidedAboveTerrain run under autotest at
--parallel=16, over the 60 simulated seconds the test watches:
GUIP updates 1047 at 17.2Hz (nominal 20Hz)
late callbacks 76 of 1047 (7.3%), worst 243ms
time discarded 5.82s, so 55.08s integrated of 60.90s elapsed
distance 27.90m of an expected 30.00m, +-1.00m -> failed
The dataflash shows the loss is upstream of the controller, not in it:
the script commanded 0.495m/s and the position controller achieved
0.442m/s against a desired 0.443m/s - it tracked what it was given to
within 0.001m/s, and what it was given was slow.
Cap the step at a fixed MAX_DT instead, so ordinary jitter is
integrated honestly and only a real stall is bounded. Pinning the
simulation speedup was tried first and is not a fix: at
context_set_speedup(10) the run still lost ground, reaching 28.93m,
because it reduces how often callbacks are late without changing what
happens when they are.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This reverts commit 6e7367b86f.
These reductions reduce the usage of the Lua stack, which is stored in
the heap. This reverts back to the stock Lua values; some complex
scripts may desire extra locals. There is some increased risk of memory
fragmentation and so forth but presumably such scripts are prepared.
The actual C stack depth can be limited by `LUAI_MAXCCALLS`.
Every CAN driver had grown its own option bit to log raw frames as CANF
messages. That is now redundant: CAN_Pn_OPTIONS bit 0 (LogAllFrames)
logs every frame on the bus, and unlike the script option it covers
transmitted frames as well as received ones, as the logging callback is
run from both CANIface::receive() and CANIface::send().
Removed the option and its logging from BattMon_ANX, EFI_HFE,
EFI_Halo6000, EFI_NMEA2k and UltraMotion, and dropped the CAN_logger
example, which did nothing else.
BATT_ANX_OPTIONS, EFI_HFE_OPTIONS, EFI_H6K_OPTIONS and EFI_2K_OPTIONS
had no other bits defined, so those parameters are gone. UM_OPTIONS
keeps ParseTelemetry and SendPosAsNamedValueFloat at their existing bit
positions.
maps uavcan.equipment.power.CircuitStatus circuits onto scripting
battery monitor instances, giving per-circuit voltage and current
monitoring from CAN power distribution nodes
Parameter-name headings in the driver and applet markdown docs were at
the same level as the "Parameters" heading they sit under, so they
rendered as siblings rather than being nested within that section.
Demote them one level throughout.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ahrs:wind_estimate() is deprecated. Scripts which already checked the
returned value for nil now get a check which actually means something;
the rest fall back to a zero wind vector, which is what they were
already getting from an invalid estimate in most cases.
ahrs:get_wind() should be used instead. The generator can not attach a
deprecation warning to a manual binding, so the warning is emitted from
the binding itself in the same manner as the generated bindings do it.
The Vector3f-returning AP_AHRS::wind_estimate() method is about to be
removed from the AHRS interface. Scripting has no way of receiving
both the vector and the validity flag from AP_AHRS::get_wind(), so
provide the old shape as a compatibility binding here rather than
keeping a method in AP_AHRS purely for scripting's benefit.
No change to the Lua API.
test scripts / build (astyle-cleanliness) (push) Canceled after 0s
test scripts / build (check_autotest_options) (push) Canceled after 0s
test scripts / build (logger_metadata) (push) Canceled after 0s
test scripts / build (param-file-validation) (push) Canceled after 0s
test scripts / build (param_parse) (push) Canceled after 0s
test scripts / build (python-cleanliness) (push) Canceled after 0s
test scripts / build (shellcheck) (push) Canceled after 0s
test scripts / build (validate_board_list) (push) Canceled after 0s
test scripting / test-scripting (push) Canceled after 0s
AP_Periph does not build AP_OSD, but OSD_ENABLED defaults to 1 so the
generated bindings failed to link with undefined references to
AP_OSD::_singleton
The rangefinder_quality_test.lua example (driving the Sub RngfndQuality
autotest) pushes a distance/quality/status through the scripting range
finder driver interface, waits UPDATE_PERIOD_MS, then reads it back
through the client interface and checks it matches. The value is copied
from the driver state to the client-facing state by a periodic task on
the main loop, which is a different thread to the scripting VM. Under
host load (e.g. parallel autotest) or high SIM_SPEEDUP that copy can land
after the read, so the client still reports the previous test's value and
the script emits a spurious failure -- reproduced at --speedup=40, where
the 28m test read back 27m and reported "#complete#: !!failure!!".
Retry the read up to MAX_EVAL_RETRIES times (UPDATE_PERIOD_MS apart)
before declaring a mismatch, so a slow cross-thread copy is waited out
while a genuine mismatch still fails once the retries are exhausted.
With this RngfndQuality passes 20/20 at --speedup=40 and 100 (was ~1 in 6
failing).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Checking libraries/AP_Scripting/modules/mavlink_attitude.lua 2 warnings
libraries/AP_Scripting/modules/mavlink_attitude.lua:37:43: used variable _max_lag_ms with unused hint
libraries/AP_Scripting/modules/mavlink_attitude.lua:37:56: used variable _convergence_loops with unused hint
this allows a script which converts ArduPilot targets into a wire protocol to send to a gimbal to tell ArduPilot what sorts of targets the script/gimbal can understand.
For example, if the gimbal being controlled can understand a lat/lng/alt, the script can tell ArduPilot that with the new method call.
Andrew Tridgell
Clyde McQueen
Peter BarkerandClaude Opus 5
Thomas Watson
Iampete1
Andy Piper
Yuri Rage
Randy Mackay
Marek S. Łukasiewicz
Pierre Kancir
Ben ButterworthandPierre Kancir
George Zogopoulos
Huibean
Christian Clauss
Bob Long
Tim Tuxworth