Introduction
Blimps are a basic aerial vehicle that have been used in a variety of applications throughout their history. In the early 1900s they were used as transports and carriers, but they have since been replaced in that respect by airplanes for most applications. They remain in use for applications that do not require much mobility, such as advertisment and camera blimps at sporting events, and weather balloons that float in the air to observe atmospheric conditions.
The Blimp Project itself is a very versatile project. Since the blimp board employs a fairly sophisticated MSP430F5510 microcontroller, there are many different approaches and extensions to explore in this project. As part of the required functionality, we created a TCB structure to handle the various tasks of the blimp, utilized onboard IR emitters and sensors through output pins and the ADC_10 peripheral to detect objects nearby, and use eZ430-RF2500s as wireless relays between the blimp and the PC. We also implemented a PID controller to have the blimp automatically maintain or change its elevation. We further expanded the project to include the use of a game controller for manual control as well as collision detection for the front and sides of the blimp.
Related Work
Previous blimp projects have used many different peripherals and extensions, such as a compass and electric field sensors. The Blimp Project is a relatively new addition to the Embedded Systems course, although a similar project was the focus of the Robotics Capstone course in previous years. The robotics project used a more sophisticated processer and used WIFI for communication with the blimp, whereas in this project we focus on the MSP430 controller we studied over the duration of the course. In addition, the applications in this course were more focused than in a capstone course, which is usually fairly open-ended.
Blimps are prominently used in acedemia. In the past, the Emerging Leaders in Engineering K-12 program has created similar blimps as outreach tools and fun projects. Blimps are also the focus of research in many different colleges and industries. The department of atmospheric sciences at UW uses blimps to observe weather patterns and atmospheric conditions. Blimps also have defense/security related applications as they are quite capable of stationary surveillance. Some companies, such as the Airship Research Lab, are actively designing new blimp structures for commercial uses, including ferrying cargo and people while trying to solve common issues like structural integrity, bouyancy, and range and altitude capabilities.
System Design and Implementation
Overview of Functionality
Figure 3.1 shows a general overview of our project. It consists of the Blimp, which is controlled by the MSP430F5510 microcontroller, the UART-wireless relay and the PC-side application. After describing the modification to the hardware, we will discuss the internals of each individual component in detail.
Figure 3.1: System Overview
Hardware Changes
Various non-electrical hardware modifications were made to the standard blimp design to avoid potential pitfalls in collision avoidance, improve blimp responsiveness to motor commands, and enhance testing convenience. Instead of the typical cigar shaped blimp envelope, a circular "flying saucer" shape was used instead. The symetrical profile of the "flying saucer" allowed us to avoid a potential situation where the blimp may get stuck in an area that is too narrow for it to turn due to the length of the cigar shape. In addition, the flat bottom of the saucer opened up the opportunity for an innovative gondola attachment system using rigid supports intead of hanging strings. Two thin Styrofoam bricks were secured to the front and rear of the gondola using sticky Velcro and then attached to the flat bottom of the saucer in the same way. The Velcro allowed easy removal of the gondola for testing. The rigid support made the blimp much more responsive to motor commands by reducing the swaying and twisting inherent in the hanging method. The result was a significant improvement in steering quality.
Blimp Firmware
At a high level, the Blimp firmware is structured into initialization code and six independent tasks. The initialization code is executed once during startup and configures the input and output pins of the LEDs and fans. Moreover, it calibrates the main clock to 12MHz and sets up the peripherals like the UART module, the watchdog timer and the real-time clock.
Figure 3.2 shows the six different tasks that make up the Blimp firmware. The tasks share data by using global variables and use inter-task messages for internal communication. The communication rx task receives external messages from the PC and the communication tx task sends the command response back to the PC.
Figure 3.2: Tasks that make up the blimp firmware
Each task is represented by a task control block (TCB) as shown in Listing 3.1. It contains a function that is called each time the task is executed as well as a pointer to a task specific data structure consisting of references to all the global variables that this task relies upon. Our decision not to access global variables directly but only through the data structure makes the updates of global variables more explicit and the code in the end more readable.
Listing 3.1: Task Control Block (TCB)
We run the tasks in a round-robin fashion but dynamically enable or disable tasks depending on whether they have work to do. To this end, the task control block contains two flags pending_message and periodic. The first indicates that there is a pending external or internal message for this task, whereas the second is set for tasks that should always run regardless whether or not there is a pending message. We run a task if either of the flags is set.
If the blimp is in an idle state, only the communication rx and the system monitor task run -- these are periodic tasks. If the blimp receives an external message, for example to run the left fan forward at speed 42, the flag pending_message of the motor control task is set. Therefore, the motor control task is run the next time it is his turn.
The tasks themselves build upon a variety of subsystems as depicted in figure Figure 3.3. Each subsystem abstracts a specific component or peripheral of the blimp and provides a higher-level interface.
Figure 3.3: Architectural Overview of Blimp Firmware
Four subsystems are related to the various timers and clock sources we have on the blimp: the watchdog timer, the real time clock, the digitally-controlled oscillator and a generic timer subsytem. The latter provides functions to start and stop a timer and to get the current value of the timer. The cpu subsystem provides functionality to enable and disable interrupts, to enter a low power mode as well as synchronization functions used to guard critical sections. Two more systems are related to the leds on the blimp. Both of them provide functions to turn leds on, off or toggle them. Finally, the fan subsystem gives an interface to control an individual fan and the temperature subsystem provides the means to read the current core temperature.
Communication rx and tx tasks
The communication receive task is responsible for receiving the bytes from the UART and assembling them into messages. Whenever the blimp receives a byte an interrupt service routine puts it into a circular buffer. Each time the communication rx task runs it check whether there is a complete message in the circular buffer and if that is the case creates a message structure (see listing 3.2). Moreover, it sets the pending\_message flag for the task that is supposed to handle that kind of message.
Listing 3.2: Structure representing a message from the PC
The communication transmit task checks if any task prepared an outgoing message. If that is the case it starts sending the message using UART. This is done asynchronously, and so the MSP430 can move on to process other tasks.
System Monitor Task
The blimp system can be in a stopped or running state. At startup the blimp is in the stopped state where it accepts only a restricted set of commands. It is possible to send a ping, to put the blimp in the running state, to reset the blimp as well as to query the current system status. All other commands, in particular commands to run the fans or to query a sensor are rejected.
The system monitor task keeps track of the current system status. If we are in the running state and send the stop command, the blimp goes into a fail-safe mode, i.e. it turns the left and right fans off and runs the vertical fan in reverse at a slow speed. This way if the blimp gets stuck at the ceiling, it flies gently down.
Apart from the system state, the blimp can also be in one of two connection states: either connected to the PC GUI or not. It starts up in the not connected state and transitions into the connected state as soon as it receives any command, in particular the ping command. We use the real time clock to record the last time we received a command from the PC. Each time the system monitor runs, it checks what time we received the last command and if it was too long ago, we assume we lost connection to the PC GUI and go into the fail-safe mode.
The system monitor additionally clears the watchdog timer and reads the current temperature if requested from the GUI.
Sensing Task
The sensing task is responsible for measuring proximity using the front, rear, down, port and starboard infrared LEDs. We conduct a new measurement if either the GUI or some other task in the system requests it. The request specifies which of the five sensor values should be updated and we only update those.
A single measurement consists of taking 500 samples. We alternating turning the corresponding IR LED on and off, and then we add and subtract the sample to a sampling sum respectively. Since the sensor values were quite noisy, we use an IIR low-pass filter to reduce the noise. The new sensor value is computed by adding 7/8 of the old filtered sensor value and 1/8 of the new raw sensor value.
The filtered sensor value was then mapped to a distance. The difficulty was that the sensor values do not map linearly to a distance. Therefore, we measured the sensor values at different distances and used those data points to generate a lookup table.
The blue squares in figure 3.4 show the measured sensor values for the down sensor for different heights of the blimp. If the down sensor touches the ground we read 660, at a virtual distance of 255 the sensor value is 290. The sensing task maps the sensor values to a distance as follows: if the sensor value is greater or equal to 660 the distance is 0, and if it is lower than 290 the distance is 255. In between 290 and 660 we use the measured mapping of sensor values to distance. However, we only have a few data point in this range. To get estimates for the other values we use linear interpolation. This way we can come up with a lookup table that maps all possible sensor values between 290 and 660 to a distance in the range of 0 to 255.
Figure 3.4: Mapping of Sensor Values to a Distance
Listing 3.3 shows the MATLAB code we used to generate the lookup table for the down sensor and the red line in figure 3.4 shows the interpolated values.
Listing 3.3: MATLAB code to generate lookup table for down sensor
To save power, we disable the analog to digital converter after the sensing task completes.
Motor Control Task
The three motors for the left, right, and vertical fans are each connected to a channel of the LV8405 H-bridge driver IC. Each channel has a low and a high pin that control the motors as shown in table 3.1.
| High Pin | Low Pin | Motor Output |
|---|---|---|
| High | High | Standby |
| High | Low | Forward |
| Low | High | Reverse |
Table 3.1: Motor states
Pulling both pins low puts the motor in the brake state, essentially shorting the motor and causing large current consumption. Therefore, the code enforces that the motors are never put in this state. The control of the motors occurs in motor_control.c, with the useful macros and function defined in fan.h. During the fan initialization routine the pins controlling the fans are set to output. All six pins are then set high so that the three motors are in the standby state.
Each fan is controlled with standby, forward, and reverse functions. The standby function takes no arguments and sets both pins for the corresponding fan to high. The forward and reverse functions appropriately set the corresponding pins and take an integer argument for the duty cycle. The left and right fans are controlled by pulse-width modulation using Timer A0. One of the pins is held high and the other is toggled by the Timer A output unit. A PWM period of 16384 cycles, which corresponds to a PWM frequency of 733 Hz, is used. Using this PWM period, the fans will not start if the duty period is below 1400 cycles. The duty cycle values passed from the UART protocol to the motor controller are in the range of 0 to 255. These values are linearly mapped to a range of PWM duty periods from 1400 to 9592. The latter range was chosen because only one shift and one addition operation is necessary to map the range 0 to 255 to it. The vertical fan could not be controlled with the same hardware PWM, so a software PWM was implemented using Timer A1. The software PWM operates in a similar manner to the hardware PWM, with one pin being held high and the other being toggled in the interrupt. Two additional functions put all the motors in standby and put the motors into a failsafe mode. In failsafe mode the left and right fans are put into standby and the vertical fan is run in reverse at a low duty cycle. This ensures that the blimp will slowly drop to the ground without any major changes in its horizontal position.
The motor controller receives a motor id, direction, and duty cycle from the set motor command. These parameters are used to call the correct function with the given duty cycle. The motor controller also receives inter-task messages from the motion controller. These are handled in a similar way by simply calling the correct function with the provided duty cycle.
PID Motion Controller for Altitude Control
The PID controller is part of the motion controller task and is enabled when the setpoint is set to a non-zero value with the set command. The set point provided by the set command is between 0 and 255. The proportional, integral, and differential constants used in the controller are set by the tune command. The PC sends them in the range 0 to 255, which we linearly map to 0 to 5.0 using a lookup table.
The PID polls the vertical sensor value, which is between 0 and 255, and calculates the difference between this value and the set point, resulting in a value from -255 to 255. The proportional term is calculated by multiplying the proportional constant by the error. The error is then added to a running total, which is checked to prevent integer overflow. This total error is used to calculate the integral term by simply multiplying the running total by the integral constant. An error difference is then calculated between the current and previous error values. The derivative term is calculated by simply multiplying this difference by the derivative constant. The pid output is then the sum of the three terms. If the output is negative the motor direction is set to reverse, otherwise the motor direction is forward. Once the motor direction is set, the absolute value of the output is taken. If the output is greater than 255 it is set to 255 since this is the maximum value of our PWM duty. The motor direction and duty are then sent to the motor controller through the inter-task messaging system. As long as the set point is non-zero, the task is set to run continuously and will be executed every program loop.
Final Project Application, Collision Avoidance
The final project application consists of a collision avoidance system for the blimp. This system utilizes the front, port, and starboard LED values to avoid obstacles in front and on the sides of the blimp. This system incorporates the PID Altitude Controller in order to prevent collisions with the ground. The collision avoidance system is turned on with the Obstacle Avoid On command and turned off with the Obstacle Avoid Off command.
The obstacle avoidance starts by reading the values of the front, port, and starboard IR LEDs. The LED values range from 0 to 255 where 0 corresponds to an object touching the blimp and 255 corresponds to an object at infinite distance. The default state is the forward state where the left and right motors both run forward with a set duty of 100. The sensor values are then checked. If the value of the front IR LED is below the front threshold of 200 the front collision state is set and a timer is started. If the port or starboard LED values are below the side threshold of 200 the left or right collision state is set respectively and a timer is started. Once a front collision is detected the collision avoidance goes into the stop state and then into either the left or right turn states. In order to stop the blimp from moving forward and colliding, in the stop state the left and right motors are set in reverse with a duty of 255. The timer is used to ensure that the fans are run for two seconds. After these two seconds have elapsed the left and right IR LED values are compared. The smaller value indicates that the obstacle is closer to that side and either the left or right turn state is entered to move away from the obstacle. If the obstacle is closer to the left, the blimp turns to the right by running the left motor forward at a duty of 20 and the right motor in reverse at a duty of 20. A right turn is performed in the same way with the motor inputs reversed.
Every half second, the front IR LED value is checked so see if it has gone above the front clear threshold of 255. If this threshold has not been reached yet the blimp continues turning for another half second and checks the value again. This is to make sure that the blimp continues turning until it has turned away from the obstacle. Once the front threshold has been cleared the timer is stopped and the blimp goes back into the forward state. For side collisions the blimp makes a gradual turn by running both motors forward, but with different duties. For example, to turn left (in the case of a right side collision) the right fan is set forward with a duty of 150 and the left fan is set forward with a duty of 20. The timer is used to execute this turn for half a second and then the blimp returns to the forward state. If the blimp is still to close to the obstacle it will detect a side collision again and execute the turn maneuver again for another half second. This allows the blimp to turn gradually away from side obstacles. The collision avoidance also includes debugging messages that can be turned on and off with the debug and debug off commands. In debugging mode the state that the blimp is sent over the wireless link to the UART: forward, stop, front collision right turn, front collision left turn, side collision left turn, and side collision right turn.
The initial version of the collision avoidance system did not use timers and instead made corrections to the maneuvers every program loop. The stopping state used a proportional controller, where the difference between the front threshold and the current measurement was used to determine the duty of the motors. The difference between the current and previous sensor values was then taken to determine if the blimp was stopped. Once this difference dropped below a threshold the blimp was considered to be stopped and the turn maneuver to clear the obstacle was then started. Side collisions were also checked every program loop instead of performing a turning maneuver for a fixed time period. Unfortunately the sensor values were too noisy for this implementation to work correctly so the timer based implementation was created.
Blimp-PC Communication
The blimp and PC communicate to each other by means of wireless communication over eZ430-RF2500 communicators. The messages are passed by UART from the sender to its attached wireless module, which sends the data wirelessly using IEEE 802.15.4 standard to the receiver module. The receiver module then passes the information over UART to the destination.
There are two wireless modules in use in our setup: one attached to the blimp and one connected to the PC. Both modules run the identical communication program on their respective MSP430F2274s. The communication program makes use of two input buffers, one for the wired UART and one for the 802.15 wireless. On each module, the receive_callback method writes incoming bytes into the wireless buffer and enables the ISR for the UART transmitter (USCI0TX). The USCI0TX then sends bytes that are on the wireless buffer by UART to either the blimp or the PC. Outgoing messages are handled in the opposite fashion. The ISR for the UART receiver (ISCI0RX) writes messages received over UART into the UART buffer. All messages are sent at 9600 BAUD in 8N1 format.
Table 3.2 shows the commands used by the PC-side GUI to send commands to the blimp. We have a very straightforward protocol that uses the minimum number of bytes possible for each command. The PC side application can send several kinds of queries and commands wirelessly to the Hindenburg, which responds with queried values, ACK, or one of the error codes. Some of the messages have payloads to carry data, which results in packets of variable size depending on the message to send. For example, the command
m 2 f 255tells the blimp to activate motor 2 ("m 2") to run forward ("f") at a duty cycle of 255 ("255"), or at full speed.
| ASCII Letter | hexcode | Message |
|---|---|---|
| <none> | 0x0 | NULL message |
| s | 0x73 | Disable motors and sensors |
| r | 0x72 | Enable motors and sensors |
| m | 0x6D | Motor control commands |
| x | 0x78 | Set setpoint |
| y | 0x79 | Tune PID params |
| z | 0x7A | Query Motion Controller |
| p | 0x70 | Poll sensor |
| c | 0x63 | Reset blimp |
| q | 0x71 | Query System Status |
| k | 0x6B | Ping |
| t | 0x74 | Query System Temperature |
| o | 0x6F | Enable obstacle avoidance |
| n | 0x6E | Disable obstacle avoidance |
Table 3.2: Commands for PC to Blimp Communication
| ASCII Letter | hexcode | Response to | Message |
|---|---|---|---|
| M | 0x4D | m | Returns setpoint |
| P | 0x50 | p | Returns polled sensor data |
| K | 0x4B | k | Keep Alive |
| Q | 0x51 | q | Running or Stopped |
| T | 0x54 | t | Current temperature |
| ! | 0x21 | commands with no responses | ACK |
| ? | 0x3F | commands with no responses | Command not allowed in current state |
| < | 0x3C | commands with no responses | Command not recognized |
Table 3.3: Responses from Blimp to the PC
A network stack from TI called SimpliciTI was used to send and receive bytes over wireless. The existing SimpliciTI package that we had access to was initially configured to use with Code Composer. While this worked, the process of compiling and downloading took an unacceptable amount of time. We adapted SimpliciTI so that in compiled with msp430-gcc and wrote a Makefile that automated the task of compiling and downloading it to the RF2500 modules.
PC Interface
The PC user interface provides a cross platform graphical environment to allow the user to send motor commands, send system level control commands, adjust the PID controller, and steer the blimp with a game controller or joystick. It was implemented in Python using Tkinter, pygame, and pyserial. Data input and command issue is controlled with buttons, sliders, and text boxes. Figure 3.5 shows the interface in each of the three operating modes: GUI control, autopilot, and joystick.
Figure 3.5: The PC interface in (left to right) autopilot, GUI, and joystick modes.
The GUI is split into four sections: Motor Control, Altitude Control, System Commands, and Status. Each of these sections encapsulates a different class of blimp commands or actions and different combinations of sections are enabled in each of the three modes.
Motor Control: This section provides low level control over each individual fan on the blimp. Each fan has a corresponding slider and send button. The sliders are initially set to a full stop in the middle and fans speeds are controlled by the distance of the slider from this zero point. Moving a slider upwards corresponds to forward fan direction and moving a slider downwards corresponds to reverse. The actual motor command is sent when the corresponding button is pushed.
Altitude Control: The height PID controller can be tuned and the set point modified using the widgets in this section. Each of the P, I, and D terms can be set using the text boxes on the left and the set point can be set using the text box on the right. Input is validated so that only numeric values under 255 can be entered. The tune and set commands are sent when the corresponding buttons are pressed.
Status: Various feedback about the current state of the blimp is displayed here. The three check boxes, Status, Auto, and Temp each periodically send status commands to the blimp and display the result. The Status check box displays either a "RUN" or "STOP" and will turn green if the blimp was successfully pinged and red if the PC did not receive a ping response. The Auto check box sends motion controller status queries and displays if the autopilot is on or off. The Temp check box enables querying the MSP430 temperature and displays the result. These periodic status updates are not enabled all the time due to wireless conflicts.
| Mode | Motor | Altitude | System | Status |
|---|---|---|---|---|
| GUI | X | X | X | X |
| Joystick | X | X | ||
| Autopilot | X | X | X |
Table 3.4: Enabled commands in different GUI modes.
System Commands: System level controls affect how the blimp reacts to various commands and disables or enables certain functions in the GUI. Each of the Run, Stop, and Reset buttons directly send the corresponding command to the blimp. In addition, the user can select an operating mode, which both turns collision avoidance on/off on the blimp and disables buttons in the GUI to limit accidental interference in different modes. Table 3.4 shows which commands are enabled in each mode. For example in joystick mode, the altitude and motor controls are disabled because these are controlled using the joystick instead as in figure 3.6.
Figure 3.6: Game controller to steer the Blimp.
The internal workings of the interface rely on Tkinter for all graphical widgets, pygame for all the button and joystick events, and pyserial for all serial communication. All these components are cross platform and the final GUI was tested on both Windows 7 and Ubuntu. All user events, from joystick movement to button clicks, are handled using pygame's event queue. For Tkinter button presses a pygame USEREVENT is appended to the queue, and pygame detects the joystick events automatically. To increase GUI responsiveness, events are handled in a separate thread from the Tkinter main GUI loop. Nearly all events have a one-to-one correspondence with a wireless command sent via pyserial; however, due to the wireless issues, the motor commands for the joystick are sent every half second to correct for lost or incorrect commands.
Results
PID Motion Controller for Altitude Control
The PID controller works fairly well and usually prevents the blimp from hitting the ground. However, noisy sensor values and variable sensor readings having a significant effect on performance. The readings from the IR LEDs are very noisy and have large amounts of fluctuation even when the blimp is not moving. To deal with this, the sensor values are low pass filtered. The filter must still weight the current sensor value fairly heavily (at least 1/8, although 1/4 seems to work better) in order to operate correctly. If the weight of the current sensor value is too low, the output of the filter changes too slowly and the blimp will hit the ground before the sensor values begin to decrease and indicate a collision. To further remedy this issue, the non-linear sensor values are mapped onto a linear range of values from 0 to 255 using a lookup table as described in section Sensing Task. This calibration was performed separately for each sensor, since the values from each sensor were very different. Also complicating control, the sensor values are highly depending on surface properties and on the charge of the battery. Surface color and reflectivity have a strong effect on the sensor values. To deal with this issue the sensor calibrations were performed on a surface of intermediate color and reflectivity, a green wall. The final issue is that the sensor values are also completely dependent on battery charge. When the battery is at full charge the sensor readings are very high (objects are detected at further distances than they actually are) and the blimp will hit the ground. When the battery runs down, the sensor readings are very low and the blimp will constantly run the vertical fan forward at the maximum duty cycle because it always detects that it is right above the ground. Therefore, the altitude control only works properly in the small range of battery voltages where the sensor data matches the calibration data in the lookup tables. This problem could be ameliorated by including multiple lookup tables for different battery voltages, although this solution is not optimal and is limited by the flash memory on the microcontroller.
Final Project Application, Collision Avoidance
The collision avoidance suffers from similar issues to the altitude control due the noise and variable nature of the sensors. An additional issue is that when the blimp gets close to the ground the shadow it casts causes the front sensor to drop below threshold and trigger a front collision. Running the vertical fan while moving forward causes the blimp to rotate due to the torque of the motor, which complicates navigation. An improvement would be to run one or both of the side fans briefly to counter the torque from the vertical fan motor when it is running. The collision avoidance would also benefit from using multiple sensor value lookup tables based on the battery voltage.
Future Work
As mentioned previously, noisy and variable sensor values made it difficult to implement the height control and collision avoidance. Improving the hardware so that the sensor values are less noisy and do not depend on the charge of the battery could lead to a significant improvement in navigation performance. In lieu of these hardware changes, improvements in software such as implementing a Kalman filter, having multiple lookup tables for different battery voltages, or using a faster filtering operation on the incoming sensor data could also improve navigation performance. Having additional sensors to improve state estimation would also improve navigation performance. For example we initially tried to detect a stop state by comparing current and previous sensor values, but the sensors proved too noisy for this to work. Therefore we simply run the fans in reverse for two seconds and then assume the blimp is stopped. Having some sort of inertial measurement unit that would allow us to measure velocity and acceleration would allow us to detect motion more robusly than with the sensors. Another useful hardware update would be to improve the wireless communication. The reliability of the wireless link is quite poor with a high rate of packet loss when the motors are running. The reliability was increased by adding a large capacitor to the battery input in order to prevent power fluctuation when the motors are run. Even with this improvement there is still about 5 pecent packet loss. Although software solutions could be devised to deal with the issues discussed here, ultimately the solution is to improve the circuit components and layout.
The exterior of the blimp could also be augmented or improved in a number of ways for different applications. Our existing joystick controller works very well considering the limitations of the balloon, so it's not too hard to imagine strapping some small brushes on the balloon and use it as a cleaning utility, or putting a flashlight on it to be a floating workbench assistant. Similarly, making the envelope out of an insulated material may make it more usable outdoors, for recreation or for specialized uses like carrying small objects. We could also (with better hardware) expand the project to involve blimp-to-blimp interactions, such as a follow-the-leader interaction, or some sort of trans-building race.
There are a few peripherals on the blimp that were not used in this project and can be utilized in future extensions. One of the other groups utilized the compass on the blimp board. This may be a good way to control the heading of the blimp, and in the case of our flying saucer, would be useful in detecting if the blimp is spinning or not. The blimp can also be programmed to fly at a specific heading, making the blimp itself a (very large and cumbersome) compass. We can also make use of the internal cyclical redundancy check module to generate error correction for lost packets. This may be of particular interest to our application, as we encountered several problems with packet loss across the wireless communicators. Whether or not this built in CRC module is reliable would require investigation, and we would also want to see if the error recovery from the built-in CRC is more reliable than any CRC protocol we can implement directly in the communicator. Similarly, we could implement packet encapsulation for all our messages to make the communication more reliable.
Another interesting MSP430 peripheral available is the real time clock. This peripheral, if it is reliable and easy to use with everything else on the blimp, can allow for some very specialized functions on the blimp. For example, the blimp could be made into an alarm clock for pre-programmed times. As an example, the blimp would detect that it was 6 AM in the morning, and then fly above the sleeping person and periodically blast the fan to make that annoyingly loud noise, which may be enough to wake someone. Alternatively, the blimp could notify the children in the house when it was time for bed or when it was time for school, or notify you when your favorite TV show was supposed to be on. While this would probably require a sophisticated navigation system, and an actual alarm clock would be superior by far to the blimp for these situations, it would be a relatively flashy application.