Using STorM32 with ArduPilot

The STorM32 gimbal controller can communicate with an ArduPilot flight controller via (i) a serial data line or (ii) the CAN bus using UAVCAN. The serial/UAVCAN communication allows for a much richer data transmission and accordingly richer set of features than possible with the traditional PWM connections. It also leads to a clean wiring.

Two aspects of the communication can be distinguished:

• Control of the gimbal: The serial/UAVCAN communication allows us to control the orientation of the gimbal, with higher precision than possible with the standard inputs, and gives access to all other features of the STorM32 controller, such as triggering a camera, executing on-board scripts, and so on. It also allows the STorM32 to feed back information to the flight controller and the ground station, such as the actual camera orientation, which can be displayed by a ground station or OSD. Advanced operation modes, which in addition involves the flight controller, ground station, companion computer, or other electronics, such as follow me or object tracking, also fall into that category.
• Improved stabilization: In addition, the serial/UAVCAN communication is used to transfer dedicated data from the flight controller to the STorM32 controller, which helps in achieving better stabilization, and hence better videos. For instance, yaw drift can be corrected, horizon shifts in high-speed turns removed, or smoother pans achieved. This part of the serial/UAVCAN communication is called the STorM32-Link.

This article is mostly concerned with the first aspect, also because the STorM32-Link is not yet fully developed.

If you just need the range of functionality possible with the standard tilt & pan control, then you don't need anything of the following, and you may stop reading here. Also, some of the features discussed below can be accomplished by workarounds. Decide yourself which approach fits your needs best. :)

STorM32 - ArduPilot Support

Four modes of operation are available:

STorM32 Mavlink

• MNT_TYPE = 4
• SERIALx_PROTOCOL = 1
• STorM32 MAVLink heartbeat must be activated, Mavlink Configuration = “emit heartbeat” or higher
• available in ArduPilot and BetaCopter

For further details please visit ArduPilot Docs > Copter > Optional Hardware > Camera&Gimbals > SToRM32 Gimbal Controller. A good sum-up by lvale is found here [1], and a workaround to access further STorM32 functions here [2].

STorM32 Serial

• MNT_TYPE = 5
• SERIALx_PROTOCOL = 8
• STorM32 MAVLink heartbeat must be deactivated, Mavlink Configuration = “no heartbeat”
• available in ArduPilot and BetaCopter

For further details please visit ArduPilot Docs > Copter > Optional Hardware > Camera&Gimbals > SToRM32 Gimbal Controller.

STorM32 UAVCAN

• MNT_TYPE = 83
• CAN_P1_DRIVER = 1
• STorM32 MAVLink heartbeat must be deactivated, Mavlink Configuration = “no heartbeat”
• available only in BetaCopter

Comment: The CAN bus on the flight controller must be activated properly. This can require that also other parameters in the flight controller's CAN section must be set appropriately. Please consult the ArduPilot Docs.

STorM32 Native

• MNT_TYPE = 84
• SERIALx_PROTOCOL = 84
• STorM32 MAVLink heartbeat must be deactivated, Mavlink Configuration = “no heartbeat”
• available only in BetaCopter

The STorM32 UAVCAN and STorM32 Native modes are essentially identical, except that the data communication in the former case is via the CAN bus using the UAVCAN protocol, and in the latter case via the selected serial port.

The remainder of this wiki page is devoted exclusively to describing the STorM32 UAVCAN/Native modes; the STorM32 UAVCAN mode is chosen exemplarily.

Feature Matrix

Feature	STorM32 Mavlink	STorM32 Serial	STorM32 UAVCAN
Gimbal Angle Control	x	x	x
Camera Trigger	x (?)	-	x
MAV_MOUNT_STATUS message	x	x	x
Video on/off	-	-	x
Extended Gimbal Angle Control	-	-	x
360° Gimbal with Free Look	-	-	x
STorM32 Functions	-	-	x
STorM32 Scripts	-	-	x
STorM32-Link	-	-	x

BetaCopter

I made some modifications to the ArduCopter firmware (currently AC3.6-dev) and called the result BetaCopter. However, unless the STorM32-specific features are activated by a "secret key" 83 or 84, BetaCopter will - to the best of my knowledge - behave exactly like the original firmware. This means that - to the best of my knowledge - there is no risk involved in using BetaCopter instead of ArduCopter.

For the following you need betacopter 3.6dev v005 and o323bgc v2.31e, or higher. You can download the latest versions from here: Downloads.

On the STorM32 controller the parameter Mavlink Configuration must be set to “no heartbeat”. For using CAN/UAVACN, please see the article UAVCAN.

The following settings or parameter fields are available. The features involve settings on both the BetaCopter and STorM32 side.

ArduCopter: MNT_TYPE = 83 or 84

As mount type you may choose 83 or 84, which activates BetaCopter's UAVCAN or native STorM32 protocol. You should then notice this:

• All ArduCopter camera features are working. That is, whenever a certain path of actions (Mavlink, receiver, mission, UAVCAN, ...) lets ArduCopter want to take a picture, the STorM32 controller will know and activate it's camera functions.
• All ArduCopter mount features are working. Well, that's mostly exactly what you get also with the other modes of operation, e.g., when using the Mavlink connection with ArduPilot.
• In the Message box of MissonPlanner "STorM32 ..." messages will appear (currently only for MNT_TYPE = 84).
• The STorM32-Link is present.

Setting MNT_TYPE = 83 or 84 is mandatory for any of this to work.

STorM32: Virtual Channel Configuration = serial

In the STorM32 GUI, the parameter Virtual Channel Configuration can be set to “serial”, which has this effect:

All STorM32 functions can be invoked by selecting a “Virtual-1” - “Virtual-16” input channel, as if the STorM32 would be directly connected to the receiver. This allows doing many useful things, such as activating a script or triggering video on/off from the transmitter. It however also allows doing nonsense, and it is the users responsibility to avoid that. For instance, if the ArduPilot mount is activated and is in Rc Targeting mode, and e.g. Rc Pitch Control is set to a virtual input channel, then the gimbal may move in funny ways since it may receive the transmitter stick information from both the ArduPilot mount and the receiver. In contrast, if the ArduPilot mount is in GPS or ROI Targeting mode, then one gets "free look", which is useful and quite cool actually. As said, all that is exactly as if the receiver would be directly connected to the STorM32 on its RC ports.

STorM32-Link

With MNT_TYPE = 83 or 84 you have also activated the STorM32-Link (for details on the STorM32-Link see [3]). In the STorM32 GUI, specifically the [GUI:Dashboard] and/or the [GUI:Data Display], you should note that the STorM32-Link field goes to OK.

The main parts of the STorM32-Link functionality are not yet implemented in the STorM32 firmware. However, as evidenced by the STorM32-Link field showing OK, the data exchange is established.

Testing the Serial Connection

The serial connection can be tested in several ways. The following tests do not require that the copter is completely built, and do not require that the copter is armed.

• Message box in MissonPlanner: In the message box several messages related to the STorM32 should appear. In particular, a message like "STorM32 v2.11e nt v1.30 F103RC" informing about the STorM32 firmware version should be visible. Also, a message "STorM32 in NORMAL mode" should occur when the gimbal has finished initialization and entered NORMAL mode.

• STorM32-Link field in the STorM32 GUI: The [GUI:Dashboard] and [GUI:Data Display] each have a field which is related to the STorM32-Link. They should display OK or a similar positive message.

• Trigger Camera NOW: In MissionPlanner the camera can be triggered by a right-mouse-click dropdown menu in the Flight Data map. On the STorM32 side the camera trigger can be easily tested by connecting a visible-light LED (red, green, blue, not IR) to the #IR port.

• Gimbal RC Targeting: With the ArduPilot mount in RC Targeting mode (which should be the default setting), the camera can be turned with the transmitter sticks.

• Sniffing the communication: One of course can sniff directly what is going on on the communication data lines. This is especially helpful when using CAN/UAVCAN. You when need a SLCAN adapter, e.g., the UC4H SLCAN adapter.

Gimbal Point

MissionPlanner supports what it calls a gimbal point. It is a blue point icon on the map, which indicates the estimated position at which the gimbal is looking at (see also e.g. https://github.com/ArduPilot/MissionPlanner/issues/1323). In order to activate it, the following ArduPilot parameters must be set:

• MNT_STAB_ROLL = 0
• MNT_STAB_TILT = 1