Andy Piper
ffbecd9403
update() cleared _gyro_healthy/_accel_healthy for every instance and relied on the backends to set them true again a few microseconds later. Those flags are read from other threads - AP_RCTelemetry::check_sensor_status_flags() runs from the CRSF frame handler on the RC input thread - so every main loop iteration left a window in which a perfectly healthy sensor reads unhealthy. At an ELRS telemetry rate of ~200Hz that window is sampled often enough to report "Bad Gyro Health" continuously on a vehicle whose gyro never missed a sample. It is invisible in a log: IMU.GH stays 1 even logged at loop rate, because logging also runs from the main loop and so cannot observe the window. Drop the central clear and have update_gyro()/update_accel() set the flag false only when there is no fresh sample, so a healthy sensor never sees it transiently cleared. The error-count preference later in update() can still demote a sensor in the same cycle; that path is unchanged. A backend whose start() failed to register stays in _backends[] and still has update() and update_filters() called every cycle, with gyro_instance/accel_instance left at their default. Default those to INS_MAX_INSTANCES and bounds-check the frontend helpers that index by them, so the new clear is not applied to instance 0 and nothing indexes one past the end. notify_*_fifo_reset() gets the same check because LSM9DS1 calls it from probe(), before registration. ADIS16607 and NONE redeclared gyro_instance/accel_instance, shadowing the base members; the duplicates are removed so the default applies there too. ADIS16607 also tested enable_fast_sampling(accel_instance) from probe(), before the instance is known. That was only right for instance 0 while the driver had its own zero-initialised copy, and with the new default it disabled fast sampling altogether. Pre-fetch the instance numbers in start() as the Invensense drivers do and move the rate decision and the DEC_RATE write there, after registration, so a failed write leaves an instance that reads unhealthy rather than pre-fetched numbers with nothing registered behind them.
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