CAN-BUS

Summary

The UAVCAN_NODE_STATUS message is designed to bridge the status of devices on the UAVCAN (now DroneCAN) bus onto the MAVLink network. It reports the health, uptime, and mode of individual CAN nodes.

Status

Unsupported

Directionality

• TX (Transmit): None
• RX (Receive): None

Description

ArduPilot does not implement this message.

While ArduPilot has robust support for DroneCAN (the protocol formerly known as UAVCAN v0) and manages many peripherals (ESCs, GPS, Compass) via CAN, it does not act as a transparent bridge reflecting the raw status of every CAN node onto MAVLink using this specific message.

Instead, ArduPilot abstracts the peripherals. For example, a CAN GPS is reported via GPS_RAW_INT and GPS_STATUS, and a CAN ESC is reported via ESC_TELEMETRY, rather than as a generic "UAVCAN Node."

Intended Data Fields (Standard)

• time_boot_ms: Timestamp (ms since boot).
• time_usec_1: Timestamp (us since UNIX epoch).
• uptime_sec: Time since the node started.
• health: Node health (OK, Warning, Error, Critical).
• mode: Node mode (Operational, Initialization, Maintenance, etc.).
• sub_mode: Sub-mode.
• vendor_specific_status_code: Vendor specific status.

Theoretical Use Cases

1. Unified Health Monitor:
   • Scenario: A vehicle has 20 CAN peripherals (lights, servos, sensors).
   • Action: The GCS displays a "CAN Bus Health" table listing every node ID, its uptime, and its health status. This allows a technician to instantly spot a device that is rebooting frequently or in an error state, even if it doesn't have a dedicated MAVLink message.
2. Network Topology Mapping:
   • Scenario: Diagnosing a bus wiring fault.
   • Action: By monitoring which nodes fall offline (stop sending UAVCAN_NODE_STATUS) when a specific cable is wiggled, ground crew can isolate physical connection issues.

Summary

The UAVCAN_NODE_INFO message provides detailed static information about a UAVCAN (DroneCAN) node, such as its hardware version, software version, and unique ID.

Status

Unsupported

Directionality

• TX (Transmit): None
• RX (Receive): None

Description

ArduPilot does not implement this message.

Similar to UAVCAN_NODE_STATUS (310), ArduPilot does not transparently bridge raw DroneCAN node information onto the MAVLink network using this message.

Intended Data Fields (Standard)

• time_boot_ms: Timestamp (ms since boot).
• uptime_sec: Time since the node started.
• name: Node name string.
• hw_version_major / minor: Hardware version.
• sw_version_major / minor: Software version.
• sw_vcs_commit: Version Control System commit ID.

Theoretical Use Cases

1. Firmware Auditing:
   • Scenario: A fleet manager needs to ensure all ESCs are running the latest safety-critical firmware.
   • Action: The GCS queries UAVCAN_NODE_INFO for all nodes. It compares the sw_version against a manifest and flags any ESCs running outdated code.
2. Asset Tracking:
   • Scenario: Tracking individual components for warranty purposes.
   • Action: The message contains the Unique ID (UUID) of the node. The GCS logs this UUID, allowing the operator to track the flight hours of a specific servo or GPS unit across multiple airframes.

Summary

The CAN_FRAME message encapsulates a raw Controller Area Network (CAN) frame. It is used to bridge the vehicle's onboard CAN buses over the MAVLink connection, effectively turning the Autopilot into an SLCAN adapter. This allows external tools (like the DroneCAN GUI) to interact with CAN peripherals via the autopilot's telemetry or USB link.

Status

Supported (TX & RX)

Directionality

• TX (Transmit): Autopilot -> GCS (Forwards frames received on the physical CAN bus).
• RX (Receive): GCS -> Autopilot (Injects frames onto the physical CAN bus).

Usage

The bridging functionality is controlled via the MAV_CMD_CAN_FORWARD command.

• Enable: Send MAV_CMD_CAN_FORWARD with param1 = bus_id to start receiving CAN_FRAME messages from that bus.
• Disable: Send MAV_CMD_CAN_FORWARD with param1 = 0.

Core Logic

The implementation is in AP_CANManager within libraries/AP_CANManager/AP_CANManager.cpp.

1. RX (Injection): handle_can_frame (Line 486) receives the message, buffers it, and writes it to the specified physical CAN bus.
2. TX (Forwarding): can_frame_callback (Line 665) listens to the physical CAN bus and forwards frames to MAVLink if forwarding is enabled for that channel.

Data Fields

• target_system: System ID.
• target_component: Component ID.
• bus: Bus number.
• len: Frame length.
• id: Frame ID.
• data: Frame data.

Practical Use Cases

1. DroneCAN Debugging:
   • Scenario: A user wants to update the firmware on a CAN GPS or ESC.
   • Action: They connect the DroneCAN GUI to the Autopilot's USB port (MAVLink SLCAN). The Autopilot forwards all CAN traffic, allowing the GUI to see and update the peripheral as if it were directly connected.

Summary

The CANFD_FRAME message encapsulates a raw CAN FD (Flexible Data-rate) frame. It serves the same purpose as CAN_FRAME (386) but supports the extended data length (up to 64 bytes) and faster bitrates of the CAN FD standard.

Status

Supported (TX & RX)

Directionality

• TX (Transmit): Autopilot -> GCS (Forwards CAN FD frames).
• RX (Receive): GCS -> Autopilot (Injects CAN FD frames).

Usage

The bridging functionality is controlled via the MAV_CMD_CAN_FORWARD command, just like CAN_FRAME.

Core Logic

The implementation is in AP_CANManager within libraries/AP_CANManager/AP_CANManager.cpp:706.

1. Detection: When a frame arrives on the bus, can_frame_callback checks frame.isCanFDFrame().
2. Routing: If it is a CAN FD frame, it is wrapped in this message instead of the legacy CAN_FRAME.

Data Fields

• target_system: System ID.
• target_component: Component ID.
• bus: Bus number.
• len: Frame length.
• id: Frame ID.
• data: Frame data.

Practical Use Cases

1. Modern Peripheral Updates:
   • Scenario: Updating a newer DroneCAN servo that uses CAN FD for faster telemetry updates.
   • Action: The DroneCAN GUI sends firmware blocks using CANFD_FRAME messages, which the Autopilot injects onto the high-speed bus.

Summary

The CAN_FILTER_MODIFY message allows the Ground Control Station (GCS) to dynamically configure the whitelist of CAN IDs that are forwarded by the Autopilot via the CAN_FRAME / CANFD_FRAME mechanism. This is essential for managing bandwidth on the telemetry link, allowing the GCS to subscribe only to specific DroneCAN messages of interest.

Status

Supported

Directionality

• TX (Transmit): None
• RX (Receive): Autopilot (Configures internal CAN forwarding filters)

Usage

This message is typically sent by the DroneCAN GUI or a script after enabling forwarding with MAV_CMD_CAN_FORWARD.

Core Logic

The implementation is in AP_CANManager::handle_can_filter_modify within libraries/AP_CANManager/AP_CANManager.cpp:575.

It maintains a sorted list of whitelisted IDs (can_forward.filter_ids) and performs binary searches to filter outgoing frames efficiently.

Operations

The operation field controls how the provided list of IDs is applied:

• 0 (CAN_FILTER_REPLACE): Replaces the entire current whitelist with the new list.
• 1 (CAN_FILTER_ADD): Adds the new IDs to the existing whitelist (ignoring duplicates).
• 2 (CAN_FILTER_REMOVE): Removes the specified IDs from the existing whitelist.

Data Fields

• target_system: System ID.
• target_component: Component ID.
• bus: Bus number.
• operation: What operation to perform on the filter list.
• num_ids: Number of IDs in ids list.
• ids: Filter IDs, length 16.

Practical Use Cases

1. Selective Sniffing:
   • Scenario: A developer wants to debug the GNSS output of a CAN GPS but doesn't want to flood the telemetry link with high-frequency ESC status messages.
   • Action: The tool sends CAN_FILTER_REPLACE with only the DroneCAN GNSS Fix message ID. The Autopilot now only forwards those specific frames.