Charts

 

 Figure 1

 

 

Figure 2

 

Figure 3

 

 

 Figure 4

 

 

[Testing] Flight test 9-15-12

Purpose:

1. Collect data for pressure readings from the senor as a function of altitude of the plane and make a graph of this function.
2. Test the product code during flight to see if the servo rotate at given different levels.

Procedure:

Our plane climbed from ground to 9000 feet. During the flight, we collected pressure and altitude from the program, and altitude from the altimeter of the plane for every 500 feet. When the plane went down, we used our product code to control the servo to rotate at certain altitude and checked if it functions.

Data section:

Table of data from ReadAltitude function (from 1500ft to 9000ft)

Pressure(pa)	altitude(ft)
96025	1478.98636
94700	1859.03592
93375	2243.41572
92050	2632.23762
90725	3025.61801
89400	3423.6781
88075	3826.54418
86750	4234.34789
85425	4647.22657
84100	5065.32359
82775	5488.7887
81450	5917.77842
80125	6352.4565
78800	6792.99431
77475	7239.57142
76150	7692.37605
74825	8151.6057
73500	8617.46778
72175	9090.18027

            (see figure 1 in post "chart")


Table of data collected from plane

Pressure(pa)	altitude(ft)
95953	1500
94130	2000
92351	2500
90756	3000
89033	3500
87523	4000
85849	4500
84280	5000
82702	5500
81230	6000
78645	6500
78129	7000
76700	7500
75145	8000
73792	8500
72404	9000

              (see figure 2 in post "chart")

Analysis:

When we combine the data collected from the function and plane, the data collect from function is overlap with the data from plane. This char indicates that the function from the library matches the real data very well. Thus, the ReadAltitude function from library is dependable.

(see figure 3 in post "chart")

Also, we noticed that the data in this chart look like a linear function, but the theoretical function from library is an exponential function:

Altituded(ft) = 145402*(1-( Pressure(pa) / 101325)^0.1903)

The reason we get a linear function is that the range of altitude in the chart is too small. When we changed the range to from 0 to 100000ft, we get a exponential function finally. As we can see, the collected data is a part of this function, and it looks like a linear function in this part:

(see figure 4 in post "chart")

We tested the product code to control the rotation of servo for serval times, but it did not rotate until the product code was corrected. Finally, the servo rotated as predicted at the last time when the plane went down through the altitude of 2000ft.

Before the product code was corrected, the servo did not work because the program calibrated the initail pressure every time the board is restarted or the code is uploaded. The variable, gaugePressure, which is the difference between initail and current pressure, was used to control the servo. However, if the initial pressure is calibrated during the flight, the wrong gaugePressure would be used to control the servo and lead to failure. At the last time, the code was changed to control the servo by using directly the reading from pressure sensor, and the servo worked as predicted.

This problem implied that initial pressure is not a necessary variable for servo control, and calibration of initial pressure might be get rid of.

Conclusion:

In this test, we achieved our goals successfully. We found out that the reading from the plane matches the theorical function very well and controlled the servo working as predicted by solving a little bug. Also, we noticed that the calibration might not be necessary in servo control. At last, thank Jason for his adept flying skills to make this test possible.

[Programming] Servo control code

Stage 1: Basic function

Goal: Create a code that allows servo to rotate certain angel for certain pressure

Idea: Use “Level model” to rotate the servo
         Assume that we allow servo to rotate each 30 degree for each 1000 Pa change of pressure
         We have:

 

 

 

 

 

Level = (current pressure – initial pressure) / pressurePerLevel

                               and then we can let servo rotate: Level * AngelPerLevel degree
Solution:

int floors=(bmp.readPressure() - initialPressure)/PPerFloor;
if(floors<lastFloor)
{
myservo.write(AngelPerFloor*lastFloor);
}
else
{
myservo.write(AngelPerFloor*floors);
lastFloor=floors;
}
(codes from “main_code 5.1_debug swtich”)

P.S.

          In the code: “floors” refers to levels
          To avoid the servo rotating back to previous level, I used variabe “Lastfloors” to record the last level. Only when the current level is greater than last floor, we change the degree that servo should rotate.


Stage 2: Non- uniform function

Goal: Becasue the change of pressuren and the change angel of the servo are not linear functions,      each point in the function of “pressure vs servo” should be executed separately

Idea: To avoid the servo rotating back to previous level, we used variabe “levelflag” here to record the last level.

Solution:

long gaugepressure= bmp.readPressure()- initialPressure;
if(gaugepressure>level1 && gaugepressure<level2 && levelflag < 2)
{
myservo.write(angle1);
if(levelflag<1)
levelflag=1;
}
if(gaugepressure>level2 && gaugepressure<level3 && levelflag < 3)
{
myservo.write(angle2);
if(levelflag<2)
levelflag=2;
}
if(gaugepressure>level3 && gaugepressure<level4 && levelflag < 4)
{
myservo.write(angle3);
If(levelflag<3)
levelflag=3;
}
if(gaugepressure>level4 && gaugepressure<level5 && levelflag < 5)

{

myservo.write(angle4);
if(levelflag<4)
levelflag=4;
}
if(gaugepressure>level5)
{
myservo.write(angle5);
if(levelflag<5)
levelflag=5;
}
(codes from “main_code_5.3_servo control updated”)

Stage 3: Mason's version

Goal:

First rotate: when the rocket is launched
Second rotate: reach 3 miles or 90 seconds
Third rotate: reach 5 miles or 3 mins
Fourth rotate: when it's back to 5 miles or 6 mins
Fifth rotate: 15 mins

Trival goal:

First rotate: reach Lv1 or 30 seconds

Second rotate: reach Lv2 or 90 seconds
Third rotate: reach Lv3 or 180 seconds
Fourth rotate: reach Lv4 or 360seconds
Fifth rotate: reach Lv5 or 900 seconds

Solution:

if((gaugepressure>level1 && gaugepressure<level2 && levelflag < 2) || (millis() > 30000 && millis() < 90000))
{
myservo.write(angle1);
if(levelflag<1)
levelflag=1;
}
if((gaugepressure>level2 && gaugepressure<level3 && levelflag < 3) || (millis() > 90000 && millis() < 180000))
{
myservo.write(angle2);
if(levelflag<2)
levelflag=2;
}
if((gaugepressure>level3 && gaugepressure<level4 && levelflag < 4)|| (millis() > 180000 && millis() < 360000))
{
myservo.write(angle3);
if(levelflag<3)
levelflag=3;
}
if((gaugepressure>level4 && gaugepressure<level5 && levelflag < 5) || (millis() > 360000 && millis() < 900000))
{
myservo.write(angle4);
if(levelflag<4)
levelflag=4;
}
if((gaugepressure>level5)|| (millis() > 900000 ))
{
myservo.write(angle5);
if(levelflag<5)
levelflag=5;
}

(codes from “main_code_5.5”)

Limitation: However, there's a serious bug in this code!

When it reaches Lv1 and the time goes into the interval between 90 sec and 180 sec, the program will go into both the first and the second “if”. In other world, the servo will rotate angel1 and angel2 almost at the same time. Thus, the servo will not work!

 

Stage 4: Modified version

Goal: Solve the bug in stage 3.

Idea: check the level every time before allowing the servo rotate

Solution:

if((gaugepressure<level1 && gaugepressure>level2 && levelflag < 2) || (millis() > 30000 && millis() < 90000)) //if the new floor is lower than the last floor, keep angel the servo has moved
{
if(levelflag==1)
myservo.write(angle1);
if(levelflag<1)
levelflag=1;
}
if((gaugepressure<level2 && gaugepressure>level3 && levelflag < 3) || (millis() > 90000 && millis() < 180000)) //if the new floor is lower than the last floor, keep angel the servo has moved
{
if(levelflag==2)
myservo.write(angle2);
if(levelflag<2)
levelflag=2;
}
if((gaugepressure<level3 && gaugepressure>level4 && levelflag < 4)|| (millis() > 180000 && millis() < 360000)) //if the new floor is lower than the last floor, keep angel the servo has moved
{
if(levelflag==3)
myservo.write(angle3);
if(levelflag<3)
levelflag=3;
}
if((gaugepressure<level4 && gaugepressure>level5 && levelflag < 5) || (millis() > 360000 && millis() < 900000)) //if the new floor is lower than the last floor, keep angel the servo has moved
{
if(levelflag==4)
myservo.write(angle4);
if(levelflag<4)
levelflag=4;
}
if((gaugepressure<level5)|| (millis() > 900000 )) //if the new floor is lower than the last floor, keep angel the servo has moved
{
if(levelflag==5)
myservo.write(angle5);
if(levelflag<5)
levelflag=5;
}
(codes from “main_code_5.6_modified servo control with pressure”)

Conclusion: Hopefully, it will work well in the next test that getting a function of pressure and the real altitude.

T-Minus One Week

We are one week out and have been in the lab all day.  We are here now as James and Professor Mason are debugging the program.  It appears as one of the accelerometers has died. 



Last week, the gear that attaches to the servo was machined to allow a recess for the servo arm to seat into. There was also a copper shaft made with a groove cut into it for the snap rings. Both gears also had grooves cut into them to allow an o-ring to be run around them in order to keep them positively seated.

The final design was printed and is installed on the board today.  We decided to bolt the sample container to the board in order to make sure that it does not move during flight.  The o-rings had to be lubed in order for the servo to turn the top.  All of the gears were attached to their components.  The o-ring grooves ended up not being used due to binding of the gears. 

The electrical team got all of the wiring done on the board.  All of the components were then installed on the board.  Additionally, a camera was added to watch to make sure that the servo turns during flight. 

Working on the drill press

 

 

Getting there...

 

 



The final board layout

Today, we were also able to test the whole assembly and everything held.  We put the board on the vibration simulator as the servo test program ran and everything went well.

Vertical testing

 

Horizontal testing

 

As the day/night wore on, we all got tired and so we had Professor Mason on the testing of the on-board camera.  As you can see, or rather hear, it was comical...

 

Testing on-board camera



 

Wiring Schematics

I've spent a few hours haphazardly using/learning to use by trial and error/watching a couple tutorial videos on Eagle, an electronics CAD program, to make a schematic and PCB diagram for the project.

[Testing] 9-6-12

Today I started to put together the horizontal vibration testing chamber. I used three cans to make this apparatus. I traced and cut an outline out of the first can so that the two can apparatus could fit nicely inside. Then I hot glued the two cans onto the cutout can. Testing will be done tomorrow.

[Mechanical] Revised Design

We learned some things from the initial design and printing.  As mentioned before, we knew we had to reduce the overall size from 1.75" x 1.75" down to 1.25" x 1.25" which has been done.  In addition we added a dual gusset support underneath the sample container to support the weight and any flex in the unit as well as add additional gluing surface area. 

One challenge that we have is that we have been unable to source a 360 degree servo and the current one that we have is only operable to 180 degrees.  One solution for this was to redesign the setup and move away from a direct drive system and toward a geared one.  The new design has the servo attaching to the servo arm as normal but then the arm is inserted and glued to a gear.  The gear will contact a smaller gear (at least 2:1 ratio) that will be connected to the top disk allowing for a full 360 degree turn. 

The black part is the servo with the white servo arm attached.  It is inserted into the semi-transparent gear (shown without teeth).  The yellow part is the top disk and smaller gear (again shown without teeth).  Finally, the red part is the modified base (sample container). 

 

After meeting with the group and discussing the design we realized that we need a way to keep the gear positively connected during the vibrations associated with launch/flight.  We decided that there will need to be a groove cut into the two gears and an o-ring strung around them to keep them from vibrating apart.  This will be reflected in future designs. 

 

Another issue that we are contemplating is whether the rapid prototype printer that we have will be able to handle the printing of the gears.  If not, we will have to source pre-made gears and attach them to the parts that we print.