STorM32-BGC Wiki V1 - User contributions [en]

Getting Started

2014-12-17T16:05:21Z

Yang: /* Flash Firmware */

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

In case above does not work, typical traps when flashing are
# The board has no power - connect the board to the computer via USB to power it.
# The pins labeled UART are used for flashing - which is wrong, the RC pins should be used
# Wrong serial port is selected in the tool

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
* Mot0: Pitch motor to point the camera up/down
* Mot1: Roll motor to stabilize the horizon
* Mot2: Yaw motor to turn the camera left/right

=== Summary ===

Motors are connected, IMU(s) are connected, battery power cable is ready and its polarity doublechecked.

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.
With the Gimbal Configuration tool this is very simple.

# Change to the {{GUI|Gimbal Configuration tab}}. There you can enter the values for the motor poles, the motor directions and the IMU orientation manually, or run the {{GUI|Configure Gimbal Tool}}. [[File:Gimbal config tool 1.png|none|300px]]
# In the welcome screen you can select what to configure, we want to do all and hence click on {{GUI|Continue}}. [[File:Gimbal config tool 2.png|none|300px]]
# Next we are asked to position the gimbal to look forward. So you manually adjust the camera so that it points into the forward direction of your copter. You might not be able to do that perfectly because of the motor magnets, 15° is more than enough. Once the camera is in forward position click on {{GUI|Continue}}. [[File:Gimbal config tool 3.png|none|300px]] [[File:Gimbal config tool forward.jpg| none | 500px]]
# Now you are asked to pitch the frame, the entire copter, by 45° downward, as if the goal would film the ground in front of the copter. So you lift the frame accordingly and both, frame and camera should point downwards. To be more precise, the camera should not move relative to the frame. If it does you should consider balancing the camera better. Anyway, the entire goal in this task is to get a clear reading of which axis of each IMU are all impacted by this 45° degree movement. The IMU does measure the accelarion values, as we are static its only acceleration is the earth gravity. For example the reading in the forward position might be x/y/z=0g/1g/0g. When pitching downward, the value could change to 0.7g/0.7g/0g and therefore we know that the pitch axis is along the z axis, its reading did not change (much). This plus the +/- sign allows to derive the IMU orientation by simply measuring it. [[File:Gimbal config tool 4a.png|none|300px]] [[File:Gimbal config tool 45.jpg| none | 500px]]
# Once the IMU orientation was read, the values are shown and we can continue with the next step. [[File:Gimbal config tool 4.png|none|300px]]
# This is just informational that the motor direction values are all being set to Auto. [[File:Gimbal config tool 5.png|none|300px]]
# Last step is the motor pole counts for each motor. This is again information you should get from the motor vendor, data like N12P14, meaning 14 poles. [[File:Gimbal config tool 6.png|none|300px]]
# With this the basic parameters are set but not stored permanently in the board. So you click on {{GUI|Okay}} to close the wizard. [[File:Gimbal config tool 7.png|none|300px]]
# The setup screen got updated now with the provided IMU, IMU2 and motor pole counts for each motor. All motors are disabled and the direction set to Auto. [[File:Gimbal config tool 8.png|none|300px]]
# In order to make these settings permanently stored, tick the checkbox next the {{GUI|Write}} button and the button will change its label to {{GUI|Write+Store}}. Press that button and the values get saved in the board's eeprom. [[File:Gimbal config tool 9.png|none|300px]]
# Attention: These values are used at startup only. Hence you have to reset the board! [[File:Gimbal config tool 10.png|none|300px]]

== First Startup ==

With above steps completed, plug in the battery in order to get power to the motors. Remember, the motor outputs had been disabled in above step. Now position the camera to look forward by hand and then enable the motors. In the {{GUI|Setup}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields, they are all set to {{GUIPARAM|disabled}}. Change them to {{GUIPARAM|normal}} individually. Or better, click on {{GUI|Enable all Motors}}), and write and store the changed setting. Without the writing the values all you did is changing the values on your computer. Without the store the changes are not saved permanently in the controller's eeprom.

The controller will now go through a sequence of steps.
settle - calibrate - level - autodir - relevel - normal

# Settle: In order to calibrate to normal, the gimbal has to be stable, it should not be moved. In a copter that is quite simple as the copter is on the ground, a handheld device needs to be put at a table to remain in one position for a few seconds.
# Calibrate: Calibrate the sensors. Take a second at max.
# Level: This is the point where the motors will be turned in order to level the camera in pitch and roll axis. Yaw motor is under power, so you feel some resistance but does not move yet.
# Autodir: Here the motors are moved slightly into one direction and based on the sensor changes the controller knows if this was an up or down etc movement and will use this as the motor directions.
# Relevel: Since autodir did move the camera, it is quickly brought back in a horizontal position.
# Normal: The is the final stage and now the gimbal is operational. Simply move the camera out of position by hand, move the frame,... whatever you do the camera should remain stable. You can pitch the camera+-90°, you can yaw the camera by +-180° or roll the camera about +-45°. More roll is not possible as then the pitch axis and the yaw axis get more and more aligned. In a roll of 90° the pitch and yaw axis would both rotate the camera.

In the past the first startup was problematic often and after lots of debugging the same root causes were identified: Motor directions, IMU orientation and occasionally the motor pole count. Therefore the Gimbal Configuration tool was implemented and hence all of these problems should be gone.
* During the level phase the gimbal does constantly move around, never finding the level position: The Pitch and Roll Motors are not connected to Mot0 (Pitch) and Mot1 (Roll) but reverse. Hence the control logic does measure that pitch has to be changed by -5°, applies the proper movement sequence to the motor but all that happens is that suddenly the roll value is off by -5°. Make sure the motors are connected correctly.
* Camera turns upside down or things like that: The IMU orientation is wrong.
* Gimbal starts shaking, makes high frequency noises and things like that: This would be normal as we have not configured the PID values for the motor control loop yet. In case that happens, set for all motors the P, I and D values to very low numbers but not zero (P=0.10; I=5.0; D=0.0050) and write them to the board. This will cause the gimbal to be slow when correcting movements but at least you can prove all is functional.

We can save some time during the startup if we would speedup the levelling and the motor directions. For this we have three options in the {{GUI|Tools}} menu.
[[File:Gimbal config motor directions.png|none|300px]]

* {{GUI|Get Current Motor Directions}}: Since the gimbal is now in a normal operation, the Autodir phase was completed, it knows the directions. By selecting this menu the motor directions in the {{GUI|Gimbal Configuration}} tab are changed from {{GUIPARAM|auto}} to their actual direction {{GUIPARAM|normal}} or {{GUIPARAM|reverse}}.
* {{GUI|Get Current Pitch and Roll Motor Positions}}: Initially the gimbal does not know the current motor position. So it powers the motor's windings to assume a default position. Now that the gimbal is level, we know the motor positions default. Hence we can take the current position as {{GUIPARAM|Pitch Startup Motor Pos}} and {{GUIPARAM|Roll Startup Motor Pos}}
* {{GUI|Adjust Yaw Startup Motor Pos Parameter Tool}}: Yaw is a different story. The current Yaw value cannot be zero'ed in as there is no sensor telling what "forward" means. Hence the motor start position is the only way but using what value? With the Yaw tool you can manually move the gimbal in yaw to bring it into the forward position and then safe that as the {{GUIPARAM|Yaw Startup Motor Pos}}.

Don't forget to {{GUI|Write+Store}} these values permanently by ticking the checkbox next to the {{GUI|Write}} button to change its label and click that button.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

Talk:Getting Started

2014-12-14T18:55:42Z

Yang:

Oh fu**. Then change the UI back to what it was.

Just kiddin'. I'll update the screenshots and text once it is out.

Was about 6 hours of work, not including the break.

Getting Started

2014-12-14T18:53:24Z

Yang:

''Comment by OlliW: Werner, great that you're working on this here!! Unfortunately, the Gimbal Configuration Toll has changed dramatically with v0.57e.
''

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
* Mot0: Pitch motor to point the camera up/down
* Mot1: Roll motor to stabilize the horizon
* Mot2: Yaw motor to turn the camera left/right

=== Summary ===

Motors are connected, IMU(s) are connected, battery power cable is ready and its polarity doublechecked.

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.
With the Gimbal Configuration tool this is very simple.

# Change to the {{GUI|Gimbal Configuration tab}}. There you can enter the values for the motor poles, the motor directions and the IMU orientation manually, or run the {{GUI|Configure Gimbal Tool}}. [[File:Gimbal config tool 1.png|none|300px]]
# In the welcome screen you can select what to configure, we want to do all and hence click on {{GUI|Continue}}. [[File:Gimbal config tool 2.png|none|300px]]
# Next we are asked to position the gimbal to look forward. So you manually adjust the camera so that it points into the forward direction of your copter. You might not be able to do that perfectly because of the motor magnets, 15° is more than enough. Once the camera is in forward position click on {{GUI|Continue}}. [[File:Gimbal config tool 3.png|none|300px]] [[File:Gimbal config tool forward.jpg| none | 500px]]
# Now you are asked to pitch the frame, the entire copter, by 45° downward, as if the goal would film the ground in front of the copter. So you lift the frame accordingly and both, frame and camera should point downwards. To be more precise, the camera should not move relative to the frame. If it does you should consider balancing the camera better. Anyway, the entire goal in this task is to get a clear reading of which axis of each IMU are all impacted by this 45° degree movement. The IMU does measure the accelarion values, as we are static its only acceleration is the earth gravity. For example the reading in the forward position might be x/y/z=0g/1g/0g. When pitching downward, the value could change to 0.7g/0.7g/0g and therefore we know that the pitch axis is along the z axis, its reading did not change (much). This plus the +/- sign allows to derive the IMU orientation by simply measuring it. [[File:Gimbal config tool 4a.png|none|300px]] [[File:Gimbal config tool 45.jpg| none | 500px]]
# Once the IMU orientation was read, the values are shown and we can continue with the next step. [[File:Gimbal config tool 4.png|none|300px]]
# This is just informational that the motor direction values are all being set to Auto. [[File:Gimbal config tool 5.png|none|300px]]
# Last step is the motor pole counts for each motor. This is again information you should get from the motor vendor, data like N12P14, meaning 14 poles. [[File:Gimbal config tool 6.png|none|300px]]
# With this the basic parameters are set but not stored permanently in the board. So you click on {{GUI|Okay}} to close the wizard. [[File:Gimbal config tool 7.png|none|300px]]
# The setup screen got updated now with the provided IMU, IMU2 and motor pole counts for each motor. All motors are disabled and the direction set to Auto. [[File:Gimbal config tool 8.png|none|300px]]
# In order to make these settings permanently stored, tick the checkbox next the {{GUI|Write}} button and the button will change its label to {{GUI|Write+Store}}. Press that button and the values get saved in the board's eeprom. [[File:Gimbal config tool 9.png|none|300px]]
# Attention: These values are used at startup only. Hence you have to reset the board! [[File:Gimbal config tool 10.png|none|300px]]

== First Startup ==

With above steps completed, plug in the battery in order to get power to the motors. Remember, the motor outputs had been disabled in above step. Now position the camera to look forward by hand and then enable the motors. In the {{GUI|Setup}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields, they are all set to {{GUIPARAM|disabled}}. Change them to {{GUIPARAM|normal}} individually. Or better, click on {{GUI|Enable all Motors}}), and write and store the changed setting. Without the writing the values all you did is changing the values on your computer. Without the store the changes are not saved permanently in the controller's eeprom.

The controller will now go through a sequence of steps.
settle - calibrate - level - autodir - relevel - normal

# Settle: In order to calibrate to normal, the gimbal has to be stable, it should not be moved. In a copter that is quite simple as the copter is on the ground, a handheld device needs to be put at a table to remain in one position for a few seconds.
# Calibrate: Calibrate the sensors. Take a second at max.
# Level: This is the point where the motors will be turned in order to level the camera in pitch and roll axis. Yaw motor is under power, so you feel some resistance but does not move yet.
# Autodir: Here the motors are moved slightly into one direction and based on the sensor changes the controller knows if this was an up or down etc movement and will use this as the motor directions.
# Relevel: Since autodir did move the camera, it is quickly brought back in a horizontal position.
# Normal: The is the final stage and now the gimbal is operational. Simply move the camera out of position by hand, move the frame,... whatever you do the camera should remain stable. You can pitch the camera+-90°, you can yaw the camera by +-180° or roll the camera about +-45°. More roll is not possible as then the pitch axis and the yaw axis get more and more aligned. In a roll of 90° the pitch and yaw axis would both rotate the camera.

In the past the first startup was problematic often and after lots of debugging the same root causes were identified: Motor directions, IMU orientation and occasionally the motor pole count. Therefore the Gimbal Configuration tool was implemented and hence all of these problems should be gone.
* During the level phase the gimbal does constantly move around, never finding the level position: The Pitch and Roll Motors are not connected to Mot0 (Pitch) and Mot1 (Roll) but reverse. Hence the control logic does measure that pitch has to be changed by -5°, applies the proper movement sequence to the motor but all that happens is that suddenly the roll value is off by -5°. Make sure the motors are connected correctly.
* Camera turns upside down or things like that: The IMU orientation is wrong.
* Gimbal starts shaking, makes high frequency noises and things like that: This would be normal as we have not configured the PID values for the motor control loop yet. In case that happens, set for all motors the P, I and D values to very low numbers but not zero (P=0.10; I=5.0; D=0.0050) and write them to the board. This will cause the gimbal to be slow when correcting movements but at least you can prove all is functional.

We can save some time during the startup if we would speedup the levelling and the motor directions. For this we have three options in the {{GUI|Tools}} menu.
[[File:Gimbal config motor directions.png|none|300px]]

* {{GUI|Get Current Motor Directions}}: Since the gimbal is now in a normal operation, the Autodir phase was completed, it knows the directions. By selecting this menu the motor directions in the {{GUI|Gimbal Configuration}} tab are changed from {{GUIPARAM|auto}} to their actual direction {{GUIPARAM|normal}} or {{GUIPARAM|reverse}}.
* {{GUI|Get Current Pitch and Roll Motor Positions}}: Initially the gimbal does not know the current motor position. So it powers the motor's windings to assume a default position. Now that the gimbal is level, we know the motor positions default. Hence we can take the current position as {{GUIPARAM|Pitch Startup Motor Pos}} and {{GUIPARAM|Roll Startup Motor Pos}}
* {{GUI|Adjust Yaw Startup Motor Pos Parameter Tool}}: Yaw is a different story. The current Yaw value cannot be zero'ed in as there is no sensor telling what "forward" means. Hence the motor start position is the only way but using what value? With the Yaw tool you can manually move the gimbal in yaw to bring it into the forward position and then safe that as the {{GUIPARAM|Yaw Startup Motor Pos}}.

Don't forget to {{GUI|Write+Store}} these values permanently by ticking the checkbox next to the {{GUI|Write}} button to change its label and click that button.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

Getting Started

2014-12-14T18:52:47Z

Yang:

''Comment by OlliW: Werner, great that you're working on this here!! Unfortunately, the Gimbal Configuration Toll has changed dramatically with v0.57e.
''

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
* Mot0: Pitch motor to point the camera up/down
* Mot1: Roll motor to stabilize the horizon
* Mot2: Yaw motor to turn the camera left/right

=== Summary ===

Motors are connected, IMU(s) are connected, battery power cable is ready and its polarity doublechecked.

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.
With the Gimbal Configuration tool this is very simple.

# Change to the {{GUI|Gimbal Configuration tab}}. There you can enter the values for the motor poles, the motor directions and the IMU orientation manually, or run the {{GUI|Configure Gimbal Tool}}. [[File:Gimbal config tool 1.png|none|300px]]
# In the welcome screen you can select what to configure, we want to do all and hence click on {{GUI|Continue}}. [[File:Gimbal config tool 2.png|none|300px]]
# Next we are asked to position the gimbal to look forward. So you manually adjust the camera so that it points into the forward direction of your copter. You might not be able to do that perfectly because of the motor magnets, 15° is more than enough. Once the camera is in forward position click on {{GUI|Continue}}. [[File:Gimbal config tool 3.png|none|300px]] [[File:Gimbal config tool forward.jpg| right | 500px]]
# Now you are asked to pitch the frame, the entire copter, by 45° downward, as if the goal would film the ground in front of the copter. So you lift the frame accordingly and both, frame and camera should point downwards. To be more precise, the camera should not move relative to the frame. If it does you should consider balancing the camera better. Anyway, the entire goal in this task is to get a clear reading of which axis of each IMU are all impacted by this 45° degree movement. The IMU does measure the accelarion values, as we are static its only acceleration is the earth gravity. For example the reading in the forward position might be x/y/z=0g/1g/0g. When pitching downward, the value could change to 0.7g/0.7g/0g and therefore we know that the pitch axis is along the z axis, its reading did not change (much). This plus the +/- sign allows to derive the IMU orientation by simply measuring it. [[File:Gimbal config tool 4a.png|none|300px]] [[File:Gimbal config tool 45.jpg| right | 500px]]
# Once the IMU orientation was read, the values are shown and we can continue with the next step. [[File:Gimbal config tool 4.png|none|300px]]
# This is just informational that the motor direction values are all being set to Auto. [[File:Gimbal config tool 5.png|none|300px]]
# Last step is the motor pole counts for each motor. This is again information you should get from the motor vendor, data like N12P14, meaning 14 poles. [[File:Gimbal config tool 6.png|none|300px]]
# With this the basic parameters are set but not stored permanently in the board. So you click on {{GUI|Okay}} to close the wizard. [[File:Gimbal config tool 7.png|none|300px]]
# The setup screen got updated now with the provided IMU, IMU2 and motor pole counts for each motor. All motors are disabled and the direction set to Auto. [[File:Gimbal config tool 8.png|none|300px]]
# In order to make these settings permanently stored, tick the checkbox next the {{GUI|Write}} button and the button will change its label to {{GUI|Write+Store}}. Press that button and the values get saved in the board's eeprom. [[File:Gimbal config tool 9.png|none|300px]]
# Attention: These values are used at startup only. Hence you have to reset the board! [[File:Gimbal config tool 10.png|none|300px]]

== First Startup ==

With above steps completed, plug in the battery in order to get power to the motors. Remember, the motor outputs had been disabled in above step. Now position the camera to look forward by hand and then enable the motors. In the {{GUI|Setup}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields, they are all set to {{GUIPARAM|disabled}}. Change them to {{GUIPARAM|normal}} individually. Or better, click on {{GUI|Enable all Motors}}), and write and store the changed setting. Without the writing the values all you did is changing the values on your computer. Without the store the changes are not saved permanently in the controller's eeprom.

The controller will now go through a sequence of steps.
settle - calibrate - level - autodir - relevel - normal

# Settle: In order to calibrate to normal, the gimbal has to be stable, it should not be moved. In a copter that is quite simple as the copter is on the ground, a handheld device needs to be put at a table to remain in one position for a few seconds.
# Calibrate: Calibrate the sensors. Take a second at max.
# Level: This is the point where the motors will be turned in order to level the camera in pitch and roll axis. Yaw motor is under power, so you feel some resistance but does not move yet.
# Autodir: Here the motors are moved slightly into one direction and based on the sensor changes the controller knows if this was an up or down etc movement and will use this as the motor directions.
# Relevel: Since autodir did move the camera, it is quickly brought back in a horizontal position.
# Normal: The is the final stage and now the gimbal is operational. Simply move the camera out of position by hand, move the frame,... whatever you do the camera should remain stable. You can pitch the camera+-90°, you can yaw the camera by +-180° or roll the camera about +-45°. More roll is not possible as then the pitch axis and the yaw axis get more and more aligned. In a roll of 90° the pitch and yaw axis would both rotate the camera.

In the past the first startup was problematic often and after lots of debugging the same root causes were identified: Motor directions, IMU orientation and occasionally the motor pole count. Therefore the Gimbal Configuration tool was implemented and hence all of these problems should be gone.
* During the level phase the gimbal does constantly move around, never finding the level position: The Pitch and Roll Motors are not connected to Mot0 (Pitch) and Mot1 (Roll) but reverse. Hence the control logic does measure that pitch has to be changed by -5°, applies the proper movement sequence to the motor but all that happens is that suddenly the roll value is off by -5°. Make sure the motors are connected correctly.
* Camera turns upside down or things like that: The IMU orientation is wrong.
* Gimbal starts shaking, makes high frequency noises and things like that: This would be normal as we have not configured the PID values for the motor control loop yet. In case that happens, set for all motors the P, I and D values to very low numbers but not zero (P=0.10; I=5.0; D=0.0050) and write them to the board. This will cause the gimbal to be slow when correcting movements but at least you can prove all is functional.

We can save some time during the startup if we would speedup the levelling and the motor directions. For this we have three options in the {{GUI|Tools}} menu.
[[File:Gimbal config motor directions.png|none|300px]]

* {{GUI|Get Current Motor Directions}}: Since the gimbal is now in a normal operation, the Autodir phase was completed, it knows the directions. By selecting this menu the motor directions in the {{GUI|Gimbal Configuration}} tab are changed from {{GUIPARAM|auto}} to their actual direction {{GUIPARAM|normal}} or {{GUIPARAM|reverse}}.
* {{GUI|Get Current Pitch and Roll Motor Positions}}: Initially the gimbal does not know the current motor position. So it powers the motor's windings to assume a default position. Now that the gimbal is level, we know the motor positions default. Hence we can take the current position as {{GUIPARAM|Pitch Startup Motor Pos}} and {{GUIPARAM|Roll Startup Motor Pos}}
* {{GUI|Adjust Yaw Startup Motor Pos Parameter Tool}}: Yaw is a different story. The current Yaw value cannot be zero'ed in as there is no sensor telling what "forward" means. Hence the motor start position is the only way but using what value? With the Yaw tool you can manually move the gimbal in yaw to bring it into the forward position and then safe that as the {{GUIPARAM|Yaw Startup Motor Pos}}.

Don't forget to {{GUI|Write+Store}} these values permanently by ticking the checkbox next to the {{GUI|Write}} button to change its label and click that button.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

Getting Started

2014-12-14T18:51:33Z

Yang:

''Comment by OlliW: Werner, great that you're working on this here!! Unfortunately, the Gimbal Configuration Toll has changed dramatically with v0.57e.
''

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
* Mot0: Pitch motor to point the camera up/down
* Mot1: Roll motor to stabilize the horizon
* Mot2: Yaw motor to turn the camera left/right

=== Summary ===

Motors are connected, IMU(s) are connected, battery power cable is ready and its polarity doublechecked.

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.
With the Gimbal Configuration tool this is very simple.

# Change to the {{GUI|Gimbal Configuration tab}}. There you can enter the values for the motor poles, the motor directions and the IMU orientation manually, or run the {{GUI|Configure Gimbal Tool}}. [[File:Gimbal config tool 1.png|none|300px]]
# In the welcome screen you can select what to configure, we want to do all and hence click on {{GUI|Continue}}. [[File:Gimbal config tool 2.png|none|300px]]
# Next we are asked to position the gimbal to look forward. So you manually adjust the camera so that it points into the forward direction of your copter. You might not be able to do that perfectly because of the motor magnets, 15° is more than enough. Once the camera is in forward position click on {{GUI|Continue}}. [[File:Gimbal config tool 3.png|none|300px]] [[File:Gimbal config tool forward.jpg]]
# Now you are asked to pitch the frame, the entire copter, by 45° downward, as if the goal would film the ground in front of the copter. So you lift the frame accordingly and both, frame and camera should point downwards. To be more precise, the camera should not move relative to the frame. If it does you should consider balancing the camera better. Anyway, the entire goal in this task is to get a clear reading of which axis of each IMU are all impacted by this 45° degree movement. The IMU does measure the accelarion values, as we are static its only acceleration is the earth gravity. For example the reading in the forward position might be x/y/z=0g/1g/0g. When pitching downward, the value could change to 0.7g/0.7g/0g and therefore we know that the pitch axis is along the z axis, its reading did not change (much). This plus the +/- sign allows to derive the IMU orientation by simply measuring it. [[File:Gimbal config tool 4a.png|none|300px]] [[File:Gimbal config tool 45.jpg]]
# Once the IMU orientation was read, the values are shown and we can continue with the next step. [[File:Gimbal config tool 4.png|none|300px]]
# This is just informational that the motor direction values are all being set to Auto. [[File:Gimbal config tool 5.png|none|300px]]
# Last step is the motor pole counts for each motor. This is again information you should get from the motor vendor, data like N12P14, meaning 14 poles. [[File:Gimbal config tool 6.png|none|300px]]
# With this the basic parameters are set but not stored permanently in the board. So you click on {{GUI|Okay}} to close the wizard. [[File:Gimbal config tool 7.png|none|300px]]
# The setup screen got updated now with the provided IMU, IMU2 and motor pole counts for each motor. All motors are disabled and the direction set to Auto. [[File:Gimbal config tool 8.png|none|300px]]
# In order to make these settings permanently stored, tick the checkbox next the {{GUI|Write}} button and the button will change its label to {{GUI|Write+Store}}. Press that button and the values get saved in the board's eeprom. [[File:Gimbal config tool 9.png|none|300px]]
# Attention: These values are used at startup only. Hence you have to reset the board! [[File:Gimbal config tool 10.png|none|300px]]

== First Startup ==

With above steps completed, plug in the battery in order to get power to the motors. Remember, the motor outputs had been disabled in above step. Now position the camera to look forward by hand and then enable the motors. In the {{GUI|Setup}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields, they are all set to {{GUIPARAM|disabled}}. Change them to {{GUIPARAM|normal}} individually. Or better, click on {{GUI|Enable all Motors}}), and write and store the changed setting. Without the writing the values all you did is changing the values on your computer. Without the store the changes are not saved permanently in the controller's eeprom.

The controller will now go through a sequence of steps.
settle - calibrate - level - autodir - relevel - normal

# Settle: In order to calibrate to normal, the gimbal has to be stable, it should not be moved. In a copter that is quite simple as the copter is on the ground, a handheld device needs to be put at a table to remain in one position for a few seconds.
# Calibrate: Calibrate the sensors. Take a second at max.
# Level: This is the point where the motors will be turned in order to level the camera in pitch and roll axis. Yaw motor is under power, so you feel some resistance but does not move yet.
# Autodir: Here the motors are moved slightly into one direction and based on the sensor changes the controller knows if this was an up or down etc movement and will use this as the motor directions.
# Relevel: Since autodir did move the camera, it is quickly brought back in a horizontal position.
# Normal: The is the final stage and now the gimbal is operational. Simply move the camera out of position by hand, move the frame,... whatever you do the camera should remain stable. You can pitch the camera+-90°, you can yaw the camera by +-180° or roll the camera about +-45°. More roll is not possible as then the pitch axis and the yaw axis get more and more aligned. In a roll of 90° the pitch and yaw axis would both rotate the camera.

In the past the first startup was problematic often and after lots of debugging the same root causes were identified: Motor directions, IMU orientation and occasionally the motor pole count. Therefore the Gimbal Configuration tool was implemented and hence all of these problems should be gone.
* During the level phase the gimbal does constantly move around, never finding the level position: The Pitch and Roll Motors are not connected to Mot0 (Pitch) and Mot1 (Roll) but reverse. Hence the control logic does measure that pitch has to be changed by -5°, applies the proper movement sequence to the motor but all that happens is that suddenly the roll value is off by -5°. Make sure the motors are connected correctly.
* Camera turns upside down or things like that: The IMU orientation is wrong.
* Gimbal starts shaking, makes high frequency noises and things like that: This would be normal as we have not configured the PID values for the motor control loop yet. In case that happens, set for all motors the P, I and D values to very low numbers but not zero (P=0.10; I=5.0; D=0.0050) and write them to the board. This will cause the gimbal to be slow when correcting movements but at least you can prove all is functional.

We can save some time during the startup if we would speedup the levelling and the motor directions. For this we have three options in the {{GUI|Tools}} menu.
[[File:Gimbal config motor directions.png|none|300px]]

* {{GUI|Get Current Motor Directions}}: Since the gimbal is now in a normal operation, the Autodir phase was completed, it knows the directions. By selecting this menu the motor directions in the {{GUI|Gimbal Configuration}} tab are changed from {{GUIPARAM|auto}} to their actual direction {{GUIPARAM|normal}} or {{GUIPARAM|reverse}}.
* {{GUI|Get Current Pitch and Roll Motor Positions}}: Initially the gimbal does not know the current motor position. So it powers the motor's windings to assume a default position. Now that the gimbal is level, we know the motor positions default. Hence we can take the current position as {{GUIPARAM|Pitch Startup Motor Pos}} and {{GUIPARAM|Roll Startup Motor Pos}}
* {{GUI|Adjust Yaw Startup Motor Pos Parameter Tool}}: Yaw is a different story. The current Yaw value cannot be zero'ed in as there is no sensor telling what "forward" means. Hence the motor start position is the only way but using what value? With the Yaw tool you can manually move the gimbal in yaw to bring it into the forward position and then safe that as the {{GUIPARAM|Yaw Startup Motor Pos}}.

Don't forget to {{GUI|Write+Store}} these values permanently by ticking the checkbox next to the {{GUI|Write}} button to change its label and click that button.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

File:Gimbal config tool 45.jpg

2014-12-14T18:50:43Z

Yang:

Getting Started

2014-12-14T18:43:54Z

Yang:

''Comment by OlliW: Werner, great that you're working on this here!! Unfortunately, the Gimbal Configuration Toll has changed dramatically with v0.57e.
''

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
* Mot0: Pitch motor to point the camera up/down
* Mot1: Roll motor to stabilize the horizon
* Mot2: Yaw motor to turn the camera left/right

=== Summary ===

Motors are connected, IMU(s) are connected, battery power cable is ready and its polarity doublechecked.

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.
With the Gimbal Configuration tool this is very simple.

# Change to the {{GUI|Gimbal Configuration tab}}. There you can enter the values for the motor poles, the motor directions and the IMU orientation manually, or run the {{GUI|Configure Gimbal Tool}}. [[File:Gimbal config tool 1.png|none|300px]]
# In the welcome screen you can select what to configure, we want to do all and hence click on {{GUI|Continue}}. [[File:Gimbal config tool 2.png|none|300px]]
# Next we are asked to position the gimbal to look forward. So you manually adjust the camera so that it points into the forward direction of your copter. You might not be able to do that perfectly because of the motor magnets, 15° is more than enough. Once the camera is in forward position click on {{GUI|Continue}}. [[File:Gimbal config tool 3.png|none|300px]] [[File:Gimbal config tool forward.jpg|none|300px]]
# Now you are asked to pitch the frame, the entire copter, by 45° downward, as if the goal would film the ground in front of the copter. So you lift the frame accordingly and both, frame and camera should point downwards. To be more precise, the camera should not move relative to the frame. If it does you should consider balancing the camera better. Anyway, the entire goal in this task is to get a clear reading of which axis of each IMU are all impacted by this 45° degree movement. The IMU does measure the accelarion values, as we are static its only acceleration is the earth gravity. For example the reading in the forward position might be x/y/z=0g/1g/0g. When pitching downward, the value could change to 0.7g/0.7g/0g and therefore we know that the pitch axis is along the z axis, its reading did not change (much). This plus the +/- sign allows to derive the IMU orientation by simply measuring it. [[File:Gimbal config tool 4a.png|none|300px]] [[File:Gimbal config tool 45.jpg|none|300px]]
# Once the IMU orientation was read, the values are shown and we can continue with the next step. [[File:Gimbal config tool 4.png|none|300px]]
# This is just informational that the motor direction values are all being set to Auto. [[File:Gimbal config tool 5.png|none|300px]]
# Last step is the motor pole counts for each motor. This is again information you should get from the motor vendor, data like N12P14, meaning 14 poles. [[File:Gimbal config tool 6.png|none|300px]]
# With this the basic parameters are set but not stored permanently in the board. So you click on {{GUI|Okay}} to close the wizard. [[File:Gimbal config tool 7.png|none|300px]]
# The setup screen got updated now with the provided IMU, IMU2 and motor pole counts for each motor. All motors are disabled and the direction set to Auto. [[File:Gimbal config tool 8.png|none|300px]]
# In order to make these settings permanently stored, tick the checkbox next the {{GUI|Write}} button and the button will change its label to {{GUI|Write+Store}}. Press that button and the values get saved in the board's eeprom. [[File:Gimbal config tool 9.png|none|300px]]
# Attention: These values are used at startup only. Hence you have to reset the board! [[File:Gimbal config tool 10.png|none|300px]]

== First Startup ==

With above steps completed, plug in the battery in order to get power to the motors. Remember, the motor outputs had been disabled in above step. Now position the camera to look forward by hand and then enable the motors. In the {{GUI|Setup}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields, they are all set to {{GUIPARAM|disabled}}. Change them to {{GUIPARAM|normal}} individually. Or better, click on {{GUI|Enable all Motors}}), and write and store the changed setting. Without the writing the values all you did is changing the values on your computer. Without the store the changes are not saved permanently in the controller's eeprom.

The controller will now go through a sequence of steps.
settle - calibrate - level - autodir - relevel - normal

# Settle: In order to calibrate to normal, the gimbal has to be stable, it should not be moved. In a copter that is quite simple as the copter is on the ground, a handheld device needs to be put at a table to remain in one position for a few seconds.
# Calibrate: Calibrate the sensors. Take a second at max.
# Level: This is the point where the motors will be turned in order to level the camera in pitch and roll axis. Yaw motor is under power, so you feel some resistance but does not move yet.
# Autodir: Here the motors are moved slightly into one direction and based on the sensor changes the controller knows if this was an up or down etc movement and will use this as the motor directions.
# Relevel: Since autodir did move the camera, it is quickly brought back in a horizontal position.
# Normal: The is the final stage and now the gimbal is operational. Simply move the camera out of position by hand, move the frame,... whatever you do the camera should remain stable. You can pitch the camera+-90°, you can yaw the camera by +-180° or roll the camera about +-45°. More roll is not possible as then the pitch axis and the yaw axis get more and more aligned. In a roll of 90° the pitch and yaw axis would both rotate the camera.

In the past the first startup was problematic often and after lots of debugging the same root causes were identified: Motor directions, IMU orientation and occasionally the motor pole count. Therefore the Gimbal Configuration tool was implemented and hence all of these problems should be gone.
* During the level phase the gimbal does constantly move around, never finding the level position: The Pitch and Roll Motors are not connected to Mot0 (Pitch) and Mot1 (Roll) but reverse. Hence the control logic does measure that pitch has to be changed by -5°, applies the proper movement sequence to the motor but all that happens is that suddenly the roll value is off by -5°. Make sure the motors are connected correctly.
* Camera turns upside down or things like that: The IMU orientation is wrong.
* Gimbal starts shaking, makes high frequency noises and things like that: This would be normal as we have not configured the PID values for the motor control loop yet. In case that happens, set for all motors the P, I and D values to very low numbers but not zero (P=0.10; I=5.0; D=0.0050) and write them to the board. This will cause the gimbal to be slow when correcting movements but at least you can prove all is functional.

We can save some time during the startup if we would speedup the levelling and the motor directions. For this we have three options in the {{GUI|Tools}} menu.
[[File:Gimbal config motor directions.png|none|300px]]

* {{GUI|Get Current Motor Directions}}: Since the gimbal is now in a normal operation, the Autodir phase was completed, it knows the directions. By selecting this menu the motor directions in the {{GUI|Gimbal Configuration}} tab are changed from {{GUIPARAM|auto}} to their actual direction {{GUIPARAM|normal}} or {{GUIPARAM|reverse}}.
* {{GUI|Get Current Pitch and Roll Motor Positions}}: Initially the gimbal does not know the current motor position. So it powers the motor's windings to assume a default position. Now that the gimbal is level, we know the motor positions default. Hence we can take the current position as {{GUIPARAM|Pitch Startup Motor Pos}} and {{GUIPARAM|Roll Startup Motor Pos}}
* {{GUI|Adjust Yaw Startup Motor Pos Parameter Tool}}: Yaw is a different story. The current Yaw value cannot be zero'ed in as there is no sensor telling what "forward" means. Hence the motor start position is the only way but using what value? With the Yaw tool you can manually move the gimbal in yaw to bring it into the forward position and then safe that as the {{GUIPARAM|Yaw Startup Motor Pos}}.

Don't forget to {{GUI|Write+Store}} these values permanently by ticking the checkbox next to the {{GUI|Write}} button to change its label and click that button.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

File:Gimbal config tool forward.jpg

2014-12-14T18:42:51Z

Yang:

Getting Started

2014-12-14T18:37:31Z

Yang:

''Comment by OlliW: Werner, great that you're working on this here!! Unfortunately, the Gimbal Configuration Toll has changed dramatically with v0.57e.
''

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
* Mot0: Pitch motor to point the camera up/down
* Mot1: Roll motor to stabilize the horizon
* Mot2: Yaw motor to turn the camera left/right

=== Summary ===

Motors are connected, IMU(s) are connected, battery power cable is ready and its polarity doublechecked.

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.
With the Gimbal Configuration tool this is very simple.

# Change to the {{GUI|Gimbal Configuration tab}}. There you can enter the values for the motor poles, the motor directions and the IMU orientation manually, or run the {{GUI|Configure Gimbal Tool}}. [[File:Gimbal config tool 1.png|none|300px]]
# In the welcome screen you can select what to configure, we want to do all and hence click on {{GUI|Continue}}. [[File:Gimbal config tool 2.png|none|300px]]
# Next we are asked to position the gimbal to look forward. So you manually adjust the camera so that it points into the forward direction of your copter. You might not be able to do that perfectly because of the motor magnets, 15° is more than enough. Once the camera is in forward position click on {{GUI|Continue}}. [[File:Gimbal config tool 3.png|none|300px]] [[File:|none|300px]]
# Now you are asked to pitch the frame, the entire copter, by 45° downward, as if the goal would film the ground in front of the copter. So you lift the frame accordingly and both, frame and camera should point downwards. To be more precise, the camera should not move relative to the frame. If it does you should consider balancing the camera better. Anyway, the entire goal in this task is to get a clear reading of which axis of each IMU are all impacted by this 45° degree movement. The IMU does measure the accelarion values, as we are static its only acceleration is the earth gravity. For example the reading in the forward position might be x/y/z=0g/1g/0g. When pitching downward, the value could change to 0.7g/0.7g/0g and therefore we know that the pitch axis is along the z axis, its reading did not change (much). This plus the +/- sign allows to derive the IMU orientation by simply measuring it. [[File:Gimbal config tool 4a.png|none|300px]] [[File:|none|300px]]
# Once the IMU orientation was read, the values are shown and we can continue with the next step. [[File:Gimbal config tool 4.png|none|300px]]
# This is just informational that the motor direction values are all being set to Auto. [[File:Gimbal config tool 5.png|none|300px]]
# Last step is the motor pole counts for each motor. This is again information you should get from the motor vendor, data like N12P14, meaning 14 poles. [[File:Gimbal config tool 6.png|none|300px]]
# With this the basic parameters are set but not stored permanently in the board. So you click on {{GUI|Okay}} to close the wizard. [[File:Gimbal config tool 7.png|none|300px]]
# The setup screen got updated now with the provided IMU, IMU2 and motor pole counts for each motor. All motors are disabled and the direction set to Auto. [[File:Gimbal config tool 8.png|none|300px]]
# In order to make these settings permanently stored, tick the checkbox next the {{GUI|Write}} button and the button will change its label to {{GUI|Write+Store}}. Press that button and the values get saved in the board's eeprom. [[File:Gimbal config tool 9.png|none|300px]]
# Attention: These values are used at startup only. Hence you have to reset the board! [[File:Gimbal config tool 10.png|none|300px]]

== First Startup ==

With above steps completed, plug in the battery in order to get power to the motors. Remember, the motor outputs had been disabled in above step. Now position the camera to look forward by hand and then enable the motors. In the {{GUI|Setup}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields, they are all set to {{GUIPARAM|disabled}}. Change them to {{GUIPARAM|normal}} individually. Or better, click on {{GUI|Enable all Motors}}), and write and store the changed setting. Without the writing the values all you did is changing the values on your computer. Without the store the changes are not saved permanently in the controller's eeprom.

The controller will now go through a sequence of steps.
settle - calibrate - level - autodir - relevel - normal

# Settle: In order to calibrate to normal, the gimbal has to be stable, it should not be moved. In a copter that is quite simple as the copter is on the ground, a handheld device needs to be put at a table to remain in one position for a few seconds.
# Calibrate: Calibrate the sensors. Take a second at max.
# Level: This is the point where the motors will be turned in order to level the camera in pitch and roll axis. Yaw motor is under power, so you feel some resistance but does not move yet.
# Autodir: Here the motors are moved slightly into one direction and based on the sensor changes the controller knows if this was an up or down etc movement and will use this as the motor directions.
# Relevel: Since autodir did move the camera, it is quickly brought back in a horizontal position.
# Normal: The is the final stage and now the gimbal is operational. Simply move the camera out of position by hand, move the frame,... whatever you do the camera should remain stable. You can pitch the camera+-90°, you can yaw the camera by +-180° or roll the camera about +-45°. More roll is not possible as then the pitch axis and the yaw axis get more and more aligned. In a roll of 90° the pitch and yaw axis would both rotate the camera.

In the past the first startup was problematic often and after lots of debugging the same root causes were identified: Motor directions, IMU orientation and occasionally the motor pole count. Therefore the Gimbal Configuration tool was implemented and hence all of these problems should be gone.
* During the level phase the gimbal does constantly move around, never finding the level position: The Pitch and Roll Motors are not connected to Mot0 (Pitch) and Mot1 (Roll) but reverse. Hence the control logic does measure that pitch has to be changed by -5°, applies the proper movement sequence to the motor but all that happens is that suddenly the roll value is off by -5°. Make sure the motors are connected correctly.
* Camera turns upside down or things like that: The IMU orientation is wrong.
* Gimbal starts shaking, makes high frequency noises and things like that: This would be normal as we have not configured the PID values for the motor control loop yet. In case that happens, set for all motors the P, I and D values to very low numbers but not zero (P=0.10; I=5.0; D=0.0050) and write them to the board. This will cause the gimbal to be slow when correcting movements but at least you can prove all is functional.

We can save some time during the startup if we would speedup the levelling and the motor directions. For this we have three options in the {{GUI|Tools}} menu.
[[File:Gimbal config motor directions.png|none|300px]]

* {{GUI|Get Current Motor Directions}}: Since the gimbal is now in a normal operation, the Autodir phase was completed, it knows the directions. By selecting this menu the motor directions in the {{GUI|Gimbal Configuration}} tab are changed from {{GUIPARAM|auto}} to their actual direction {{GUIPARAM|normal}} or {{GUIPARAM|reverse}}.
* {{GUI|Get Current Pitch and Roll Motor Positions}}: Initially the gimbal does not know the current motor position. So it powers the motor's windings to assume a default position. Now that the gimbal is level, we know the motor positions default. Hence we can take the current position as {{GUIPARAM|Pitch Startup Motor Pos}} and {{GUIPARAM|Roll Startup Motor Pos}}
* {{GUI|Adjust Yaw Startup Motor Pos Parameter Tool}}: Yaw is a different story. The current Yaw value cannot be zero'ed in as there is no sensor telling what "forward" means. Hence the motor start position is the only way but using what value? With the Yaw tool you can manually move the gimbal in yaw to bring it into the forward position and then safe that as the {{GUIPARAM|Yaw Startup Motor Pos}}.

Don't forget to {{GUI|Write+Store}} these values permanently by ticking the checkbox next to the {{GUI|Write}} button to change its label and click that button.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

File:Gimbal config motor directions.png

2014-12-14T18:22:29Z

Yang:

File:Gimbal config tool 9.png

2014-12-14T17:33:06Z

Yang:

File:Gimbal config tool 8.png

2014-12-14T17:31:32Z

Yang:

Getting Started

2014-12-14T13:20:04Z

Yang:

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
* Mot0: Pitch motor to point the camera up/down
* Mot1: Roll motor to stabilize the horizon
* Mot2: Yaw motor to turn the camera left/right

=== Summary ===

Motors are connected, IMU(s) are connected, battery power cable is ready and its polarity doublechecked.

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.
With the Gimbal Configuration tool this is very simple.

# Change to the {{GUI|Gimbal Configuration tab}}. There you can enter the values for the motor poles, the motor directions and the IMU orientation manually, or run the {{GUI|Configure Gimbal Tool}}. [[File:Gimbal config tool 1.png|none|300px]]
# In the welcome screen you can select what to configure, we want to do all and hence click on {{GUI|Continue}}. [[File:Gimbal config tool 2.png|none|300px]]
# Next we are asked to position the gimbal to look forward. So you manually adjust the camera so that it points into the forward direction of your copter. You might not be able to do that perfectly because of the motor magnets, 15° is more than enough. Once the camera is in forward position click on {{GUI|Continue}}. [[File:Gimbal config tool 3.png|none|300px]] [[File:|none|300px]]
# Now you are asked to pitch the frame, the entire copter, by 45° downward, as if the goal would film the ground in front of the copter. So you lift the frame accordingly and both, frame and camera should point downwards. To be more precise, the camera should not move relative to the frame. If it does you should consider balancing the camera better. Anyway, the entire goal in this task is to get a clear reading of which axis of each IMU are all impacted by this 45° degree movement. The IMU does measure the accelarion values, as we are static its only acceleration is the earth gravity. For example the reading in the forward position might be x/y/z=0g/1g/0g. When pitching downward, the value could change to 0.7g/0.7g/0g and therefore we know that the pitch axis is along the z axis, its reading did not change (much). This plus the +/- sign allows to derive the IMU orientation by simply measuring it. [[File:Gimbal config tool 4a.png|none|300px]] [[File:|none|300px]]
# Once the IMU orientation was read, the values are shown and we can continue with the next step. [[File:Gimbal config tool 4.png|none|300px]]
# This is just informational that the motor direction values are all being set to Auto. [[File:Gimbal config tool 5.png|none|300px]]
# Last step is the motor pole counts for each motor. [[File:Gimbal config tool 6.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:Gimbal config tool 1.png|none|300px]]
[[File:|none|300px]]

The tab called {{GUI|Configure IMU}} is meant to support you in setting up the IMU orientation. There are so many different ways in which you can attach the IMU to your camera (above the camera, below, at the backside, with the axis up, down, left, right, and so on) but the controller does not know. Hence you have to tell.

'''It is of outmost importance to set the IMU orientation correctly, else the controller has no chance to work correctly. Please double and triple check that you got the IMU stetting right!'''

=== Determining the IMU Orientation ===
The first thing is to ensure that all motors are shut off to avoid any motor movements. Then investigate the IMU board, there is usually an arrow printed on it for the x axis. If not, you may use the little dot marker on the IMU chip as reference (see the [[Getting_Started#Appendix|Appendix]] below). Now hold the gimbal and camera in front of you, as if you would be taking a picture. {{GUIPARAM|Up}} refers to the top of the camera, {{GUIPARAM|forward}} to its front with the lense, and {{GUIPARAM|right}} to the right-hand side of the camera. The questions to answer in the IMU orientation dialog are where the z axis and x arrow point to.

The IMU's z axis points outwards of the surface of the IMU chip, i.e., comes straight out of the IMU board. In the example below, as the IMU board is mounted upside down, it points downwards the camera, so you specify the {{GUI|z axis points}} {{GUIPARAM|down}}. For the x axis we use the printed arrow on the IMU board. In the example below it is pointing in the camera's forward (shooting) direction, hence in the GUI you set that the {{GUI|x axis points}} {{GUIPARAM|forward}}. The little graphic on the right displays your setting, i.e., the IMU's x-y-z axes with respect to the camera's up-right-forward orientations.

To send these setting to the board click on the {{GUI|Write}} button. In order to make the changes permanent, the menu option {{GUI|Store to EEPROM}} can be used. Alternatively, click on the check box next to the {{GUI|Write}} button, which causes the button label to change to {{GUI|Write+Store}}, and hit the button. Both methods are fine.

Please note that the {{GUI|Configure IMU}} page is for your support only. Its sole purpose is to help you determining the IMU orientation index, here no. 15, and writing it into the {{GUI|Imu Orientation}} parameter field located on the {{GUI|Gimbal Setup}} tab.

{{COMMENT|In older firmware versions (v0.27 and lower) the meaning of {{GUIPARAM|right}} and {{GUIPARAM|left}} is reversed. The orientation index number however has not changed.}}

[[File:6configureimu.png|480px]]

[[File:3imuorientation.JPG|480px]]

=== Checking the IMU Orientation ===
In order to ensure a correct IMU Orientation you should test it. Write the setting to the controller (temporarily or into the EEPROM) and then click on the {{GUI|Data Display}} button. This will open a realtime monitor window. In the top you can see the current Pitch, Roll, and Yaw angles once you did click on {{GUI|Start}} in the window.

As the motors are (hopefully) disabled still, you can move the camera by hand. The following behavior must be observed:
* When you tilt the camera downwards (lens points to the ground), the Pitch value has to get more positive (the red line in the middle panel of the Data Display has to move upwards).
* When you roll the camera like in flying a right turn (clockwise when standing behind the camera), the Roll value has to get more positive (the green line in the middle panel of the Data Display has to move upwards).
* When you rotate the camera around the yaw axis anti-clock wise, the Yaw value hast to get more positive (the blue line in the middle panel of the Data Display has to move upwards).

If you do not observe that, then go back and repeat the IMU orientation setting.

[[File:9datadisplay.png|480px]]

=== Appendix ===
In case your IMU board has no arrow printed on it or you are uncertain then you can use the white dot in one of the corners on the IMU chip (MPU6050) as well for the orientation. In the diagram below the axes and their orientation in relationship to the dot are shown.

As said before, the z axis comes out of the top surface of the chip and the x axis points away from the dot. Check the chip labels, the x axis runs in the reading direction of the labeling.

The diagram below provides some examples of the IMU orientation.

[[File:5IMUorientation.JPG|600px]]

== Motor Settings ==

''the procedure is still valid, but an easier procedure is available in v0.56''

For the motor settings there is a separate tab as well, the {{GUI|Configure Motors}} tab. Again, ensure that the motors are disengaged.

In the example below the Mot0 port on the controller is connected to the Pitch motor, which lets the camera look up or down. Mot1 is connected to the Roll motor, which keeps the horizon level. Remember, Mot2 has to be used for Yaw always.

The motor poles are best read from the motor's datasheets found in the internet. A common value is 14 poles for smaller motors. Large motors may have 22 poles or even more. Self-wound motors often have 12 poles.

The last setting of importance is the motor direction. However, the STorM32 controller provides you an {{GUIPARAM|auto}} setting, which is recommended to be used. With {{GUIPARAM|auto}} the initialization phase of the gimbal takes few seconds longer - who cares (you can avoid that later if you like).

With these few steps the most important fields in the {{GUI|Gimbal Setup}} tab are properly set, and you are ready to go!

[[File:7configuremotors.png|480px]]

== First Startup ==

Once you have completed the above steps, the motors can be turned on. In the {{GUI|Expert}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields are all set to {{GUIPARAM|normal}} (the default is {{GUIPARAM|disabled}}). If not, set them to "normal" (or click on {{GUI|Enable all Motors}}), and write and store the changed setting.

{{COMMENT|If you are using the STorM32-BGC for a 2 axis gimbal, set {{GUI|Yaw Usage}} to {{GUIPARAM|disabled}} (and maybe set {{GUI|Yaw P}}, {{GUI|Yaw I}}, and {{GUI|Yaw D}} to zero).}}

Now connect a battery to the controller (it is assumed that you did follow the above advice of powering the board via USB). The gimbal should go through a number of initialization steps (the green led blinks, with increasing frequency), and finally should start with normal operation (the green led goes solid).

{{COMMENT|During the initialization the gimbal needs to be at rest.}}

In short, after power up keep the gimbal at rest until the green led goes solid. Holding the gimbal e.g. in the hands is not keeping it at rest.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

File:Gimbal config tool 7.png

2014-12-14T13:18:30Z

Yang:

File:Gimbal config tool 6.png

2014-12-14T13:17:44Z

Yang:

File:Gimbal config tool 5.png

2014-12-14T13:16:49Z

Yang:

File:Gimbal config tool 4a.png

2014-12-14T13:02:03Z

Yang:

File:Gimbal config tool 4.png

2014-12-14T12:59:19Z

Yang:

File:Gimbal config tool 3.png

2014-12-14T12:54:30Z

Yang:

File:Gimbal config tool 2.png

2014-12-14T12:53:04Z

Yang:

File:Gimbal config tool 1.png

2014-12-14T12:49:18Z

Yang:

Getting Started

2014-12-14T12:43:51Z

Yang:

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]

On the backside of the board is a I2C#2 connector for the optional frame IMU.

One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna. Which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
Mot0: Pitch motor to point the camera up/down
Mot1: Roll motor to stabilize the horizon
Mot2: Yaw motor to turn the camera left/right

[[File:0connections.JPG|none|480px]]

== First Configuration ==

The last steps in the firmware flashing section had been to check if the StorM32-BGC is operational.
* Disconnect the USB cable and click on the com port selector at the very bottom. Remember the list. [[File:Board read 0.png|none|300px]]
* Plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
* Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

Now it's time to set the most important parameters, namely the IMU orientations and motor parameter values. Without that the controller can't perform the basic operations even.

'''For the following the motors should NOT be operational.''' This can be achieved in various ways, for example by physically disconnecting all motors, or using the {{GUI|Disable all Motors}} buttons in the configuration tabs. The easiest and recommended way is however to power the board via USB only, i.e. to not connect a battery to it (when the board is powered by USB only the motors are shut off and won't work).

[[File:1main.png|480px]]

== IMU Orientation ==

''the procedure is still valid, but a better and much easier procedure is available in v0.56''

The tab called {{GUI|Configure IMU}} is meant to support you in setting up the IMU orientation. There are so many different ways in which you can attach the IMU to your camera (above the camera, below, at the backside, with the axis up, down, left, right, and so on) but the controller does not know. Hence you have to tell.

'''It is of outmost importance to set the IMU orientation correctly, else the controller has no chance to work correctly. Please double and triple check that you got the IMU stetting right!'''

=== Determining the IMU Orientation ===
The first thing is to ensure that all motors are shut off to avoid any motor movements. Then investigate the IMU board, there is usually an arrow printed on it for the x axis. If not, you may use the little dot marker on the IMU chip as reference (see the [[Getting_Started#Appendix|Appendix]] below). Now hold the gimbal and camera in front of you, as if you would be taking a picture. {{GUIPARAM|Up}} refers to the top of the camera, {{GUIPARAM|forward}} to its front with the lense, and {{GUIPARAM|right}} to the right-hand side of the camera. The questions to answer in the IMU orientation dialog are where the z axis and x arrow point to.

The IMU's z axis points outwards of the surface of the IMU chip, i.e., comes straight out of the IMU board. In the example below, as the IMU board is mounted upside down, it points downwards the camera, so you specify the {{GUI|z axis points}} {{GUIPARAM|down}}. For the x axis we use the printed arrow on the IMU board. In the example below it is pointing in the camera's forward (shooting) direction, hence in the GUI you set that the {{GUI|x axis points}} {{GUIPARAM|forward}}. The little graphic on the right displays your setting, i.e., the IMU's x-y-z axes with respect to the camera's up-right-forward orientations.

To send these setting to the board click on the {{GUI|Write}} button. In order to make the changes permanent, the menu option {{GUI|Store to EEPROM}} can be used. Alternatively, click on the check box next to the {{GUI|Write}} button, which causes the button label to change to {{GUI|Write+Store}}, and hit the button. Both methods are fine.

Please note that the {{GUI|Configure IMU}} page is for your support only. Its sole purpose is to help you determining the IMU orientation index, here no. 15, and writing it into the {{GUI|Imu Orientation}} parameter field located on the {{GUI|Gimbal Setup}} tab.

{{COMMENT|In older firmware versions (v0.27 and lower) the meaning of {{GUIPARAM|right}} and {{GUIPARAM|left}} is reversed. The orientation index number however has not changed.}}

[[File:6configureimu.png|480px]]

[[File:3imuorientation.JPG|480px]]

=== Checking the IMU Orientation ===
In order to ensure a correct IMU Orientation you should test it. Write the setting to the controller (temporarily or into the EEPROM) and then click on the {{GUI|Data Display}} button. This will open a realtime monitor window. In the top you can see the current Pitch, Roll, and Yaw angles once you did click on {{GUI|Start}} in the window.

As the motors are (hopefully) disabled still, you can move the camera by hand. The following behavior must be observed:
* When you tilt the camera downwards (lens points to the ground), the Pitch value has to get more positive (the red line in the middle panel of the Data Display has to move upwards).
* When you roll the camera like in flying a right turn (clockwise when standing behind the camera), the Roll value has to get more positive (the green line in the middle panel of the Data Display has to move upwards).
* When you rotate the camera around the yaw axis anti-clock wise, the Yaw value hast to get more positive (the blue line in the middle panel of the Data Display has to move upwards).

If you do not observe that, then go back and repeat the IMU orientation setting.

[[File:9datadisplay.png|480px]]

=== Appendix ===
In case your IMU board has no arrow printed on it or you are uncertain then you can use the white dot in one of the corners on the IMU chip (MPU6050) as well for the orientation. In the diagram below the axes and their orientation in relationship to the dot are shown.

As said before, the z axis comes out of the top surface of the chip and the x axis points away from the dot. Check the chip labels, the x axis runs in the reading direction of the labeling.

The diagram below provides some examples of the IMU orientation.

[[File:5IMUorientation.JPG|600px]]

== Motor Settings ==

''the procedure is still valid, but an easier procedure is available in v0.56''

For the motor settings there is a separate tab as well, the {{GUI|Configure Motors}} tab. Again, ensure that the motors are disengaged.

In the example below the Mot0 port on the controller is connected to the Pitch motor, which lets the camera look up or down. Mot1 is connected to the Roll motor, which keeps the horizon level. Remember, Mot2 has to be used for Yaw always.

The motor poles are best read from the motor's datasheets found in the internet. A common value is 14 poles for smaller motors. Large motors may have 22 poles or even more. Self-wound motors often have 12 poles.

The last setting of importance is the motor direction. However, the STorM32 controller provides you an {{GUIPARAM|auto}} setting, which is recommended to be used. With {{GUIPARAM|auto}} the initialization phase of the gimbal takes few seconds longer - who cares (you can avoid that later if you like).

With these few steps the most important fields in the {{GUI|Gimbal Setup}} tab are properly set, and you are ready to go!

[[File:7configuremotors.png|480px]]

== First Startup ==

Once you have completed the above steps, the motors can be turned on. In the {{GUI|Expert}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields are all set to {{GUIPARAM|normal}} (the default is {{GUIPARAM|disabled}}). If not, set them to "normal" (or click on {{GUI|Enable all Motors}}), and write and store the changed setting.

{{COMMENT|If you are using the STorM32-BGC for a 2 axis gimbal, set {{GUI|Yaw Usage}} to {{GUIPARAM|disabled}} (and maybe set {{GUI|Yaw P}}, {{GUI|Yaw I}}, and {{GUI|Yaw D}} to zero).}}

Now connect a battery to the controller (it is assumed that you did follow the above advice of powering the board via USB). The gimbal should go through a number of initialization steps (the green led blinks, with increasing frequency), and finally should start with normal operation (the green led goes solid).

{{COMMENT|During the initialization the gimbal needs to be at rest.}}

In short, after power up keep the gimbal at rest until the green led goes solid. Holding the gimbal e.g. in the hands is not keeping it at rest.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

Getting Started

2014-12-14T12:17:27Z

Yang:

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg|none|300px]]
And on the other side of the board is a I2C#2 connector for the optional frame IMU.
One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna, which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
Mot0: Pitch motor to point the camera up/down
Mot1: Roll motor to stabilize the horizon
Mot2: Yaw motor to turn the camera left/right

[[File:0connections.JPG|none|480px]]

== First Configuration ==

It is assumed that a firmware was uploaded to the controller before (for uploading firmware see [[How to flash firmware]]). At the first-time connection of the controller to the computer via USB, Windows will search for the USB driver and install it. This can take several minutes; it is important to wait until Windows reports that the device is ready for use. With the controller connected to USB, you won't see much happening except the two LEDs blinking with various frequencies; the gimbal can be moved freely as no power is applied to the motors (remember: no battery connected yet!).

Now start the GUI executable matching the controller's firmware version and select the COM port assigned to the USB device in the {{GUI|Port}} dropdown box at the bottom left. If you are unsure about the correct COM port, then unplug the USB cable, click on the dropdown icon of the field to open the full list of available COM ports and memorize that list. Plug in the USB cable again, and open the list again. The required COM port is the additional one.

Once the proper COM port is selected, the first thing is to hit the {{GUI|Read}} button. If everything is in order, the GUI will read the currently stored settings from the controller. In the message box at the bottom you will see some status messages and a final "Read...DONE!" text.

Now it's time to set the most important parameters, namely the IMU orientation and motor parameter values. Without that the controller can't perform even the basic operations.

'''For the following the motors should NOT be operational.''' This can be achieved in various ways, for example by physically disconnecting all motors, or using the {{GUI|Disable all Motors}} buttons in the configuration tabs. The easiest and recommended way is however to power the board via USB only, i.e. to not connect a battery to it (when the board is powered by USB only the motors are shut off and won't work).

[[File:1main.png|480px]]

== IMU Orientation ==

''the procedure is still valid, but a better and much easier procedure is available in v0.56''

The tab called {{GUI|Configure IMU}} is meant to support you in setting up the IMU orientation. There are so many different ways in which you can attach the IMU to your camera (above the camera, below, at the backside, with the axis up, down, left, right, and so on) but the controller does not know. Hence you have to tell.

'''It is of outmost importance to set the IMU orientation correctly, else the controller has no chance to work correctly. Please double and triple check that you got the IMU stetting right!'''

=== Determining the IMU Orientation ===
The first thing is to ensure that all motors are shut off to avoid any motor movements. Then investigate the IMU board, there is usually an arrow printed on it for the x axis. If not, you may use the little dot marker on the IMU chip as reference (see the [[Getting_Started#Appendix|Appendix]] below). Now hold the gimbal and camera in front of you, as if you would be taking a picture. {{GUIPARAM|Up}} refers to the top of the camera, {{GUIPARAM|forward}} to its front with the lense, and {{GUIPARAM|right}} to the right-hand side of the camera. The questions to answer in the IMU orientation dialog are where the z axis and x arrow point to.

The IMU's z axis points outwards of the surface of the IMU chip, i.e., comes straight out of the IMU board. In the example below, as the IMU board is mounted upside down, it points downwards the camera, so you specify the {{GUI|z axis points}} {{GUIPARAM|down}}. For the x axis we use the printed arrow on the IMU board. In the example below it is pointing in the camera's forward (shooting) direction, hence in the GUI you set that the {{GUI|x axis points}} {{GUIPARAM|forward}}. The little graphic on the right displays your setting, i.e., the IMU's x-y-z axes with respect to the camera's up-right-forward orientations.

To send these setting to the board click on the {{GUI|Write}} button. In order to make the changes permanent, the menu option {{GUI|Store to EEPROM}} can be used. Alternatively, click on the check box next to the {{GUI|Write}} button, which causes the button label to change to {{GUI|Write+Store}}, and hit the button. Both methods are fine.

Please note that the {{GUI|Configure IMU}} page is for your support only. Its sole purpose is to help you determining the IMU orientation index, here no. 15, and writing it into the {{GUI|Imu Orientation}} parameter field located on the {{GUI|Gimbal Setup}} tab.

{{COMMENT|In older firmware versions (v0.27 and lower) the meaning of {{GUIPARAM|right}} and {{GUIPARAM|left}} is reversed. The orientation index number however has not changed.}}

[[File:6configureimu.png|480px]]

[[File:3imuorientation.JPG|480px]]

=== Checking the IMU Orientation ===
In order to ensure a correct IMU Orientation you should test it. Write the setting to the controller (temporarily or into the EEPROM) and then click on the {{GUI|Data Display}} button. This will open a realtime monitor window. In the top you can see the current Pitch, Roll, and Yaw angles once you did click on {{GUI|Start}} in the window.

As the motors are (hopefully) disabled still, you can move the camera by hand. The following behavior must be observed:
* When you tilt the camera downwards (lens points to the ground), the Pitch value has to get more positive (the red line in the middle panel of the Data Display has to move upwards).
* When you roll the camera like in flying a right turn (clockwise when standing behind the camera), the Roll value has to get more positive (the green line in the middle panel of the Data Display has to move upwards).
* When you rotate the camera around the yaw axis anti-clock wise, the Yaw value hast to get more positive (the blue line in the middle panel of the Data Display has to move upwards).

If you do not observe that, then go back and repeat the IMU orientation setting.

[[File:9datadisplay.png|480px]]

=== Appendix ===
In case your IMU board has no arrow printed on it or you are uncertain then you can use the white dot in one of the corners on the IMU chip (MPU6050) as well for the orientation. In the diagram below the axes and their orientation in relationship to the dot are shown.

As said before, the z axis comes out of the top surface of the chip and the x axis points away from the dot. Check the chip labels, the x axis runs in the reading direction of the labeling.

The diagram below provides some examples of the IMU orientation.

[[File:5IMUorientation.JPG|600px]]

== Motor Settings ==

''the procedure is still valid, but an easier procedure is available in v0.56''

For the motor settings there is a separate tab as well, the {{GUI|Configure Motors}} tab. Again, ensure that the motors are disengaged.

In the example below the Mot0 port on the controller is connected to the Pitch motor, which lets the camera look up or down. Mot1 is connected to the Roll motor, which keeps the horizon level. Remember, Mot2 has to be used for Yaw always.

The motor poles are best read from the motor's datasheets found in the internet. A common value is 14 poles for smaller motors. Large motors may have 22 poles or even more. Self-wound motors often have 12 poles.

The last setting of importance is the motor direction. However, the STorM32 controller provides you an {{GUIPARAM|auto}} setting, which is recommended to be used. With {{GUIPARAM|auto}} the initialization phase of the gimbal takes few seconds longer - who cares (you can avoid that later if you like).

With these few steps the most important fields in the {{GUI|Gimbal Setup}} tab are properly set, and you are ready to go!

[[File:7configuremotors.png|480px]]

== First Startup ==

Once you have completed the above steps, the motors can be turned on. In the {{GUI|Expert}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields are all set to {{GUIPARAM|normal}} (the default is {{GUIPARAM|disabled}}). If not, set them to "normal" (or click on {{GUI|Enable all Motors}}), and write and store the changed setting.

{{COMMENT|If you are using the STorM32-BGC for a 2 axis gimbal, set {{GUI|Yaw Usage}} to {{GUIPARAM|disabled}} (and maybe set {{GUI|Yaw P}}, {{GUI|Yaw I}}, and {{GUI|Yaw D}} to zero).}}

Now connect a battery to the controller (it is assumed that you did follow the above advice of powering the board via USB). The gimbal should go through a number of initialization steps (the green led blinks, with increasing frequency), and finally should start with normal operation (the green led goes solid).

{{COMMENT|During the initialization the gimbal needs to be at rest.}}

In short, after power up keep the gimbal at rest until the green led goes solid. Holding the gimbal e.g. in the hands is not keeping it at rest.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

Getting Started

2014-12-14T12:14:23Z

Yang:

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938|STM download page].

== Hardware setup ==

=== The camera IMU ===

This IMU is to be mounted in a way so that it does measure all camera movements. Its actual position does not matter, behind the camera, on the pitch arm below the camera,... anything will work. The only thing to watch out for is that its axis are aligned with the camera axis. Each axis has to be either horizontal or vertical. Just imagine, the sensor would read that the horizon is level but because of an misalignment the camera does hang slightly to one side and hence the horizon in the video is not level.

=== Mounting the StorM board ===

One of the outstanding features of the StorM board is its 2nd IMU support. In fact the board has such IMU itself already and to make use of it, the board should hence be mounted on the copter frame. The direction does not matter as long as it is the frame. In case this is not possible, either the 2nd IMU support has to be disabled or another external IMU is mounted to the frame and connected to the frame I2C connector.
Again, the IMU axis have to be either vertical or horizontal.

=== Electric connection and insulation ===

All the IMUs go to their corresponding I2C plug, that is the I2C labeled Picoblade connector next to the USB connector for the camera IMU.
[[File:Stom32-bgc-v130-ports-and-connections-01.jpg]]
And on the other side of the board is a I2C#2 connector for the optional frame IMU.
One thing we found out the hard way is to never mount the board or the IMUs with metal screws and distance sleeves, always use plastic ones. Not only does that enhance the probability of survival in case of an electric defect but also the I2C bus might use the entire metal frame and motors as antenna, which leads to massive amounts of errors on the I2C bus. And without constant readings of the IMU positions the entire purpose of the gimbal is forfeit.
Make sure the IMUs are mounted rigidly also so they measure the actual position.

=== Gimbal mechanics ===

Before using the gimbal, it is absolutely necessary to balance it and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any improper balance or resistance to rotation will make setting up the gimbal more difficult or even impossible. The goal shall be to rotate the camera in the gimbal and it should stay in that position by itself. In other words, the center of gravity should be in the center of all gimbal motor axis. Just imagine the camera's center of gravity is way below the pitch axis (looking with the camera up and down). It would act like a pendulum. So just because your copter does accelerate forward, the gimbal pitch motor has to hold against the mass inertia. You will need very strong motors and lots of energy which is a waste. On the other hand, if the gimbal is balanced properly, all the motor has to compensate is copter rotations, wind resistance and inertia when rotating the camera to point to somewhere else.

=== Powering the Gimbal ===

For the motors the 5V supply of the USB bus is not enough for sure. So the motors will work only if the battery connector provides the power. That is the reason why e.g. flashing the firmware is done via USB power only as we do not want to motors to get power at that time. The battery connector can handle any voltage from 6V to 18V. Connecting the PC via the USB cable while the board is powered via a battery is no problem at all. The order does not matter, first USB then battery or reverse, both will work.

=== Motor connector ===

The board has three connectors for the motors labeled Mot0 to Mot2. Before connecting any motor, it might be a good idea to measure the resistance of the motor windings and the motor frame. The three motor cables should have an electrical resistance of 12 Ohm or more and completely isolated from the motor housing. If the resistance is too low, the amount of amps flowing through the motor might be too high for the board driver to handle. And if one of the motor cables is connected to the motor housing, the entire gimbal and maybe even the frame gets the motor voltage.
The usage of the three connectors is
Mot0: Pitch motor to point the camera up/down
Mot1: Roll motor to stabilize the horizon
Mot2: Yaw motor to turn the camera left/right

The pins on each motor can have any order, that does influence the motor direction only, which the board does figure out by itself automatically.

== Connections ==

In order to operate the gimbal the first time, only a few things need to be connected to the controller:
* MPU module - without a MPU module connected to the I2C port the controller will show errors and won't power up the motors.
* Motors - Mot0 and Mot1 are for the Pitch and Roll motors (or vice versa, this can be configured in the GUI), and Mot2 for the Yaw motor. The order of the three pins of each motor is irrelevant (the motor directions can be configured in the GUI).
* USB port - connect it to a computer for setup and debugging purposes.
* Battery - please do '''not connect''' a battery yet, see next chapter.

All the other ports, such as the Rc input ports, shall remain disconnected for now.

[[File:0connections.JPG|480px]]

== First Configuration ==

It is assumed that a firmware was uploaded to the controller before (for uploading firmware see [[How to flash firmware]]). At the first-time connection of the controller to the computer via USB, Windows will search for the USB driver and install it. This can take several minutes; it is important to wait until Windows reports that the device is ready for use. With the controller connected to USB, you won't see much happening except the two LEDs blinking with various frequencies; the gimbal can be moved freely as no power is applied to the motors (remember: no battery connected yet!).

Now start the GUI executable matching the controller's firmware version and select the COM port assigned to the USB device in the {{GUI|Port}} dropdown box at the bottom left. If you are unsure about the correct COM port, then unplug the USB cable, click on the dropdown icon of the field to open the full list of available COM ports and memorize that list. Plug in the USB cable again, and open the list again. The required COM port is the additional one.

Once the proper COM port is selected, the first thing is to hit the {{GUI|Read}} button. If everything is in order, the GUI will read the currently stored settings from the controller. In the message box at the bottom you will see some status messages and a final "Read...DONE!" text.

Now it's time to set the most important parameters, namely the IMU orientation and motor parameter values. Without that the controller can't perform even the basic operations.

'''For the following the motors should NOT be operational.''' This can be achieved in various ways, for example by physically disconnecting all motors, or using the {{GUI|Disable all Motors}} buttons in the configuration tabs. The easiest and recommended way is however to power the board via USB only, i.e. to not connect a battery to it (when the board is powered by USB only the motors are shut off and won't work).

[[File:1main.png|480px]]

== IMU Orientation ==

''the procedure is still valid, but a better and much easier procedure is available in v0.56''

The tab called {{GUI|Configure IMU}} is meant to support you in setting up the IMU orientation. There are so many different ways in which you can attach the IMU to your camera (above the camera, below, at the backside, with the axis up, down, left, right, and so on) but the controller does not know. Hence you have to tell.

'''It is of outmost importance to set the IMU orientation correctly, else the controller has no chance to work correctly. Please double and triple check that you got the IMU stetting right!'''

=== Determining the IMU Orientation ===
The first thing is to ensure that all motors are shut off to avoid any motor movements. Then investigate the IMU board, there is usually an arrow printed on it for the x axis. If not, you may use the little dot marker on the IMU chip as reference (see the [[Getting_Started#Appendix|Appendix]] below). Now hold the gimbal and camera in front of you, as if you would be taking a picture. {{GUIPARAM|Up}} refers to the top of the camera, {{GUIPARAM|forward}} to its front with the lense, and {{GUIPARAM|right}} to the right-hand side of the camera. The questions to answer in the IMU orientation dialog are where the z axis and x arrow point to.

The IMU's z axis points outwards of the surface of the IMU chip, i.e., comes straight out of the IMU board. In the example below, as the IMU board is mounted upside down, it points downwards the camera, so you specify the {{GUI|z axis points}} {{GUIPARAM|down}}. For the x axis we use the printed arrow on the IMU board. In the example below it is pointing in the camera's forward (shooting) direction, hence in the GUI you set that the {{GUI|x axis points}} {{GUIPARAM|forward}}. The little graphic on the right displays your setting, i.e., the IMU's x-y-z axes with respect to the camera's up-right-forward orientations.

To send these setting to the board click on the {{GUI|Write}} button. In order to make the changes permanent, the menu option {{GUI|Store to EEPROM}} can be used. Alternatively, click on the check box next to the {{GUI|Write}} button, which causes the button label to change to {{GUI|Write+Store}}, and hit the button. Both methods are fine.

Please note that the {{GUI|Configure IMU}} page is for your support only. Its sole purpose is to help you determining the IMU orientation index, here no. 15, and writing it into the {{GUI|Imu Orientation}} parameter field located on the {{GUI|Gimbal Setup}} tab.

{{COMMENT|In older firmware versions (v0.27 and lower) the meaning of {{GUIPARAM|right}} and {{GUIPARAM|left}} is reversed. The orientation index number however has not changed.}}

[[File:6configureimu.png|480px]]

[[File:3imuorientation.JPG|480px]]

=== Checking the IMU Orientation ===
In order to ensure a correct IMU Orientation you should test it. Write the setting to the controller (temporarily or into the EEPROM) and then click on the {{GUI|Data Display}} button. This will open a realtime monitor window. In the top you can see the current Pitch, Roll, and Yaw angles once you did click on {{GUI|Start}} in the window.

As the motors are (hopefully) disabled still, you can move the camera by hand. The following behavior must be observed:
* When you tilt the camera downwards (lens points to the ground), the Pitch value has to get more positive (the red line in the middle panel of the Data Display has to move upwards).
* When you roll the camera like in flying a right turn (clockwise when standing behind the camera), the Roll value has to get more positive (the green line in the middle panel of the Data Display has to move upwards).
* When you rotate the camera around the yaw axis anti-clock wise, the Yaw value hast to get more positive (the blue line in the middle panel of the Data Display has to move upwards).

If you do not observe that, then go back and repeat the IMU orientation setting.

[[File:9datadisplay.png|480px]]

=== Appendix ===
In case your IMU board has no arrow printed on it or you are uncertain then you can use the white dot in one of the corners on the IMU chip (MPU6050) as well for the orientation. In the diagram below the axes and their orientation in relationship to the dot are shown.

As said before, the z axis comes out of the top surface of the chip and the x axis points away from the dot. Check the chip labels, the x axis runs in the reading direction of the labeling.

The diagram below provides some examples of the IMU orientation.

[[File:5IMUorientation.JPG|600px]]

== Motor Settings ==

''the procedure is still valid, but an easier procedure is available in v0.56''

For the motor settings there is a separate tab as well, the {{GUI|Configure Motors}} tab. Again, ensure that the motors are disengaged.

In the example below the Mot0 port on the controller is connected to the Pitch motor, which lets the camera look up or down. Mot1 is connected to the Roll motor, which keeps the horizon level. Remember, Mot2 has to be used for Yaw always.

The motor poles are best read from the motor's datasheets found in the internet. A common value is 14 poles for smaller motors. Large motors may have 22 poles or even more. Self-wound motors often have 12 poles.

The last setting of importance is the motor direction. However, the STorM32 controller provides you an {{GUIPARAM|auto}} setting, which is recommended to be used. With {{GUIPARAM|auto}} the initialization phase of the gimbal takes few seconds longer - who cares (you can avoid that later if you like).

With these few steps the most important fields in the {{GUI|Gimbal Setup}} tab are properly set, and you are ready to go!

[[File:7configuremotors.png|480px]]

== First Startup ==

Once you have completed the above steps, the motors can be turned on. In the {{GUI|Expert}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields are all set to {{GUIPARAM|normal}} (the default is {{GUIPARAM|disabled}}). If not, set them to "normal" (or click on {{GUI|Enable all Motors}}), and write and store the changed setting.

{{COMMENT|If you are using the STorM32-BGC for a 2 axis gimbal, set {{GUI|Yaw Usage}} to {{GUIPARAM|disabled}} (and maybe set {{GUI|Yaw P}}, {{GUI|Yaw I}}, and {{GUI|Yaw D}} to zero).}}

Now connect a battery to the controller (it is assumed that you did follow the above advice of powering the board via USB). The gimbal should go through a number of initialization steps (the green led blinks, with increasing frequency), and finally should start with normal operation (the green led goes solid).

{{COMMENT|During the initialization the gimbal needs to be at rest.}}

In short, after power up keep the gimbal at rest until the green led goes solid. Holding the gimbal e.g. in the hands is not keeping it at rest.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

Getting Started

2014-12-14T11:11:04Z

Yang:

You have a Gimbal, the StorM32-BGC board, the IMU and all cables. So what is next?
This page is intended to guide you through the essential steps (based on the 0.56 firmware version) and contains references to the detail pages in case you need to know more. Basically the steps are

<div class="toclimit-2">__TOC__</div>

== Ordering information ==

The StorM32-BGC board can be found at various shops. As of today there are three hardware revisions but frankly, they do not differ much. Hence nothing wrong with buying a v1.1 board, just keep in mind that some pins are placed at different places. Since the v1.3 hardware revision is the one you get everywhere these days, this page is using it as example.
Together with the board buy an IMU and matching cable from the same vendor. There are tons of IMUs available but the connectors can be different. The plug on the StorM board is a so called Picoblade connector.
And finally an USB-to-serial adapter with a matching cable is required for flashing the latest firmware. It can be any FTDI, CP2102, ..., but NOT a PL2303 based adapter. Again, if you do not have one already, I recommend getting this with the other parts. Personally I prefer those where the drivers come from the Windows Update Site automatically.

Things to watch out for when comparing prices
* Bluetooth module included? The StorM board is designed to solder an HC06 bluetooth module on it. Then you can run the config tool on your laptop via bluetooth. The range of these modules is quite low, so do not expect to use it to remote monitor the gimbal values in flight. If in future there will be a smartphone app available, this might be realyl cool for changing configurations, on the other hand, how often will you be doing that?
* Connectors soldered on it? Having connectors already soldered allows to simply plug in the motors and go. On the other hand, the RC and motor connectors are quite large, hence might be placed on the opposite side or motor cables being soldered directly to the board. Consider your preferences before buying.
* IMU and cable included already? Or does it come without the IMU?

== Flash Firmware ==

Because the StorM board has a very active community, new firmware versions with new enhancements are released on about monthly basis these days, so the first step will be to flash the newest firmware.
This description here assumes the board used was bought by a vendor with a firmware already uploaded and it should be updated only. Else refer to the [[How to flash firmware]] page.
Very quickly, there are three typical traps when flashing
# The board has no power
# The pins labeled UART is used for flashing instead of the RC labeled pins
# Wrong serial port is selected in the tool

In order to flash a new firmware the following steps are recommended.

# Get your USB-to-serial adapter to work by installing all windows drivers as requested by the vendor. [[File:Usb-to-uart-driver.png|none|300px]]
# Unplug(!) the USB-to-serial adapter again
# Connect the USB-to-serial adapter to the StorM board to the pins labeled RC(!). The firmware is not programmed via the UART labeled port, not via USB but via the RC pins. In other words, when the board is brought into the bootload mode, the RC pins are re-assigned to microcontroller's UART1, in normal mode these pins are assigned to the PWM timer. And the pins labeled as UART are the mcu's UART0. All of this is a security measure to avoid people programming the board via e.g. bluetooth and end up with an nonoperational board. [[File:Stom32-bgc-flashing-w-usbttladapter-connections-02.jpg|none|300px]]
# Connect the StorM board via USB to the computer. We are not using this connection yet but we power the board via USB. Although we do not need it yet, this might trigger Windows to install a driver for the STM processor's USB connection.
# Download the newest firmware, unzip it and run the exe file, in this example the o323BGCTool_v056.exe program. It does not matter what the current firmware installed is, you use the tool that comes with the firmware zip file. Get the zip file from here: [[Downloads]].
# In the tool select the {{GUI|Flash Firmware tab}} on the very right hand side and select the hardware revision of your board. This does change the firmware file to be used in the field below. [[File:Firmware_selector.png|none|300px]]
# In step two, the middle of the screen, there is a {{GUI|com port selector}} for flashing. NOT the com port selector at the bottom! Click on the drop down box to see all currently available com ports. Since we do not have connected the USB-to-serial adapter to the computer yet, the new one appearing when plugging in the adapter will be the one to use. Hence remember that list of ports to identify the new one in the next step. [[File:Firmware_comport1.png|none|300px]]
# Plugin the USB-to-serial adapter and click again on the drop down box of the serial connector for programming. Select the new one. [[File:Firmware_comport2.png|none|300px]]
# The board has two buttons, the boot and reset button. When the board is started, the very first thing the software does is checking if the boot button is currently pressed. If it is, the bootloader mode is entered, else the normal operation starts. The best way of entering the bootloader mode is hence to press the boot button and while it is pressed press and release the reset button to initiate a hard reset. [[File:Firmware-bootloadermode.jpg|none|300px]]
# Check if the board is in bootloader mode or in operational mode. If the boards appears to be dead, then it is brought into bootloader mode successfully, if the Leds are blinking, it is in normal operation and obviously the boot button was not pressed while the reset button was released. [[File:Firmware-bootloadermode-leds.jpg|none|300px]]
# Now the board is listening on the RC pins for serial data, the usb adapter is connected, the firmware tool is using the Windows COM port of the serial adapter, hence you can click on {{GUI|Flash Firmware}} button. [[File:Firmware_start_flash.png|none|300px]]
# A dos box will open and either return an error that the UART connection is not responding or a sequence of downloading and verifying the firmware is shown. [[File:Flash.png|none|300px]]
# After the reset your board is operational and can be reached via the USB cable. Hence disconnect both, the USB cable and the USB-to-serial adapter and click on the com port selector at the very bottom. Again, remember the list. [[File:Board read 0.png|none|300px]]
# Then plugin the StorM board via the USB cable to power it. Either the matching driver was installed already or it will be installed now. Either way once windows has installed the driver when clicking on the drop down for the com port selector, it should now show an additional one.[[File:Board read 1.png|none|300px]]
# Jump back to the {{GUI|Main tab}} and click on {{GUI|Read}} to validate the connection with the board. [[File:Board_read_2.png|none|300px]]

In case you have troubles with the StorM's USB driver, it can be found here: [http://www.st.com/web/en/catalog/tools/PF257938].

== Hardware setup ==

Gimbal, location of the StorM board, IMU location, cables, power
== Dos and Don'ts ==

The STorM32-BGC is an electronic device.

This should have said it all, yet some specific don'ts:
* {{WARNING|'''Don't get any parts of the board into contact with the (plus pole of the) battery'''}}, this will immediately destroy the board.
* {{WARNING|'''The voltage on the POT and BUT pins must not exceed 3.3 V'''}}, else the board will be immediately destroyed.
* {{WARNING|'''The voltage on any of the other pins must not exceed 5 V'''}}, else the board will be immediately destroyed.
* The 3.3 V pins on the board should only be used as supply. {{WARNING|'''Do not apply voltage to a 3.3 V pin'''}}. {{WARNING|'''Do not connect a 3.3 V pin to a GND pin'''}}.
* {{WARNING|'''Do not use metal screws to mount the board'''}}. This can lead to short circuits. At the very least use plastic washers.
* The motor drivers are not short-circuit protected. It is recommended for new/unknown motors to measure the resistances of the motor phases and to the motor housing before the they are connected to the board.

== Parts Checklist ==

* 1x STorM32-BGC
* 1x MPU6050 breakout board (plus 4pol cable and plug to connect to the controller)
* 1x 3 axis gimbal with motors (plus 3x motor cable, each 3pol)
* 1x lipo 2S - 4S (plus 2pol cable and plug to connect to the controller)
* 1x USB 2.0 cable
* latest firmware and GUI, [[Downloads]]
* 1x USB to serial adapter + 4 dupont 2.54 mm cables (necessary for firmware update or first flashing)
* 1x joystick + 5 dupont 2.54 mm cables (OPTIONAL)
* 1x IR led + 2 dupont 2.54 mm cables (OPTIONAL)
* plenty of time and patience ;-)

For possible sources for some parts you may check out [[Where to buy accessories and supplies]].

== The Gimbal ==

Before you power up anything it is absolutely necessary to balance your gimbal and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any imbalance or distraction to free rotation will make setting up the gimbal more difficult or even impossible. The goal shall be, no matter where your camera, mounted in the gimbal, points at, it should remain in that position. In addition, the MPU module should be mounted rigidly, preferably to the camera support. Please note: The better you do the job here, the better the stabilization performance will be.

== Connections ==

In order to operate the gimbal the first time, only a few things need to be connected to the controller:
* MPU module - without a MPU module connected to the I2C port the controller will show errors and won't power up the motors.
* Motors - Mot0 and Mot1 are for the Pitch and Roll motors (or vice versa, this can be configured in the GUI), and Mot2 for the Yaw motor. The order of the three pins of each motor is irrelevant (the motor directions can be configured in the GUI).
* USB port - connect it to a computer for setup and debugging purposes.
* Battery - please do '''not connect''' a battery yet, see next chapter.

All the other ports, such as the Rc input ports, shall remain disconnected for now.

[[File:0connections.JPG|480px]]

== First Configuration ==

It is assumed that a firmware was uploaded to the controller before (for uploading firmware see [[How to flash firmware]]). At the first-time connection of the controller to the computer via USB, Windows will search for the USB driver and install it. This can take several minutes; it is important to wait until Windows reports that the device is ready for use. With the controller connected to USB, you won't see much happening except the two LEDs blinking with various frequencies; the gimbal can be moved freely as no power is applied to the motors (remember: no battery connected yet!).

Now start the GUI executable matching the controller's firmware version and select the COM port assigned to the USB device in the {{GUI|Port}} dropdown box at the bottom left. If you are unsure about the correct COM port, then unplug the USB cable, click on the dropdown icon of the field to open the full list of available COM ports and memorize that list. Plug in the USB cable again, and open the list again. The required COM port is the additional one.

Once the proper COM port is selected, the first thing is to hit the {{GUI|Read}} button. If everything is in order, the GUI will read the currently stored settings from the controller. In the message box at the bottom you will see some status messages and a final "Read...DONE!" text.

Now it's time to set the most important parameters, namely the IMU orientation and motor parameter values. Without that the controller can't perform even the basic operations.

'''For the following the motors should NOT be operational.''' This can be achieved in various ways, for example by physically disconnecting all motors, or using the {{GUI|Disable all Motors}} buttons in the configuration tabs. The easiest and recommended way is however to power the board via USB only, i.e. to not connect a battery to it (when the board is powered by USB only the motors are shut off and won't work).

[[File:1main.png|480px]]

== IMU Orientation ==

''the procedure is still valid, but a better and much easier procedure is available in v0.56''

The tab called {{GUI|Configure IMU}} is meant to support you in setting up the IMU orientation. There are so many different ways in which you can attach the IMU to your camera (above the camera, below, at the backside, with the axis up, down, left, right, and so on) but the controller does not know. Hence you have to tell.

'''It is of outmost importance to set the IMU orientation correctly, else the controller has no chance to work correctly. Please double and triple check that you got the IMU stetting right!'''

=== Determining the IMU Orientation ===
The first thing is to ensure that all motors are shut off to avoid any motor movements. Then investigate the IMU board, there is usually an arrow printed on it for the x axis. If not, you may use the little dot marker on the IMU chip as reference (see the [[Getting_Started#Appendix|Appendix]] below). Now hold the gimbal and camera in front of you, as if you would be taking a picture. {{GUIPARAM|Up}} refers to the top of the camera, {{GUIPARAM|forward}} to its front with the lense, and {{GUIPARAM|right}} to the right-hand side of the camera. The questions to answer in the IMU orientation dialog are where the z axis and x arrow point to.

The IMU's z axis points outwards of the surface of the IMU chip, i.e., comes straight out of the IMU board. In the example below, as the IMU board is mounted upside down, it points downwards the camera, so you specify the {{GUI|z axis points}} {{GUIPARAM|down}}. For the x axis we use the printed arrow on the IMU board. In the example below it is pointing in the camera's forward (shooting) direction, hence in the GUI you set that the {{GUI|x axis points}} {{GUIPARAM|forward}}. The little graphic on the right displays your setting, i.e., the IMU's x-y-z axes with respect to the camera's up-right-forward orientations.

To send these setting to the board click on the {{GUI|Write}} button. In order to make the changes permanent, the menu option {{GUI|Store to EEPROM}} can be used. Alternatively, click on the check box next to the {{GUI|Write}} button, which causes the button label to change to {{GUI|Write+Store}}, and hit the button. Both methods are fine.

Please note that the {{GUI|Configure IMU}} page is for your support only. Its sole purpose is to help you determining the IMU orientation index, here no. 15, and writing it into the {{GUI|Imu Orientation}} parameter field located on the {{GUI|Gimbal Setup}} tab.

{{COMMENT|In older firmware versions (v0.27 and lower) the meaning of {{GUIPARAM|right}} and {{GUIPARAM|left}} is reversed. The orientation index number however has not changed.}}

[[File:6configureimu.png|480px]]

[[File:3imuorientation.JPG|480px]]

=== Checking the IMU Orientation ===
In order to ensure a correct IMU Orientation you should test it. Write the setting to the controller (temporarily or into the EEPROM) and then click on the {{GUI|Data Display}} button. This will open a realtime monitor window. In the top you can see the current Pitch, Roll, and Yaw angles once you did click on {{GUI|Start}} in the window.

As the motors are (hopefully) disabled still, you can move the camera by hand. The following behavior must be observed:
* When you tilt the camera downwards (lens points to the ground), the Pitch value has to get more positive (the red line in the middle panel of the Data Display has to move upwards).
* When you roll the camera like in flying a right turn (clockwise when standing behind the camera), the Roll value has to get more positive (the green line in the middle panel of the Data Display has to move upwards).
* When you rotate the camera around the yaw axis anti-clock wise, the Yaw value hast to get more positive (the blue line in the middle panel of the Data Display has to move upwards).

If you do not observe that, then go back and repeat the IMU orientation setting.

[[File:9datadisplay.png|480px]]

=== Appendix ===
In case your IMU board has no arrow printed on it or you are uncertain then you can use the white dot in one of the corners on the IMU chip (MPU6050) as well for the orientation. In the diagram below the axes and their orientation in relationship to the dot are shown.

As said before, the z axis comes out of the top surface of the chip and the x axis points away from the dot. Check the chip labels, the x axis runs in the reading direction of the labeling.

The diagram below provides some examples of the IMU orientation.

[[File:5IMUorientation.JPG|600px]]

== Motor Settings ==

''the procedure is still valid, but an easier procedure is available in v0.56''

For the motor settings there is a separate tab as well, the {{GUI|Configure Motors}} tab. Again, ensure that the motors are disengaged.

In the example below the Mot0 port on the controller is connected to the Pitch motor, which lets the camera look up or down. Mot1 is connected to the Roll motor, which keeps the horizon level. Remember, Mot2 has to be used for Yaw always.

The motor poles are best read from the motor's datasheets found in the internet. A common value is 14 poles for smaller motors. Large motors may have 22 poles or even more. Self-wound motors often have 12 poles.

The last setting of importance is the motor direction. However, the STorM32 controller provides you an {{GUIPARAM|auto}} setting, which is recommended to be used. With {{GUIPARAM|auto}} the initialization phase of the gimbal takes few seconds longer - who cares (you can avoid that later if you like).

With these few steps the most important fields in the {{GUI|Gimbal Setup}} tab are properly set, and you are ready to go!

[[File:7configuremotors.png|480px]]

== First Startup ==

Once you have completed the above steps, the motors can be turned on. In the {{GUI|Expert}} tab check that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields are all set to {{GUIPARAM|normal}} (the default is {{GUIPARAM|disabled}}). If not, set them to "normal" (or click on {{GUI|Enable all Motors}}), and write and store the changed setting.

{{COMMENT|If you are using the STorM32-BGC for a 2 axis gimbal, set {{GUI|Yaw Usage}} to {{GUIPARAM|disabled}} (and maybe set {{GUI|Yaw P}}, {{GUI|Yaw I}}, and {{GUI|Yaw D}} to zero).}}

Now connect a battery to the controller (it is assumed that you did follow the above advice of powering the board via USB). The gimbal should go through a number of initialization steps (the green led blinks, with increasing frequency), and finally should start with normal operation (the green led goes solid).

{{COMMENT|During the initialization the gimbal needs to be at rest.}}

In short, after power up keep the gimbal at rest until the green led goes solid. Holding the gimbal e.g. in the hands is not keeping it at rest.

== Next step - PID Tuning ==

At this point the gimbal may already stabilize the camera. However, usually, the camera is not yet stabilized perfectly, or the gimbal may even start to show weird shaking or make high frequency noises. This indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

File:Board read 2.png

2014-12-14T11:09:53Z

Yang:

File:Board read 1.png

2014-12-14T11:06:33Z

Yang:

File:Board read 0.png

2014-12-14T11:06:23Z

Yang:

File:Firmware start flash.png

2014-12-14T11:03:09Z

Yang:

File:Firmware-bootloadermode-leds.jpg

2014-12-14T11:01:02Z

Yang:

File:Firmware-bootloadermode.jpg

2014-12-14T11:00:23Z

Yang:

File:Firmware-bootloadermode.png

2014-12-14T10:58:25Z

Yang:

File:Firmware comport2.png

2014-12-14T10:49:54Z

Yang:

File:Firmware comport1.png

2014-12-14T10:49:43Z

Yang:

File:Firmware selector.png

2014-12-14T10:49:22Z

Yang: Yang uploaded a new version of "File:Firmware selector.png"

File:Firmware selector.png

2014-12-14T10:46:57Z

Yang:

File:Usb-to-uart-driver.png

2014-12-14T10:31:54Z

Yang:

Getting Started

2014-06-16T20:05:24Z

Yang: /* Checking the IMU Orientation */

<div class="toclimit-2">__TOC__</div>

== Foreword ==

This page is intended to help you making the first steps with the STorM32 brushless gimbal controller. Every gimbal is unique because of different size, motors, and camera weight. Copying the configuration of one gimbal to another usually won't work. Hence, you have to learn what happens with your gimbal when changing settings. If you're not prepared to invest the time then the STorM32-BGC, like any other gimbal controller, won't make you happy :-). Otherwise, let's get started...

== Dos and Don'ts ==

The STorM32-BGC is an electronic device.

This should have said it all, yet some specific don'ts:
* {{WARNING|'''Don't get any parts of the board into contact with the (plus pole of the) battery'''}}, this will immediately destroy the board.
* {{WARNING|'''The voltage on the POT and BUT pins must not exceed 3.3 V'''}}, else the board will be immediately destroyed.
* {{WARNING|'''The voltage on any of the other pins must not exceed 5 V'''}}, else the board will be immediately destroyed.
* The 3.3V pins on the board should only be used as supply. {{WARNING|'''Do not apply voltage to a 3.3 V pin'''}}.
* {{WARNING|'''Do not use metal screws to mount the board'''}}. This can lead to short circuits. At the very least use plastic washers.
* The motor drivers are not short-circuit protected. It is recommended for new/unknown motors to measure the resistances of the motor phases and to the motor housing before the they are connected to the board.

== Parts Checklist ==

* 1x STorM32BGC
* 1x MPU6050 breakout board (plus 4pol cable and plug to connect to the controller)
* 1x 3 axis gimbal with motors (plus 3x motor cable, each 3pol)
* 1x Lipo 2s - 4s (plus 2pol cable and plug to connect to the controller)
* 1x USB 2.0 cable
* latest firmware and gui, [[Downloads]]
* 1x USB to serial adapter + 4 dupont 2.54mm cables (necessary for firmware update or first flashing)
* 1x joystick + 5 dupont 2.54mm cables (OPTIONAL)
* 1x IR led + 2 dupont 2.54mm cables (OPTIONAL)
* plenty of time and patience ;-)

For possible sources for some parts you may check out [[Where to buy accessories and supplies]].

== The Gimbal ==

Before you power up anything it is absolutely necessary to balance your gimbal and to ensure minimum resistance to rotations (friction in bearings, stiff cables, etc). Any imbalance or distraction to free rotation will make setting up the gimbal more difficult or even impossible. The goal shall be, no matter where your camera, mounted in the gimbal, points at, it should remain in that position. In addition, the MPU module should be mounted rigidly, preferably to the camera support. Please note: The better you do the job here, the better the stabilization performance will be.

== Connections ==

In order to operate the gimbal the first time, only a few things need to be connected to the controller:
* MPU module - without a MPU module connected to the I2C port the controller will show errors and won't power up the motors.
* Motors - Mot0 and Mot1 are meant for the Pitch and Roll motors (which is the default setting), and Mot2 for the Yaw motor. The order of the three pins of each motor is irrelevant as motor directions were not defined in the GUI yet.
* USB port - connect it to a computer for setup and debugging purposes.
* Battery - please do '''not connect''' a battery yet, see next chapter.

All the other ports, such as the Rc input ports, shall remain disconnected for now.

[[File:0connections.JPG|480px]]

== First Configuration ==

Assuming a firmware was uploaded to the controller before (for uploading firmware see [[How to flash firmware|here]]), the first time you connect the controller to the computer via USB you won't see much happening, except the two LEDs blinking with various frequencies; the gimbal can be moved freely as no power is applied to the motors (remember: no battery connected yet!). Windows will search for the USB driver, which can take a couple of minutes. Please wait until it reports having installed it.

Now you start the GUI executable matching the controller's firmware version and select the COM port assigned to the USB controller in the {{GUI|Port}} dropdown box at the bottom left. If you are not sure which COM port is used, unplug the USB cable, click on the dropdown icon of the field to open the full list of available COM ports and memorize that list. Plug in the USB cable again, and open the list again. The required COM port is the additional one.

Once the proper COM port is selected, the first thing is to hit the {{GUI|Read}} button. If everything is in order, the GUI will read the currently stored settings from the controller. In the message box at the bottom you will see some status messages and a final "Read...DONE!" text.

Now it's time to set the most important parameters, namely the IMU orientation and motor parameter values. Without that the controller can't perform even the basic operations.

'''For the following the motors should NOT be operational.''' This can be achieved in various ways, for example by physically disconnecting all motors, or using the {{GUI|Disable all Motors}} buttons in the configuration tabs. The easiest and recommended way is however to power the board via USB only, i.e. to not connect a battery to it (when the board is powered by USB only the motors are shut off and won't work).

[[File:1main.png|480px]]

== IMU Orientation ==

The tab called {{GUI|Configure IMU}} is meant to support you in setting up the IMU orientation. There are so many different ways in which you can attach the IMU to your camera (above the camera, below, at the backside, with the axis up, down, left, right, and so on) but the controller does not know. Hence you have to tell.

'''It is of outmost importance to set the IMU orientation correctly, else the controller has no chance to work correctly. Please double and triple check that you got the IMU stetting right!'''

=== Determining the IMU Orientation ===
The first thing is to ensure that all motors are shut off to avoid any motor movements. Then investigate the IMU board, there is usually an arrow printed on it for the x-axis. If not, you may use the little dot marker on the IMU chip as reference (see the [[Getting_Started#Appendix|Appendix]] below). Now hold the gimbal and camera in front of you, as if you would be taking a picture. "Up" refers to the top of the camera, "forward" to its front with the lense, and "right" to the right-hand side of the camera. The questions to answer in the IMU orientation dialog are where the z axis and x arrow point to.

The IMU's z axis points outwards of the surface of the IMU chip, i.e., comes straight out of the IMU board. In the example below, as the IMU board is mounted upside down, it points downwards the camera, so you specify the {{GUI|z axis points}} "down". For the x axis we use the printed arrow on the IMU board. In the example below it is pointing in the camera's forward (shooting) direction, hence in the GUI you set that the {{GUI|x axis points}} "forward". The little graphic on the right displays your setting, i.e., the IMU's x-y-z axes with respect to the camera's up-right-forward orientations.

To send these setting to the board click on the {{GUI|Write}} button. In order to make the changes permanent, the menu option {{GUI|Store to EEPROM}} can be used. Alternatively, click on the check box next to the {{GUI|Write}} button, which causes the button label to change to {{GUI|Write+Store}}, and hit the button. Both methods are fine.

Please note that the {{GUI|Configure IMU}} page is for your support only. Its sole purpose is to help you determining the IMU orientation index, here no. 15, and writing it into the {{GUI|Imu Orientation}} parameter field located on the {{GUI|Gimbal Setup}} tab.

'''''Comment''': In older firmware versions (v0.27 and lower) the meaning of "right" and "left" is reversed. The orientation index number however has not changed.''

[[File:6configureimu.png|480px]]

[[File:3imuorientation.JPG|480px]]

=== Checking the IMU Orientation ===
In order to ensure a correct IMU Orientation you should test it. Write the setting to the controller (temporarily or into the EEPROM) and then click on the {{GUI|Data Display}} button. This will open a realtime monitor window. In the top you can see the current Pitch, Roll, and Yaw angles once you did click on {{GUI|Start}} in the window.

As the motors are (hopefully) disabled still, you can move the camera by hand. The following behavior must be observed:
* When you tilt the camera downwards (lens points to the ground), the Pitch value has to get more positive (the red line in the middle panel of the Data Display has to move upwards).
* When you roll the camera like in flying a right turn (clockwise when standing behind the camera), the Roll value has to get more positive (the green line in the middle panel of the Data Display has to move upwards).
* When you rotate the camera around the yaw axis anti-clock wise, the Yaw value hast to get more positive (the blue line in the middle panel of the Data Display has to move upwards).

If you do not observe that, then go back and repeat the IMU orientation setting.

[[File:9datadisplay.png|480px]]

=== Appendix ===
In case your IMU board has no arrow printed on it or you are uncertain then you can use the white dot in one of the corners on the IMU chip (MPU6050) as well for the orientation. In the diagram below the axes and their orientation in relationship to the dot are shown.

As said before, the z axis comes out of the top surface of the chip and the x axis points away from the dot. Check the chip labels, the x axis runs in the reading direction of the labeling.

The diagram below provides some examples of the IMU orientation.

[[File:5IMUorientation.JPG|600px]]

== Motor Settings ==

For the motor settings there is a separate tab as well, the {{GUI|Configure Motors}} tab. Again, ensure that the motors are disengaged.

In the example below the Mot0 port on the controller is connected to the Pitch motor, which lets the camera look up or down. Mot1 is connected to the Roll motor, which keeps the horizon level. Remember, Mot2 has to be used for Yaw always.

The motor poles are best read from the motor's datasheets found in the internet. A common value is 14 poles for smaller motors. Large motors may have 22 poles or even more. Self-wound motors often have 12 poles.

The last setting of importance is the motor direction. However, the STorM32 controller provides you an "auto" setting, which is recommended to be used. With "auto" the initialization phase of the gimbal takes few seconds longer - who cares (you can avoid that later if you like).

With these few steps the most important fields in the {{GUI|Gimbal Setup}} tab are properly set, and you are ready to go!

[[File:7configuremotors.png|480px]]

== Next step - PID Tuning ==

Once you have completed the above steps, the motors can be turned on. Check in the {{GUI|Expert}} tab that the {{GUI|Pitch Usage}}, {{GUI|Roll Usage}} and {{GUI|Yaw Usage}} parameter fields are all set to "normal" (the default is "disabled"). If not, set them to "normal" (or click on {{GUI|Enable all Motors}}) and write and store the changed setting.

Now connect a battery to the controller (it is assumed that you did follow above advice of powering the board via USB). The gimbal should initialize and start to work. It may also start to show weird shaking or make high frequency noises, which indicates that the PID values in the {{GUI|Main}} tab are not proper.

See the PID parameter [[Tuning Guide|Tuning Guide]] for adjusting those.

Example Setups

2014-06-14T13:56:51Z

Yang: /* wdaehn's RC Timer ASP */

On this page you may describe and show your STorM32-based gimbal setup, '''including''' all relevant technical specifications (please try to adhere to the suggested list of technical infos).

<div class="toclimit-2">__TOC__</div>

== Keychain Camera Gimbals ==

=== OlliW's ===
[[File:Storm32-bgc-v017-test-microgimbal-01-wp01.jpg|thumb|200px]]

'''Technical details:'''
* camera: key cam 808 #16 V2 with lense D
* pitch motor: [//www.lioncast.de/Produktbilder_NEU/Playstation_1_2/PS2_Slim_Motor_7700x/PS2_Slim_Motor_7700x.jpg PS2 Slim disc drive replacement motor], rewound, R: ca. 24 Ohm, config: 9N12P, winding: 0.10mm, 150t
* roll motor: [//www.lioncast.de/Produktbilder_NEU/Playstation_1_2/PS2_Slim_Motor_7700x/PS2_Slim_Motor_7700x.jpg PS2 Slim disc drive replacement motor], rewound, R: ca. 24 Ohm, config: 9N12P, winding: 0.10mm, 150t
* yaw motor: [//www.lioncast.de/Produktbilder_NEU/Playstation_1_2/PS2_Slim_Motor_7700x/PS2_Slim_Motor_7700x.jpg PS2 Slim disc drive replacement motor], rewound, R: ca. 24 Ohm, config: 9N12P, winding: 0.10mm, 150t
* battery: 3S
* typical pitch PID values: P = 6.0, I = 750, D = 0.070, Vmax = 150    (f0=15.9Hz, d=0.40)
* typical roll PID values: P = 7.0, I = 450, D = 0.185, Vmax = 150    (f0=7.85Hz, d=0.38)
* typical yaw PID values: P = 7.0, I = 450, D = 0.185, Vmax = 150    (f0=7.85Hz, d=0.38)
* controller board: this is a test gimbal, boards are varying

== Mobius ActionCam Gimbals ==

== GoPro Hero Gimbals ==

=== Hexakopter's ===
[[File:Hexakopter's GoPro-Gimbal.jpg|thumb|200px]]

'''Technical details:'''
* camera: GoPro Hero 1
* pitch motor: [http://www.goodluckbuy.com/dji-phantom-brushless-gimbal-camera-mount-w-motor-and-controller-for-gopro3-fpv-aerial-photography.html motor taken from this GLB gimbal]
* roll motor: [http://www.goodluckbuy.com/dji-phantom-brushless-gimbal-camera-mount-w-motor-and-controller-for-gopro3-fpv-aerial-photography.html motors taken from this GLB gimbal]
* yaw motor: [//www.rctimer.com/product_870.html rctimer model 5010-021-150T], R: 14.65 Ohm, config: 12N14P, winding: 0.21mm, 150t
* battery: 3S
* pitch PID values: P = 13, I = 680, D = 0.1400, Vmax = 100    (f0=11.1Hz, d=0.67)
* roll PID values: P = 7, I = 450, D = 0.1000, Vmax = 115    (f0=10.7Hz, d=0.52)
* yaw PID values: P = 12.70, I = 450, D = 0.0900, Vmax = 115    (f0=11.3Hz, d=1.00)
* controller board: STorM32bgc v1.0, F103RB, TC's in SO08 package

=== careyer's StorM-stick===
[[File:StorM-stick.JPG|thumb|200px]]

'''Technical details:'''
* camera: Gopro Hero 3 BE
* pitch motor: [//www.rctimer.com/product_871.html rctimer model BG HP2212 ], R: 18.3 Ohm, config: 12N14P, winding: 0.15mm, 70t
* roll motor: [//www.rctimer.com/product_871.html rctimer model BG HP2212 ], R: 18.3 Ohm, config: 12N14P, winding: 0.15mm, 70t
* yaw motor: [//www.rctimer.com/product_871.html rctimer model BG HP2212 ], R: 18.3 Ohm, config: 12N14P, winding: 0.15mm, 70t
* battery: 3S

* typical pitch PID values: P = 4.0, I = 200, D = 0.100, Vmax = 100    (f0=7.12Hz, d=0.45)
* typical roll PID values: P = 4.0, I = 200, D = 0.100, Vmax = 100    (f0=7.12Hz, d=0.45)
* typical yaw PID values: P = 11.0, I = 280, D = 0.200, Vmax = 100    (f0=5.96Hz, d=0.74)
* controller board: STorM32bgc v1.2 FW 027d

== Sony Nex Gimbals ==

=== Erick's ===
'''Technical details:'''
* camera: Sony Nex 5n
* pitch motor: [//www.rctimer.com/product_870.html rctimer model 5010-021-150T], R: 14.65 Ohm, config: 12N14P, winding: 0.21mm, 150t
* roll motor: [//www.rctimer.com/product_870.html rctimer model BGM5208-180T], R: 17.2 Ohm, config: 12N14P, winding: 0.24mm, 180t
* yaw motor: [//www.rctimer.com/product_870.html rctimer model BGM5208-180T], R: 17.2 Ohm, config: 12N14P, winding: 0.24mm, 180t
* battery: 3S
* typical pitch PID values: P = 11, I = 450, D = 0.5000, Vmax = 110    (f0=4.78Hz, d=0.37)
* typical roll PID values: P = 12, I = 250, D = 0.5000, Vmax = 160    (f0=3.56Hz, d=0.54)
* typical yaw PID values: P = 12, I = 150, D = 0.6000, Vmax = 155    (f0=2.52Hz, d=0.63)
* controller board: STorM32bgc v1.1, F103RC, TC's in SO08 package

=== Hexakopter's ===
[[File:Hexakopter's Sony Nex5n-Gimbal.jpg|thumb|200px]]

'''Technical details:'''
* camera: Sony Nex 5n
* pitch motor: [//www.rctimer.com/product_870.html rctimer model 5010-021-150T], R: 14.65 Ohm, config: 12N14P, winding: 0.21mm, 150t
* roll motor: [//www.rctimer.com/product_870.html rctimer model 5010-021-150T], R: 14.65 Ohm, config: 12N14P, winding: 0.21mm, 150t
* yaw motor: [//www.rctimer.com/product_870.html rctimer model 5010-021-150T], R: 14.65 Ohm, config: 12N14P, winding: 0.21mm, 150t
* battery: 2S and 3S
* 2S pitch PID values: P = 13.0, I = 680, D = 0.1250, Vmax = 175    (f0=11.7Hz, d=0.71)
* 2S roll PID values: P = 16.5, I = 340, D = 0.1800, Vmax = 190    (f0=6.92Hz, d=1.05)
* 2S yaw PID values: P = 17.3, I = 280, D = 0.3000, Vmax = 215    (f0=4.86Hz, d=0.94)

Old 3S PID settings:
* 3S pitch PID values: P = 13.0, I = 680, D = 0.1250, Vmax=115    (f0=11.7Hz, d=0.71)
* 3S roll PID values: P = 16.5, I = 340, D = 0.1800, Vmax = 130    (f0=6.92Hz, d=1.05)
* 3S yaw PID values: P = 17.3, I = 280, D = 0.3000, Vmax = 135    (f0=4.86Hz, d=0.94)

New 3S PID settings:
* 3S pitch PID values: P = 11.0, I = 340, D = 0.1150, Vmax=110    (f0=8.65Hz, d=0.88)
* 3S roll PID values: P = 12,3 I = 300, D = 0.2550, Vmax = 111    (f0=5.46Hz, d=0.70)
* 3S yaw PID values: P = 12.0, I = 365, D = 0.4000, Vmax = 111    (f0=4.81Hz, d=0.50)

* controller board: STorM32bgc v1.0, F103RB, TC's in SO08 package and v1.2, F103RC, TC's in DFN package

=== wdaehn's RC Timer ASP ===
[[File:RCTimer ASP NEX Blue.jpg|thumb|200px]]

'''Technical details:'''
* camera: Sony Nex 5n with SEL-P1650 Lens
* gimbal: [//www.rctimer.com/product_977.html rctimer ASP 3 axis Nex-GH5 brushless gimbal]
* pitch motor: [//www.rctimer.com/product_901.html rctimer model BGM4108-015-130T], R: 17.00 Ohm, config: 24N22P, winding: 0.15mm, 130t
* roll motor: [//www.rctimer.com/product_901.html rctimer model BGM4108-015-130T], R: 17.00 Ohm, config: 24N22P, winding: 0.15mm, 130t
* yaw motor: [//www.rctimer.com/product_1137.html rctimer model BGM4114HS-017-100T], R: 15.2 Ohm, config: 24N22P, winding: 0.17mm, 100t
* battery: 3S
* typical pitch PID values: P = 9.30, I = 590.00, D = 0.0400, Vmax = 187    (f0=19.33Hz, d=0.9572)
* typical roll PID values: P = 8.50, I = 240.00, D = 0.0700, Vmax = 230    (f0=9.319Hz, d=1.0369)
* typical yaw PID values: P = 9.70, I = 170, D = 0.0700, Vmax = 140    (f0=8.843Hz, d=1.4059) ----Please note, Yaw was not tuned much since it is not relevant for my cablecam
* controller board: STorM32bgc v1.2, F103RC, TC's in SO08 package, Firmware v0.28

Tuning Recipe

2014-06-14T12:58:30Z

Yang:

The biggest problem for people new to brushless gimbals is finding the correct values of the PID parameters. A PID controller is a well known and often used method for calculating a new input value by measuring the difference between the current state compared with the target state and applying a formula to the difference. In theory, after such calculation, the target state would be reached immediately, but in reality the motor is not indefinitely fast. So in the next iteration there is a an error still, smaller but it exists and a better input value will be calculated based on the now current difference between actual and target.

Due to this iterative approach the control loop can react very precisely to any kind of distortions, however all kind of bad things might happen if the formula is wrong. For example the gimbal might look down by 15°, our formula is: motorpower = 15° * 2W/°. Due to this amount of power the motor turns 30° instead of the expected 15°. So in the next iteration the direction is inverted to -15° * 2W/° = -30W (30W in the reverse direction). The effect would be a shaking of the motor between the +15° and -15° position. The formula used by a PID control algorithm is more advanced than above example and is optimized for quick reaction without overshooting the the target position (much). But even here, if the parameters are wrong, you get all kinds of weird movement patterns.

see [http://en.wikipedia.org/wiki/PID_controller Wikipedia] for the details

== Balancing the Gimbal ==

Before you do any tuning, the gimbal has to be balanced. Balancing means the center of gravity of the mounted camera is in the center of all three gimbal motor axis. This can be tested quite easily by moving the camera by hand, while all gimbal motors are turned off, and the camera should remain in that position if you let go.
A perfectly balanced gimbal has multiple advantages

* We want to move the camera with the RC stick. When the center of gravity would e.g. be below the pitch axis, the camera would try to get into the vertical position by itself. Which sounds like a good idea at first sight, but as soon as we look downwards or upwards, this effect would work against us.
* If the gimbal as a whole is accelerated, the camera would move as well - see image below.
* The motors need to apply more power to keep the camera in the selected position.

In reality you will always need to compromise here, e.g. the Nex Camera has a lens that moves in and out when zooming, the gimbal does not allow infinite adjustments etc. Hence take considerable effort to balance the gimbal but at some point it will be good enough. The stronger the motors are in relationship to the camera weight the more reserve you have, for weaker motors a perfect balance will be more important.

[[File:DSC_7111.jpg]]

Imagine the copter would accelerate to the right. Because the center of gravity is below the pitch axis, the camera would look a bit downward then.

{{#ev:youtube|4Mq2NTyiBf8}}

== Tuning Procedure ==

As each value on every axis might impact the other axis, best approach is to enable one axis after the other. Hence the first step in tuning a brand new gimbal would be to disable all motors except the Pitch motor and find the proper parameters for that. Then enable the Roll motor and tune its parameters, finally the Yaw axis.
Our goal with the PID tuning is to find the highest value for each of the [P], [I] and [D] parameters, that work stable still. The higher the values are the higher the corrective signal will be and the better distortions can be compensated. If one of the values are too large, it does overcompensate, something we would notice as oscillations, noise or erratic behavior in worst case.
Another point is we will start with a low value, then increase it until we get into an area the gimbal starts to behave imperfectly and then we move back until it works again. The reason is simply when increasing the value we test the control loop behavior while the gimbal has no distortions at all. Once these distortions are visible and we reduce the parameter value again, we will find the value needed to balance an currently oscillating gimbal. A concrete example from below videos: A value D=0.04 was picked, everything was fine. It got increased to 0.05, everything was fine still. At D=0.06 heavy vibrations were visible, hence I did step back to the previous D=0.05 value but now there were vibrations here as well! I could manually move the motor into a different position and then the vibrations are gone. What happened?
At 0.06 I was at a resonance frequency of the control loop, but with a slight decrease back to 0.05 the frequency was very similar still and the control loop was not able to get out of this by itself. To be on the safe side I picked 0.04 for [D], as at this value the shaking did stop by itself.
The other thing I do is turning the motors by hand into all allowed positions. Please note, this has less to do with the PID regulation as such, it is a test if the current parameter values work in all positions rather. If the gimbal and camera would be balanced perfectly, there would not be a need for that. But in reality....

[[File:1main.png]]

=== The online PID simulator ===
If you want to know more about the PID control loop, there is a [[PID online simulator]] page showing the effects in a diagram and let you play with the various parameters.

=== The Starting Point ===

Set the [P], [I] and [D] value to zero. Without a P and I there will no position correction at all, the motor will just hold its current position.

=== Setting Vmax ===

With this [Vmax] parameter we control the amount of energy applied to the motor. The software has the option to increase the value if required, that is controlled by the [Voltage Correction] percentage, which would be yet another unpredictable variable impacting the tuning. Hence set this to zero for now.
Now turn the motor by hand against the motor momentum and predict how much force will be required to hold the camera in a steady position at any time.

In this example video the starting value is 190 and there is a clear resistance to any manual movement. Then the value gets reduced to 55 and you can see that the motor can be turned almost freely. In fact, it does not even have enough power to keep the current position - so much about my gimbal being balanced perfectly, right? And finally the value is set to its max of 255.
In principle using the max value would be okay, except that it is a waste of battery power and the motor might get hot. Therefore the advice is to define a useful low [Vmax] value, in case this is too low in extreme situations, we can allow temporarily higher values later by using the [Voltage Correction] option.

Note: A common misconception is that the motor needs to work against the static forces of an improperly balanced gimbal only. Hence you can get away with smaller motors if only your gimbal is very well built. This is true from the static forces. But as soon as you want to move the camera with the stick, the motor has to work against the mass momentum of the camera. And then there are unpredictable dynamic forces like wind resistance etc. Keep all of that in mind when estimating the amount of force the motor should apply to the camera.

{{#ev:youtube|wq6e38EWjWE}}

=== The D-Parameter ===

The [D]erivative term of the PID control loop is not directly related to the movement of the gimbal, it is a high frequency correction looking ahead, in order to dampen future oscillations. If this value is too high, the frequency of the correction itself gets visible/audible. Therefore, by keeping P and I at zero and just increasing the D value, we can see at what value no high frequency noise is audible on the gimbal motor. The value should be as large as possible but without noise. Once you found a good value, move the motor by hand to doublecheck no noise is at any motor position the gimbal might ever reach. If you find one value working in almost all positions except one, that would be an indicator for an imperfectly balanced gimbal on this axis. Go back to start.

Note: In the GUI you can move the slider with the cursor keys as well. Click on the slider handle and then one click with the left/right key does change the value by its minimal step width. Very useful, especially for the [D] values.

Listen to this video here. Initially D=0.17 and the gimbal is shaking like mad. A very low frequency with high amplitudes. Then the value is reduced to D=0.10 which lets the position to remain stable but a higher frequency noise can be heard clearly. With D=0.05 the frequency is even higher, we want the frequency to be so high that no noise is audible. At D=0.04 the noise is suddenly gone.

{{#ev:youtube|voxJ9IAcaQg}}

=== The P-Parameter ===

Now set the [I] value to 5, which is the lowest non-zero value and start tuning the [P]roportional term of the PID controller. This constant is multiplied with the positional error to get the correction amount. Exactly like in the example in the introduction at the top of this page. The higher the factor is the higher the calculated correction amount will be. If it is too high we will have the tendency of overshooting the target position and if it is way too high we would get even totally erratic movements. Hence our goal is to have a very high value here but a smooth movement in all motor positions.

The video below shows the procedure. After five seconds the [P] and I are set to values greater than zero and the Gimbal moves into a level position automatically. Then the [P] value is increased and we keep seeing the same behavior. Once [P]=15 there are some weird shakes when the motor is released from a tilted position, which gets worse and worse and with P=23 the camera does shake for a while even. Only once the [P] value is down at 13.0 a smooth movement from all positions is achieved again.

{{#ev:youtube|O_FC6S_Lpgs}}

=== The I-Parameter ===

Now we want to set [I] to the maximum value possible without introducing any side effects. If you look carefully at the last few seconds of the previous video, when [I] was at 5 still, the camera could not be kept level when the gimbal itself was moved. The [I]ntegral term (integral over the time) is responsible for this part of the movement.

In the video below the [I] value is increased to 480 initially and in comparison you can see the same movement with I=5. Perfect movement now, fast speed, the camera remains horizontal, it truly is horizontal, everything fine. But maybe we can increase it even further. At 700 the same situation, everything looks nice. But at I=1200 you can see that the camera no longer is horizontally aligned, the "time" aspect of the control loop starts to overcompensate. If you look carefully at the yellow cable of the IMU connector, it is vibrating - sorry, not very visible in the video. So 1200 is a too high value for sure. There were slight vibrations in some positions of the camera at 700 even, so [I] got set to 620 at the end.

{{#ev:youtube|kGFhd7Q4vgw}}

== Repeat above 5 steps ==

First with the roll axis and at the end with the Yaw axis. Yaw is somewhat differently as there is no "horizontal" or zero position in Yaw. And because the Yaw axis has to carry the most weight, the power values are usually higher there, or a larger motor is used.

== Next step - RC Inputs ==

With these settings we have a self leveling gimbal. No matter what movements the gimbal support is undergoing, the camera remains stable. While this might be perfectly sufficient for basic operation, normally the gimbal shall also be moved via a RC stick or, on a hand-held gimbal, via a joystick, or functions such as switching between hold and pan modes or releasing the shutter of the camera remotely are desired.

You can learn about these possibilities in the next chapters; continue with [[Configure the RC Input]].

PID online simulator

2014-06-14T12:56:42Z

Yang:

== Ideal PID values ==

You can plan with the characteristics of an PID control loop yourself using this [http://www.rentanadviser.com/en/pid-fuzzy-logic/pid-fuzzy-logic.aspx online-simulator] here.
First click on the "Plot Realtime" button and now you can play with the input value R(t) by moving the slider as if you would tell our gimbal to move to a new target position. In the diagram the red line shows your value R(t), the target value, and the blue line is the actual position. With the initial values for PID there is a short delay but the target value is reached quickly and without overshooting it. Nice.

[[File:Pid-1-ideal.png]]

== D-parameter too high ==
Now increase D to 0.2, same behavior. When D=0.3 there are some oscillations in the diagram but the target value is reached after 5 seconds.
Now increase D to 0.4. At first nothing does happen as there is no or almost no error. But even the slightest change kicks the logic into maximum oscillations that will never stop.
That is the reason why we need to tune the parameters not only from a static position, but also while oscillating already and in all different positions.

[[File:Pid-2-d-too-high.png]]

== P-parameter too high ==
Same behavior you will find when the P or I part gets too high. At P=1.2 I=0.5 and D=0.2 and changing the input value R(t) with the slider shows that the target value is reached quickly but with first oscillations already. Increasing P to 1.5 and it takes ages already until the target value is reached.

[[File:Pid-3-p-too-high.png]]

== I-Parameter too high ==
And at I=15 (P=0.5; D=0.2) the target position is never reached again.

[[File:Pid-4-I-too-high.png]]

PID online simulator

2014-06-14T12:55:14Z

Yang: /* D-parameter too high */

PID online simulator

2014-06-14T12:54:21Z

Yang:

== Ideal PID values ==

You can plan with the characteristics of an PID control loop yourself using this [http://www.rentanadviser.com/en/pid-fuzzy-logic/pid-fuzzy-logic.aspx online-simulator] here.
First click on the "Plot Realtime" button and now you can play with the input value R(t) by moving the slider as if you would tell our gimbal to move to a new target position. In the diagram the red line shows your value R(t), the target value, and the blue line is the actual position. With the initial values for PID there is a short delay but the target value is reached quickly and without overshooting it. Nice.

[[File:Pid-1-ideal.png]]

== D-parameter too high ==
Now increase D to 0.2, same behavior. When D=0.3 there are some oscillations in the diagram but the target value is reached after 5 seconds.
Now increase D to 0.4. At first nothing does happen as there is no or almost no error. But even the slightest change kicks the logic into maximum oscillations that will never stop.
That is the reason why we need to tune the parameters not only from a static position, but also while oscillating already and in all the different location.

[[File:Pid-2-d-too-high.png]]

== P-parameter too high ==
Same behavior you will find when the P or I part gets too high. At P=1.2 I=0.5 and D=0.2 and changing the input value R(t) with the slider shows that the target value is reached quickly but with first oscillations already. Increasing P to 1.5 and it takes ages already until the target value is reached.

[[File:Pid-3-p-too-high.png]]

== I-Parameter too high ==
And at I=15 (P=0.5; D=0.2) the target position is never reached again.

=== The Starting Point ===

Set the [P], [I] and [D] value to zero. Without a P and I there will no position correction at all, the motor will just hold its current position.

[[File:Pid-4-I-too-high.png]]

PID online simulator

2014-06-14T12:53:04Z

Yang: Created page with "You can plan with the characteristics of an PID control loop yourself using this [http://www.rentanadviser.com/en/pid-fuzzy-logic/pid-fuzzy-logic.aspx online-simulator] here. ..."

You can plan with the characteristics of an PID control loop yourself using this [http://www.rentanadviser.com/en/pid-fuzzy-logic/pid-fuzzy-logic.aspx online-simulator] here.
First click on the "Plot Realtime" button and now you can play with the input value R(t) by moving the slider as if you would tell our gimbal to move to a new target position. In the diagram the red line shows your value R(t), the target value, and the blue line is the actual position. With the initial values for PID there is a short delay but the target value is reached quickly and without overshooting it. Nice.

[[File:Pid-1-ideal.png]]

Now increase D to 0.2, same behavior. When D=0.3 there are some oscillations in the diagram but the target value is reached after 5 seconds.
Now increase D to 0.4. At first nothing does happen as there is no or almost no error. But even the slightest change kicks the logic into maximum oscillations that will never stop.
That is the reason why we need to tune the parameters not only from a static position, but also while oscillating already and in all the different location.

[[File:Pid-2-d-too-high.png]]

Same behavior you will find when the P or I part gets too high. At P=1.2 I=0.5 and D=0.2 and changing the input value R(t) with the slider shows that the target value is reached quickly but with first oscillations already. Increasing P to 1.5 and it takes ages already until the target value is reached.

[[File:Pid-3-p-too-high.png]]

And at I=15 (P=0.5; D=0.2) the target position is never reached again.

=== The Starting Point ===

Set the [P], [I] and [D] value to zero. Without a P and I there will no position correction at all, the motor will just hold its current position.

[[File:Pid-4-I-too-high.png]]

Tuning Recipe

2014-06-14T12:52:39Z

Yang:

The biggest problem for people new to brushless gimbals is finding the correct values of the PID parameters. A PID controller is a well known and often used method for calculating a new input value by measuring the difference between the current state compared with the target state and applying a formula to the difference. In theory, after such calculation, the target state would be reached immediately, but in reality the motor is not indefinitely fast. So in the next iteration there is a an error still, smaller but it exists and a better input value will be calculated based on the now current difference between actual and target.

Due to this iterative approach the control loop can react very precisely to any kind of distortions, however all kind of bad things might happen if the formula is wrong. For example the gimbal might look down by 15°, our formula is: motorpower = 15° * 2W/°. Due to this amount of power the motor turns 30° instead of the expected 15°. So in the next iteration the direction is inverted to -15° * 2W/° = -30W (30W in the reverse direction). The effect would be a shaking of the motor between the +15° and -15° position. The formula used by a PID control algorithm is more advanced than above example and is optimized for quick reaction without overshooting the the target position (much). But even here, if the parameters are wrong, you get all kinds of weird movement patterns.

see [http://en.wikipedia.org/wiki/PID_controller Wikipedia] for the details

== Balancing the Gimbal ==

Before you do any tuning, the gimbal has to be balanced. Balancing means the center of gravity of the mounted camera is in the center of all three gimbal motor axis. This can be tested quite easily by moving the camera by hand, while all gimbal motors are turned off, and the camera should remain in that position if you let go.
A perfectly balanced gimbal has multiple advantages

* We want to move the camera with the RC stick. When the center of gravity would e.g. be below the pitch axis, the camera would try to get into the vertical position by itself. Which sounds like a good idea at first sight, but as soon as we look downwards or upwards, this effect would work against us.
* If the gimbal as a whole is accelerated, the camera would move as well - see image below.
* The motors need to apply more power to keep the camera in the selected position.

In reality you will always need to compromise here, e.g. the Nex Camera has a lens that moves in and out when zooming, the gimbal does not allow infinite adjustments etc. Hence take considerable effort to balance the gimbal but at some point it will be good enough. The stronger the motors are in relationship to the camera weight the more reserve you have, for weaker motors a perfect balance will be more important.

[[File:DSC_7111.jpg]]

Imagine the copter would accelerate to the right. Because the center of gravity is below the pitch axis, the camera would look a bit downward then.

{{#ev:youtube|4Mq2NTyiBf8}}

== Tuning Procedure ==

As each value on every axis might impact the other axis, best approach is to enable one axis after the other. Hence the first step in tuning a brand new gimbal would be to disable all motors except the Pitch motor and find the proper parameters for that. Then enable the Roll motor and tune its parameters, finally the Yaw axis.
Our goal with the PID tuning is to find the highest value for each of the [P], [I] and [D] parameters, that work stable still. The higher the values are the higher the corrective signal will be and the better distortions can be compensated. If one of the values are too large, it does overcompensate, something we would notice as oscillations, noise or erratic behavior in worst case.
Another point is we will start with a low value, then increase it until we get into an area the gimbal starts to behave imperfectly and then we move back until it works again. The reason is simply when increasing the value we test the control loop behavior while the gimbal has no distortions at all. Once these distortions are visible and we reduce the parameter value again, we will find the value needed to balance an currently oscillating gimbal. A concrete example from below videos: A value D=0.04 was picked, everything was fine. It got increased to 0.05, everything was fine still. At D=0.06 heavy vibrations were visible, hence I did step back to the previous D=0.05 value but now there were vibrations here as well! I could manually move the motor into a different position and then the vibrations are gone. What happened?
At 0.06 I was at a resonance frequency of the control loop, but with a slight decrease back to 0.05 the frequency was very similar still and the control loop was not able to get out of this by itself. To be on the safe side I picked 0.04 for [D], as at this value the shaking did stop by itself.
The other thing I do is turning the motors by hand into all allowed positions. Please note, this has less to do with the PID regulation as such, it is a test if the current parameter values work in all positions rather. If the gimbal and camera would be balanced perfectly, there would not be a need for that. But in reality....

[[File:1main.png]]

If you want to know more about the PID control loop, there is a [[PID online simulator]] page show the effects in a diagram.

=== Setting Vmax ===

With this [Vmax] parameter we control the amount of energy applied to the motor. The software has the option to increase the value if required, that is controlled by the [Voltage Correction] percentage, which would be yet another unpredictable variable impacting the tuning. Hence set this to zero for now.
Now turn the motor by hand against the motor momentum and predict how much force will be required to hold the camera in a steady position at any time.

In this example video the starting value is 190 and there is a clear resistance to any manual movement. Then the value gets reduced to 55 and you can see that the motor can be turned almost freely. In fact, it does not even have enough power to keep the current position - so much about my gimbal being balanced perfectly, right? And finally the value is set to its max of 255.
In principle using the max value would be okay, except that it is a waste of battery power and the motor might get hot. Therefore the advice is to define a useful low [Vmax] value, in case this is too low in extreme situations, we can allow temporarily higher values later by using the [Voltage Correction] option.

Note: A common misconception is that the motor needs to work against the static forces of an improperly balanced gimbal only. Hence you can get away with smaller motors if only your gimbal is very well built. This is true from the static forces. But as soon as you want to move the camera with the stick, the motor has to work against the mass momentum of the camera. And then there are unpredictable dynamic forces like wind resistance etc. Keep all of that in mind when estimating the amount of force the motor should apply to the camera.

{{#ev:youtube|wq6e38EWjWE}}

=== The D-Parameter ===

The [D]erivative term of the PID control loop is not directly related to the movement of the gimbal, it is a high frequency correction looking ahead, in order to dampen future oscillations. If this value is too high, the frequency of the correction itself gets visible/audible. Therefore, by keeping P and I at zero and just increasing the D value, we can see at what value no high frequency noise is audible on the gimbal motor. The value should be as large as possible but without noise. Once you found a good value, move the motor by hand to doublecheck no noise is at any motor position the gimbal might ever reach. If you find one value working in almost all positions except one, that would be an indicator for an imperfectly balanced gimbal on this axis. Go back to start.

Note: In the GUI you can move the slider with the cursor keys as well. Click on the slider handle and then one click with the left/right key does change the value by its minimal step width. Very useful, especially for the [D] values.

Listen to this video here. Initially D=0.17 and the gimbal is shaking like mad. A very low frequency with high amplitudes. Then the value is reduced to D=0.10 which lets the position to remain stable but a higher frequency noise can be heard clearly. With D=0.05 the frequency is even higher, we want the frequency to be so high that no noise is audible. At D=0.04 the noise is suddenly gone.

{{#ev:youtube|voxJ9IAcaQg}}

=== The P-Parameter ===

Now set the [I] value to 5, which is the lowest non-zero value and start tuning the [P]roportional term of the PID controller. This constant is multiplied with the positional error to get the correction amount. Exactly like in the example in the introduction at the top of this page. The higher the factor is the higher the calculated correction amount will be. If it is too high we will have the tendency of overshooting the target position and if it is way too high we would get even totally erratic movements. Hence our goal is to have a very high value here but a smooth movement in all motor positions.

The video below shows the procedure. After five seconds the [P] and I are set to values greater than zero and the Gimbal moves into a level position automatically. Then the [P] value is increased and we keep seeing the same behavior. Once [P]=15 there are some weird shakes when the motor is released from a tilted position, which gets worse and worse and with P=23 the camera does shake for a while even. Only once the [P] value is down at 13.0 a smooth movement from all positions is achieved again.

{{#ev:youtube|O_FC6S_Lpgs}}

=== The I-Parameter ===

Now we want to set [I] to the maximum value possible without introducing any side effects. If you look carefully at the last few seconds of the previous video, when [I] was at 5 still, the camera could not be kept level when the gimbal itself was moved. The [I]ntegral term (integral over the time) is responsible for this part of the movement.

In the video below the [I] value is increased to 480 initially and in comparison you can see the same movement with I=5. Perfect movement now, fast speed, the camera remains horizontal, it truly is horizontal, everything fine. But maybe we can increase it even further. At 700 the same situation, everything looks nice. But at I=1200 you can see that the camera no longer is horizontally aligned, the "time" aspect of the control loop starts to overcompensate. If you look carefully at the yellow cable of the IMU connector, it is vibrating - sorry, not very visible in the video. So 1200 is a too high value for sure. There were slight vibrations in some positions of the camera at 700 even, so [I] got set to 620 at the end.

{{#ev:youtube|kGFhd7Q4vgw}}

== Repeat above 5 steps ==

First with the roll axis and at the end with the Yaw axis. Yaw is somewhat differently as there is no "horizontal" or zero position in Yaw. And because the Yaw axis has to carry the most weight, the power values are usually higher there, or a larger motor is used.

== Next step - RC Inputs ==

With these settings we have a self leveling gimbal. No matter what movements the gimbal support is undergoing, the camera remains stable. While this might be perfectly sufficient for basic operation, normally the gimbal shall also be moved via a RC stick or, on a hand-held gimbal, via a joystick, or functions such as switching between hold and pan modes or releasing the shutter of the camera remotely are desired.

You can learn about these possibilities in the next chapters; continue with [[Configure the RC Input]].

Tuning Recipe

2014-06-14T12:50:29Z

Yang:

The biggest problem for people new to brushless gimbals is finding the correct values of the PID parameters. A PID controller is a well known and often used method for calculating a new input value by measuring the difference between the current state compared with the target state and applying a formula to the difference. In theory, after such calculation, the target state would be reached immediately, but in reality the motor is not indefinitely fast. So in the next iteration there is a an error still, smaller but it exists and a better input value will be calculated based on the now current difference between actual and target.

Due to this iterative approach the control loop can react very precisely to any kind of distortions, however all kind of bad things might happen if the formula is wrong. For example the gimbal might look down by 15°, our formula is: motorpower = 15° * 2W/°. Due to this amount of power the motor turns 30° instead of the expected 15°. So in the next iteration the direction is inverted to -15° * 2W/° = -30W (30W in the reverse direction). The effect would be a shaking of the motor between the +15° and -15° position. The formula used by a PID control algorithm is more advanced than above example and is optimized for quick reaction without overshooting the the target position (much). But even here, if the parameters are wrong, you get all kinds of weird movement patterns.

see [http://en.wikipedia.org/wiki/PID_controller Wikipedia] for the details

== Balancing the Gimbal ==

Before you do any tuning, the gimbal has to be balanced. Balancing means the center of gravity of the mounted camera is in the center of all three gimbal motor axis. This can be tested quite easily by moving the camera by hand, while all gimbal motors are turned off, and the camera should remain in that position if you let go.
A perfectly balanced gimbal has multiple advantages

* We want to move the camera with the RC stick. When the center of gravity would e.g. be below the pitch axis, the camera would try to get into the vertical position by itself. Which sounds like a good idea at first sight, but as soon as we look downwards or upwards, this effect would work against us.
* If the gimbal as a whole is accelerated, the camera would move as well - see image below.
* The motors need to apply more power to keep the camera in the selected position.

In reality you will always need to compromise here, e.g. the Nex Camera has a lens that moves in and out when zooming, the gimbal does not allow infinite adjustments etc. Hence take considerable effort to balance the gimbal but at some point it will be good enough. The stronger the motors are in relationship to the camera weight the more reserve you have, for weaker motors a perfect balance will be more important.

[[File:DSC_7111.jpg]]

Imagine the copter would accelerate to the right. Because the center of gravity is below the pitch axis, the camera would look a bit downward then.

{{#ev:youtube|4Mq2NTyiBf8}}

== Tuning Procedure ==

As each value on every axis might impact the other axis, best approach is to enable one axis after the other. Hence the first step in tuning a brand new gimbal would be to disable all motors except the Pitch motor and find the proper parameters for that. Then enable the Roll motor and tune its parameters, finally the Yaw axis.
Our goal with the PID tuning is to find the highest value for each of the [P], [I] and [D] parameters, that work stable still. The higher the values are the higher the corrective signal will be and the better distortions can be compensated. If one of the values are too large, it does overcompensate, something we would notice as oscillations, noise or erratic behavior in worst case.
Another point is we will start with a low value, then increase it until we get into an area the gimbal starts to behave imperfectly and then we move back until it works again. The reason is simply when increasing the value we test the control loop behavior while the gimbal has no distortions at all. Once these distortions are visible and we reduce the parameter value again, we will find the value needed to balance an currently oscillating gimbal. A concrete example from below videos: A value D=0.04 was picked, everything was fine. It got increased to 0.05, everything was fine still. At D=0.06 heavy vibrations were visible, hence I did step back to the previous D=0.05 value but now there were vibrations here as well! I could manually move the motor into a different position and then the vibrations are gone. What happened?
At 0.06 I was at a resonance frequency of the control loop, but with a slight decrease back to 0.05 the frequency was very similar still and the control loop was not able to get out of this by itself. To be on the safe side I picked 0.04 for [D], as at this value the shaking did stop by itself.
The other thing I do is turning the motors by hand into all allowed positions. Please note, this has less to do with the PID regulation as such, it is a test if the current parameter values work in all positions rather. If the gimbal and camera would be balanced perfectly, there would not be a need for that. But in reality....

[[File:1main.png]]

You can plan with the characteristics of an PID control loop yourself using this [http://www.rentanadviser.com/en/pid-fuzzy-logic/pid-fuzzy-logic.aspx online-simulator] here.
First click on the "Plot Realtime" button and now you can play with the input value R(t) by moving the slider as if you would tell our gimbal to move to a new target position. In the diagram the red line shows your value R(t), the target value, and the blue line is the actual position. With the initial values for PID there is a short delay but the target value is reached quickly and without overshooting it. Nice.

[[File:Pid-1-ideal.png]]

Now increase D to 0.2, same behavior. When D=0.3 there are some oscillations in the diagram but the target value is reached after 5 seconds.
Now increase D to 0.4. At first nothing does happen as there is no or almost no error. But even the slightest change kicks the logic into maximum oscillations that will never stop.
That is the reason why we need to tune the parameters not only from a static position, but also while oscillating already and in all the different location.

[[File:Pid-2-d-too-high.png]]

Same behavior you will find when the P or I part gets too high. At P=1.2 I=0.5 and D=0.2 and changing the input value R(t) with the slider shows that the target value is reached quickly but with first oscillations already. Increasing P to 1.5 and it takes ages already until the target value is reached.

[[File:Pid-3-p-too-high.png]]

And at I=15 (P=0.5; D=0.2) the target position is never reached again.

=== The Starting Point ===

Set the [P], [I] and [D] value to zero. Without a P and I there will no position correction at all, the motor will just hold its current position.

[[File:Pid-4-I-too-high.png]]

=== Setting Vmax ===

With this [Vmax] parameter we control the amount of energy applied to the motor. The software has the option to increase the value if required, that is controlled by the [Voltage Correction] percentage, which would be yet another unpredictable variable impacting the tuning. Hence set this to zero for now.
Now turn the motor by hand against the motor momentum and predict how much force will be required to hold the camera in a steady position at any time.

In this example video the starting value is 190 and there is a clear resistance to any manual movement. Then the value gets reduced to 55 and you can see that the motor can be turned almost freely. In fact, it does not even have enough power to keep the current position - so much about my gimbal being balanced perfectly, right? And finally the value is set to its max of 255.
In principle using the max value would be okay, except that it is a waste of battery power and the motor might get hot. Therefore the advice is to define a useful low [Vmax] value, in case this is too low in extreme situations, we can allow temporarily higher values later by using the [Voltage Correction] option.

Note: A common misconception is that the motor needs to work against the static forces of an improperly balanced gimbal only. Hence you can get away with smaller motors if only your gimbal is very well built. This is true from the static forces. But as soon as you want to move the camera with the stick, the motor has to work against the mass momentum of the camera. And then there are unpredictable dynamic forces like wind resistance etc. Keep all of that in mind when estimating the amount of force the motor should apply to the camera.

{{#ev:youtube|wq6e38EWjWE}}

=== The D-Parameter ===

The [D]erivative term of the PID control loop is not directly related to the movement of the gimbal, it is a high frequency correction looking ahead, in order to dampen future oscillations. If this value is too high, the frequency of the correction itself gets visible/audible. Therefore, by keeping P and I at zero and just increasing the D value, we can see at what value no high frequency noise is audible on the gimbal motor. The value should be as large as possible but without noise. Once you found a good value, move the motor by hand to doublecheck no noise is at any motor position the gimbal might ever reach. If you find one value working in almost all positions except one, that would be an indicator for an imperfectly balanced gimbal on this axis. Go back to start.

Note: In the GUI you can move the slider with the cursor keys as well. Click on the slider handle and then one click with the left/right key does change the value by its minimal step width. Very useful, especially for the [D] values.

Listen to this video here. Initially D=0.17 and the gimbal is shaking like mad. A very low frequency with high amplitudes. Then the value is reduced to D=0.10 which lets the position to remain stable but a higher frequency noise can be heard clearly. With D=0.05 the frequency is even higher, we want the frequency to be so high that no noise is audible. At D=0.04 the noise is suddenly gone.

{{#ev:youtube|voxJ9IAcaQg}}

=== The P-Parameter ===

Now set the [I] value to 5, which is the lowest non-zero value and start tuning the [P]roportional term of the PID controller. This constant is multiplied with the positional error to get the correction amount. Exactly like in the example in the introduction at the top of this page. The higher the factor is the higher the calculated correction amount will be. If it is too high we will have the tendency of overshooting the target position and if it is way too high we would get even totally erratic movements. Hence our goal is to have a very high value here but a smooth movement in all motor positions.

The video below shows the procedure. After five seconds the [P] and I are set to values greater than zero and the Gimbal moves into a level position automatically. Then the [P] value is increased and we keep seeing the same behavior. Once [P]=15 there are some weird shakes when the motor is released from a tilted position, which gets worse and worse and with P=23 the camera does shake for a while even. Only once the [P] value is down at 13.0 a smooth movement from all positions is achieved again.

{{#ev:youtube|O_FC6S_Lpgs}}

=== The I-Parameter ===

Now we want to set [I] to the maximum value possible without introducing any side effects. If you look carefully at the last few seconds of the previous video, when [I] was at 5 still, the camera could not be kept level when the gimbal itself was moved. The [I]ntegral term (integral over the time) is responsible for this part of the movement.

In the video below the [I] value is increased to 480 initially and in comparison you can see the same movement with I=5. Perfect movement now, fast speed, the camera remains horizontal, it truly is horizontal, everything fine. But maybe we can increase it even further. At 700 the same situation, everything looks nice. But at I=1200 you can see that the camera no longer is horizontally aligned, the "time" aspect of the control loop starts to overcompensate. If you look carefully at the yellow cable of the IMU connector, it is vibrating - sorry, not very visible in the video. So 1200 is a too high value for sure. There were slight vibrations in some positions of the camera at 700 even, so [I] got set to 620 at the end.

{{#ev:youtube|kGFhd7Q4vgw}}

== Repeat above 5 steps ==

First with the roll axis and at the end with the Yaw axis. Yaw is somewhat differently as there is no "horizontal" or zero position in Yaw. And because the Yaw axis has to carry the most weight, the power values are usually higher there, or a larger motor is used.

== Next step - RC Inputs ==

With these settings we have a self leveling gimbal. No matter what movements the gimbal support is undergoing, the camera remains stable. While this might be perfectly sufficient for basic operation, normally the gimbal shall also be moved via a RC stick or, on a hand-held gimbal, via a joystick, or functions such as switching between hold and pan modes or releasing the shutter of the camera remotely are desired.

You can learn about these possibilities in the next chapters; continue with [[Configure the RC Input]].

File:Pid-4-I-too-high.png

2014-06-14T12:49:53Z

Yang:

File:Pid-3-p-too-high.png

2014-06-14T12:48:57Z

Yang:

File:Pid-2-d-too-high.png

2014-06-14T12:47:41Z

Yang:

File:Pid-1-ideal.png

2014-06-14T12:45:02Z

Yang: