myRIO GoPro Gimbal

From home movies to live action cinema, a steady picture is always a sign of high quality video.
Production studios everywhere have large complex setups to keep their cameras stable while
they record masterpieces for the big screen, but that’s out of reach for the hobbyist video
maker. Depending on the location, those kinds of apparatus may not even be feasible. Wireless
drones, for instance, have become a way to capture stunning new video; but due to their small
size and weight limitations, stable video can be quite a challenge.

The camera gimbal has been a unique advancement in video recording. It is an inverse motion
device, used to keep the camera steady across as many axes as it supports. Regardless of how
the gimbal is handled, it seeks to maintain the desired camera position. Precise control
algorithms applied to motors in the gimbal’s structure account for changes in the camera’s
support and correct for them. Depending on the number of axes, these devices can become
very complex and expensive, but single and dual access gimbals can be built and designed
relatively cheaply. This project was completed to show how dual axis hardware could be
controlled using NI’s new myRIO. The goal was to produce a relatively inexpensive gimbal, thus
enabling anyone to get the professional touch they’re looking for.
Building a Camera Gimbal
There are currently many designs out there for camera gimbals. Each becomes more complex
based on the number of axis it supports, different drive options, sensors, controller, and the
camera that it supports. For this project we chose to create a single-axis gimbal using Brushless
DC (BLDC) motors. A few key advantages of the design led us to select it. Mechanically, the
frame is very light and simple. Both axes of rotation pass through the center of gravity of the
camera and frame, which allows the inertia of the system to work with our controller instead of
against it. The use of BLDC motors also allows for direct drive to both rotational axes,
eliminating backlash usually inherent in a geared or belt driven system. Because the design is so
light and simple there are quite a few reasonably priced setups readily available for purchase.
To save ourselves the trouble of machining a frame and rewinding motors we decided to
purchase the frame and motors of the below system made by RCTimer.

The set up gave us a good starting point mechanically, but left us to determine all of the
circuitry required to drive the motors, and a method for positional feedback in order to apply a
control algorithm to the system.

BLDC Motor Control

Brushed motors have a physical connection between the rotating and stationary sections of the
motor in order to shift the control of the current flow through the motor based physical
contacts touching at certain points. The point where the current flow switches is called the
commutation point, and with brushes the exchange is taken care of mechanically. This makes
the operation of the motor very simple; applying current in one direction or the other allows it
to spin. In a BLDC, those physical connections (brushes) are removed and replaced with
accurate control of current traveling into the motor. The direction of current applied to the
motor induces magnetic fields in coils of wire, known as cogs, attached to a stationary stator.
The drive shaft passes through the stator and connects to a casing around the cogs. Permanent
magnetic poles in that casing are attracted or repelled by the cogs depending on the fields
generated. This causes both the casing and the drive shaft to spin.

Casing with Permanent Magnets ------ Motor Stator and Cogs

Ideally these motors would only need to induce two different fields to make a full rotation, but
in application the motor tends to reverse direction with only two fields. As the point of
commutation (the point where the current is reversed) is approached, neither field exerts much
pull on the motor allowing it to often switch directions rather than continuing on. To drive the
motor through those points, BLDC’s are built to induce three separate fields each 120 degrees
out of phase which each other. The addition of the third keeps points of commutation from
lining up and forces the motor to continue spinning.

Three Phase BLDC Motor Diagram

Source: http://bldc.wikidot.com/bldc-and-8051
Adding a third phase to drive the motor increases the complexity of driving the motor. Instead
of simply applying current in one direction or the other, as with a brushed motor, we have to
induce the fields in the correct order at a varying rate, depending on the speed and position of
the motor. Inducing the wrong field can oppose the desired direction and cause loss of torque
and added vibration; as such only one or two fields are generated at a time. Due to the fact that
position and speed are important to the correct operation of BLDC’s, some sort of feedback on
the motor’s electrical position is required. Some motors are made with Hall Effect sensors to
provide that information, but some are not. The motors we used were in the latter category
and require what is known as sensorless operation.

Stepping through BLDC Commuation

Source: http://bldc.wikidot.com/bldc-and-8051

Sensorless operation can be based on a variety of methods and control schemes. The most
popular method is to sense the back EMF of the phase that is not being driven. The point at
which that voltage reaches zero is also the next commutation point. As the two coincide it can
be used to advance to the next step in the pattern at the correct time. The downside to this
method is that enough back EMF voltage must be generated in order for it to be measured,
which does not occur until the motor achieves a higher number of rotations per minute (RPM).
In order to reach those higher RPM’s, a startup procedure is employed. A start up procedure, in
its simplest form, is open loop control of the motor. Once the initial position of the motor is
known, a predetermined pattern can be applied to turn the motor until it reaches a high
enough speed to produce measureable EMF. Other methods use current chopping or current
measurement in order to determine the commutation point, and can be further researched
online.

In the case of the GoPro gimbal, our motors are never intended to complete a full rotation,
which made sensorless control very difficult. Controllably turning the motors proved to be the
most challenging aspect of the project. In the end we elected to use an Electronic Speed
Control (ESC) device. Often found in hobbyist airplanes, the controllers are reasonably priced
(~$20 each) and are pre-built to carry out the proprietary sensorless control of BLDC motors. As
we were on a limited time frame for the project, we deferred the sensorless motor control to
the expertise of the engineers who designed the controller.

The ESC was not a complete solution for driving our motors, it still required an input from our
control to determine the speed of the motor, and it could only drive the motor in a single
direction. In order to change directions we implemented a set of relays controlled by the myRIO
FPGA to reverse the sequence of commutations the ESC was providing the motor. As you recall
from above, a BLDC motor has three inputs for each field it can generate, by swapping the 1st
and 3rd wires between the BLDC and the ESC, we were able to reverse the sequence of
commutations and thus the direction that the ESC drove the motor.

ESC Relay Diagram

Positional Feedback
Now that we were able to drive our motor successfully, we needed to turn that motor based on
the position of our GoPro. To do so we chose to employ the use of an inertial measurement
unit (IMU). For this project, we selected the MPU-6050 due to its small size and I2C
communication abilities.

The MPU 6050 is a single chip made by invensense that has both onboard accelerometers and
gyros. It gives data for the x, y, and z axis for both acceleration and gyro data, and we can use
these values to calculate both pitch and roll. This device is considered to have 6 degrees of
freedom, because of 3 degrees for acceleration and 3 degrees for the gyro.

Gyroscopic data is given as degree/s, so if we integrate that over time, we can determine
position. The problem with integrating over long periods of time is that small errors continue
to build up, and this is what is referred to as gyro drift. Because of this, gyros are only accurate
for small periods of time when the IMU is moving.

Accelerometers are accurate when the IMU is sitting still because you can perform
trigonometry functions on the acceleration vectors knowing that gravity is the only force acting
on the IMU (always in the Z direction at a force of 1G). The trig functions to calculate position
based on the acceleration data are shown below:

Source: http://husstechlabs.com/projects/atb1/using-the-accelerometer/

When the IMU is rotating, gravity is no longer the only force acting on the IMU. Because of this,
position calculations solely based on acceleration data become inaccurate. The additional
rotational forces create an output with spikes, which appears shown as noise in the
acceleration data. To accommodate for this noise we will need to incorporate data from the
gyro in our position calculations.

While accelerometer data is accurate over long periods of time when the IMU is still, Gyros are
accurate over short periods of times when the IMU is moving. By combining these two
measurements, we can get an accurate position reading of the IMU in any state. To combine
them we implemented a high pass filter on the gyroscope to only pass quick changes, and a
low pass filter on the accelerometers to eliminate the spikes of noise when the IMU is moving.
This is done by utilizing a complementary filter. Below is a diagram of how the complimentary
filter operates:
 Source: http://web.mit.edu/scolton/www/filter.pdf.

To implement this complementary filter in code, the following formulas were used:

Filtered Angle = α × (Gyroscope Angle) + (1 − α) × (Accelerometer Angle) where

α = τ/(τ + Δt) and (Gyroscope Angle) = (Last Measured Filtered Angle) + ω×Δt
Δt = sampling rate, τ = time constant greater than timescale of typical accelerometer noise
Source: http://www.geekmomprojects.com/gyroscopes-and-accelerometers-on-a-chip/

The time constant can be modified based on your application. For this project, we found a
value of .5 worked best. With a T Value of .5, time periods less than .5 seconds favor the
gyroscope measurement, and for time periods greater than .5 seconds the accelerometer
position is more heavily weighted. Because our sampling period was .001 seconds, and we
wanted a T=.5, our α=.998:

This is the Block Diagram of our Code that performs the calculations on the accelerometer and
gyroscope data to determine the position of the camera:
Communicating with the MPU-6050
The MPU 6050 transfers it’s data over I2C, a two wire digital communication protocol. The
default address of the IMU is 0x68. The required connections from the myRIO to the I2C chip
are shown below:
The maximum speed that the IMU can transfer data is 400Kbit/s, thus the clock rate for the I2C
communication on the myRIO is set to 400 KHz. To initialize the the IMU at our desired
settings, configuration values are written to registers in the IMU in an Initialization subVI as
shown on the next page:

More information about the registers, and how these values were chosen can be found here:
http://invensense.com/mems/gyro/documents/RM-MPU-6000A.pdf.
The accelerometer and gryo data is stored in the registers shown below:

When we want to retrieve those values, we perform the I2C write read function shown below:

This Writes 0x3B to address 0x68 and reads 14 bytes. The IMU is set up to continue sending the
next register value to the master until the master stops acknowledging., therefore we only
need to write 0x3B and can set the master to read 14 bytes. The array that is output from the
above VI is all 14 bytes, which contain the raw gyro, accelerometer, and temperature data. We
then parse that raw data and convert it to a meaningful position.

PID Control Theory

We are using the PID VI from the PID and Fuzzy Logic toolkit to control the Gimbal System:
The PID controller has a “setpoint” that we give as an input, and the goal of the PID controller is
to make the “process variable input” equal to the “setpoint” by varying the “output”. We
define the possible values of “output” with the “output range” control, which defines the
minimum and maximum possible values of output.

The most important inputs to the PID VI are the PID gains. These numbers determine the
behavior of the control system, and the concept of PID gains is a thoroughly documented
concept in Control Theory. The PID gains are described below from the detailed help:

More information about how these gains determine the output is found from the detailed help
on the PID algorithm and is shown on the next page:
The loop of our main VI that implements PID is shown below:

We are passing the position data from \the IMU through a Single Process Shared Variable with
a single element RT FIFO. We also have the PID VI in a case structure that only executes if the
gimbal is between +- 170 degrees to avoid rotating the gimbal past the length of our wires.
Although our system could improve from better tuning, the PID values we settled on were .085,
0, 1e-5.

Software
LabVIEW myRIO Suite 2013 with FPGA module

PID and Fuzzy Logic Toolkit 2013

Hardware
Gimbal Frame with motors: http://www.rctimer.com/index.php?gOo=goods_details.dwt&goodsid=872

10A Brushless Motor Speed Controller: http://www.rctimer.com/product_149.html

Solid State Relay (Qty 4): http://www.mouser.com/ProductDetail/Panasonic-Electric-

Works/AQV252G/?qs=ZM9KzLiT/SMCdDQ80hqKow==

MPU-6050 with breakout: https://www.sparkfun.com/products/11028

I K Ohm resistor (Qty 4)

Power Supply (10V up to 1A)