Peter BarkerandClaude Opus 5
cd8a2df5fa
The test drives "ftp crclocal" and "ftp crccmp". MAVProxy grew those in 328d7de20 (2026-07-27) and has not cut a release since - the newest tag, v1.8.74, is from 2025-08-02 and contains neither - so on a released MAVProxy "ftp crclocal" falls through to the usage print and the test waits out its 60s pexpect timeout. Skipping it unconditionally would cost real coverage: build_ci.sh installs MAVProxy by cloning master, which does have both commands, so the test runs and passes in CI today. A version gate would not work either, because MAVProxy master still calls itself 1.8.74 - the same version the release reports - so any mavproxy_version_gt() test would disable the test in CI as well. Ask the ftp module whether it implements the command instead, and skip only where it does not. Nothing has to be un-done later: the skip stops applying by itself once the local MAVProxy has crccmp. Keeping this in disabled_tests() rather than returning early inside the test means the skip is still reported in the run summary and the JUnit report. Ask the MAVProxy we are actually going to run, not the one this process could import. MAVPROXY_CMD can name a MAVProxy in another virtualenv, which is the whole point of the variable, and an in-process "import MAVProxy" would then answer for the wrong install - saying the command is present when the MAVProxy under test lacks it, which is exactly the 60s timeout this is meant to avoid. Take the interpreter out of the mavproxy script's shebang and put the question to that, keeping the lookup next to mavproxy_cmd() in util.py where MAVPROXY_CMD is read. Verified four ways: with crccmp present the entry is absent and test.Plane.MAVFTPCrcCompareMAVProxy passes; with MAVPROXY_CMD pointing at a stub install whose ftp module has no crccmp the probe reports False and the entry appears, while an in-process import in that same run still says True; and with MAVPROXY_CMD naming a path that does not exist the probe returns "don't know" and the test is left enabled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ArduPilot Project
ArduPilot is the most advanced, full-featured, and reliable open source autopilot software available. It has been under development since 2010 by a diverse team of professional engineers, computer scientists, and community contributors. Our autopilot software is capable of controlling almost any vehicle system imaginable, from conventional airplanes, quad planes, multi-rotors, and helicopters to rovers, boats, balance bots, and even submarines. It is continually being expanded to provide support for new emerging vehicle types.
The ArduPilot project is made up of
User Support & Discussion Forums
-
Support Forum: https://discuss.ardupilot.org/
-
Community Site: https://ardupilot.org
Developer Information
-
Github repository: https://github.com/ArduPilot/ardupilot
-
Main developer wiki: https://ardupilot.org/dev/
-
Developer discussion: https://discuss.ardupilot.org
-
Developer chat: https://discord.com/channels/ardupilot
Top Contributors
- Flight code contributors
- Wiki contributors
- Most active support forum users
- Partners who contribute financially
How To Get Involved
-
The ArduPilot project is open source and we encourage participation and code contributions: guidelines for contributors to the ardupilot codebase
-
We have an active group of Beta Testers to help us improve our code: release procedures
-
Desired Enhancements and Bugs can be posted to the issues list.
-
Help other users with log analysis in the support forums
-
Improve the wiki and chat with other wiki editors on Discord #documentation
-
Contact the developers on one of the communication channels
License
The ArduPilot project is licensed under the GNU General Public License, version 3.
Maintainers
ArduPilot is comprised of several parts, vehicles and boards. The list below contains the people that regularly contribute to the project and are responsible for reviewing patches on their specific area.
- Andrew Tridgell:
- Vehicle: Plane, AntennaTracker
- Board: Pixhawk, Pixhawk2, PixRacer
- Francisco Ferreira:
- Bug Master
- Grant Morphett:
- Vehicle: Rover
- Willian Galvani:
- Vehicle: Sub
- Board: Navigator
- Michael du Breuil:
- Subsystem: Batteries
- Subsystem: GPS
- Subsystem: Scripting
- Peter Barker:
- Subsystem: DataFlash, Tools
- Randy Mackay:
- Vehicle: Copter, Rover, AntennaTracker
- Siddharth Purohit:
- Subsystem: CAN, Compass
- Board: Cube*
- Tom Pittenger:
- Vehicle: Plane
- Bill Geyer:
- Vehicle: TradHeli
- Emile Castelnuovo:
- Board: VRBrain
- Georgii Staroselskii:
- Board: NavIO
- Gustavo José de Sousa:
- Subsystem: Build system
- Julien Beraud:
- Board: Bebop & Bebop 2
- Leonard Hall:
- Subsystem: Copter attitude control and navigation
- Matt Lawrence:
- Vehicle: 3DR Solo & Solo based vehicles
- Matthias Badaire:
- Subsystem: FRSky
- Mirko Denecke:
- Board: BBBmini, BeagleBone Blue, PocketPilot
- Paul Riseborough:
- Subsystem: AP_NavEKF2
- Subsystem: AP_NavEKF3
- Víctor Mayoral Vilches:
- Board: PXF, Erle-Brain 2, PXFmini
- Amilcar Lucas:
- Subsystem: Marvelmind
- Samuel Tabor:
- Subsystem: Soaring/Gliding
- Henry Wurzburg:
- Subsystem: OSD
- Site: Wiki
- Peter Hall:
- Vehicle: Tailsitters
- Vehicle: Sailboat
- Subsystem: Scripting
- Andy Piper:
- Subsystem: Crossfire
- Subsystem: ESC
- Subsystem: OSD
- Subsystem: SmartAudio
- Alessandro Apostoli:
- Subsystem: Telemetry
- Subsystem: OSD
- Rishabh Singh:
- Subsystem: Avoidance/Proximity
- David Bussenschutt:
- Subsystem: ESP32,AP_HAL_ESP32
- Charles Villard:
- Subsystem: ESP32,AP_HAL_ESP32