Autonomous Stabilization System for a Coaxial Helicopter full report
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
computer science technology
Active In SP

Posts: 740
Joined: Jan 2010
19-01-2010, 11:14 PM

.doc   Autonomous Stabilization System for a Coaxial Helicopter.doc (Size: 579.5 KB / Downloads: 148)
Autonomous Stabilization System for a Coaxial Helicopter
The purpose of this project and implimentation was the design of a fully autonomous stabilization system intended for systems capable of intelligent programming and navigation. This means that the design focuses mainly on the control feedback systems that control the helicopterâ„¢s motors that then provide lift to increase and decrease altitude, and produce a tilt about the helicopterâ„¢s central vertical axis which would be used for stabilization and potentially lateral motion. We chose this project and implimentation because it was an ambitious project and implimentationed aimed to challenge us as well as provide a level of sophistication that would allow this project and implimentation to be applicable not only as a semester project and implimentation but to potentially be used in future project and implimentations.
2.2.1 MOTORS
1.0 Introduction
The purpose of this project and implimentation was the design of a fully autonomous stabilization system intended for systems capable of intelligent programming and navigation. This means that the design focuses mainly on the control feedback systems that control the helicopterâ„¢s motors that then provide lift to increase and decrease altitude, and produce a tilt about the helicopterâ„¢s central vertical axis which would be used for stabilization and potentially lateral motion. We chose this project and implimentation because it was an ambitious project and implimentationed aimed to challenge us as well as provide a level of sophistication that would allow this project and implimentation to be applicable not only as a semester project and implimentation but to potentially be used in future project and implimentations.
Overall Goal: Design an Autonomous Flying System
Goal 1: Produce a successful design with power and electronic control feedback systems off-board.
Sub Goal 1.1: Design is capable of stable flight at a stationary altitude
Sub Goal 1.2: Design is capable of stable flight at variable altitude
Sub Goal 1.3: Design is capable of stable flight at variable altitude and is capable of non-vertical movement.
1.1 Structure
A simplified diagram showing how the stabilization of the helicopter is obtained is shown below. Essentially, we are controlling the speed of the various motors to achieve stabilization. We achieve this by letting the MCU output a PWM wave to the motors, which is adjusted according to movement detected by the accelerometers and gyroscope.

Fig 1.1 structure
The movement detected by the individual sensors is shown below. Using this mechanism, we are able to create a feedback loop which should stabilize the helicopter.
Fig 1.2 movements of the sensors
More specifically, there are three major aspects of the craft that need to be controlled using a feedback system. These aspects are altitude, rotation, and orientation.
¢ The rotation of the craft will be implemented via a control feedback system that uses a gyroscope to determine rotation and adjusts the two rotor motors accordingly to keep the craft from spinning out of control.
¢ Orientation will be controlled using a basic algorithm to determine the appropriate voltage levels needed on the propellers to adjust the tilt of the apparatus such that the tilt corresponds to either hover (no or close to no movement) or a specific degree direction and rate. The tilt will be determined using a two-axis low-g accelerometer.
¢ To control altitude we determined what the Z axis acceleration is and try to eliminate it.
The following diagram briefly outlines the design of the above systems.
Fig 1.3 Brief design
2.0 Hardware
The essential components of the hardware system are
¢ Protoboard and MCU
o Push Buttons
¢ Gyroscope
o Voltage divider
¢ XY-Accelerometer
o Voltage regulator
¢ Z-Accelerometer
¢ Helicopter
o Motors
- Optoisolator Circuits
o Launch Pad and IO Tether
¢ Power Supply
2.1 Protoboard
The Atmel Mega32 microcontroller is mounted on the provided custom made Protoboard. We added three ports, for interfacing with the motors and sensors. Port A is used for receiving the outputs from the sensors, Port C is used for the PWM outputs to the motors, and Port D is to interface with buttons that are used to turn on the helicopter as well as the debug LED which proved invaluable for the development of our project and implimentation. Due to the current that is required by the whole system, we replaced the voltage regulator with a LM340 5V regulator that can support our design's current needs better.
The Push buttons were used for some basic debugging and testing purposes, however, they were mainly implemented for the purpose of starting up the helicopter flight routine without introducing any sort of vibration/electronic noise into the system. This allowed us to turn on the helicopter without touching anything sensitive and allowed us to better balance the craft once we got down to the nitty gritty aspects of making the stability system tight enough to work within the length of our IO tether.

Fig 2.1 connection of ports
2.2 Helicopter
We bought a Blade Runner RC helicopter from Ebay for $10. We tore this apart, removing the chassis, RF receiver, and lithium ion battery. We used the rest of the parts, namely the gears and rotors for our design. This was done since we did not have the facilities, budget or time to design and build these ourselves. The structure of the helicopter is such that there are two main rotors to provide lift that are individually controlled through their own motors and gear systems. For the body of the helicopter, we glued the whole gear system on to a slab of Styrofoam. Since weight is especially a key issue, we decided to wire everything with 36 gauge wire, which reduces its impact on weight. Due to the number of wires that are to and from the helicopter, we decided to connect them to jumpers for easy interfacing. Below is an early conceptual model that demonstrates the design of the Helicopter's geometry.

Fig: 2.2 the model of coaxial helicopter
2.2.1 Motors
To interface with the total of five motors (2 main, and three for stabilizing), we designed a 5 channel optoisolator circuit that was based off the one used in Lab 5. The diagram for a one channel optoisolator is shown below. Essentially, this circuit is duplicated five times on a solder board.

Fig: 2.3 optoisolator circuit

Fig: 2.4 port showing optoisolator circuit connections
The main motors came with the helicopter are Mabuchi motors (part # FF-N20PN), which are rated at 1.5 -6 V, and 14600 r/min with no load. We believe that these motors are sufficient to meet our goals of the project and implimentation. From the optoisolator circuit, Vcc is common to all of the motors and the grounds are independent. Hence, we connect the positive leads together while we use the ground wire to individually control the motor speeds.
We plan on using smaller motors ( 0.20" diameter x 0.4" long), which operate at 1.5-3Vdc at 110 mA, as the stabilization system. We bought these from (CAT# DCM-255). Essentially, these motors come out from the body of the helicopter, and provide tilt about the x and y axes. To do this, we experimented with different types of rod material that would be light, yet rigid enough to support the motors. We finally set on using 1/16 diameter hollow aluminum rods, so we can run the power cables through them. To mount the motors onto the rods, we used the glue gun to create a mat of insulation between the motors and the rods, which also acted as the adhesion layer. Finally, we also glued the rods to the new Styrofoam chassis with the proper geometric spacing of 120 degrees between each rod maintaining that the distance from the main rotor shaft to the stabilization motor on that rod was equal among all of the rods. Similar to the main motors, the power for these motors was all common, thus we can control them just by having their ground wire interfaced through. Thus only six IO wires are required for all of the five motors.
"Launch Pad"
For practical reasons, it made sense to use a base where the helicopter can take off and land, while all the wires are out of its way. Hence we chose to elevate the base where the helicopter launches off. We managed to build this off scrap found around campus, namely a particle board with wood pieces stuck to it. The IO tether ended up being a large part of the design process since we had to make sure that the helicopter would gain enough altitude to have the ability to stabilize but still not too much so that it could have some slack on the line even if it moves laterally to stabilize.
2.3 Gyroscope
We were able to sample a single chip rate gyro from analog devices (ADXRS150EB) . As this comes packaged already as an evaluation board, no soldering had to be done. To mount this onto the helicopter, we used a DIP socket, which was mounted on a small piece of solder board. The way we interfaced to gyroscope is shown blow. We built a voltage divider to provide the reference voltage needed using 2 1K ohm resistors, since the input voltage is 5V. We finally placed this onto the chassis of the helicopter.

Fig: 2.5 gyroscope
2.4 XY Accelerometer
Freescale provided our lab with samples of ± 1.5g Dual Axis Micro-machined Accelerometers (MMA6261Q), which were sufficient for our needs. As these come in rather bulky evaluation boards, we dremmeled off most of the board to loose as much weight as possible. Since this accelerometer requires a 3.3V input, we use a 2490 power regulator provided by Freescale as well to provide the necessary voltage. The way we interfaced to this chip is shown below. This chip was also placed in the helicopter chassis but not coupled to the chassis as can be seen. This was a crude version of a motion isolator we used to try and absorb vibration noise from the propeller motion. In experimentation we noticed that this lowered the peak-to-peak level of the noise due to the main motors on at 50% power from 1 Volt to .5 Volts simply on the oscilloscope. This combined with our real-time averager provided us with a very robust system for determining the tilt of the craft as explained in the software section.

Fig: 2.6 XY-Accelerometer
2.5 Z accelerometer
Freescale also provided low g micromachined accelerometers (MMA1260D), with specifications sufficient to meet our needs. Again, we dremmeled the boards down to cut down weight. As the only required voltage is a 5V DC input, no voltage regulator or divider was required. The evaluation board was finally placed on the Styrofoam base, towards the front of the helicopter, which also provided a better balance.

Fig: 2.7 Z-Accelerometer
2.6 Power Supply
We were able to get a 250W ATX power supply from the ECE department, which is able to power our whole system. Initially using the power supplies in class, we noticed that there were voltage dips whenever the system is on (between 2 and 3V drop), and hence not very reliable. Now using this power supply, these voltage dips are reducing to maximum of 5V.
3.0 Stability System
The stability system consisted of 4 different control feedback systems. We experimented with various different methods of producing reliable results and below are our conclusions. In the end our software was capable of having the helicopter demonstrate autonomous stabilization in all X, Y, and Z axes as well as stabilization in itâ„¢s rotation about its Z axis. We will describe how each of these control feedback systems was implemented.
3.1 Gyroscope
This was the first of the control feedback systems to be designed. We had a very good amount of success with this one which we later found out was due to the gyroscopeâ„¢s immunity to vibration noise that was very common in our mechanical system. Our first pass in designing this system was considerable successful.
First the gyroâ„¢s level at no motion was calibrated at the start of the program. This was done by waiting a while and then assuming that this was the point where the helicopter was stable and to save this value as the gyroâ„¢s calibration point. Then the system was rather simple. The code would wait for an analog conversion to complete and then check the value coming out of the gyro. If this value was different than the gyroâ„¢s calibration point we knew that the helicopter was rotating in a known direction and we would adjust the PWM signal to each motor accordingly. This was a linear adjustment and no PID was necessary in this system. This was our trim adjustment.
At first this was very effective so we did not venture to incorporate a PID into this design. The helicopter would self compensate and very quickly reach an equilibrium. This worked very well on the ground where friction was present. However in the air we started to notice some strange effects. At this point we had implemented some basic run-time averages for some of the other sensors so we decided to apply this method to the gyro scope and this worked very well. This was where we tried to implement a PID and the helicopter would oscillate wildly. To quell the oscillation would have required too much processing power and not enough benefit since the simple 32 run-time average was much more effective and dampened quite quickly even when the adjustment levels were very low.
3.2 The Run Time Averages
Later in the design process while implementing and integrating the Z-Accelerometer we noticed that no matter what we did, we could not get a reliable result when the propellers were on and incorporating an immense amount of noise into the system. These were due to vibrations in the mechanical system and were impossible to fix using many methods that we tried such as analog low pass filters of very low cut-offs as well as mechanical motion isolators. What we ended up doing was to implement a run time average. This way the noise would be averaged out and we would get the average value out of the sensor. This method ended up being used for all of the sensors on board. Also a basic motion isolator was used for the X,Y accelerometer: the accelerometer was decoupled from the chassis and the only thing holding it up were the wires that provided its connections to power and its output. This allowed some of the vibrations to be absorbed by these "springs."
This method was rather simple. First we would calibrate the sensor. This was done in a similar manner to the first method we used with the gyroscope but more sophisticated. We would set up an array of the length of our filter. This length had to be of size 2n (where n = 1, 2, 3 ¦) so that we could use shift operations for quicker computation. For our purposes these sizes were satisfactory. Using a loop an analog conversion would be run for every array element. This would fill up the array which was used as a buffer. The calibration variable was then set to the first average of this buffer which was assumed to be the most accurate representation of the calibration point of the craft when it™s not moving.
To use this buffer during the actual program we could run the analog conversion of the specific sensor and take its value and put it and the end of the array and then move the rest of the array down by one bumping off the last array element. Then we would take the average of the buffer and use this as the value of the sensor and compare it against the calibration point. This method proved very effective and was simple to use since if we wanted less noise we would simply increase the size of the buffer. However, we had to be careful in doing this since if we had too many of these averages running and they were too long then the system would become slow and inaccurate and also potentially oscillate.
3.3 The X and Y Accelerometers
For these stability systems we simply had to control the PWM signal sent to the three stability motors. Using the run time average system described above we would discern when the helicopter was tilted in a specific angle. Then using some basic trigonometry we could see the relative weights that we had to add to the signals or subtract from them. These are shown in the diagram below,

Fig: 2.8 Calculation of the angle
This means that to rotate the craft about the x-axis we could apply one unit of force to the front motor to tilt it one way or apply one unit to each of the other two motors each to tilt the craft the other way. This is because that the lever arm of the other two motors is half as effective as the lever arm of the front motor. This was rather convenient for us.
The other axis was a little more complex. We decided that we would simply use the two motors capable of providing tilt about the y axis rather than trying to compensate for the resulting x axis tilt with the front motor since this could potentially defeat the x-axis accelerometer algorithm. Instead we just used the two of them with equal powers to adjust for y-tilt and let the x-accelerometer system take care of the resultant x axis tilt.
Also, we implemented a variable for each axis which represented how flat the craft was. This was later used in the Z accelerometer for a short while to gauge whether the Z accelerometer was getting a bad sensor reading due to the fact that its orientation was tilter and its acceleration of gravity different. This was something we wanted to avoid since we only wanted the Z accelerometer to gauge up and down motion and not tilt.
The stability system was generally turned on after the helicopter had reached a certain upward momentum. This was to ensure that the stability motors would not be affected by take off which needed to be a smooth and quick upward motion which could potentially introduce shock into the system and send the sensors to ill-readings. Also, since power management was a problem in our initial design we implemented some limiting speeds to the stability motors. Although these did not matter too much when we fixed our power supply to something more reliable, it was very useful since we could adjust how fast the helicopter reacted as well as smooth out the stability system and not give it too much power. This allowed for a much more gradual and sustainable stability.
3.4 The Z Accelerometer
This was the hardest of the systems to implement. We basically spent a good amount of time playing with the thresholds until we found a good stability point. The same method was used as for the rest of the systems. However, this one was a good deal touchier. In the end we had to cater our helicopter takeoff routine around this sensor and basically only let it turn on when we were generally sure that the helicopter had gained enough altitude so that maintaining an altitude was not too close to the ground where all of the mechanical lift systems would simply fail. This was one of the few sensors in which we had to hand find the threshold for which the system behaved correctly. This was found to be minimal and was just some basic noise rejection methods.
3.5 The Helicopter Stability Routine
We defined more helicopter states than we implemented although the states defining lateral movement would have been easy to implement but we did not have enough time to fully test them as well as the fact that our cables were not long enough to truly demonstrate this functionality. The routine the helicopter takes to demonstrate stability is a rather straight forward one and toggles between the different stability systems as to give it true autonomous behavior. These states are toggled through by a very basic timing system that does not really use seconds or milliseconds but time increments that we catered to our needs (although they are labeled as otherwise).
GROUND “ This state was used before TAKEOFF. No stability systems were turned on other than the gyroscope and usually the speeds of the rotors was zero or around 30%. This allowed for some trim calculations to be done before the helicopter took off but these did not prove too effective and were cut out in later versions.
TAKEOFF “ This was the most sensitive part of the flight process. If the helicopter took off in a strange way then this behavior would take a while to smooth out over the expanse of the flight and often times was beyond the reach of our cables so we focused on this phase more than the others. Basically the helicopter required a quick increase in rotor speed to give it the initial upward motion to get up in the air. This made us push the rotors to 95% (to give some space for gyroscopic adjustments to take place). It took some trial and error but we finally calibrated the take off routine to work well with the gyro and then we were able to gyroscopically stabilize take off. This proved very effective in later tests. All other stability systems were turned off to make sure that the takeoff motion was done in as close to a vertical manner and that no shock signaling would alter this upward trajectory and send the helicopter in an unpredictable lateral motion.
HOVER “ Although an intermediate state was implemented named STABLE which was when the stability system was turned on and the altitude compensation system was not this was the extent of the state and needs no further explanation. The HOVER state is the state which the helicopter reaches when it is ideally meant to hover. At this point all of the stabilization systems are working and generally the helicopter will experience fluctuations based on the ambient air currents but will compensate for them rather quickly. This state was quickly switched on after the TAKEOFF when we assumed the helicopter reached a high enough altitude for the stability systems to be effective.
LANDING “ In this state all systems are turned off other than the gyroscope. This state simply lowers the speed of the main motors until they reach a certain threshold where the helicopter is sinking downwards. This is meant to cause a gradual decrease in altitude and in turn land the craft gracefully. This is the simpler of the states since we assume that the craft has reached stability by the time it reaches this state and the altitude was minimal so it would land quickly and with no problems. This state is turned on after our hovering grace period is over.
For a good portion of the program we used Bruce Landâ„¢s fixed point code that we had used before in lab#4. This allowed us to have a greater control and resolution in incrementing and decrementing the PWM signals. Other than this all code was originally written and any code used other than this was used for reference only.
Result “we are not able to finish this project and implimentation, due to lack of time and unavailable of components like Gyroscope, Accelerometers etc. we successfully done optoisolator circuit and input constant voltage for microcontroller. And we are able to collect a lot of information about how the coaxial helicopter works and how can we achieve stabilization using 5 motors and a microcontroller.
3-Terminal 1A Positive Voltage Regulator
¢ Output Current up to 1A
¢ Output Voltages of 5, 6, 8, 9, 10, 12, 15, 18, 24V
¢ Thermal Overload Protection
¢ Short Circuit Protection
¢ Output Transistor Safe Operating Area Protection
The KA78XX/KA78XXA series of three-terminal positive regulator are available in the TO-220/D-PAK package and with several fixed output voltages, making them useful in a wide range of applications. Each type employs internal current limiting, thermal shut down and safe operating area protection, making it essentially indestructible. If adequate heat sinking is provided, they can deliver over 1A output current. Although designed primarily as fixed voltage regulators, these devices can be used with external components to obtain adjustable voltages and currents.

Internal Block Diagram

1. Input 2. GND 3. Output

Rev. 1.0.0


ABSOLUTE MAXIMUM RATINGS (TA = 25°C unless otherwise specied)
Parameter Symbol Value Units
TOTAL DEVICE Storage Temperature TSTG -55 to +150 °C
Operating Temperature TOPR -55 to +100 °C
Lead Solder Temperature TSOL 260 for 10 sec °C
Total Device Power Dissipation @ TA = 25°C Derate above 25°C PD 250 mW
3.3 (non-M), 2.94 (-M)
EMITTER DC/Average Forward Input Current IF 100 (non-M), 60 (-M) mA
Reverse Input Voltage VR 6 V
Forward Current - Peak (300µs, 2% Duty Cycle) IF(pk) 3 A
LED Power Dissipation @ TA = 25°C Derate above 25°C PD 150 (non-M), 120 (-M) mW mW/°C
2.0 (non-M), 1.41 (-M)
DETECTOR Collector-Emitter Voltage VCEO 30 V
Collector-Base Voltage VCBO 70 V
Emitter-Collector Voltage VECO 7 V
Detector Power Dissipation @ TA = 25°C Derate above 25°C PD 150 mW mW/°C
2.0 (non-M), 1.76 (-M)
ELECTRICAL CHARACTERISTICS (TA = 25°C unless otherwise specied)
Parameter Test Conditions Symbol Min Typ* Max Unit
EMITTER Input Forward Voltage (IF = 10 mA) VF 1.18 1.50 V
Reverse Leakage Current (VR = 6.0 V) IR 0.001 10 µA
DETECTOR Collector-Emitter Breakdown Voltage (IC = 1.0 mA, IF = 0) BVCEO 30 100 V
Collector-Base Breakdown Voltage (IC = 100 µA, IF = 0) BVCBO 70 120 V
Emitter-Collector Breakdown Voltage (IE = 100 µA, IF = 0) BVECO 7 10 V
Collector-Emitter Dark Current (VCE = 10 V, IF = 0) ICEO 1 50 nA
Collector-Base Dark Current (VCB = 10 V) ICBO 20 nA
Capacitance (VCE = 0 V, f = 1 MHz) CCE 8 pF
TRANSFER CHARACTERISTICS (TA = 25°C Unless otherwise specied.)
DC Characteristic Test Conditions Symbol Device Min Typ* Max Unit
Current Transfer Ratio, Collector to Emitter (IF = 10 mA, VCE = 10 V) CTR 4N35 4N36 4N37 100 %
H11A1 50
H11A5 30
4N25 4N26 H11A2 H11A3 20
4N27 4N28 H11A4 10
(IF = 10 mA, VCE = 10 V, TA = -55°C) 4N35 4N36 4N37 40
(IF = 10 mA, VCE = 10 V, TA = +100°C) 4N35 4N36 4N37 40
Collector-Emitter Saturation Voltage (IC = 2 mA, IF = 50 mA) VCE (SAT) 4N25 4N26 4N27 4N28 0.5 V
(IC = 0.5 mA, IF = 10 mA) 4N35 4N36 4N37 0.3
H11A1 H11A2 H11A3 H11A4 H11A5 0.4
AC Characteristic Non-Saturated Turn-on Time (IF = 10 mA, VCC = 10 V, RL = 100) (Fig.20) TON 4N25 4N26 4N27 4N28 H11A1 H11A2 H11A3 H11A4 H11A5 2 µs
Non Saturated Turn-on Time (IC = 2 mA, VCC = 10 V, RL = 100) (Fig.20) TON 4N35 4N36 4N37 2 10 µs
TRANSFER CHARACTERISTICS (TA = 25°C Unless otherwise specied.) (Continued)
AC Characteristic Test Conditions Symbol Device Min Typ* Max Unit
Turn-off Time (IF = 10 mA, VCC = 10 V, RL = 100) (Fig.20) TOFF 4N25 4N26 4N27 4N28 H11A1 H11A2 H11A3 H11A4 H11A5 2 µs
(IC = 2 mA, VCC = 10 V, RL = 100) (Fig.20) 4N35 4N36 4N37 2 10
Use Search at wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion

Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  PHS BASED ONLINE VEHICLE TRACKING SYSTEM full report project topics 6 8,559 07-01-2016, 11:33 AM
Last Post: Guest
  FINGER PRINT BASED ELECTRONIC VOTING MACHINE full report project topics 48 42,595 09-10-2015, 10:18 PM
Last Post: Guest
  RF Based SPY robot full report seminar topics 4 11,818 09-03-2015, 11:25 PM
Last Post: rsnnzxrkv
  DIGITAL SPEEDOMETER full report seminar surveyer 8 11,677 30-10-2014, 07:50 PM
Last Post: akhil4718
  MICROCONTROLLER BASED DAM GATE CONTROL SYSTEM full report seminar class 13 10,321 13-07-2014, 11:33 PM
Last Post: Guest
  DOOR LOCKING SECURITY SYSTEM UING GSM FULL REPORT seminar class 11 10,837 14-06-2014, 08:07 PM
Last Post: lagua2012
  PLC BASED TRAFFIC CONTROL SYSTEM full report seminar class 5 10,708 10-01-2014, 03:08 PM
Last Post: seminar project topic
  Microcontroller Based Anesthesia Injector full report project topics 4 8,986 19-10-2013, 09:02 AM
Last Post: Guest
  MICROCONTROLLER BASED AUTOMATIC RAILWAY GATE CONTROL full report project topics 55 75,966 07-10-2013, 08:54 AM
Last Post: Guest
  TOLL COLLECTION SYSTEM USING RFID REPORT seminar projects maker 0 367 24-09-2013, 03:02 PM
Last Post: seminar projects maker