TA: Aaron Parks (Big thanks to him for fixing our hardware countless times!)
Team members: Antonius Harijanto, Chuong Dao, Matthew Dorsett, Matthew Kraus
History
Origin of a Blimp
For centuries, the concept of a flying ship fascinated inventors. As
technology progressed, engineers experimented with airships, which are
somewhat different in design than what are commonly referred to today as
blimps. Early airships had rigid hulls and were a means of public
transportation during the 1920s and 1930s The Hindenburg is a well-known
example of an airship that used hydrogen, but helium was also used in
other airships. The lesser known USS Shenandoah (ZR-1) built by the US
Navy used the inert gas helium. Although it used helium (that is not
flammable like hydrogen), the Shenandoah also ended in disaster, killing
14 of the crew in 1925. Attempting to navigate through harsh weather,
the crew struggled to release expanding helium gas as the airship was
rapidly pushed up by storm currents, but the expanding helium overcame
the containing strength of the hull, bursting the ship in half. An
insufficient number of gas valves (used to release helium), in
combination with uncontrollable, harsh weather, were cited as the
primary causative factors to the crash. Modern blimps use similar tanks
to regulate the amount of compressed helium to control blimp height and
pressure. Although the principles of buoyancy were not unknown to the
airship pioneers, the practicality of airships for warfare or public
transportation was heavily questioned and eventually abandoned. The
modern day incarnation of the airship has been reduced to blimps used
mainly for advertising. Other applications of the blimp include games,
such as the Kirov Airship used in the “Command and Conquer: Red Alert”
franchise (inspired by the actual Soviet Navy cruiser named “Kirov”) as
well as academia courses that use blimps as a vehicle for teaching
embedded systems.
References:
SEPTEMBER OCTOBER. (2005). American History, 40(4), 14-15.
“Shenandoah” Disaster. September 10, 1925.
Overview
Introduction to BlimpBot
BlimpBot is one of UW's CSE 466 class projects. BlimpBot is a small gondola robot that is attached to an air ballon. The project is about designing a system for the robot to control the air ballon. The purpose of the project is to be able to control the blimp in a manual/semi-automated way. The manual controller would allow user to control the direction of the robot using a computer, the automated controllers allow the blimp to maintain its own height and the collision avoidance controller tries to avoid collisions when the blimp flies.
Overview of the implementation
Below is the technical feature implemented for our BlimpBot project:
1. BlimpBot system
The system is programmed onto TI MSP430F5510 microcontroller that is embedded on the BlimpBot.
The microcontroller already has a built-in implementation of hardware UART, hardware Timer, and ADC10 that eases
the BlimpBot system implementation.
In addition to the microcontroller, there are five infrared sensors on the BlimpBot that are used to detect obstacles
and measure height. The sensor is connected and controlled by the MSP430 microcontroller.
The infrared sensor consists of a wide-range IR receiver and five narrow-range IR emitter mounted on the front, back, left, right, and down sides of the bot.
Receiver :
Emitter :
Lastly, there is a port for RF2500 debugger that is being used to send commands to the bot.
In this project, the debugger is connected to a microcontroller board with radio capability, RF2500, that is hooked to a computer through a wireless
radio.
2. RF communication
The radio communication between BlimpBot and the computer is done through RF2500, which is a microcontroller with radio communication
capability.
The connection schematic is as follow:
BlimpBot <-[UART]-> RF2500.......<-[RADIO]->....... RF2500 <-[UART]-> Computer
3. PC GUI
We also developed a PC-side application to communicate with the bot. The PC application sends the data to RF2500 through UART and the
RF2500 relays it to the other RF2500 that is connected to the blimp.
The PC application is a GUI application that has interface to control the blimp's direction and also turning on/off the features.
For the communication, we have a notion of "command". A command is stream of bytes that is prefixed by
a '$' and enclosed by a ';'
This message framing is done to ease the data parsing through UART. A command is something that the
PC and BlimpBot agrees on as way to communicate.
Here are some example of commands:
"$STOP;" tells the bot to go to stop state.
"$RUN;" tells the bot to go to start running. (eg. starting the PID-based height controller)
"$MOT0>100" tells the bot to run the left motor with power 100.
WCI Module
As mentioned in the 'System Design' section, WCI is a module that handles the command parsing. On the network communication,
it is responsible for deciding whether what is being enclosed between a '$' and a ';' is a valid or not.
Given the raw packet streams, WCI module parses them into a structure that the BlimpBot system understands.
The fundamental idea is to abstract the complex communication details from the BlimpBot system implementor.
In our case, the system implementor only needed to know how to use the WCI module, without knowing anything about the WCI other than its interface.
RF2500
Overview
TI RF2500 is the microcontroller board we use for the wireless communication between
BlimpBot and the computer. RF2500 is a board package from TI that has a wireless radio and MSP430F2274
microcontroller chipset on it.
Two RF2500 boards are used, one on the BlimpBot side and the other is on the computer side. It communicates
to the bot and the computer through the provided hardware UART interface.
Implementation Details RF2500 <-> RF2500
The wireless communication is done using SimpliciTI network stack made by Texas Instrument.
The connection is initiated using the provided SMPL_Commission() facility, which allows two RF2500
devices to communicate as soon as both of them are available, given that each of them knows each other's
network address. When a UART packet is received by the RF2500, it adds it to a circular buffer. RF2500 then sends it
through the radio whenever it has either received 10 bytes of data or it receives a ';'
In a similar manner, whenever the packet is received from the radio link, it adds it to a circular buffer. The difference
is that the packet received would be relayed through the UART right away, without having to wait for a ';' or any specific
packet length.
Computer / BlimpBot
Computer
The computer communicates with the RF2500 board attached to it through an ez430 device, which is a USB-based microcontroller debugger that
provides a USB-to-UART interface. The computer then sees the microcontroller as a standard UART serial device.
BlimpBot
BlimpBot already has a port for RF2500 device. It uses the two outermost pins as the UART RX and TX pin.
Parsing
Both the computer and the bot passes the received UART packet into the WCI module, one byte at a time. The WCI module handles all the complex
parsing of the packets and would do a callback whenever it has a fully-parsed data.
Motor control & IR Sensing
Motor
What is the motor for?
There are three motors on the bot and they are used to control the flying direction of the bot. The vertical motor
is controlling the altitude of the motor, while the left and right motor is controlling the moving direction.
Motor Technical Overview
Each of the motor is controlled by two pins, HI and LO. They could be stopped or ran in a clockwise or counter-clockwise
direction. Since the motor could only get into either a running or not-running state, we control the speed of the rotation
using PWM. By the hardware design, only the left and right motor can be controlled by a hardware PWM however. The vertical
motor needs to be controlled using a software-implemented PWM.
Left / Right Motor Implementation
To control the speed of left/right motor, we configure the timer associated with the motor to be in the set/reset mode.
When this mode is selected, the timer peripheral would toggle an associated pin to output HI or LO depending on the value
that we set on the associated CCR, which in turns turn the motor on/off. In more details, the timer has a counter that gets
incremented for every tick. When this counter is equal to the CCR value we set, the motor would be turned off. And so, if we
want to increase the motor speed, we make the CCR value bigger because it makes the motor turned on longer.
More detailed on which pins corresponds to which CCR and also which pins values correspond to what motor states could be found here: UW CSE 466 Autumn 2012 page.
Vertical Motor Implementation
To control the vertical motor speed, we implemented a software PWM using TimerB (one of the five timer peripherals available in MSP430F5510)
Our implementation of software-based PWM relies on two timer capture/compare-channels interrupt. One of the interrupt disable the motor
when it gets called while the other enable it. Setting the motor is speed is then equivalent to setting up how often one interrupt is called
compared to the other.
Implementation Issues
We found a subtle issue with datatype, which is as follow:
uint32_t sum;
uint16_t a,b;
When we try to do sum = a+b with (a+b) = value(MAX_UINT16_T), the sum does not result in
what is expected. To get around this, we need to change the datatype of a and b both to be uint32_t.
Another issue we found was regarding PWM frequency. If we set the base frequency (a frequency of a single tick) in the
timer that controls the PWM to be too big (meaning that the timer gets called very often), we had a power issue, which is
the RF2500 attached to the bot became less responsive. To work around this, we reduced the base frequency.
We concluded that when the PWM frequency is too high, the system experiences too much noise from the motors, and the communication link fails. Aaron soldered some capacitors on the blimp to reduce noise, which helped immensely.
IR Sensing
IR Sensor Overview
The BlimpBot has five five infrared sensors, on the front, back, left, right, and down. The down one is used to
measure altitude while the rest is to measure something else (eg. obstacles). The sensors are actually consisting
of five narrow-ranged infrared emitters and a single wide-ranged infrared receiver. What really happens on an object/
altitude detection is that the emitted IR gets reflected by the floor/object and then it gets caught be the receiver.
This value captured by the receiver is the sensor reading.
IR Sensor Poller Implementation
The five different sensors are muxed together, and the output of the mux is connected to an input port of the
microcontroller in BlimpBot. Our implementation of the IR sensor poller selects the correct IR sensor to poll
on the MUX, toggle the enable pin of the IR emitter, and sleep for 1000 clock cycles before reading the
the ADC10. This 1000 clock cycles delay is needed because the time that the IR emitter takes to
turn on is significantly slower than the time that ADC10 takes to turn on and produces the sensor reading.
What we do to make the ADC10 reading more reliable is by summing up 200 consecutive sensor readings. As soon
as this is completed, we deactivate the enable bit on the IR emitter to save power.
Autonomous Altitude Control
Autonomous Altitude Control
Controlling Blimp Altitude
The blimp has an autonomous altitude control mode, which allows us to set a target value for the downward-facing IR sensor. The blimp then uses its vertical motor in an attempt to reach a vertical equilibrium at that sensor value. From the GUI we can set that target value on the fly, so even though the blimp's height is controlled autonomously, we still can finely tune the height at which it flies.
PID Controller
The method used to control the altitude is a PID controller; this stands for Proportional, Integral, Derivative. At a constant time interval, the PID controller calculates the signed error between the current value of the downward-facing IR sensor and the target value we set. It then calculates the signed difference between the current error and the error from the last PID update, and saves that as delta_error. Finally, if the absolute value of the error is above a certain threshold, it adds the new error to a running error total, which it saves as integral_error. These three values - error, delta_error, and integral_error - are fields in a PID struct, along with three constants: Kp, Ki, and Kd. The controller then calculates the sum Kp * error + Ki * integral_error + Kd * delta_error and saves that sum as the raw controller output. This output is what we want to apply to the vertical motor, so we must first normalize it to a value between -255 and 255, which are our motor bounds. If the normalized value still exceeds one of these bounds, it is saturated, and we simply return the bound from the PID controller. Otherwise, we return our normalized value, and this value is applied to the motor.
The goal of collision avoidance is to make the BlimpBot move forward without hitting any objects. This is simple in principle, but nearly impossible to implement without hours of countless testing and tweaking. Our design is rudimentary but produces decent results; we have the blimp run straight ahead until it “sees” an obstacle, then it checks the left/right IR sensors to determine which direction is the most “clear”. It then turns that direction and continues to move forward.
Implementation Details
Whenever collision avoidance is activated, the blimp is switched into the corresponding mode called AUTO CONTROL mode. In this mode, the autonomous altitude control is enabled to keep the blimp from touching the ground, and the blimp periodically executes the Collision Avoidance task and the PID Control task.
PC GUI
PC GUI
Below is a screenshot of our PC-side GUI:
Library Selection
The user interface (as well as the PC control side) was written using
C++. Jules’ Utility Class Extensions (JUCE) has a massive 350,000 line
codebase and was used for the graphical front end as well as
multithreading (www.rawmaterialsoftware.com). The C++ Boost library was
used for the serial port communications. As both JUCE and Boost run on
multiple platforms, our GUI is also cross-platform and can be run
natively on Windows and Mac machines. (Although untested, it should work
equally well under Linux). This was important as our development team
had Apple, Windows, and Linux users.
Serial Connection
The serial connection is managed in the upper-right
portion of the screen. When the program is first launched on a machine,
there will not be any serial ports listed in the dropdown combo box.
Click “Add Port...” to add a port such as “COM5” in Windows or
“/dev/tty.uart-B3FF606E6614123C” on Mac. Once you add a port, it will be
remembered the next time you launch the program. Clicking “Connect”
should connect to the RF2500 attached to a UART debugger (the “black”
one, not the “blue” one) that is plugged into the USB port, and the
button should turn green to indicate success. Clicking on “Disconnect”
severs the connection, and the button should turn red to indicate “no
connection.”
Serial Data Window
Once connected, incoming and outgoing serial data
can be viewed in text mode in the upper-left corner of the interface.
Red text indicates text that is sent, and green text indicates received
data. Commands can be typed in the text box below the black serial data
window. Pressing “enter/return” will send the data and clear the
textbox, whereas pressing the “Send” button will send the text but keep
the textbox data; this is useful for spamming if necessary.
Quick Connection
These send commands to the blimp and are named by what
they do.
Elite Commander Modes
“PID mode” activates the blimp’s onboard PID
controller. “Collision Avoidance” activates the avoidance mode. Note
that the Collision Avoidance mode overrides the manual mode, which is
described next.
Steering
This is also known as “manual mode” in which directional
commands are translated into blimp motor commands, effectively steering
the blimp. The orange dot can be dragged around with the mouse, and a
red vector indicates the direction of movement. The Port and Starboard
Engine indicators on the left/right of the Steering widget indicate the
relative direction and power of the left/right fans on the blimp. Note
that if the red vector is pointing up, the blimp moves forward by
pushing air aft (back) as indicated by the engine power meters. Clicking
anywhere in the Steering widget will cause a direction change. The (0,0)
origin represents no movement. The position vector snaps to both x and y
axes, making it easy to reset the blimp speed to exactly zero.
Altitude Control
The altitude dial can be used to set the target sensor value
for the down facing sensor, which is used to update one of the fields in
the PID controller structure. This can be used to set the desired
altitude cruising height of the blimp.
Videos
PID-based altitude controller Demo Video
This video demonstrates the PID-based altitude controller on our BlimpBot. The bot is trying to maintain its altitude so that it does not
hit the ground.
Collision Avoidance Demo Video
This video demonstrates the obstacle avoidance feature of our blimp; or, as we like to call it, "obstacle reaction."
