UAVCAN

The information on this page refers to firmware v2.40 and higher.

The STorM32 gimbal controller supports UAVCAN. This allows communicating with the STorM32 controller through a CAN bus, very similar to the communication through the serial interfaces or Wifi.

Configuration

The STorM32 parameters, which are related to UAVCAN, are split into the 'normal' and the 'UAVCAN' parameter sections. The parameters in the normal section are accessible like all the other parameters, e.g. via the GUI. The parameters in the UAVCAN section are however accessible only by using UAVCAN's Node configuration mechanism. The two parameter sections are exclusive, that is, a parameter is either in the one or the other section, but not in both. The single exception is the Uavcan Node ID parameter, which can be configured by either mechanism.

GUI Parameters

In the GUI, the parameters in the normal section are located in the [GUI:Interfaces Tool] window, which is accessible via the [GUI:Tools] menu.

Uavcan Configuration:
Set to “normal” to activate the UAVCAN communication. The STorM32 board needs to be reset for a change to become effective.

Uavcan Node ID:
Sets the node ID of the STorM32 controller (default = 71). Dynamic node allocation is not supported. The range of allowed IDs is restricted to 11 - 124. The STorM32 board needs to be reset for a change to become effective.

UAVCAN Parameters

The parameters in the UAVCAN section can be accessed e.g. using the UAVCAN GUI Tool, and a SLCAN adapter. A uc4h SLCAN adapter is probably the cheapest option, for a advanced option see the Zubax Babel.

NodeId:
Sets the node ID of the STorM32 controller (default = 71). Dynamic node allocation is not supported. The range of allowed IDs is restricted to 11 - 124. The STorM32 board needs to be reset for a change to become effective.

NodeStatus Rate:
Sets the rate at which the uavcan.protocol.NodeStatus message is emitted (default = 1000). A value of 1000 means that a message is broadcasted every 1000 ms.

GimbalStatus Rate:
Sets the rate at which the storm32.GimbalStatus message is emitted (default = 500). A value of 500 means that a message is broadcasted every 500 ms. A value of 0 deactivates the emission of the message.

UAVCAN Messages

The STorM32 controller supports the UAVCAN standard data types which are needed for basic operation, as well as the tunnel.Broadcast data type.

NodeStatus (BC, ID 341)

See uavcan.protocol.NodeStatus.

GetNodeInfo (SR, ID 1)

See uavcan.protocol.GetNodeInfo.

RestartNode (SR, ID 5)

See uavcan.protocol.RestartNode.

param.ExecuteOpCode (SR, ID 10)

See uavcan.protocol.param.ExecuteOpcode.

param.GetSet (SR, ID 11)

See uavcan.protocol.param.GetSet.

tunnel.Broadcast (BC, ID 2010)

See uavcan.tunnel.Broadcast.

This message appears to not yet have been finally released to the official standard. It is most important though, since it provides the backbone for the communication with the STorM32 controller via UAVCAN. The STorM32 essentially implements a UAVCAN-UART bridge.

STorM32 Data Types

The STorM32 specific data types used in older versions are deprecated; this section is only kept for reference.

Comment: It is not claimed that the STorM32 specific data types are the last conclusion of wisdom; they are open for discussion. They may however suggest a skeleton for standard definitions.

Comment: Currently the ArduPilot build system does not seem to allow using vendor-specific UAVCAN messages, at least I could not figure that out. I thus had to move the STorM32 specific messages listed here to the name space "uavcan" of the standard data types, in order to realize a communication between ArduPilot and STorM32 (see ArduCopter controls STorM32 gimbal by UAVCAN). This however affected the signatures, and thus: (1) The UAVCAN messages in firmware v2.31e are not compatible with those in v2.30. (2) This is (hopefully) going to change in future versions. In short: For as long as the UAVCAN message set has not stabilized, one has to carefully pay attention to versions .

storm32.Status (BC, ID 8300)

# Gimbal Attitude, angles in degrees +-180°, in gimbal frame.
float32 pitch_deg
float32 roll_deg
float32 yaw_deg

Reports the camera angles in degrees. The yaw angle is relative to the gimbal frame or vehicle orientation.

storm32.Control (BC, ID 8301)

# Gimbal Attitude, angles in degrees +-180°, in gimbal frame.
float32 pitch_deg
float32 roll_deg
float32 yaw_deg

Moves the camera to the given orientation. The yaw angle is relative to the gimbal frame or vehicle orientation. It works like a CMD_SETANGLE command, see Inputs and Functions: Rc Input Processing.

storm32.NodeSpecific (BC, ID 8302)

# Node Specific
uint8[<=64] payload

The payload can correspond to any of the simple serial or RC commands, with the crc word stripped off (the crc is not needed since the message is already protected by UAVCAN]. Only commands of lengths less or equal 64 bytes can be handled (this excludes e.g. the 'p' command). The response of the STorM32 controller to the received command is packed into and send out as a storm32.NodeSpecificAck data type.

storm32.NodeSpecificAck (BC, ID 8303)

# Node Specific Ack
uint8 initiator_node_id
uint8[<=64] payload

The payload holds the response to any of the simple serial or RC commands, with the crc word stripped off. Only responses of lengths less or equal 64 bytes can be handled (this excludes e.g. the 'g' command). The initiator_node_id holds the id of the node, which emitted the storm32.NodeSpecific message to which this is the response.

Comments on STorM32 specific UAVCAN Data Types

NodeSpecific, NodeSpecificAck

This set of messages provides access to all features of the STorM32 controller which are accessible via serial commands, and thus establish a powerful message set. They function very similar to the MAV_CMD_TARGET_SPECIFIC Mavlink command, so please read Comments on STorM32 specific Mavlink Messages.

Example

The camera can be recentered by sending the RC command CMD_SETPITCHROLLYAW, with the pitch, roll, and yaw input values set to zero. This can be achieved by sending the byte stream

0xFA 0x06 0x12 0x00 0x00 0x00 0x00 0x00 0x00 crc-low-byte crc-high-byte

to any of the serial ports (USB, Uart, ...), or by sending a storm32.NodeSpecific message to the CAN port, with the payload set to

0xFA 0x06 0x12 0x00 0x00 0x00 0x00 0x00 0x00

In the latter case, the STorM32 controller will respond with emitting a storm32.NodeSpecificAck message on the CAN port, with the payload set to

0xFB 0x01 0x96 0x00