[IR] LED Zeppelin(Technically its a blimp)By: Team Fabulous and the Shiny Blimp(Will Pitts, Sean Cowan, Alexandre Bykov, Craig Macomber)

Table Of Contents:Table Of Contents:Introduction

Terminology/IconographyGoals

Related WorkSystem Design & Implementation

ClientProtocolMechanicalsBlimp OSSensorsRadiosMotor ControlMotion Controller

The basis vectors / high level control coordinatesGenerating the High Level Drive valuesPID ImplementationPID Tuning

Fail SafeBlimp BallOutcomeAreas for Further Study

Introduction

Terminology/Iconography

ClientThe desktop application for controlling, monitoring and configuring the blimp wirelessly

Blimp

And how the blimp actually looks: (Forwards is to the right)

● Envelope: Hold the helium to lift the blimp● Tail Hook: holds counterweight/ballast in the back● Fin: Helps blimp fly straight● Gondola: Holds all the electronics to the envelope● Radio: The RF2500 board for communicating with the client wirelessly● Motors: The three motors laid out as diagramed below

Here is the iconography used to show the 3 propeller motors:

GoalsThe blimp is shiny, and it shines best when floating majestically through open space around eye height. Also, controlling the blimp manually is work. Thus, when optimizing for maximum awesome, and minimum work, we decided our blimp must fly, by itself, majestically through open space around eye height. This requires:

● Avoiding objects● Flying forward in open space● Keeping a stable height● Smooth majestic flight controls, free of cyclical instabilities● Manual overrides for attacking and displacing less majestic blimps● Fallback autopilot to keep our fantastic creation safe, and still flying (majestically) even in

the presence of enemy radio jamming attacks, unexpected faraday changes, and remote hardware failure.

Related WorkMany class before us have done similar projects, but we didn’t draw any particular inspiration from them.

System Design & Implementation

ClientThe client is written in Python 2.7 and uses Tkinter + PIL for graphics and pySerial for serial communication. It uses the classic computer gaming WASD controls for controlling the blimp, with the addition of C and V to control altitude. The manual control overrides and PID settings can also be set from the client. In order to deal with the high probability of data errors that arises while the motors are on, as much computation as possible is performed on the blimp itself, with the client as mostly a thin

wrapper that displays some data and sends some general commands. By making the client as thin of a wrapper over the communication API as possible, the blimp’s PID and autopilot function perfectly well if connection is interrupted (a valuable component of any mission critical system!).

The client sends updates to the blimp several times a second, consisting of a run command (or stop command if the blimp is stopped), motor controls, and the autopilot mask. Since each regular update contains the same information, the blimp will never miss an important update unless communication has completely broken down. The blimp responds with a packet containing all of its sensor data. Neither the client nor the blimp expects regular pings, and instead treats all communication as either a ping or a ping response.

ProtocolWe designed the protocol so that it specifies the state of the blimp, instead of sending action type commands. This makes the commands idempotent, and thus we just spam them over the radio link. We grouped important command sets into single packets so they would be set atomically. When combined with our checksums (16 bit CRC) this means that if the radio connection is working at all, the blimp will correctly get its state set, rather than missing commands, and will never enter a state not specified by the client. The current commands on the blimp are listed in the table below.

MechanicalsThe gondola is mounted on the front of the envelope so the fans are closer to the front. This makes forward flight more stable (straighter) and helps the blimp detect obstacles in front of it faster. To keep it level in this configuration we placed most of the ballast on the tail hook in the back. This also allows for easy adjusting of weights to keep it near neutral buoyancy:

The tail hook also serves as a nice holder for our catchline when its not in use (pictured). Also pictured is the fin, made of some salvaged paper. It is simply folded over and taped on. It should increase the drag in the back compared to the front, and also increase the drag when moving horizontally vs forward. Both these effects should lead to straighter forward flight.

Blimp OS

The Blimp OS for the blimp consists of a circular task queue which holds different tasks that run on the blimp. The tasks are statically defined in the queue and each task is a method which accepts a null pointer argument, and returns nothing. Currently, 6 different tasks are implemented to handle the blimp functions. The implemented tasks and their function on the blimp are listed below:

● System init task: Called to initialize values and set up blimp hardware to run. Only runs once on startup.

● System monitor task: Controls the run/stop and connection state of the blimp. Also resets the watchdog timer.

● Communication task: handles the receiving and sending of messages between the blimp and the client.

● Motor Control task: handles the low-level motor control.● Sensor task: handles the polling of the IR LED and reading the IR sensor values.● Motion Control task: Implements the PID control for altitude control and the obstacle

avoidance routine, and sets the motor settings accordingly. When executed, a task runs until completion. When completed, the next task in the queue is executed, and the cycle repeats. Communication between tasks is handled through one global struct which holds all the shared data.

SensorsControl of the sensors is handled through the sensor task which receives sensor requests from other tasks, toggles the appropriate IR LED, and measures the value returned from the IR receiver. At the heart of the system, is a simple 2-state state machine. In the initial state, the accumulator and sensor count is cleared and the task waits for an active fields in the global struct for a sensor poll request by another task. When a poll request is seen, the output to the decoder, for the corresponding sensor, sets the enable signal high, enables the ADC10, and transitions to the Sensing state. In the sensing state, the ADC10 is checked to see if the conversion is complete. If so, the result is added if the light was turned on, or subtracted if turned off to the accumulator variable and sample count is incremented. This is repeated until 50 samples are taken After 50 samples the accumulator result is inverted and added with an offset dependant on the direction of the sensor. This is to make the sensor values start at zero when an object is close and increase as the object moves away. Finally, the sensor state is set to the initial state and waits for the next poll request.

RadiosFor the wireless radio communication on the RF2500 boards, the system handles all communication at the byte level and is completely oblivious to the packet protocol mentioned above. To handle two-way communication, the system consists of two ring buffers, a send and receive buffer.

For sending data received by the UART to wireless link, when a byte received from the UART, the receive interrupt routine is called. The data byte in the receive register is added send buffer. If the send buffer is full, the data is dropped. It also exits low power mode, as a signal that there is data ready to send. On exiting low power mode, the processor starts in a while loop to send data. First, it disables general interrupts to safely access the buffer. Then, it creates a message buffer and takes as many bytes as it can from the send buffer up to the wireless packet limit, and sends the message buffer. The loop then check if there is data still in the buffer. If so, the loop repeats. Otherwise, the system enables general interrupts and enters low power mode. For receiving data from the wireless link, when a wireless packet is received by the system, sRxCallBack() is called which adds the data payload to the receive buffer. The UART taking data interrupt enable is also set to signal there is data ready. When the UART taking data interrupt is serviced, data from the receive buffer is removed sent on the UART. If the receive buffer becomes empty, the UART taking data interrupt flag is cleared. Otherwise, the flag will be left set, so the next data byte can be sent when the UART is ready. The circular buffer implementation used in the radios shared with the blimp itself. It is a general purpose interrupt safe circular buffer we wrote for MSP430s, and has worked quite well. The two radios together effectively implement a 9600 baud wireless serial cable. On the client side of this link can be any 3.3-3.7 volt serial port. Currently a dlpdesign board is used with a 3.3V LDO regulator:

Motor ControlThe motor control task handles the low-level motor commands to set the power and direction for the left, right and vertical fans. Motor commands sent from the communication task or the motion controller, are received by the motor control task via the motor setting direction and power in the global struct. The speed for each motor is determined single unsigned byte with 0 meaning the motor is off, and 255 for max speed.

For the left and right horizontal fans, the speed of the motor is set through PWM in Timer_A0. The period of Timer_A0 is set to 255 in register CCR0. This is so a motor speed of 255 corresponds to a duty cycle of 100%. The timer compare registers CCR1, CCR2, CCR3, and CCR4 determine the duty cycle for the rfan_h, rfan_l, lfan_h, and lfan_l output. To set the horizontal motors, on each iteration of the motor control task the power for the left and right motor is checked. If the power is 0, both the high and low signal are disconnected from the PWM output and set high to keep the motor in the off state. Otherwise, the direction is used to determine which output should have the PWM set. If the direction is forward the low output signal is set to PWM, and the power field value is assigned to the appropriate CCR register. The high output signal is set high. If the other direction is specified, the opposite would be applied. For the vertical fan, PWM is not available, so it is controlled with two interrupts from Timer_A1. The first interrupt is for compare register CCR0 which is set to 255 for the period. The second interrupt, on compare register CCR1 sets the duty cycle according to the vertical fan power. Additionally, a flag vfan_forward is set to determine which output vfan_l or vfan_h is toggled in the interrupts. The other output is set high.

Motion Controller

The basis vectors / high level control coordinatesOur motion controller is run every time there is new data from all the range sensors. It does “high level” motor control in a “Right Turn”, “Forward”, “Up” basis.

This is a complete basis for the raw motor driver basis meaning that every possible motor drive combination can be represented as linear combinations of them. These basis vectors / controls / axis are also orthogonal, meaning that they are independant. Once computed the drive values are converted into raw motor settings, and placed in the globals where the motor controller will find and use them.

Generating the High Level Drive valuesThe motion controller computes 3 drive values every update; one for each of the axis. Each of these drive values is produced via a PID controller that is based on sensor readings. Below are listed the inputs to each of these PIDs in “Axis : Sensor Value : Set Point” form:

● Up : Down Range : Vertical Set Point● Right Turn : Left Range - Right Range : 0● Forward : Forward Range - Reverse Range : Forward Bias

Details:● The “Forward Bias” (negative here) makes the PID try and keep the distance in front

shorter than the distance behind, which makes it fly forward when nothing is insight.● The turn sensor input is actually shifted forward 0 to help reduce trying to turn when

there is only a small difference between the right and left ranges.● The Forward and Right Turn PID controllers currently only use the P terms. Use ot the

other terms does not seem necessary, but could be explored. This high level control code is strictly stateless with a few exceptions:

● The sensors are run through an IIR filter which this has state (see Sensors)● The PID controllers integral and derivative terms store some state

PID ImplementationThe PID is updated every time new data is acquired from all the sensors. This usually takes about the same amount of time, so a delta time value of 1 is used for the integral and derivative terms to simplify the math. This results in the integral term needing to be divided down, and the derivative term needing a very large coefficient (about 2048). A bit of special care was taken when writing the PID code to avoid potential overflow issues, since its pretty easy to overflow if no checks are in place.

PID TuningInitial PID tuning was done by reprogramming the blimp with new constants. This was replaced by allowing them to be set from the client over the radio. This helped a huge amount since it decreased the time required to try new settings by at least a factor of ten.

Fail SafesWe designed a couple of things to make our blimp fail safe. First is that the blimp is slightly heavier than air. This makes it go down if it loses power, instead of up. We also implemented a hard coded “disconnected autopilot” which is selected instead of the editable one if the radio connection drops. This fallback autopilot has reduced motor drive strengths, and a low vertical set point to make sure the blimp is safe if it bumps anything, and tends to come down. This could recover from the case of a too high of vertical set point causing the blimp to climb up out or radio range: it would automatically revert to the hard coded low set point and come down. This also applies to the manual controls. Its possible to manually override the autopilot, but those settings are ignored when not connected to the client. Also, the choice of idempotent commands in the protocol allows dropped packets to not cause issues, and the checksums make only correct commands are ever applied. This means that if the blimp is connected (even with very high error rates) it will be kept in the correct state as requested by the client. Thus, it will either be in the correct state, or in the failsafe disconnected autopilot. The Watchdog timer also serves as a failsafe. It makes sure that if the OS is no longer running its tasks, it will reset. This means that the motor control and motion control are guaranteed to run, or the processor will reset. Since we disable the motors on reset, this makes sure they can’t get stuck on in the event of a firmware crash, or voltage related reset. We also never drove the motors at full power. The autopilot contains a max duty factor setting: 200/255 when connected and 50/255 when disconnected. This is low enough that it it will not damage the blimp if it crashes into something.

Blimp BallIts like basketball, except you can’t touch the ball, the ball is a blimp, and the location, teams, scoring and rules are different. Blimp Ball is exciting, and packed with high RPM action, invisible flashing lights, and shiny blimps. Blimp Ball requires one regulation [IR] LED Zeppelin, an open area and at least one player.

OutcomeVertical height control is pretty stable once well tuned PID using all 3 terms. Other object avoidance works, but generally bumps walls a bit first before avoiding. Here are all the sensor reading from a tuning session. Time is in seconds:

And here is an enlargement of the last portion, with the final constants:

Clearly, it matches the set point very well, and recovers from hitting of flying over obstacles. Since we only use the difference of the front and back ranges, we never bothered to offset them to match the rest, so they show larger values. Overall, it looks like the sensor accuracy was worse than the PID controllers, since it did not fly as amazingly level as the plot shows, though it was pretty level. Our failsafes generally worked well, though the heavier than air failsafe failed several times due to vents in the ceiling sucking up the blimp. Fortunately this only happened when the ceiling was rather low, since we only flew near low ceilings, but this could be an issue in the future. The winds in the hallways also were higher than expected (about walking speed sometimes!) which made the blimp fly pretty fast even when in its fail safe or off modes. We didn’t observe any cases where we are sure the watchdog timer helped, but it may have, and it did not cause any issues. Some cases our blimp side failsafes correctly handled:

● Client crashed

● Client radio out of range● Client exited● High data corruption over radio● Physically disconnected radio● Loss of battery power

And the one case where it failed:● Blimp sucked into vents in ceiling

We also had an incident where we damaged some of the propellers in a full power test before we had any of the autopilot or fail safes implemented. This never happened again, partly because of limits we imposed on motor duty cycles, and partly because the blimp never flew into such bad positions under controlled flight. Initially we mounted the gondola under the center of the envelope, which lead to the blimp not flying very straight. Later we moved it to the front (and to compensate, added the tail hook to put the ballast in the back). We have no detailed measurements, but we think this resulted in straighter forward flight, and better vision for the forward sensor.

Areas for Further StudySome more work could be done for smarter obstacle avoidance by adding state to the motion controller to remember obstacles. This could even include a kalman filter. Further investigation into the radio issues when running the motors could also be done.