CAN Bus Communication: Difference between revisions

From STorM32-BGC Wiki
Jump to navigation Jump to search
 
(28 intermediate revisions by the same user not shown)
Line 1: Line 1:
''The information on this page refers to firmware v2.40 and higher.''
''The information on this page refers to firmware v2.58e and higher.''
<!--The STorM32 gimbal controller supports the DJI CAN bus. This allows communicating with the STorM32 controller via a [https://de.wikipedia.org/wiki/Controller_Area_Network CAN] bus.-->


The STorM32 gimbal controller supports the DJI CAN bus and [http://uavcan.org/ UAVCAN] protocols. This allows communicating with the STorM32 controller through a [https://de.wikipedia.org/wiki/Controller_Area_Network CAN] bus, very similar to the communication through the [[Serial_Communication|serial interfaces]] or [[Using_a_ESP8266_Wifi_Module|Wifi]].
The STorM32 gimbal controller had CAN bus support in previous versions, but this feature was removed with version v2.58e.


<div class="toclimit-2">__TOC__</div>
Up to including firmware v2.53 the STorM32 controller supported the UAVCAN protocol.
 
Up to including firmware v2.57e the STorM32 controller supported the DJI CAN bus.
 
<div class="toclimit-3">__TOC__</div>


== DJI CAN Bus ==
== DJI CAN Bus ==
Line 12: Line 17:


See also [[Using STorM32 with DJI]].
See also [[Using STorM32 with DJI]].
{{COMMENT| The DJI CAN bus support is not available in firmware versions higher than v2.57e.}}


=== Configuration ===
=== Configuration ===
Line 35: Line 42:
The STorM32's [http://uavcan.org/ UAVCAN] support offers the very same functions and features as the communication through the [[Serial_Communication|serial interfaces]] or [[Using_a_ESP8266_Wifi_Module|Wifi]]; they only differ by the bus which is used.
The STorM32's [http://uavcan.org/ UAVCAN] support offers the very same functions and features as the communication through the [[Serial_Communication|serial interfaces]] or [[Using_a_ESP8266_Wifi_Module|Wifi]]; they only differ by the bus which is used.


See also [[Using STorM32 with ArduPilot]].
{{COMMENT| The UAVCAN support is not available in firmware versions higher than v2.53.}}
 
{{#ev:youtube|Sw24wAIoemA|360}}
 
{{#ev:youtube|NxqCmlby_04|360}}


=== Configuration ===
=== Configuration ===
Line 50: Line 61:
{{PARAMNAME|Uavcan Node ID}}: <br> 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.
{{PARAMNAME|Uavcan Node ID}}: <br> 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.


This parameter also sets the channel ID for the UAVCAN tunnel.Broadcast message, and the gimbal_id for the STorM32 specific olliw.storm32.Status, olliw.storm32.Control, olliw.storm32.Command, and olliw.storm32.CommandAck messages.
This parameter also sets the channel ID for the UAVCAN tunnel.Broadcast message, and the gimbal ID for the STorM32 specific olliw.storm32.Status, olliw.storm32.Control, olliw.storm32.Command, and olliw.storm32.CommandAck messages.


==== UAVCAN Parameters ====
==== UAVCAN Parameters ====
Line 56: Line 67:
The parameters in the UAVCAN section can be accessed e.g. using the [http://uavcan.org/GUI_Tool/Overview/ UAVCAN GUI Tool], and a SLCAN adapter. A [http://www.olliw.eu/2017/uavcan-for-hobbyists/ uc4h SLCAN adapter] is probably the cheapest option, for a advanced option see the [https://kb.zubax.com/display/MAINKB/Zubax+Babel Zubax Babel].
The parameters in the UAVCAN section can be accessed e.g. using the [http://uavcan.org/GUI_Tool/Overview/ UAVCAN GUI Tool], and a SLCAN adapter. A [http://www.olliw.eu/2017/uavcan-for-hobbyists/ uc4h SLCAN adapter] is probably the cheapest option, for a advanced option see the [https://kb.zubax.com/display/MAINKB/Zubax+Babel Zubax Babel].


{{PARAMNAME|NodeId}}: <br> 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.
{{PARAMNAME|NodeId}}: <br> See the description for the GUI parameter {{PARAMNAME|Uavcan Node ID}}.


{{PARAMNAME|NodeStatus Rate}}: <br> Sets the rate at which the [http://uavcan.org/Specification/7._List_of_standard_data_types/#nodestatus uavcan.protocol.NodeStatus] message is emitted (default = 1000). A value of 1000 means that a message is broadcasted every 1000 ms.
{{PARAMNAME|NodeStatus Rate}}: <br> Sets the rate at which the [http://uavcan.org/Specification/7._List_of_standard_data_types/#nodestatus uavcan.protocol.NodeStatus] message is emitted (default = 1000). A value of 1000 means that a message is broadcasted every 1000 ms.


{{PARAMNAME|GimbalStatus Rate}}: <br> 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.
{{PARAMNAME|GimbalStatus Rate}}: <br> Sets the rate at which the [[#olliw.storm32.Status_.28BC.2C_ID_8300.29 | olliw.storm32.Status]] 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 ===
{{PARAMNAME|Debug}}: <br> A value of 1 enables the emission of [https://uavcan.org/Specification/7._List_of_standard_data_types/#logmessage uavcan.protocol.debug.LogMessage] messages. A value of 0 deactivates the emission of the message.
 
=== UAVCAN Standard Messages ===
----
----


The STorM32 controller supports the UAVCAN [http://uavcan.org/Specification/7._List_of_standard_data_types/ standard data types] which are needed for basic operation, as well as the tunnel.Broadcast data type.
The STorM32 controller supports the UAVCAN [http://uavcan.org/Specification/7._List_of_standard_data_types/ standard data types] which are needed for basic operation, as well as the tunnel.Broadcast and debug.LogMessage data types.


==== NodeStatus (BC, ID 341) ====
==== NodeStatus (BC, ID 341) ====
Line 93: Line 106:
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 which is based on exchanging these tunnel messages.
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 which is based on exchanging these tunnel messages.


See also [[Uavcan]].
==== debug.LogMessage (BC, ID 16383) ====
 
See [https://uavcan.org/Specification/7._List_of_standard_data_types/#logmessage uavcan.protocol.debug.LogMessage].
 
=== STorM32 specific UAVCAN Data Types ===
----
 
In addition to the above standard data types, the STorM32 supports also some STorM32 specific data types, which are located in the name space olliw.storm32.
 
==== olliw.storm32.Status (BC, ID 8300) ====
 
uint8 gimbal_id
uint8 mode
uint32 status
uint8 orientation_type
float32[4] orientation
float32[<=3] angular_velocity
 
Reports the camera orientation. Default is angles in degrees, and yaw angle relative to the gimbal frame or the vehicle.
 
==== olliw.storm32.Control (BC, ID 8301) ====
 
uint8 gimbal_id
uint8 mode
uint8 control_mode
float32[4] orientation
float32[<=3] angular_velocity
 
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|Inputs and Functions: Rc Input Processing]].-->
 
==== olliw.storm32.Command (BC, ID 8302) ====
 
uint8 gimbal_id        #0 means broadcast, any gimbal should listen
uint8[<=128] payload
 
The payload can correspond to any of the [[Serial_Communication#Serial_Communication_-_Simple_Commands|simple serial]] or [[Serial_Communication#Serial_Communication_-_RC_Commands|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 128 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 olliw.storm32.CommandAck data type.
 
==== olliw.storm32.CommandAck (BC, ID 8303) ====
 
uint8 gimbal_id        #it cannot be zero, it must by a unique id of the gimbal
uint8[<=128] payload
 
The payload holds the response to any of the [[Serial_Communication#Serial_Communication_-_Simple_Commands|simple serial]] or [[Serial_Communication#Serial_Communication_-_RC_Commands|RC commands]], with the crc word stripped off. Only responses of lengths less or equal 128 bytes can be handled (this excludes e.g. the 'g' command).
 
=== Comments on STorM32 specific UAVCAN Data Types ===
----
 
==== Status, Control ====
 
I was considering supporting the related camera_gimbal standard data types. However, they use only float16 for the quaternion and more seriously expect frames which gimbals generally cannot support, except in special situations. They are thus totally useless in practical terms, and there are no signs that useful standard data types would ever come to live. Hence the STorM32 specific data types.
 
==== Command, CommandAck ====
 
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 [[Serial_Communication#Comments_on_STorM32_specific_Mavlink_Messages|Comments on STorM32 specific Mavlink Messages]]. The same task can be accomplished with using the [[#tunnel.Broadcast_.28BC.2C_ID_2010.29|tunnel.Broadcast]] data type, but the STorM32 specific Command data types are somewhat denser and allow a somewhat faster handling, and thus are retained.
 
'''''Example'''''
 
The camera can be recentered by sending the [[Serial_Communication#Serial_Communication_-_RC_Commands|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 olliw.storm32.Command 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 olliw.storm32.CommandAck message on the CAN port, with the payload set to
 
0xFB 0x01 0x96 0x00
 
<!-- See also [[Uavcan]]. -->

Latest revision as of 05:25, 9 April 2021

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

The STorM32 gimbal controller had CAN bus support in previous versions, but this feature was removed with version v2.58e.

Up to including firmware v2.53 the STorM32 controller supported the UAVCAN protocol.

Up to including firmware v2.57e the STorM32 controller supported the DJI CAN bus.

DJI CAN Bus

The STorM32 gimbal controller can be connected to the CAN bus of a DJI flight controller, which enables the STorM32-Link and other advanced functions.

Currently only the DJI Naza M2 is supported.

See also Using STorM32 with DJI.

Comment: The DJI CAN bus support is not available in firmware versions higher than v2.57e.

Configuration

In the GUI, the DJI CAN bus related parameters are located in the [GUI:Interfaces Tool] window, which is accessible via the [GUI:Tools] menu.

Can Configuration:
Set to “dji naza” to activate the CAN bus communication with a DJI Naza M2. The STorM32 board needs to be reset for a change to become effective.

STorM32Link Configuration:
Set to any value different from “off” to activate the STorM32-Link features.

When the CAN bus is configured to “dji naza”, the STorM32-Link will become PRESENT and OK, as indicated in the respective areas in the [GUI:Dashboard] tab and the [GUI:DataDisplay]. The parameter STorM32Link Configuration determines if and which STorM32-Link features are functional.

DJI CAN Bus Messages

The STorM32 listens to the 0x090-1002 (OSD data) and 0x108-1009 (input/output) messages. In order to enable the emission of the OSD data message, the STorM32 emits 0x108-1007 (OSD heartbeat) messages at 1 Hz.

For the details on the messages, see pavelsky's rcgroups thread DJI NAZA/Phantom/A2 CAN bus communication protocol - NazaCanDecoder Arduino library.

UAVCAN

The STorM32's UAVCAN support offers the very same functions and features as the communication through the serial interfaces or Wifi; they only differ by the bus which is used.

Comment: The UAVCAN support is not available in firmware versions higher than v2.53.

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.

Can Configuration:
Set to “uavcan” 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.

This parameter also sets the channel ID for the UAVCAN tunnel.Broadcast message, and the gimbal ID for the STorM32 specific olliw.storm32.Status, olliw.storm32.Control, olliw.storm32.Command, and olliw.storm32.CommandAck messages.

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:
See the description for the GUI parameter Uavcan Node ID.

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 olliw.storm32.Status 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.

Debug:
A value of 1 enables the emission of uavcan.protocol.debug.LogMessage messages. A value of 0 deactivates the emission of the message.

UAVCAN Standard Messages

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

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 which is based on exchanging these tunnel messages.

debug.LogMessage (BC, ID 16383)

See uavcan.protocol.debug.LogMessage.

STorM32 specific UAVCAN Data Types

In addition to the above standard data types, the STorM32 supports also some STorM32 specific data types, which are located in the name space olliw.storm32.

olliw.storm32.Status (BC, ID 8300)

uint8 gimbal_id
uint8 mode
uint32 status
uint8 orientation_type
float32[4] orientation
float32[<=3] angular_velocity

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

olliw.storm32.Control (BC, ID 8301)

uint8 gimbal_id
uint8 mode
uint8 control_mode
float32[4] orientation
float32[<=3] angular_velocity

Moves the camera to the given orientation.

olliw.storm32.Command (BC, ID 8302)

uint8 gimbal_id        #0 means broadcast, any gimbal should listen
uint8[<=128] 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 128 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 olliw.storm32.CommandAck data type.

olliw.storm32.CommandAck (BC, ID 8303)

uint8 gimbal_id        #it cannot be zero, it must by a unique id of the gimbal
uint8[<=128] 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 128 bytes can be handled (this excludes e.g. the 'g' command).

Comments on STorM32 specific UAVCAN Data Types

Status, Control

I was considering supporting the related camera_gimbal standard data types. However, they use only float16 for the quaternion and more seriously expect frames which gimbals generally cannot support, except in special situations. They are thus totally useless in practical terms, and there are no signs that useful standard data types would ever come to live. Hence the STorM32 specific data types.

Command, CommandAck

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. The same task can be accomplished with using the tunnel.Broadcast data type, but the STorM32 specific Command data types are somewhat denser and allow a somewhat faster handling, and thus are retained.

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 olliw.storm32.Command 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 olliw.storm32.CommandAck message on the CAN port, with the payload set to 

0xFB 0x01 0x96 0x00


Retrieved from "http:///storm32bgc-wiki/index.php?title=CAN_Bus_Communication&oldid=9927"