Jacob Dahl
85e3cb88a7
Address customer-reported dropouts traced to several issues in the prior driver: - A single transient I2C blip flipped _initialized=false and re-ran probe()+Reset() inline on the next tick, losing most of a sample period on every isolated glitch. - start() scheduled the first collect() ~100 ms after the device reset (INA238_SAMPLE_INTERVAL_US - 7 us), but the first averaged conversion takes 540 us x 3 channels x 64 samples ~= 103.7 ms -- so the first read sometimes hit post-reset zeros. - The CONFIG register watchdog used set_bits/clear_bits that both collapsed to 0 in HIGH ADC range, making it a no-op for the default range. (ADCCONFIG and SHUNT_CAL were still checked.) - setConnected(false) could fire up to three times per failed cycle (collect, register-check branch, RunImpl else), collapsing the intended ~2 s debounce. - -t (battery index) was parsed with no range check; out-of-range values silently clamped to 1 inside Battery. Rewrite: - Non-blocking UNINITIALIZED / RESET / CONFIGURE / MEASURE state machine. Each step is its own RunImpl tick with an explicit ScheduleDelayed; init failures retry without losing the driver instance. - Tolerate ~2 s of consecutive collect() failures (MAX_CONSECUTIVE_FAILURES = DISCONNECT_DEBOUNCE_US / SAMPLE_INTERVAL_US) before triggering a full reinit; isolated glitches just skip a cycle. - SAMPLE_INTERVAL_US = 105 ms, just above the 103.68 ms ADC conversion period so we stop polling faster than the device produces samples. MEASURE compensates for in-tick I2C time so each tick is exactly SAMPLE_INTERVAL_US apart. - CONFIGURE waits SAMPLE_INTERVAL_US + 5 ms before the first MEASURE read, comfortably above the first averaged conversion. - checkConfigurationRotating() reads one config register per cycle and compares it against the value actually written, so an externally reset device is detected within three cycles regardless of ADC range. - -t arg validated against 1-3 at parse time; out-of-range values now exit with an error. - New perf counters ina238_bad_register and ina238_reinit. Driver state is also surfaced in 'ina238 status'. - File layout: ina238_registers.hpp folded into ina238.h, ina238_main.cpp folded into ina238.cpp. Constants and enums namespaced under ina238. Params switched to DEFINE_PARAMETERS. - RESET state publishes documented invalid sentinels (current = -1, temperature = NaN) instead of valid-looking zeros. Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> fix(ina238): pass literal i2c address to usage macro PRINT_MODULE_USAGE_PARAMS_I2C_ADDRESS feeds its argument through the module documentation parser's int(eval(...)) path, which only resolves Python literals. The constexpr BASEADDR identifier crashed make module_documentation with NameError. Match the convention in sibling power_monitor drivers (ina220/ina226/ina228) and pass 0x45. Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The autopilot stack the industry builds on.
About
PX4 is an open-source autopilot stack for drones and unmanned vehicles. It supports multirotors, fixed-wing, VTOL, rovers, and many more experimental platforms from racing quads to industrial survey aircraft. It runs on NuttX, Linux, and macOS. Licensed under BSD 3-Clause.
Why PX4
Modular architecture. PX4 is built around uORB, a DDS-compatible publish/subscribe middleware. Modules are fully parallelized and thread safe. You can build custom configurations and trim what you don't need.
Wide hardware support. PX4 runs on a wide range of autopilot boards and supports an extensive set of sensors, telemetry radios, and actuators through the Pixhawk ecosystem.
Developer friendly. First-class support for MAVLink and DDS / ROS 2 integration. Comprehensive SITL simulation, hardware-in-the-loop testing, and log analysis tools. An active developer community on Discord and the weekly dev call.
Vendor neutral governance. PX4 is hosted under the Dronecode Foundation, part of the Linux Foundation. Business-friendly BSD-3 license. No single vendor controls the roadmap.
Supported Vehicles
 Multicopter |
 Fixed Wing |
 VTOL |
 Rover |
…and many more: helicopters, autogyros, airships, submarines, boats, and other experimental platforms. These frames have basic support but are not part of the regular flight-test program. See the full airframe reference.
Try PX4
Run PX4 in simulation with a single command. No build tools, no dependencies beyond Docker:
docker run --rm -it -p 14550:14550/udp px4io/px4-sitl:latest
Open QGroundControl and fly. See PX4 Simulation Quickstart for more options.
Build from Source
git clone https://github.com/PX4/PX4-Autopilot.git --recursive
cd PX4-Autopilot
make px4_sitl
Note
See the Development Guide for toolchain setup and build options.
Documentation & Resources
| Resource | Description |
|---|---|
| User Guide | Build, configure, and fly with PX4 |
| Developer Guide | Modify the flight stack, add peripherals, port to new hardware |
| Airframe Reference | Full list of supported frames |
| Autopilot Hardware | Compatible flight controllers |
| Release Notes | What's new in each release |
| Contribution Guide | How to contribute to PX4 |
Community
- Weekly Dev Call — open to all developers (Dronecode calendar)
- Discord — Join the Dronecode server
- Discussion Forum — PX4 Discuss
- Maintainers — see
MAINTAINERS.md - Contributor Stats — LFX Insights
Contributing
We welcome contributions of all kinds — bug reports, documentation, new features, and code reviews. Please read the Contribution Guide to get started.
Citation
If you use PX4 in academic work, please cite it. BibTeX:
@software{px4_autopilot,
author = {Meier, Lorenz and {The PX4 Contributors}},
title = {{PX4 Autopilot}},
publisher = {Zenodo},
doi = {10.5281/zenodo.595432},
url = {https://px4.io}
}
The DOI above is a Zenodo concept DOI that always resolves to the latest release. For a version-pinned citation, see the Zenodo record or our CITATION.cff.
Governance
The PX4 Autopilot project is hosted by the Dronecode Foundation, a Linux Foundation Collaborative Project. Dronecode holds all PX4 trademarks and serves as the project's legal guardian, ensuring vendor-neutral stewardship — no single company owns the name or controls the roadmap. The source code is licensed under the BSD 3-Clause license, so you are free to use, modify, and distribute it in your own projects.
