Developers

Josh Green
Baron Oldenburg
Henry Baba-Weiss

Table of contents

Introduction

In this project we designed a system to control and fly a blimp from a PC. This project included many aspects including creating a GUI to control the blimp, setting up and using a UART between a PC and a MSP430F2274, setting up and using wireless communication on eZ430-RF2500 development boards by using the SimpliciTI API, setting up another UART between a MSP430F2274 and a MSP430F5510, and using the MSP430F5510 to control the Integrated Circuits on the blimp in order to operate it. The end result was a blimp that could fly around in any direction, could maintain a set altitude, could read five IR sensors pointing in different directions and last but certainly not least could play “The Imperial March” from Star Wars.

Many interesting features have been implemented on blimps in the past. E-field sensors on blimps have been used to find outlets. IR sensors have been used on blimps for collision avoidance. Multiple types of control algorithms have been used to increase control. Here are some examples of other things that people have done with blimps:

System Design & Implementation

System Components

The system consists of a PC, two eZ430-RF2500 development boards which carry the MSP430F2274, an MSP430F5510 which was the blimp controller, and a printed circuit board (PCB) to drive the specific components of the blimp. The PC was used to control the blimp through the GUI that we created. The PC and the PC side RF2500 board communicate via UART. The two RF2500’s (PC side and blimp side) communicate over wireless radio using the SimpliciTI network protocol, developed by TI for small low-power RF networks. The blimp side radio communicates to the blimp’s MSP430F5510 again via UART.

System Structure

The blimp PCB contained many different components. The components that we used in this project were the three motors, which controlled the fans, two horizontal and one vertical, and the five IR sensor LEDs. Each of the motors was controlled by a LV8405 H-bridge driver IC. Motor control signals were sent from the blimp MSP430F5510 to one of the LV8405s to enable the motors. The PCB contains five IR LEDs; pointing forward, backward, left, right, and down. Each of these IR LEDs are connected to their own driver circuit which produce the high amount of current needed for the LEDs to work. To control the IR LEDs, four ports of the MSP430F5510 were connected to a 74HC238, which is a demultiplexer IC. Three of these ports were used as select bits and the fourth was used as an enable.

Motor Control

Each motor was controlled by two ports of the MSP430F5510: a High and Low. To make a motor go forward, the High signal must be 0 and the Low signal must be 1. To make a motor go backward High is set to 1 and Low is set to 0. When the motors are not in use they are placed in Stand-By mode by setting both High and Low to 1. To control the speed of the motors pulse width modulation (PWM) was used on the motor control signals.

The speed control of the two horizontal motors was controlled by hardware PWM using the TIMERA0 peripheral. TIMERA0 was used because it is able to produce a different PWM signals for each of the four ports used to control the horizontal motors. The period of the PWM signal was controlled by TA0CCR0 and the duty cycle of each of the four ports was controlled by TA0CCR1, TA0CCR2, TA0CCR3, and TA0CCR4, respectively. The speed of a given motor was then controlled by the duty cycle of the PWM signal on its control ports. With our clock speed set at 8MHz, we set TIMERA0 to 8000 clock cycles, which made our PWM period 1000Hz, or 1ms. We incremented our speed by increasing the controlling TA0CCRx register by 1000, with a cut off at 5000. This gave us five speeds in both directions.

To control the vertical motor we implemented a software PWM using the TIMERB0 peripheral. This PWM had the same 1000Hz (1ms) period and duty cycle settings as the horizontal motors. Depending on the direction of this motor we would toggle the High or Low port for the vertical motor in the TIMERB0 interrupt.

IR Sensor Control

IR sensing is conducted by collecting 256 samples from the ADC. We first set three select ports of the 74HC238 demultiplexer to the desired IR LED. Then we modulate the IR enable pin for 256 samples, reading the ADC when the pin is both high and low, and average the result. We also disable the UART receiver interrupt during sampling to ensure the time between each sample is consistent: IR sampling is a blocking operation, for the most part. The only operation that is allowed to run during the actual IR sampling process is the emulated software PWM for controlling the vertical fan.

Wireless Communication Protocol

For wireless communication between the computer and the blimp, we used two eZ430-RF2500 development boards and the SimpliciTI API. By using the SimpliciTI API we were able to set up point-to-point communication between our two radio boards. We used the SMPL_Commission() function to set up our point-to-point communication. This call takes an address of a device that you will be communication with and connects that device to a LinkID. The next step in the setup process is calling SMPL_Init() which takes a callback function as a parameter. This callback function is what gets called when the radio receives a message. The callback function takes as a parameter a LinkID. This LinkID can then be checked to see if the message is from the desired device. If it is the correct LinkID that we expect, then we use the SMPL_Receive() call to obtain the message. This call takes a LinkID, a message buffer, and a length as a return parameter. To send messages to another radio we used the SMPL_SendOpt() function which takes a LinkID to send the message to, a message buffer, a message length, and a transmit option. We use the SMPL_TXOPTION_ACKREQ transmit option which waits to receive an acknowledgement from the receiving radio before returning. Using this transmission method it is very easy to send messages of varying sizes and confirm their delivery. However, we kept our messages as small as possible, generally only one or two char. Smaller messages are better because they are faster and are less likely to become corrupted.

Wired UART Communication

Inter-module communication was achieved through a UART communication channel open on both the PC, communicating with the base station radio link, and the blimp microcontroller, communicating with the blimp’s radio link. There is a UART command for every possible externally controllable action on the blimp: moving the blimp in several directions, sampling each of the IR sensors, toggling and setting automatic altitude control, and run/stop. Our UART protocol is variable-length, depending on the type of request being transmitted, with a maximum request size of two bytes. Most commands consist of only a single character, while the commands for motor control require an additional byte of data passed. There is only one set of commands and all consist of Latin alphabet characters. This not only promotes consistency between the blimp and PC UART interfaces, but also allows us to easily tie the PC UART in with a command-line interface if necessary.

For processing UART commands, both the blimp and PC end-devices use the same basic design of a simple state machine. For most commands, we can immediately know what a command is when we receive a character over UART. However, for motor control, we need to know both the direction the blimp should be going and the speed at which it should power its motors. Thus, the motor control command has the following two-byte format: the direction to move in, followed by a speed from 0-5 (transmitted as the “number” in ASCII; once again, to maintain support for the CLI). Thus, on both the PC and blimp decoders, we know that if we see a “motor” command, we know that we should expect a second digit character to be received over UART next.

PC Software & GUI

We created our GUI as a Windows Presentation Foundation (WPF) application. We chose this type of application because it includes a toolbox of widgets to quickly and easily design a GUI, and also because we could use the .NET SerialPort Class to easily set up UART communication from the PC to the RF2500.

The GUI consists of buttons to control the motor directions, displays of the blimp’s horizontal and vertical speed, buttons to read the IR sensors, displays for each of the IR sensor values, buttons to set the altitude of the blimp, and buttons to play the song “The Imperial March (Darth Vader’s Theme)” from Star Wars Episode V: The Empire Strikes Back.

Button Descriptions

Initially our GUI motor buttons would send a command to increase, decrease, etc, the speed of the motors. However there was an issue with the radios where they would send the command multiple times so when a motor button was pressed the motors speed would change by more than it was supposed to. To fix this we changed our motor commands to send the desired speed of the motors. This way, even if the blimp received the same motor command multiple times from one button push, the motor will still be set to the correct speed.

GUI

Height Control

To control the height of the blimp we used a simple bang-bang controller. In the main function of the blimp code we had a while loop that periodically read the down IR sensor and compared the sensor value to the set height value and altered the vertical fan speed as necessary. The controller also included an epsilon error range to prevent the controller from being overly sensitive to the inexact IR sensor readings.

This whole process is only done if the blimp is currently in automatic altitude control mode; otherwise we do not sample the IR sensor automatically. When we receive a UART command from the on-board radio to maintain altitude, we begin allowing the IR sensor polling routine to run (in addition to other functionality on the blimp). The first time this is run, we assume the height we want to maintain is the current height. However, if we receive a separate “set height” UART command, then we use the next IR sensor reading as the target height to maintain.

Extras / application

Using the hardware pulse width modulation available on the MSP430F2013 and a piezoelectric speaker, we were able to output “The Imperial March” by transcribing the sheet music for the song into frequencies and cycle delays. We attached this circuit onto the blimp board and connected a port on the blimp radio to a port on the MSP430 which would play the song when it goes high. When the blimp radio receives a command to play the song it simply pulls that port high. We included two commands to play the song: “Play Once”, which briefly pulses the port high; and “Toggle Song Loop”, which toggles the port between low and high (the song will loop as long as the port is high).

Results

Analysis of the blimp controller

The decision to implement automatic altitude control almost entirely on the blimp controller itself was an interesting one. Our rationale was that it would be faster and more accurate to process data from the ADC on-board the blimp, instead of relaying the data all the way back to the base station for processing. In actuality, it turned out that all this processing actually made the blimp controller unable to poll the IR sensor very quickly, which resulted in more error in the sensor readings and, thus, less sensitivity to altitude changes. Specifically, using Timer B0 as a “stopwatch”, we found that the process of maintaining altitude control made the main control loop take about 5,317 cycles to execute (our processor was clocked to 8.388 kHz). To the naked eye, it seemed as if the IR sensor was being polled at a frequency of about 1 measurement per second.

To further analyze the performance of our altitude control, we let it stabilize at an arbitrary set height for 10 seconds, abruptly switched the set point, and waited another 10 seconds for it to stabilize, collecting 10 samples of IR sensor data for both parts. The following graph shows our results:

IR sensor values

Specifically, with this data, the root mean squared error of our altitude control is about 5.1. Thus, while the fluctuations are not exactly horrible, they are definitely more than we would like.

Conclusion

Overall our system worked pretty well. Our motor control system worked, we were able to poll all of the IR sensors, our altitude control worked reasonably well considering the simplicity of the control algorithm used, and the piezoelectric speaker playing Darth Vader’s theme song made it even more impressive. Throughout the project however, we continuously ran into communication issues. Our UART on the blimp seemed to be rather unstable. Towards the end of the project we realized that this might actually be due to bad hardware. Once this was discovered we got a new blimp PCB and got our code to run on this new functional board. Once we did this our system reliability increased, confirming that we initially had bad hardware.

Future work

If we had more time to work on this project, we would have liked to implement collision detection using the left/right/front/back IR LEDs. We had a lot of trouble with UART communication; perhaps we would have added some error detection methods to the UART. We also would have liked to experiment with sending information from one blimp to another. Also we tried to use a USB controller to control the fly the blimp but we did not have time to fully implement this.

There was a lot of time spent on setting up the UART communication. Perhaps either an alternative method of communication could be used or the UART could be provided to the student. That way more time could be devoted to implementing the features of the blimp.

Source files

Common files

Modules

UI