Tom Ling tl92                                                                            Norbert Huber nh48

476: Stationary Helicopter

A lever that uses a propeller to control its angle.

Intro  |  High Level Design  |  Program/Hardware Design  |  Results  |  Conclusions  |  Appendix

Intro Summary

Thinking about what a CDE (culminating design experience) should be, we devised a project that combines the microcontroller programming principles learned in ECE 476: Microcontroller Design with the control theory concepts learned in ECE 472: Feedback Control Systems to create an academically viable stationary helicopter. The device consists of a lever with a DC-motor-driven propeller attached to one end. The angle of the lever is determined by an accelerometer-based PID (proportional-derivative-integral) feedback-controller. The accelerometer signal is fed into a Mega32 MCU (microcontroller unit) that the user interacts with, using push-buttons to set the desired angle and to adjust control parameters.

back to top

High Level Design

Rationale

With the purpose of using microcontrollers to solve a control problem, we intended to construct an inverted pendulum before learning that motors with sufficient response times were outside the scope of our budget. Professor Land suggested a stationary helicopter, as he has been considering creating a similar 476 lab in the future, and so our project was born.

Logical structure

The main structure of our design is a feedback control system, as illustrated:

Error is calculated from subtracting current angle obtained from the accelerometer from the reference angle.  PID control is used to general an output that will be used for motor control.  Another separate control algorithm separate from PID is also implemented but only executed when certain flags are set.  Timer 2 from the MCU produces a pulse width modulated signal.  And based on the duty cycle of the PWM signal, the amount of current going through the motor can be controlled.  Various buttons control the gain constants for the PID control as well as set flags for other operations such as on/off.  A LCD output was also implemented so that the status of the system can be viewed easily. The setup illustrated:

Background Math

The Proportional-Integral-Derivative (PID) control is used to calculate how much power outputs to the motor.  Below shows the general equation:

The sum of all three terms produces a value that is used to control the PWM duty cycle.  Gain constant KP produces a term that is proportional to the error.  This term affects the response time of the system.  Higher KP is, quicker the response time with the expense of stability since overshoot likely occurs.  Derivative constant KD produces a term that’s proportion to change in error.  As the lever moves toward the reference angle, it slows it down and vice versa.  This term smooth out oscillation but reduces response time.  The integral term sums all the error from the start and provides a push towards reference angle.  However, it is fairly easy to get an unstable system if the integral constant, KI, is set too high.  In practical applications, the integral term is set to zero when error crosses zero and there is also a cap on its value.

Hardware/Software Trade-offs

Most of the hardware trade-offs come from cost.  The hinges for rotation of the lever are mere 2 screws.  This created more friction and instability for the lever’s movement.  The decision to implement LCD to display various values makes our life much easier when during debugging and testing.  For practical purposes, it also makes sense to have the display for control.  However, along with the small white board it’s on, it counts $7.50 towards our budget.

Another significant trade off is using Timer 2 as the pulse width modulator.  This PWM (pulse-width modulator) is easy to implement and to debug.  However, with the 256 values determining the duty cycle, only about 50 values are useful.  The rest of them either do not generate enough power to lift the lever, or generates too much power that the lever shoots up.  Therefore, it can take a while for the lever to settle since the motor can only get discrete power output.

Relationship to Known Standards (IEEE, ISO, ANSI, et. al.)

We did not encounter any situations where we needed conform to standards. The nature of our design is independent of standards such as the IEEE standards that govern RF (radio frequency) communication or ISO/ANSI standards that govern video display conventions.

Relevant Patents, Copyrights, and Trademarks

The academic nature of the project, that is, the goal to demonstrate control and microcontroller principles instead of constructing a device with exceptional functional value takes us away from the realm of intellectual property. A helicopter-like device constructed out of an off-the-shelf propeller and a $4 DC motor from Radio Shack is irrelevant in the world of patents, ™’s, and ©’s.

back to top

Program/Hardware Design

The 3 elements to the detailed design: mechanical design, software design, and electrical design.

Mechanical Design

The key to the mechanical design is rigidity. We ensured the stand to be as stiff as possible, such that the relevant forces generated by the propeller get translated to the lever only, and do not result in disturbance that would cause the stand the oscillate, disturbing the lever and the accelerometer. As illustrated, the stand is built on a heavy wooden block (>10x heavier than the lever). A metal stand, constructed out of shelving material, is attached to the wooden block via 2 large metal hinges. The lever, made of lightweight balsa wood, is attached to the stand via 2 oiled screws, acting as the hinge. The small propeller, small so that response times are minimized, is hot glued to the motor shaft. The motor is securely taped into a semicircular groove cut into one end of the wooden lever. The accelerometer circuit mounted on a solder board, is securely screwed onto the opposite end of the lever. A dead 9V battery counterweight is taped onto the same side of the lever as the accelerometer. A threaded metal rod is attached halfway up the metal stand, providing additional rigidity, and allowing the width of the metal stand to be finely adjusted to minimize friction between the stand and the lever. The setup illustrated:

Software Design

The software design is divided into 4 sections: sensor input with handling, motor output, control calculation, and button handling.  The setup illustrated:

As in most designs there is a non-exiting while loop in the main function. It is also in this loop where most of the flags are checked to determine whether to carry out certain tasks. The first task is calling the function get_AD() every 10ms to obtain the newest values from the accelerometer. This is an 8-bit value that goes between 0 – 5V, which translate to 0 – 180 degrees. This value is displayed on the top left corner on the LCD. In order for it to be readable (not flashing all the time), only every 80^th value (or 800ms) is displayed. Other flag handling abilities in the main while loop will be discussed briefly with their respective functions.

The motor output is driven by Timer 2 Fast Pulse Width Modulator from Mega32.  Register OCR2 can determine the duty cycle of the PWM.  It is an 8-bit value so when OCR2 is set to 255, we have power and vice versa if it is 0.  The output, OC2 pin, is on Port D 7.  The value of OCR2 is determined by motor().  It takes in 2 values: power, which is how much more/less power needed, and direction, which indicates whether the lever is too high or too low.  These 2 values are passed from Prop_ctrl(), which will be discussed later.  The global variable, PCONST, is the offset value for OCR2 in order for the lever to balance at a certain angle.  Values of PCONST for 60, 75, 90, 105, and 120 degrees are built into the software.  PCONST is determined experimentally, and can be modified by calibration() or buttons.  If the direction is 1 meaning lever is lower than desired angle, (PCONST + power) would be the value for OCR2.  On the other hand, (PCONST-power*0.5) is used when lever is too high.  The factor of 0.5 is there because gravity is always there to pull it down so motor speed decreases slower than it increases.

When the ‘off’ button is pushed, motor() will not execute.  However, we do not want the propeller to drop from the air.  Therefore, Powerdown() kicks in.  It slows down the motor at a rate based on the current angle, then set OCR2 to zero when the angle is close to zero.  This ensures a soft landing instead of slamming into our stand everytime power is turned off.

There are 2 functions that handle the control algorithm. Prop_ctrl() calculates the PID control, and calibration() is another algorithm designed due to certain unique aspects of this project.  When the ‘on’ flag is set, Prop_ctrl() is executed.  We use the Inverted Pendulum Project from last spring as a reference for our implementation.  The control is calculated based on the mathematical equation mentioned before.  The 3 gain factor, proportional (KP), derivative (KD), and integral (KI), can be adjusted on the fly using the buttons. The tricky part would be the integral control.  This control is powerful since it can adjust output even if the offset is off by a lot.  However, this control has a tendency to get unstable since the sum may not converge.  Therefore, usually the sum term is set to zero whenever the error crosses zero.  However, in the case of the propeller, this can be undesirable.  One scenario would be that the offset, PCONST, is lower than it needs to be, but the lever is still slowing approaching the desired angle due to the integral controller.  Once it reaches the position, the integral controller goes to zero and the lever drops back to the angle that the offset can balance.  The result is that the lever oscillates between the 2 angles.  Now, if the sum term is not set to zero when error is zero, the lever easily go unstable and oscillates wildly as expected.  Therefore, our solution to this is to set a maximum for sum terms so that the integral controller can at most change the output (OCR2) by 2 or -2.  The other function, calibration(), will handle the problem of the offset been incorrect.

Calibration() modifies the offset, PCONST, based on the current status of the lever.  When the lever is too low it increases PCONST by 1 and vice versa.  A hardware counter, wait (set by Timer 0), is used to when the next calibration() occurs.  If error is small, wait is large so the PCONST is modified slower.  This reduces overshoot at small error and increase speed at large error.  There are 3 other factors that also determines whether calibration() is executed.  A button push sets a flag in the main while loop that turns off calibration completely.  Off button also does the trick, however, on button would turn it back on.  The third factor is whether the lever is stable or moving.  The initial consideration for using calibration mode is that the lever would balance itself at a different angle every time with the SAME offset.  Therefore, we want the lever to slowly move toward the desired angle.  Hence, calibration is only used when the fluctuation is small.  Experimentally, we determined that if the change is less than 10 (about 4 degrees) after 800ms, it is good enough to assume that the lever is stable, and calibration() kicks in.  Otherwise, it’s off.  When calibration() is on, a “c” will be displayed at the top right corner of the LCD.

The button_ctrl() is a debounce state machine that handles the 8 buttons on the STK 500 board.  These buttons are connected to PINB.  The following lists each button’s function. 

Button 0:   Toggles on/off.  Status displayed at bottom left corner of the LCD.  When off, all the values for PID controller is set to zero and calibration is off.  When on, calibration is on unless button 6 pushed.

Button 1:   Increase the reference angle by 15 degrees.  Default set to 90.  Maximum is 120.

Button 2:   Decrease the reference angle by 15 degrees.  Minimum is 60.

Button 3:   Toggle which gain factor or constant button 4 and 5 modifies.  The 4 variables are PCONST, KP, KD, and KI.

Button 4:   Increase one of the factors set by button 3.  If PCONST is selected, value can be increased quickly by holding down the button.

Button 5:   Decrease one of the factors set by button 3.  If PCONST is selected, value can be decreased quickly by holding down the button.

Button 6:   Toggle calibration mode between free run and off.  Note that with free run, calibration is on when fluctuation is small.

Button 7:   Reset PCONST to preset values.

LCD Display 

(1)   The Raw A/D value from the accelerometer.  Values go from 0 to 255, which translate to 0 to 180 degrees.  90 degrees is defined when the lever is parallel to ground.

(2)   Indicating which value (3) is showing and what values button 4 and 5 are modifying.  C: offset (PCONST).  P: proportional gain (KP).  D: derivative gain (KD).  I: integral gain (KI).

(3)   The corresponding value indicated by (2).

(4)   The letter “c” shows when calibration() is executing.

(5)   Indicating whether the system is on or off.

(6)   The error.  This is calculated from subtracting value from the accelerometer from the reference angle index.

(7)   The reference angle index (127 out of 256 is 90 degrees)

(8)   OCR2 value.  This value divided by 256 is the PWM duty cycle.

Electrical Design

There are 3 main circuits in this system: the accelerometer, the motor, and the LCD.

The circuit for the LCD was built first since the components were there already and we had plenty of experience of doing so from the previous lab exercises.  As usual, the LCD is connected to PORT C on the STK 500 board.

The sampled accelerometer, ADXL202, was the next thing that we obtained.  With Professor Land’s help, we soldered this surface mounted chip.  The corresponding resistors capacitors were applied based on the standard operating application on the data sheet.  Together, they were soldered onto a large solder board.  The ADXL202 has the ability to measure acceleration in 2 dimensions.  Nevertheless, we only needed the angle of tilt that is parallel from the lever’s motion, so only 1 wire output was soldered.  The chip also has leads for VCC and ground.  It takes voltage ranging from 3V to 5.2V.  However, the voltage range of the output is determined by voltage supplied.  To get good resolution on the reading and also for convenience, we drove the chip with 5V from the MCU.  Effectively, the output voltage has a range of 320mV for measurements from vertical to horizontal, which is 90 degrees.  The ADC has an 8 – bit accuracy.  And since we cannot put the MCU to sleep while obtaining measurement, it is fairly inaccurate for low voltage change so there is not really a point of going with all 10 bits.  Therefore, with 8 bits, there are 16 values between 0 and 90 degrees, which means the accuracy is only to 6 degrees.  To get around this limited accuracy problem, an amplifying circuit is implemented. We used an LMC 7111 op-amp and a trimpot.  The setup illustrated:

Figure 1: Sensor Circuit

The mathematical analysis of this circuit is:

V_out = Alpha * (V₊ - V_-)

The resistance, R, does not matter much as long as they match well.  We used a 100k dip-pack for it.  Alpha was chosen to be 8 for the reason that we want the range of 180 degrees to be about 5V and 5.12V (640mV*8) is about right.  The extreme cases (close to 0 or 180) may not be accurate but they are beyond the range of motion of the lever.  Finally, the trimpot is there to adjust the offset.  The initial voltage from ADXL202 was offset to 2.5V so amplification would put it out of range for the ADC to measure.  The trimpot has variable resistance to set V- in the above equation.  So increasing the trimpot resistance can bring the voltage offset to 2.5V.  In order to calibrate it, we held the lever to perfect horizontal and adjust the trimpot until the ADC reading is 127 (half of 255).

The output circuit to the motor was the last thing built due to fact that the propeller was the last piece that arrived.  Initially we built the exact same circuit as in lab 5 that drove the fan to cool down the temperature sensor.  This circuit used an optoisolator so we would not have issues with noise.  The TIP31 transistor act as the gate for current flow.  A diode is applied across the motor to prevent spikes when shutting off.  Another small capacitor was also used.  Although it was most likely redundant, its purpose was to prevent RF noise.  Professor Land also kindly provided a heat sink for TIP31 after I got burnt by it a few times.

This setup was used for much of the design process.  However, we noticed that the power output was very inconsistent.  At different times, when we turned on the motor with same PWM duty cycle, the prop would clearly be spinning at different speed.  We had no solution to this but to change the PWM duty cycle manually.  This problem was improved by updating to our final output circuit.  The setup illustrated:

Figure 2: Motor Circuit

The change was made after we found out that that the transistor TIP31 was drawing as much as 80% of the DC voltage with the motor only getting 20%.  We asked Professor Land for advice.   It was then when a problem was discovered.  The base voltage on TIP31 was -0.7V!  This baffled us since the transistor should not be functioning at all.  Nevertheless, Professor Land suggested 2 changes.  The base of the transistor in the optoisolator was connected to the 12V power supply ground through a 1M ohm resistor.  This gave us a positive base voltage in the TIP31.  In addition, another stage was added using 2N3901 to boost the voltage so that TIP31 would allow more voltage to flow through.  The result was that the motor got more power.  And even though the fluctuation in the power output was still present, it was much better than before.

Problematic Design Elements

The original output circuit did not provided sufficient voltage to the motor. The situation was rectified by cascading a second transistor.

The accelerometer without the gain/offset circuit did not provide a sufficiently wide signal band.

The original wooden stand had oscillations issues. It was replaced with a metal stand and metal hinges, which eliminated the oscillations.

back to top

Results

Speed of Execution

Our system is not particular time sensitive.  The software executing speed was not much of an issue.  They only minor concern was that the PID control calculation needed to be done in floating point number which was relatively slow.  We needed all the procedure to be executed between 2 readings from the ADC, which was 10ms.  After experimenting, we found no issues regarding speed of execution.

The main concern was the motor response time.  How fast could the motor adapt to the change in PWM duty cycle.  The answer was fast enough.  Granted, a huge swing in the duty cycle will cause the propeller to dance up and down.  However, the gain constants can be tweaked so that all changes in the duty cycle are gradual.  And it is possible to find such constant values so that the propeller can balance at various angles without ever going unstable due to motor response time.

Accuracy

There are 2 aspects of accuracy here.  The first one would be the absolute angle that the lever balances at.  The limiting factor is the ADC, which is only 8 – bit accurate.  Nevertheless, with 256 values representing 180 degrees, the resolution is within1 degree.  For our purposes, this is good enough.

How stable would the lever be is another accuracy issue.  We did not make precise measurement of fluctuations of the lever.  However, if we look at the lever from 1 foot away and it does not appear to move, we could safely say it’s stable.  And our lever could achieve that with ease.

Design Safety

The primary safety concern was the propeller flying off the motor. Budget constraints prevented us from using a pin-lock, which is a pin that is pushed through the drive shaft, physically preventing the propeller from flying off. We attached the propeller to the motor with hot glue and placed the propeller as low as possible on the drive shaft, allowing for maximum slippage before the propeller could detach. In addition, we placed an extra blob of hot glue over the tip of the drive shaft to emulate a pin-lock. We initially spun the propeller in reverse, inside a 30 gallon trash bin, so that in case the hot glue did not hold, the propeller would (1) slide further onto the drive shaft instead of off it and (2) in case it did fly off the drive shaft, the trashcan would contain it. After two weeks of testing, the hot glue is still holding the propeller in place.

Interference (e.g. CPU noise, RF noise)

We had no relevant interference issues with other groups, aside from the isolated incident of an adjacent group nearly whipping their desktop CPU into our propeller.

Usability

Our project is a low-budget learning tool. For us, it's use is limited to the knowledge gained during its development. For others, in theory, it could be used by organizations unable to afford the equipment necessary to demonstrate fundamental control principles on a inverted pendulum.

back to top

Conclusions

Result Analysis

Our final design of the stationary helicopter was much more complicated, both hardware and software, than originally planned.  As mentioned before, the boost circuit for the accelerometer signal, the addition of 2N3904 to the motor circuit were modifications we made along the way to make the hardware more reliable.  Complex control algorithm was also needed.  We discovered that the motor did not necessarily need to pump more power for the lever to balance a higher angle.  The critical point is around 110 degrees.  For example balancing at 120 degrees may require same PWM signal as balancing at 80 degrees.  After a lot of experimentation, we gave up on setting the offset, PCONST, to an exact value for a certain angle.  Rather, we let PCONST to be a value that would push the lever up to the region of the reference angle.  Then, the integral control and the calibration mode, two scheme that was not originally planned, kicks in to fine tune the angle.  And the outcome was satisfying.

The results met expectations. We have a high-degree of control over the lever angle as a result of sturdy mechanical design and lab tested software and hardware design.

For next time, adding a second degree of freedom would provide some interesting design challenges. A servo motor could tilt a the propeller to create lateral motion, creating exciting new control problems (e.g. maintain altitude while changing lateral direction).

Intellectual Property Considerations

Intellectual property is effectively nonexistent in the design of our project. In terms of mechanical design, we built a lever, which lacks significant science behind such construction. In terms of electrical and software design, the circuits and code use elementary principles that can be found textbooks. We used past projects to get a feel for what an MCU control algorithm should look like. Our own code was constructed using basic principles of PID control. Therefore, there are no patent opportunities.

Ethical Considerations

In the context of the IEEE Code of Ethics, all the claims made in this report are supported by the operational lever (Rule 3); we did not have the opportunity to sell the project to another group at, perhaps, another university (Rule 4); we were qualified to use all tools and components involved in the project (Rule 5); we incited constructive criticism from Prof. Land, TA Meg, and fellow students and noted all external contributions (Rule 7); and we encouraged the open use of our power-tools by other groups (Rule 10). 

back to top

Appendix

Appendix A: Code

The commented code may be found here.

Appendix B: Schematics

High Level Schematics

Sensor Circuit

Motor CIrcuit

Software Flow Diagram

Video Clip

Appendix C: Parts List

Appendix D: Task Breakdown

Tom: software design, control algorithm, report content, testing, and implementation.

Norbert: mechanical design, hardware design, report content, website, testing, and implementation.

Appendix E: References

Atmel Mega32 Datasheet

ADXL202E accelerometer

4N35 optoisolator

LMC7111 Operational Amplifier

TIP31C transistor

2N3904

Inverted Pendulum Project from SP 2003

back to top