Using STorM32 with ArduPilot

STorM32 - ArduPilot Support

Three modes of operation are currently available:

STorM32 Mavlink

• SERIAL_PROTOCOL = 1
• MOUNT_TYPE = 4
• STorM32 heartbeat must be activated
• available in ArduPilot and betacopter

STorM32 serial

• SERIAL_PROTOCOL = 8
• MOUNT_TYPE = 5 (the arducopter docu is wrong here)
• STorM32 heartbeat must be de-activated
• available in ArduPilot and betacopter

STorM32 native

• SERIAL_PROTOCOL = 83
• MOUNT_TYPE = 83
• STorM32 heartbeat must be de-activated
• available only in betacopter

BetaCopter 3.4-dev v013

I made some modification to ArduCopter AC3.4-dev (of 3. Aug. 2016). However, unless the STorM32-specific features are not activated by a "secret key" 83, ArduCopter will (= should to the best of my knowledge ) behave exactly like the original code. This means that - to the best of my knowledge - there is not more or less risk in using BetaCopter instead of ArduCopter, at least as long as no 83's are used.

For the following you need betacopter 3.4-dev v013 and o323bgc v2.09e. You can download them here:

• o323bgc v2.09e:
• BetaCopter v013:

On the STorM32, the Mavlink Configuration parameter must be set to “no heartbeat”.

These settings to parameter fields are available.

ArduCopter SERIALx_PROTOCOL = 83

As serial protocol you may choose 83, which activates betacopter's native STorM32 protocol (SERIALX_BAUD must be 115). You should then notice this:

• All ArduCopter Camera features are working. That is, whenever a certain path of actions (Mavlink, receiver, mission,...) lets ArduCopter think it wants to take a picture, the STorM32 will know and act.
• In the Message box of MissonPlanner a "STorM32 ..." message will appear. This so-to-say tells you that the serial ArduCopter-STorM32 connection is working.

ArduCopter MNT_TYPE = 83

As mount type you may choose 83, which activates betacopter's native STorM32 mount. In addition to the above you should then also notice this:

• All ArduCopter Mount features are working. Well, that's mostly exactly what you got already before when using the Mavlink connection with ArduPilot, so not much new function-wise here. The one addition is that also the MAV_MOUNT_STATUS message is emitted, so that in e.g. MissionPlaner the camera orientation can be read off. And see also the next parameter.

ArduCopter STORM_RC_TRGT

This is a new parameter. It allows to modify the behavior of the native STorM32 mount in the RC Targeting mode. A value of 0 sets it to the standard ArduPilot behavior, as you know it. In this setting, the camera motion is determined by the various MNT parameters. When set to 1, in contrast, the standard STorM32 behavior is obtained. Here, the camera motion is determined by STorM32's Rc Input parameter fields. That is, the camera responds to transmitter inputs in exactly the same way as you know it for the STorM32. I guess, after having gotten used to it, most will prefer this operation modus. It is also somewhat more robust against rc failsafes.

ArduCopter STORM_HAS_PAN

This is a new parameter. It allows to set the has_pan_control flag of the native STorM32 mount to 0:false or 1:true. It is not clear to me what this flag does (for the other mounts it is set to false). From the code I speculate that when false the copter will yaw along with a yaw command to the gimbal, while when true the copter isn't affected by a yawing mount. If so, the latter would enable a free 360° panning independent on the copter as expected for 360° gimbals (see e.g. digaus' tracking work). Anyway, whatever this flag does, it will be interesting to figure it out.

STorM32 Virtual Channel Configuration = serial

The STorM32's Virtual Channel Configuration parameter can be set to “serial”. You should then in addition notice this:

• All STorM32 Functions can be invoked by selecting a VIRTUAL1-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, e.g. if the ArduCopter mount is activated and is in Rc Targeting mode, and >Rc Input Control< is set to a VIRTUAL input, then the gimbal will move in funny ways since it receives signals related to the transmitter sticks from two different parties. In contrast, if the ArduCopter mount is in e.g. GPS or ROI targeting mode, when 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 SERIALx_PROTOCOL = 83 you should also note that in the STorM32 GUI, specifically the Dashboard and/or DataDisplay, the STorM32-Link field goes ON (if you want to know what STorM32-Link is about, see http://www.rcgroups.com/forums/showthread.php?t=2395475). The STorM32-Link functionality is actually not yet implemented in v2.09e, but this enabled field means that the STorM32-Link is working, and the crucial basis is established. From a practical perspective, you may use that field to check if the connection from your flight controller to the StorM32 is working.