Using STorM32 with ArduPilot

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

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. :)

Comment: Unfortunately, ArduPilot's gimbal support is not fully functioning, which is true especially for its MAVLink mount. That is, some features you will find to work nicely, some others you will find to not work. There is nothing the STorM32 or any other gimbal controller can do about it; it's ArduPilot.

STorM32 - ArduPilot Support

ArduPilot offers two mounts, which can be used with the STorM32 controller, the STorM32 Mavlink (MNT_TYPE = 4) and STorM32 Serial (MNT_TYPE = 5) mount types. For further details please visit ArduPilot Docs > Copter > Optional Hardware > Camera&Gimbals > SToRM32 Gimbal Controller. A good sum-up by lvale for the STorM32 Mavlink Mount is found here [1], and a workaround to access further STorM32 functions here [2].

In addition, the BetaCopter fork of ArduPilot additionally offers the STorM32 UAVCAN (MNT_TYPE = 83) and STorM32 Native (MNT_TYPE = 84) mount types. These mount types are created and maintained by the STorM32 firmware developer and provide the best range of functions. The STorM32 UAVCAN and STorM32 Native mounts are virtually identical function-wise; they differ only in the bus used for communication between the STorM32 and the flight controller.

A comparison of the different techniques to connect the STorM32 with the flight controller is given in the following feature matrix.

Feature Matrix

(to the best of the authors knowledge)

Feature	PWM	STorM32 Mavlink	STorM32 Serial	STorM32 UAVCAN/Native
Gimbal Angle Control	x	x (?)	x	x
Solo Smart Shots	x	-	-	x
MAV_MOUNT_STATUS message	-	x (1)	x	x
Camera Trigger	x	x (?)	-	x
Gimbal Point in MP	-	x (?)	x	x
Video on/off	-	-	-	x
360° Gimbal with Free Look	-	-	-	x
STorM32 Functions	-	-	-	x
STorM32 Scripts	-	-	-	x
STorM32-Link: Horizon Drift Comp.	-	-	-	x
STorM32-Link: Yaw Drift Comp.	-	-	-	x

(?) May or may not work properly in the latest ArduPilot releases, see the above comment. Please check with the ArduPilot community.

(1) The message reports the last set point, not the actual gimbal/camera orientation.

BetaCopter

I made some modifications to the ArduCopter firmware (currently AC3.6-dev) and called the result BetaCopter, which provides simply the best support of STorM32 gimbals.

Importantly, unless the STorM32-specific features in BetaCopter are activated by a "secret key" 83 or 84, BetaCopter behaves exactly identical to the original firmware. This means that - to the best of my knowledge - there is no risk involved in using BetaCopter instead of ArduCopter.

Comments:

• If you are satisfied with ArduPilot's gimbal support then there is no need to use BetaCopter. However, if you want to make best use of the STorM32's features and capabilities then you want to chose BetaCopter.
• Before using BetaCopter it is strongly recommended to first install the original ArduCopter firmware and get the copter flying flawlessly with it, and then to install BetaCopter.

For the following you need the latest versions of BetaCopter and the STorM32 firmware; you can download them from here: Downloads.

On the STorM32 controller, the parameter Mavlink Configuration must be set to “no heartbeat”. For configuring the STorM32's CAN bus, please see the article UAVCAN.

In order to establish a working communication between the STorM32 and the flight controller, parameters on both sides, BetaCopter and STorM32, need to be adjusted, as described in the following.

ArduCopter: MNT_TYPE = 83 or 84

As mount type you may choose 83 or 84, which activates BetaCopter's UAVCAN or native STorM32 protocols, respectively.

STorM32 UAVCAN

• MNT_TYPE = 83
• CAN_D1_PROTOCOL = 1
• CAN_P1_BITRATE = 1000000
• CAN_P1_DRIVER = 1
• STorM32 UAVCAN must be configured, as described in the UAVCAN article
• available only in BetaCopter

Comment: The CAN bus of the flight controller must be configured in addition. This can require that additional 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
• SERIALx_BAUD = 115
• available only in BetaCopter

Comment: The default baudrate of the STorM32 serial ports is 115200 bps, hence in ArduPilot SERIALx_BAUD has to be set to 115, but other values can also be configured. For, e.g., 230400 bps set in STorM32 Uart Baudrate to “230400” and in ArduPilot SERIALx_BAUD to 230.

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 (UART) port. With either mount activated, you should notice this:

• All ArduCopter mount features such as gimbal control, POI, follow me, or smart shots are working. Flawlessly.
• 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.
• In the Message box of MissonPlanner "STorM32 ..." messages will appear.
• The STorM32-Link, providing horizon drift and yaw drift compensation, and additional features, is present.

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

STorM32-Link

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

Comment: The STorM32-Link is available only for T-STorM32 gimbals, but not the conventional STorM32 NT gimbals. However, also for the latter a OK will be displayed when a working connection between STorM32 and BetaCopter has been established, and the traditional gimbal control functions are all working. However, the INUSE will not appear, indicating that the STorM32-Link, i.e., the horizon and yaw drift compensation feature, is not available.

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 this is exactly as if the receiver would be directly connected to the STorM32 on its RC ports.

Testing the Connection

The serial/UAVCAN 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.

• 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.

• 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.

• 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