Using STorM32 with ArduPilot: Difference between revisions

From STorM32-BGC Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
The STorM32 gimbal controller can communicate with an [http://ardupilot.org/ardupilot/index.html ArduPilot] flight controller via a serial data line. The serial communication allows for a much more sophisticated data exchange and accordingly a richer set of features than possible with the traditional PWM connections. It also leads to a clean wiring.
The STorM32 gimbal controller can communicate with an [http://ardupilot.org/ardupilot/index.html ArduPilot] flight controller via a serial data line. The serial communication allows for a much richer exchange and accordingly richer set of features than possible with the traditional PWM connections. It also leads to a clean wiring.


== STorM32 - ArduPilot Support ==
== STorM32 - ArduPilot Support ==
Line 30: Line 30:
* available only in BetaCopter
* available only in BetaCopter


The remainder of the page is devoted to describing the latter, STorM32 native, mode.
The remainder of this wiki page is devoted exclusively to describing the STorM32 native mode.


=== Feature Matrix ===
=== Feature Matrix ===
Line 63: Line 63:
== BetaCopter 3.4 ==
== BetaCopter 3.4 ==


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 - to the best of my knowledge - behave exactly like the original code. This means that - to the best of my knowledge - there is no additional risk in using BetaCopter instead of ArduCopter.
I made some modification to ArduCopter AC3.4 (dev of 3. Aug. 2016), yielding BetaCopter. However, unless the STorM32-specific features are not activated by a "secret key" 83, BetaCopter will - to the best of my knowledge - behave exactly like the original code. This means that - to the best of my knowledge - there is no additional risk in using BetaCopter instead of ArduCopter.


For the following you need betacopter 3.4-dev v013 and o323bgc v2.09e. You can download them here:
For the following you need betacopter 3.4-dev v013 and o323bgc v2.09e. You can download them here:
Line 69: Line 69:
* betacopter 3.4-dev v013: http://www.rcgroups.com/forums/showpost.php?p=35410025&postcount=267
* betacopter 3.4-dev v013: http://www.rcgroups.com/forums/showpost.php?p=35410025&postcount=267


On the STorM32, the {{PARAMNAME|Mavlink Configuration}} parameter must be set to {{PARAMVALUE|no heartbeat}}.
On the STorM32, the {{PARAMNAME|Mavlink Configuration}} parameter '''''must''''' be set to {{PARAMVALUE|no heartbeat}}.


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


=== ArduCopter SERIALx_PROTOCOL = 83 ===
=== ArduCopter: SERIALx_PROTOCOL = 83 ===


As serial protocol you may choose 83, which activates BetaCopter's native STorM32 protocol. SERIALx_BAUD must be set to 115. You should then notice this:
As serial protocol you may choose 83, which activates BetaCopter's native STorM32 protocol. SERIALx_BAUD must be set to 115. You should then notice this:
Line 82: Line 82:
Setting SERIALx_PROTOCOL = 83 is '''''mandatory''''' for any of the STorM32-specific features to work. That is, also the other features below won't work without that setting.
Setting SERIALx_PROTOCOL = 83 is '''''mandatory''''' for any of the STorM32-specific features to work. That is, also the other features below won't work without that setting.


=== ArduCopter MNT_TYPE = 83 ===
=== 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:
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:
Line 88: Line 88:
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. One enhancement of the 83 mode is however that also the Mavlink MAV_MOUNT_STATUS message is emitted, so that in e.g. MissionPlaner the camera orientation can be read off. Furthermore, see the next parameters.
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. One enhancement of the 83 mode is however that also the Mavlink MAV_MOUNT_STATUS message is emitted, so that in e.g. MissionPlaner the camera orientation can be read off. Furthermore, see the next parameters.


=== ArduCopter STORM_RC_TRGT ===
=== ArduCopter: STORM Parameters ===


This is a new parameter. It allows to modify the behavior of the native STorM32 mount in the RC Targeting mode.  
BetaCopter introduces some new parameters, which are collect under the STORM header.


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 the STorM32's {{PARAMNAME|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 mode. It is also somewhat more robust against rc failsafes.
* '''STORM_RC_TRGT''': Allows to modify the behavior of the native STorM32 mount in the RC Targeting mode. <br> 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 the STorM32's {{PARAMNAME|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 mode. It is also somewhat more robust against rc failsafes.


=== ArduCopter STORM_HAS_PAN ===
* '''STORM_HAS_PAN''': Allows to set the has_pan_control flag of the native STorM32 mount to 0:false or 1:true. <br> It is not totally 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.


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.
=== STorM32: Virtual Channel Configuration = serial ===
 
It is not totally 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 {{PARAMNAME|Virtual Channel Configuration}} parameter can be set to {{PARAMVALUE|serial}}. This enables this feature:
The STorM32's {{PARAMNAME|Virtual Channel Configuration}} parameter can be set to {{PARAMVALUE|serial}}. This enables this feature:
Line 108: Line 104:
=== STorM32-Link ===
=== 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 connection is present, and thus that the crucial basis is established. From a practical perspective, you may use that field to check if the serial connection from your flight controller to the STorM32 is working.
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 the STorM32-Link is about, please see http://www.rcgroups.com/forums/showthread.php?t=2395475. In short, the STorM32-Link transmits data from the flight controller to the STorM32 controller, which allows for an improved stabilization performance such as a better horizon stability, lower yaw drift, or IMU calibration.
 
The main parts of the STorM32-Link functionality are actually not yet implemented in the STorM32, this will take some more time. However, as evidenced by STorM32-Link field going ON, the data exchange is established, which can be considered a crucial milestone.  
 
== Testing the Serial Connection ==
 
That the serial connection is working can be tested in several ways.
 
* Message box of MissonPlanner: In the message box several messages related to the STorM32 should appear. In particular, a message like "STorM32 ..." informing about the STorM32's firmware version should be visible.
 
* STorM32-Link field in the STorM32 GUI: The Dashboard and Data Display each have a field which is related to the STorM32-Link. They should display OK.

Revision as of 08:30, 6 August 2016

The STorM32 gimbal controller can communicate with an ArduPilot flight controller via a serial data line. The serial communication allows for a much richer exchange and accordingly richer set of features than possible with the traditional PWM connections. It also leads to a clean wiring.

STorM32 - ArduPilot Support

Three modes of operation are currently available:

STorM32 Mavlink

  • SERIAL_PROTOCOL = 1
  • MOUNT_TYPE = 4
  • STorM32 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.

STorM32 serial

  • SERIAL_PROTOCOL = 8
  • MOUNT_TYPE = 5 (the arducopter docu is wrong here)
  • STorM32 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 native

  • SERIAL_PROTOCOL = 83
  • MOUNT_TYPE = 83
  • STorM32 heartbeat must be deactivated, Mavlink Configuration = “no heartbeat”
  • available only in BetaCopter

The remainder of this wiki page is devoted exclusively to describing the STorM32 native mode.

Feature Matrix

Feature STorM32 Mavlink STorM32 serial STorM32 native
Gimbal Angle Control x x x
Camera Trigger x - x
MAV_MOUNT_STATUS message - x x
Video on/off - - x
Extended Gimbal Angle Control - - x
360° Gimbal with Free Look - - x
STorM32 Functions - - x
STorM32 Scripts - - x
Transmitter Passthrough - - x
STorM32-Link - - x

BetaCopter 3.4

I made some modification to ArduCopter AC3.4 (dev of 3. Aug. 2016), yielding BetaCopter. However, unless the STorM32-specific features are not activated by a "secret key" 83, BetaCopter will - to the best of my knowledge - behave exactly like the original code. This means that - to the best of my knowledge - there is no additional risk in using BetaCopter instead of ArduCopter.

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

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

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

ArduCopter: SERIALx_PROTOCOL = 83

As serial protocol you may choose 83, which activates BetaCopter's native STorM32 protocol. SERIALx_BAUD must be set to 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.

Setting SERIALx_PROTOCOL = 83 is mandatory for any of the STorM32-specific features to work. That is, also the other features below won't work without that setting.

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 get also with the other modes of operation, e.g. when using the Mavlink connection with ArduPilot. One enhancement of the 83 mode is however that also the Mavlink MAV_MOUNT_STATUS message is emitted, so that in e.g. MissionPlaner the camera orientation can be read off. Furthermore, see the next parameters.

ArduCopter: STORM Parameters

BetaCopter introduces some new parameters, which are collect under the STORM header.

  • STORM_RC_TRGT: 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 the 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 mode. It is also somewhat more robust against rc failsafes.
  • STORM_HAS_PAN: Allows to set the has_pan_control flag of the native STorM32 mount to 0:false or 1:true.
    It is not totally 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”. This enables this feature:

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, e.g. if the ArduCopter mount is activated and is in Rc Targeting mode, and a RC input control, e.g. Rc Pitch, is set to a virtual input channel, then the gimbal will move in funny ways since it receives the transmitter stick information from two different sides. In contrast, if the ArduCopter mount is in 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 the STorM32-Link is about, please see http://www.rcgroups.com/forums/showthread.php?t=2395475. In short, the STorM32-Link transmits data from the flight controller to the STorM32 controller, which allows for an improved stabilization performance such as a better horizon stability, lower yaw drift, or IMU calibration.

The main parts of the STorM32-Link functionality are actually not yet implemented in the STorM32, this will take some more time. However, as evidenced by STorM32-Link field going ON, the data exchange is established, which can be considered a crucial milestone.

Testing the Serial Connection

That the serial connection is working can be tested in several ways.

  • Message box of MissonPlanner: In the message box several messages related to the STorM32 should appear. In particular, a message like "STorM32 ..." informing about the STorM32's firmware version should be visible.
  • STorM32-Link field in the STorM32 GUI: The Dashboard and Data Display each have a field which is related to the STorM32-Link. They should display OK.
Retrieved from "http:///storm32bgc-wiki/index.php?title=Using_STorM32_with_ArduPilot&oldid=3920"