Skip to content

Esp32 dev image - #40

Open
khancyr wants to merge 507 commits into
masterfrom
esp32-dev-image
Open

Esp32 dev image#40
khancyr wants to merge 507 commits into
masterfrom
esp32-dev-image

Conversation

@khancyr

@khancyr khancyr commented Jul 20, 2026

Copy link
Copy Markdown
Owner

Summary

Classification & Testing (check all that apply and add your own)

  • Checked by a human programmer
  • Non-functional change
  • No-binary change
  • Infrastructure change (e.g. unit tests, helper scripts)
  • Automated test(s) verify changes (e.g. unit test, autotest)
  • Tested manually, description below (e.g. SITL)
  • Tested on hardware
  • Logs attached
  • Logs available on request

Description

peterbarker and others added 13 commits July 21, 2026 08:36
need to take runup timestamp before we send the interlock change otherwise we really can go before the timer has run for long enough to pass the TARGET_RUNUP_TIME
would have broken loweheiser if accelcal was disabled
MagcalController advanced calibration poses using wall-clock timers
(time.time()): 24 wall-seconds maximum dwell per pose and 4
wall-seconds of unchanged-progress before rotating.  The vehicle
rotation and the calibrator's sample consumption are both simulation
time, so at SITL speedup the sphere coverage for a pose completes in a
fraction of a wall second and the controller then sat idle for the
rest of the wall-clock dwell.  This made SITLCompassCalibration the
second most expensive test in CI at ~370 wall-seconds.

Clock the controller from ATTITUDE.time_boot_ms instead so every
quantity in the controller is in the simulation time domain; the
existing constants keep their values, now correctly denominated in
simulation seconds (a full turn at pi/4 rad/s genuinely takes 8
simulation seconds).  Locally the test drops from ~370 to ~80-90
seconds.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The vehicle can silently reject a SET_POSITION_TARGET_GLOBAL_INT - the
synthetic seafloor simulation deliberately injects low-signal-quality
rangefinder outliers, and one of those landing in the wrong ~50ms makes
the terrain frame momentarily invalid, failing the frame conversion in
wp_nav.  There is no acknowledgement for the message, so the test sailed
on oblivious and timed out 80 seconds later ("Frame 10 took too long to
reach the destination", seen in CI).

Send the target until NAV_CONTROLLER_OUTPUT.wp_dist shows it has become
wp_nav's current destination.  The distance report is used rather than
the POSITION_TARGET_GLOBAL_INT echo because the latter is never emitted
for terrain-altitude destinations on Sub (the alt cannot be converted
to AMSL without a terrain database).  Blindly streaming the target is
also no good; each resend of an identical target re-initialises the
wpnav leg from a stopping point, slowing the vehicle enough to miss the
test's timeout.

The leg timer now starts only once the target is accepted, and the
message-rate request is made before the dive as there is no depth hold
between the dive and GUIDED, so sim time spent there is spent floating
back up.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Randy Mackay <rmackay9@yahoo.com>
Co-authored-by: Randy Mackay <rmackay9@yahoo.com>
Co-authored-by: Randy Mackay <rmackay9@yahoo.com>
Co-authored-by: Randy Mackay <rmackay9@yahoo.com>
Co-authored-by: Randy Mackay <rmackay9@yahoo.com>
Co-authored-by: Randy Mackay <rmackay9@yahoo.com>
andyp1per and others added 29 commits July 29, 2026 18:12
…e notches

(cherry picked from commit 1e8cb4edf57385b403f1b8e276557cd5f7ad52fc)
GCS_MAVLINK_Copter::mission_state() exists only to report the paused
state of AUTO mode, and dereferences copter.mode_auto - but that member
is compiled out when MODE_AUTO_ENABLED is 0, so the build failed.

Guard the override so we fall back to the GCS_MAVLINK base
implementation when AUTO mode is not compiled in.
start_command_do_set_roi_wpnext_offset() lives outside the
AP_MISSION_ENABLED guard in AP_Mission_Commands.cpp, so building with
AP_MISSION_ENABLED=0 failed to compile.  The command is only ever run
from a mission, so gate the feature on mission support being present.
The definition and the only call site are both already guarded, but the
declaration was not, so the vtable referenced a symbol which does not
exist when building with AP_MISSION_ENABLED=0.
Follows AP_Arming, where the virtual this overrides only exists when
mission support is compiled in.
send_Vario() reports the current waypoint number when in AUTO; there is
no mission to ask when AP_MISSION_ENABLED is 0.
…BLED

The 0x500D waypoint packet reports the current mission waypoint number,
distance and bearing, none of which exist when mission support is
compiled out.
class ModeAuto was declared unconditionally even though only its
instantiation was guarded, so its AP_Mission and
AP_Mission_ChangeDetector members failed to compile with mission support
disabled.  Guard the class, and the two aux-function switch entries
whose RC_Channel::AUX_FUNC enumerators are themselves gated on
AP_MISSION_ENABLED.
Copter's one and only AP_Mission object is a member of ModeAuto, so
compiling ModeAuto out leaves AP::mission() with nothing to return while
the rest of the codebase still believes mission support is present.

Default MODE_AUTO_ENABLED to AP_MISSION_ENABLED so that disabling
mission support removes AUTO mode too, and reject the two inconsistent
combinations at compile time.
AP_AHRS::set_home writes home to the mission via AP::mission(), which
assumes that any binary compiled with mission support also instantiates
an AP_Mission object; give the test one.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
Every vehicle which compiles mission support in also instantiates an
AP_Mission object, so the singleton is never null.  Returning a
reference rather than a pointer says so, and lets the nullptr checks at
each call site go away.

Saves around 150 bytes of flash per firmware.
boards coming in with stale defines.  The defines are several versions old, so I don't think it's really worth adding code to enforce no-more-merging of these bad defines.
The ESP32 workflow set up its whole toolchain from scratch on every run:
apt deps, an ESP-IDF clone, and install.sh downloading the toolchain into
~/.espressif (~5-10 min), then compiled with ccache installed but never
wired into the ESP-IDF build.

Run the job inside the new ardupilot/ardupilot-dev-esp32 image (ESP-IDF
toolchain baked in) and drop the manual setup. Enable ccache for the
ESP-IDF build via IDF_CCACHE_ENABLE and persist it with the shared
setup-ccache/save-ccache actions (CCACHE_MAXSIZE bumped to 1G since the
plane+copter object set exceeds the 400M default).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.