STorM32-Link: Difference between revisions

From STorM32-BGC Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
''The information on this page refers to firmware v2.35e and higher.''
''The information on this page refers to firmware v2.49e and higher.''


The STorM32-Link refers to a communication link between the STorM32 gimbal controller and a drone's flight controller, in order to achieve advanced performance which otherwise would not be possible.  
The STorM32-Link refers to a communication link between the STorM32 gimbal controller and a drone's flight controller, in order to achieve advanced performance which otherwise would not be possible.  


The primary goal of the STorM32-Link is too overcome two general and hard-to-tackle issues with 3-axis gimbals, namely the drifting of the yaw axis in the hold mode and the tilting of the horizon in high-g flight maneuvers such as high-speed turns. The respective mechanisms are called '''''Yaw Drift Compensation''''' and '''''Horizon Drift Compensation''''', and both are available for T-STorM32 gimbals since firmware v2.35e, as demonstrated by the videos below. The STorM32-Link may allow us to achieve further innovative features in the future, such as precision yaw pan modes or automatic recalibration at startup.  
The primary goal of the STorM32-Link is too overcome two general and hard-to-tackle issues with 3-axis gimbals, namely the drifting of the yaw axis in the hold mode and the tilting of the horizon in high-g flight maneuvers such as high-speed turns. The respective mechanisms are called '''''Yaw Drift Compensation''''' and '''''Horizon Drift Compensation''''', and both are available since firmware v2.35e, as demonstrated by the videos below. The STorM32-Link may allow us to achieve further innovative features in the future, such as precision yaw pan modes or automatic recalibration at startup.  


The same physical connection used for the STorM32-Link is also used for exchanging the conventional serial commands for controlling the gimbal, described in the articles [[Serial Communication]] and [[Uavcan]]. However, although the same bus is shared, this communication must not be considered part of the STorM32-Link (it's like TCP and UDP, they both share the same physical connection, but TCP is not UDP and vice versa).
The physical connection used for the STorM32-Link is also used for exchanging the conventional serial commands for controlling the gimbal, described in the article [[Serial Communication]]. However, although the same bus is shared, this communication must not be considered part of the STorM32-Link (it's like TCP and UDP, they both share the same physical connection, but TCP is not UDP and vice versa).


So, to make it clear, two aspects of the communication should be distinguished:
So, to make it clear, two aspects of the communication should be distinguished:


* '''''Control of the gimbal''''': The serial/CAN communication allows us to control the orientation of the gimbal, such as the tilt and pan of the camera, 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 ground stations, such as the actual camera orientation. Advanced operation modes such as follow me, smart shots, or object tracking, also fall into this category.
* '''''Control of the gimbal''''': The serial communication allows us to control the orientation of the gimbal, such as the tilt and pan of the camera, 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 ground stations, such as the actual camera orientation. Advanced operation modes such as follow me, smart shots, or object tracking, also fall into this category.


* '''''Improved stabilization''''': In addition, the serial/CAN communication is used to transfer dedicated data from the flight controller to the STorM32 controller, which helps it achieving better and more precise stabilization, and hence better videos. The two main features are the ''Yaw Drift Compensation'' and ''Horizon Drift Compensation'' mentioned before, but other innovative features may become possible in future.
* '''''Improved stabilization''''': In addition, the serial communication is used to transfer dedicated data from the flight controller to the STorM32 controller, which helps it achieving better and more precise stabilization, and hence better videos. The two main features are the ''Yaw Drift Compensation'' and ''Horizon Drift Compensation'' mentioned before, but other innovative features may become possible in future.


Only the second aspect of the communication makes up the STorM32-Link.
Only the second aspect of the communication makes up the STorM32-Link.
Line 17: Line 17:
The STorM32-Link support depends on the autopilot/flight-stack which is used, for details please consult [[Using STorM32 with DJI]] and [[Using STorM32 with ArduPilot]].
The STorM32-Link support depends on the autopilot/flight-stack which is used, for details please consult [[Using STorM32 with DJI]] and [[Using STorM32 with ArduPilot]].


A comment on history, and why STorM32-Link is a T-STorM32 feature: The STorM32-Link has probably the most colorful development history. Originally conceived early 2015, at a time when neither BaseCam/AlexMos nor Gremsy had such a feature, it never really took off besides being partially available since then (see [http://www.rcgroups.com/forums/showthread.php?t=2395475 STorM32-Link]). The game changed with the introduction of T-STorM32 in early 2017, since the more accurate data on the gimbal joint angles available with encoders help significantly in implementing the goals. And that's why the STorM32-Link features have been made available only for T-STorM32.
A comment on history: The STorM32-Link has a colorful development history. Originally conceived early 2015, at a time when neither BaseCam/AlexMos nor Gremsy had such a feature, it never really took off besides being partially available since then (see [http://www.rcgroups.com/forums/showthread.php?t=2395475 STorM32-Link]). The game changed with the introduction of T-STorM32 in early 2017, since the more accurate data on the gimbal joint angles available with encoders help significantly in implementing the goals. And that's why the STorM32-Link features have been made available first for only T-STorM32. With firmware version v2.49e it also was made available for conventional STorM32, besides the inherent limitations this implies.


{{#ev:youtube|l8rz78kDWNY|480}}
{{#ev:youtube|l8rz78kDWNY|480}}


{{#ev:youtube|z03PkDf0R-0|480}}
{{#ev:youtube|z03PkDf0R-0|480}}

Revision as of 18:41, 1 January 2020

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

The STorM32-Link refers to a communication link between the STorM32 gimbal controller and a drone's flight controller, in order to achieve advanced performance which otherwise would not be possible.

The primary goal of the STorM32-Link is too overcome two general and hard-to-tackle issues with 3-axis gimbals, namely the drifting of the yaw axis in the hold mode and the tilting of the horizon in high-g flight maneuvers such as high-speed turns. The respective mechanisms are called Yaw Drift Compensation and Horizon Drift Compensation, and both are available since firmware v2.35e, as demonstrated by the videos below. The STorM32-Link may allow us to achieve further innovative features in the future, such as precision yaw pan modes or automatic recalibration at startup.

The physical connection used for the STorM32-Link is also used for exchanging the conventional serial commands for controlling the gimbal, described in the article Serial Communication. However, although the same bus is shared, this communication must not be considered part of the STorM32-Link (it's like TCP and UDP, they both share the same physical connection, but TCP is not UDP and vice versa).

So, to make it clear, two aspects of the communication should be distinguished:

  • Control of the gimbal: The serial communication allows us to control the orientation of the gimbal, such as the tilt and pan of the camera, 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 ground stations, such as the actual camera orientation. Advanced operation modes such as follow me, smart shots, or object tracking, also fall into this category.
  • Improved stabilization: In addition, the serial communication is used to transfer dedicated data from the flight controller to the STorM32 controller, which helps it achieving better and more precise stabilization, and hence better videos. The two main features are the Yaw Drift Compensation and Horizon Drift Compensation mentioned before, but other innovative features may become possible in future.

Only the second aspect of the communication makes up the STorM32-Link.

The STorM32-Link support depends on the autopilot/flight-stack which is used, for details please consult Using STorM32 with DJI and Using STorM32 with ArduPilot.

A comment on history: The STorM32-Link has a colorful development history. Originally conceived early 2015, at a time when neither BaseCam/AlexMos nor Gremsy had such a feature, it never really took off besides being partially available since then (see STorM32-Link). The game changed with the introduction of T-STorM32 in early 2017, since the more accurate data on the gimbal joint angles available with encoders help significantly in implementing the goals. And that's why the STorM32-Link features have been made available first for only T-STorM32. With firmware version v2.49e it also was made available for conventional STorM32, besides the inherent limitations this implies.