0524a374d9
* fix(drivers/uavcannode): make CANNODE_NODE_ID the sole node ID policy The startup bootloader_app_shared_write() never reached the bootloader: it only accepts App-signed data and invalidates the shared region on every boot. The only consumer was uavcannode itself on a restart without a reset (nsh stop/start), where the persisted bus_speed=0 made the CAN driver init fail and left the node off the bus. The bootloader learns our node ID exclusively through the firmware update handoff in cb_beginfirmware_update, which already carries the static ID. CANNODE_NODE_ID now overrides the bootloader handoff only when nonzero, so the default (0) reuses the ID the bootloader already allocated instead of running allocation a second time. The handoff is ignored unless it carries a valid bitrate, healing regions poisoned by firmware that wrote bus_speed=0. Max is 125 because 126/127 are reserved for debug tools by DroneCAN convention, matching UAVCAN_NODE_ID. Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> * fix(drivers/uavcannode): harden bootloader handoff validation Invalidate the shared region whenever it was read valid, not only when the handoff is accepted, so stale data cannot linger on boards whose bootloader never invalidates it. Require a plausible bitrate (the CANNODE_BITRATE minimum) rather than nonzero: the canbootloader alt-app update path can hand off bus_speed = CAN_UNDEFINED (999). Reword the invalid-param error, which claimed dynamic allocation while keeping the bootloader handoff. Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> --------- Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
5.0 KiB
PX4 DroneCAN Firmware
PX4 can run as the firmware on many DroneCAN peripherals. There are multiple benefits to this:
- PX4 has built-in drivers for a wide range of sensors and peripherals components.
- PX4 has a robust DroneCAN driver implementation that has undergone multiple years of field testing.
- PX4 is continuously being developed. You routinely get access to the latest improvements.
- PX4's estimation and control code makes it easy to create "smart" cannodes like integrated AHRS modules.
- The firmware is completely open source (PX4 is BSD licensed).
Building the Firmware
Follow the PX4 building docs just as you would to build firmware for a flight controller. Device build configurations are stored here. After installing the PX4 toolchain, clone the sources and build. For example, to build for the Ark Flow target:
git clone --recursive https://github.com/PX4/PX4-Autopilot
cd PX4-Autopilot
make ark_can-flow_default
This will create an output in build/ark_can-flow_default named XX-X.X.XXXXXXXX.uavcan.bin. Follow the instructions at DroneCAN firmware update to flash the firmware.
Configuration
Static Node ID
By default, DroneCAN devices use Dynamic Node Allocation (DNA) to automatically obtain a unique node ID from the flight controller. However, you can configure a static node ID using the CANNODE_NODE_ID parameter.
To configure a static node ID:
- Set CANNODE_NODE_ID to a value between 1-125 using QGroundControl
- Reboot the device
To return to dynamic allocation, set CANNODE_NODE_ID back to 0.
Note that when switching back to dynamic allocation, the flight controller will typically continue to allocate the same node ID that was previously used (this is normal DNA behavior).
:::warning When using static node IDs, you must ensure that each device on the CAN bus has a unique node ID. Configuring two devices with the same ID will cause communication conflicts. :::
Developer Information
This section has information that is relevant to developers who want to add support for new DroneCAN hardware to the PX4 Autopilot.
DroneCAN Bootloader Installation
:::warning DroneCAN devices typically ship with a bootloader pre-installed. Do not follow the instructions in this section unless you are developing DroneCAN devices, or have (accidentally) corrupted/wiped your bootloader. :::
The PX4 project includes a standard DroneCAN bootloader for STM32 devices.
The bootloader occupies the first 8-16 KB of flash, and is the first code executed on power-up. Typically the bootloader performs low-level device initialization, automatically determines the CAN bus baud rate, acts as a DroneCAN dynamic node ID client to obtain a unique node ID, and waits for confirmation from the flight controller before proceeding with application boot.
This process ensures that a DroneCAN device can recover from invalid or corrupted application firmware without user intervention, and also permits automatic firmware updates.
Build the bootloader firmware by specifying the same peripheral target with the canbootloader build configuration instead of the default configuration.
For example, to build for the Ark Flow target:
git clone --recursive https://github.com/PX4/PX4-Autopilot
cd PX4-Autopilot
make ark_can-flow_canbootloader
The binary can then be flashed to the microcontroller using your favorite SWD/JTAG debugger, such as the Black Magic Probe, ST-Link, or Segger JLink.
Firmware Internals
For the most part, peripheral firmware works the same way as flight controller firmware builds. However, most modules are disabled - only the sensor drivers, DroneCAN driver, and internal infrastructure (uORB, etc.) are enabled.
DroneCAN communication is handled by the uavcannode module. This driver handles producer-side communication - it takes sensor/actuator data from uORB, serializes it using the DroneCAN libraries, and publishes it over CAN. In the future, this will likely be merged with the uavcan module which handles flight controller side (consumer side) drivers, which receive/deserialize data from the CAN bus and publish them over uORB.
The build system also produces firmware binaries designed to be flashed through a DroneCAN bootloader via [PX4's DroneCAN flashing support] or the DroneCAN GUI, in addition to the standard raw binary, ELF, and .px4 firmware files.