docs: auto-sync metadata [skip ci]

Co-Authored-By: PX4 BuildBot <bot@px4.io>
This commit is contained in:
PX4BuildBot
2026-02-11 22:43:01 +00:00
parent 01b348c86b
commit 36b5e1e1bb
374 changed files with 12147 additions and 1765 deletions
+9 -7
View File
@@ -1,27 +1,27 @@
# Driver Development
PX4 device drivers are based on the [Device](https://github.com/PX4/PX4-Autopilot/tree/main/src/lib/drivers/device) framework.
PX4 device drivers are based on the [Device](https://github.com/PX4/PX4-Autopilot/tree/main/src/lib/drivers/device) framework.
## Creating a Driver
PX4 almost exclusively consumes data from [uORB](../middleware/uorb.md). Drivers for common peripheral types must publish the correct uORB messages (for example: gyro, accelerometer, pressure sensors, etc.).
The best approach for creating a new driver is to start with a similar driver as a template (see [src/drivers](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers)).
The best approach for creating a new driver is to start with a similar driver as a template (see [src/drivers](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers)).
::: info
More detailed information about working with specific I/O buses and sensors may be available in [Sensor and Actuator Buses](../sensor_bus/index.md) section.
:::
::: info
Publishing the correct uORB topics is the only pattern that drivers *must* follow.
Publishing the correct uORB topics is the only pattern that drivers _must_ follow.
:::
## Core Architecture
PX4 is a [reactive system](../concept/architecture.md) and uses [uORB](../middleware/uorb.md) publish/subscribe to transport messages. File handles are not required or used for the core operation of the system. Two main APIs are used:
* The publish / subscribe system which has a file, network or shared memory backend depending on the system PX4 runs on.
* The global device registry, which can be used to enumerate devices and get/set their configuration. This can be as simple as a linked list or map to the file system.
- The publish / subscribe system which has a file, network or shared memory backend depending on the system PX4 runs on.
- The global device registry, which can be used to enumerate devices and get/set their configuration. This can be as simple as a linked list or map to the file system.
## Device IDs
@@ -33,7 +33,6 @@ The order of sensors (e.g. if there is a `/dev/mag0` and an alternate `/dev/mag1
For the example of three magnetometers on a system, use the flight log (.px4log) to dump the parameters. The three parameters encode the sensor IDs and `MAG_PRIME` identifies which magnetometer is selected as the primary sensor. Each MAGx_ID is a 24bit number and should be padded left with zeros for manual decoding.
```
CAL_MAG0_ID = 73225.0
CAL_MAG1_ID = 66826.0
@@ -83,6 +82,7 @@ struct DeviceStructure {
uint8_t devtype; // device class specific device type
};
```
The `bus_type` is decoded according to:
```C
@@ -126,17 +126,19 @@ Drivers (and other modules) output minimally verbose logs strings by default (e.
Log verbosity is defined at build time using the `RELEASE_BUILD` (default), `DEBUG_BUILD` (verbose) or `TRACE_BUILD` (extremely verbose) macros.
Change the logging level using `COMPILE_FLAGS` in the driver `px4_add_module` function (**CMakeLists.txt**).
The code fragment below shows the required change to enable DEBUG_BUILD level debugging for a single module or driver.
The code fragment below shows the required change to enable DEBUG_BUILD level debugging for a single module or driver.
```
px4_add_module(
MODULE templates__module
MAIN module
```
```
COMPILE_FLAGS
-DDEBUG_BUILD
```
```
SRCS
module.cpp