Skip to content

ArduPlane Custom Build — Light Variant — v0.2-beta

Pre-release
Pre-release

Choose a tag to compare

@erwinquilloy erwinquilloy released this 01 Jul 20:39
· 203 commits to master_custom since this release

🪶 ArduCustom Light v0.2-beta

A lightweight ArduPlane 4.6.3 build for flash-constrained F4 flight controllers. Carries forward the ArduCustom v11.3e feature set plus the fork-specific additions from v0.1-beta.

This release is a feature-additive update to v0.1-beta — same base capabilities, plus wind-aware landing-selection controls and a validated radar stack. If you were running v0.1-beta, the parameter set is a strict superset (nothing removed or renamed), so you can flash and keep flying with your existing tuning.

🔄 Assets rebuilt 2026-07-03 — all five firmware zips rebuilt from eb1873b61c. This is a build-hygiene rebuild only — no flight-behavior change vs the 2026-07-02 assets. It folds in two CI-caught fixes: an AP_GPS single-instance compile guard (the 1-GPS light config tripped clang's array-bounds check on an unreachable code path), and AP_Radar switched to NEW_NOTHROW so the throwing operator new is dropped from the binary. Every feature below is unchanged, so if you already flashed a 2026-07-02 zip you do not need to re-flash for any functional reason. The onboard version string reports v0.2-beta.

Earlier rebuild — 2026-07-02, from 1b129e4313: added pilot control of loiter radius/direction (ArduCustom PR #180), the Course Hold throttle-to-pitch compensation restore, two FS_ELAND emergency-landing glide fixes, and the LAND_WIND_STRICT parameter-registration fix — all present in the current build.

Added 2026-07-04 — SpeedyBeeF405WING-Buzz — a hardware-tone-buzzer variant of SpeedyBeeF405WING (S11/PB15 remapped to TIM12_CH2 + ALARM, so ArduPilot tunes play on a passive buzzer instead of the DShot ESCs; costs servo output 11). Built from 55f575e074 rather than the eb1873b61c of the other five zips, but the commits between those two are CI/autotest/SITL/docs only plus the new board's hwdef — no flight-behavior change vs the rest of the fleet. Its version string reports ... Light (55f575e). Flashes over the stock SpeedyBee bootloader (board ID 1106) as a normal update.

Added 2026-07-05 — two more light boards, plus code (OLC) removed — (1) MatekH743-bdshot, the Matek H743-WING (bidirectional DShot); ~305 KB free flash. (2) KakuteF4-Wing-Buzz, a hardware-tone-buzzer variant of the Kakute F4 Wing — which ships no buzzer — with a passive buzzer on the WS2812 LED pad (PA1 remapped TIM5_CH2TIM2_CH2 + ALARM; costs the LED-strip output, no servo/motor output). Both built from ebe3833df4 and report ... Light (ebe3833). This commit also drops the plus code (OLC) OSD element fork-wide — low demand per a user survey: the OSDx_PLUSCODE_* panel is compiled out on all boards and OSD_OPTIONS bit 23 (ShortenPluscode) is removed from the bitmask. No change to the existing five F4 assets (plus code was already off on 1 MB F4) — you do not need to re-flash them.

Added 2026-07-10 — omnibusf4pro — the Omnibus F4 Pro, a stock upstream 1 MB F405 FPV flight controller (MPU6000/BMI270 IMU, BMP280 baro, onboard 7456-series OSD). No fork hwdef work was needed — it already pulls in minimize_fpv_osd.inc. ~41.6 KB free flash on light (940,436 B of 1 MB used), mid-pack in the F4 fleet. Built from 0db8004 and reports ... Light (0db8004). No change to any existing asset.

⚠️ Known gotcha — EK3 sources require VisualOdom prearm. VisualOdom / external-nav is compiled out on 1 MB F4 boards by upstream's BOARD_FLASH_SIZE > 1024 gate — not a light strip (it's absent on stock ArduPlane and the full variant too on the same board). If a saved parameter has EK3_SRCx_* = ExternalNav, you'll hit this prearm. Fix: set those sources off ExternalNav — use RangeFinder (value 2, e.g. EK3_SRC1_POSZ = 2) for a downward-lidar height source, or the GPS/Baro/Compass defaults. A Benewake TFmini is a rangefinder (fully supported on light), not external nav — only the ExternalNav source value needs the absent VisualOdom backend.


What's new since v0.1-beta

Wind-aware DO_LAND_START selection — LAND_WIND_DIST and LAND_WIND_STRICT

LAND_WIND_BIAS (v0.1-beta) let the autopilot prefer landings whose approach faces into wind, but on missions with DO_LAND_START items spread over a wide area a strong bias could pull the plane toward a much farther landing purely for wind alignment. On battery-marginal RTL, that extra travel can cost you the airframe. This release adds two companion params:

  • LAND_WIND_DIST (metres, default 0 = no cap) — hard distance ceiling. Any DO_LAND_START whose start-of-approach sits farther than this many metres from the plane's decision-time position is excluded from selection. The wind bias then picks only from within-cap survivors.

    • Under RTL_AUTOLAND=1, the cap is effectively measured from HOME (plane loiters there before the pick).
    • Under RTL_AUTOLAND=2 / battery FS / GCS DO_LAND_START, the cap is measured from wherever the plane is when the trigger fires.
  • LAND_WIND_STRICT (0/1, default 0) — chooses what happens when LAND_WIND_DIST eliminates every candidate:

    • 0 (soft fallback) — fall through to upstream nearest-across-all so the plane still attempts a landing. Preserves the failsafe safety net at the cost of occasionally flying outside the cap.
    • 1 (hard fence) — refuse the autoland; RTL/failsafe stays in RTL and the plane loiters at HOME/rally requiring pilot intervention. ⚠️ Under strict mode, a battery failsafe with no in-cap landing will not attempt to land — the plane loiters until the battery dies. Only enable if you can take manual control on failsafe.

Both params ship as Standard-user parameters and are visible in the GCS parameter tree. Default values preserve pre-existing v0.1-beta behaviour bit-for-bit — nothing changes until you set them.

See README_CUSTOM.md sections LAND_WIND_DIST and LAND_WIND_STRICT for the full behaviour table, worked examples, and the safety trade-off.

Pilot control of loiter radius and direction — LOITER & RTL (added in the 2026-07-02 rebuild)

Port of ArduCustom PR #180 (shellixyz). In LOITER and RTL, once the plane is established in the loiter circle:

  • Rudder stick past half deflection left/right — snap loiter direction counter-clockwise / clockwise.
  • Roll stick grows or shrinks the loiter radius at 20 m/s (direction-aware, so pushing "outward" always grows the radius), clamped to 20–1000 m.

On mode entry the radius/direction seed from WP_LOITER_RAD (LOITER) or RTL_RADIUS with WP_LOITER_RAD fallback (RTL). The helper is disabled during RC failsafe so the emergency-landing state machine (FS_ELAND_LOTRAD, wings-level glide) keeps exclusive ownership of the loiter geometry. No parameter to enable — it's always on in LOITER/RTL outside RC failsafe. See README_CUSTOM.md § Pilot control of loiter radius and direction for the full input map.

Bug fixes in the 2026-07-02 rebuild

  • LAND_WIND_STRICT parameter registration — the parameter used an out-of-range index (64) which could panic at parameter-table setup. Fixed index; the param now registers cleanly.
  • Course Hold — restored the mf0o/shellixyz throttle-to-pitch compensation (pitch-up compensation fades to zero as throttle approaches TRIM_THROTTLE).
  • FS_ELAND glide engagement (two fixes)update_control_mode() no longer stomps the TECS gliding-requested flag every fast-loop tick during RC failsafe (it pinned the plane at FS_ELAND_GLDALT with ~48 % throttle instead of gliding), and the flag is now cleared once on failsafe entry so a stale pilot-throttle-zero latch can't start the glide prematurely from RTL cruise. Net behaviour: TECS sinks to FS_ELAND_GLDALT at normal throttle, holds altitude through the upwind alignment, then wings-level glides to touchdown — and this now works regardless of FLIGHT_OPTIONS bit 23.

Peer-aircraft radar — bench-verified end-to-end

v0.1-beta shipped the radar stack (AP_Radar library, MSP backend, OSD widget) with a "radar under test" caveat. v0.2-beta promotes it to verified: peer detection was tested on real hardware (SpeedyBee F405 WING + a FormationFlight ESP32 module), the OSD element draws correctly once both planes have GPS lock, and formation-side ESP32s see us in the FormationFlight web UI without any fork-specific firmware on their side. Same code, same parameters — just now with a bench-test data point behind it.

Fleet change

v0.2-beta launched with 5 boards (down from 6 in v0.1-beta) and has since grown to 9 via post-launch additions — see the dated ➕ notes at the top of these release notes:

Board Free flash Status
MatekH743-bdshot 305 KB ➕ Added 2026-07-05 — Matek H743-WING (H7, not F4)
KakuteF4-Wing-Buzz 81.3 KB ➕ Added 2026-07-05 — HW-buzzer variant of Kakute F4 Wing
speedybeef4v3 53.4 KB Ships — most F4 headroom
MatekF405-STD 47.0 KB ⭐ New in v0.2-beta
MatekF405-TE-bdshot 42.5 KB Ships
omnibusf4pro 41.6 KB ➕ Added 2026-07-10 — Omnibus F4 Pro (stock upstream FPV FC)
SpeedyBeeF405WING 29.7 KB Ships
SpeedyBeeF405WING-Buzz 29.2 KB ➕ Added 2026-07-04 — HW-buzzer variant of SpeedyBeeF405WING
MatekF405-Wing-bdshot 27.6 KB Ships — canary (tightest F4)
  • Added at launch: MatekF405-STD as a standard (non-bdshot) alternative in the F4 lineup with ~47 KB free.
  • Added post-launch: SpeedyBeeF405WING-Buzz (07-04), then MatekH743-bdshot + KakuteF4-Wing-Buzz (07-05). The two *-Buzz variants add a passive hardware tone buzzer to boards that ship without one (details in the dated notes above); MatekH743-bdshot is the fleet's first H7 target. Then omnibusf4pro (07-10) — the Omnibus F4 Pro, a stock upstream 1 MB F405 FPV FC that needs no fork hwdef work (~41.6 KB free).
  • Dropped: LongBowF405WING (never had bench-measured data) and KakuteH7-Wing (2 MB H7 board, outside the original "tight 1 MB F4" focus of this variant).

Free-flash numbers are v0.2-beta measurements — the full feature set (radar + LAND_WIND_DIST + LAND_WIND_STRICT) accounts for ~1.5 KB more than v0.1-beta on each board.

Docs

  • README_CUSTOM.md now leads each fork-parameter section with the purpose of the parameter (why it exists), not just the mechanics — makes the trade-offs easier to reason about at first read.
  • New Acknowledgements entry for @jaroszmm, who proposed the LAND_WIND_DIST cap idea and shaped the anchor semantics + soft-fallback / hard-fence design.

Everything from v0.1-beta still applies

The full ArduCustom v11.3e feature set (Course Hold, Auto Trim, FLTMODE_EXT 12-position, Emergency landing failsafe, RTL manual altitude, servo auto-trim, OSD stats grid, watt-hour battery monitoring, tuning knobs, TECS enhancements, radar OSD widget, and everything else) carries forward unchanged. See the v0.1-beta release notes for the complete rundown or README_CUSTOM.md on the master_custom_4.6.3_light branch for the up-to-date documentation.


Flashing

Each <board>_plane_bin_light-v0.2-beta_.zip contains the full build output for that board:

  • arduplane.apj — upload via Mission Planner / QGC / MAVProxy as you would any ArduPlane firmware (the usual path).

  • arduplane.bin — raw image for DFU / bootloader tools.

  • arduplane_with_bl.hex — image with bootloader included, for first-time flashing via STM32CubeProgrammer/DFU.

  • arduplane — ELF with debug symbols (for crash analysis, not for flashing).

  • coursehold.wav — Yaapu Telemetry Script sound file for Course Hold call-out (unchanged from v0.1-beta).

  • plane.lua — Yaapu Telemetry Script for Course Hold flight-mode ID (unchanged from v0.1-beta).

See Tools/yaapu-coursehold/README.md for Yaapu setup.