Today I wrote a script to extract the useful bits from the log files recorded during last Sundays test
Bellow is a plot of Roll and Pitch for the second test (the first one in the video(one where its still light)). The sample rate was about 50Hz. When the IMU was shocked too severely it gives really high values so I filtered out any values higher/lower than +/-180. From what I can see the only times the IMU gave wrong values was when it was bouncing on its tether. The values didn't seem to be affected by any engine vibrations although I wasn't pulsing the engine (was on full). During the static tests the vibration while pulsing is much more severe. I have been doing some research on the vibration sensitivity on the Arduimu's MPU-600 (gyro and accelerometer) and the chip should be able to handle the low frequency (30Hz) vibrations from the solenoids fairly well as long as the amplitude is reasonable because the MEMS accelerometers work at much higher frequencies (in the KHz).
You can see the point of liftoff in the middle where the roll and pitch peaks. All the oscillations are when it is rocking around on its tether.
Looking at the graph you can see that the IMU has a preference for positive values. There is a problem with some newer ArduIMU's where the manufacturer of the MPU-600 (gyro and accelerometer) changed its gyro scaling values and as such rolls and pitches appear exaggerated and wrong. The firmware I was running during the flight was older and I don't think had the new value so I dont think this is the cause of the problem. I really need to do more playing with it.
Yesterday we flew the hovering rocket for the first time. I am still working on the stabilisation program so it was controlled just by pulsing all the thrusters at maximum which resulted in a crazy looking flight.
We actually did 3 separate tests. The first one was a practise run with water to make sure everything was working. Then we did a test with peroxide but after the first hop (if you can call it that) the battery came loose so we stopped the test. We then replaced the hose and did a second test. It was quite dark by this stage so it is a bit difficult to see what it happening in the video. Here is short video showing some of the test:
My objectives for the test were:
Test the ground, flight command and data logging systems.
Demonstrate that the vehicle could actually liftoff.
Record orientation data to see how the ArduIMU coped with the flight
I had a fairly hectic saturday trying to get everything finished in time. I decided to redesign the disconnect system as it doesn't quite work as well on the vehicle as it did on the bench tests. The reason for this is that if there is any torsion on the disconnect it takes much more force to actuate and the solenoid isn't able to provide enough force.
Instead of the quick disconnect I decided to go with a more reliable system which involves cutting the pressurisation line. To cut the line I used a set of electric shears and modified them to be actuated remotely. I was really surprised by how complicated the control electronics of the shears were....
Test of the system:
For this feathered test we cut the line on the ground. The idea was for the coiled air hose to recoil so there wasn't much hanging off the rocket. Unfortunately the hose didn't recoil much so there was hose flailing around on the side of the rocket during the test. For the next test plan on cutting the hose just above the solenoid with the cutter on a trolley leaving minimal hose remaining on the rocket.
For this test we only pressurised the vehicle to 450PSI as the cheap hardware air hose we used burst at around 500PSI. Unfortunately I was at work and Buren didn't get to the fitting store before it closed to get thicker nylon hosing.
There were quite a few issues with the command system. A few times when I would command a pulse of all engines one would stay on after it should be off for a few seconds which was quite concerning. Also the vehicle didn't respond to a few of the pulse commands which I think is because it is trying to send too much data (every time it gets a new IMU update) so misses the ocational command. I think that this might be the cause of one engine staying on too long as it gets stuck sending data. I either need to get a separate radio for commands than for data or log the sensor data in HD onboard and only send data back occasionally. On a side note I was rushing on saturday truing to get everything ready and I fried the Arduino by reversing the voltage in. Luckily I could get another one locally but they didn't sell the exact same one, instead I got one based on a Atmega2560 which also has a micro-sd port and a lan port. I didn't have time to learn how to use the SD port but should be using it next test.
All the ground systems worked really well. I edited this tool which displays the orientation of the rocket (currently a picture of a plane) in 3d and also pressure in real time and allows me to send text commands I type in (I didn't have time to put in buttons....). The pressure transducer didn't work but I didn't have time to figure out why. It also logs the data and displays them in the program. This was the first time I have used the processing language and maybe its the mechanical engineer in me but I love it! I haven't looked at the orientation data propelly (need to make a program to re-play it from the log) but from looking at the screen during the test and the text log it seems quite smooth and doesn't jump around much. The vent solenoid seems to interferer with the yaw (as it uses the compass sensor) but I don't need yaw. I need to have a better look at the arduIMU firmware. I increased the arduIMU's output rate from about 5hx to 50hz but I think the way I did it might have messed up something else as even when I am holding it still the roll and pitch seems to be rougher than it was before.
We were all a bit disorganised at the test and there are a bunch of things to improve for next time. I wasn't particularly happy there were things we hadn't thought of in advance. Sam started to do an operations manual for the test but it wasn't finished to the point of being useful and we didn't all have proper roles.
I am happy with our filling and pressurisation system, its the safest system yet. Briefly: The vehicle is filled using a funnel in the clean space of the workshop and then is carefully carried outside without the pressure relief plug installed so it is open to the atmosphere. We then set up the disconnect, cameras etc. and everyone but me goes away. I then turn on the computer, test it and arm the failsafe vent solenoid. On a side note I put a really bright light on the vent solenoid so I could see when it was on so there is less chance of leaving it on and burning out. Lastly I install the pressure relief plug so then vehicle is sealed.
So there are a heap of things to improve before the next test. I cant see us being ready for an active stabilisation test this weekend but we should be ready the week after.
Yesterday I planed on doing a basic test firing of the thrusters to check if everything was woking before starting to tune/test our control system. Unfortunately we didn't get that far because I fried all 3 solid state relays by wiring them backwards. I figured that because they were switches it didn't matter which way they were wired. As it turns out they are not just switches....
Instead we did all the other things needed required for a hanging test. I am going to pick up some replacement relays locally which should work (they are rated for a minimum 24v and I am using 12) . If not I will have to wait a while for new ones.
In order to retract the pressurisation tube and quick disconnect after pressurising we are going to use a simple pulley system which pulls the line and electrical cable off to one side of the stand.
For the pressurisation and venting I decided to go with simple hard wired electronics instead of a separate micro controller which would be triggered by the computer.
This is the quick disconnect sam made a while ago. It looks a bit crude but works every time.
On sunday Burren finished the remaining plumbing and we leak tested everything to 120PSI. There were a few small leaks but we tightened the leaking fittings which fixed them. I didn't feel comfortable pressurising the tank any higher than 120PSI with us around. On sunday I want to do a complete practise run with water to test out all the systems and also see if there are any leaks at higher pressures. Electronics are now %90 finished, I just need to wire up the fail-safe pressure relief solenoid. This is a normally closed (on) relay wired to the solenoid so the solenoid will be open when the controller is not telling it to stay closed. A mechanical solution would be ideal but I cant find any normally open solenoids that suit our application. We will just have to be careful about checking battery voltage before each test.
If the systems test on sunday goes well I might also try a quick (unguided) run on the test stand. We assembled the lighting truss last night and although it is not quite as sturdy as I was hopping it should work well. As a friend pointed out might need to weigh down the sides to stop it falling over.
I managed to burn out the vent solenoid the other day by leaving it on for too long. They are not designed to operate continuously and get extremely hot when operated continuously for more than 30 seconds. As a friend pointed out they take about 9 amps to run so at 12 volts with P=IV they are dissipating more than 100w of power! I took the burnt out solenoid apart and found that one of the wires to the coil had melted. I re-soldered it but because the coil had heated up so much the enamel on the copper enamel wire had flaked off so it was shorting somewhere inside and as such the resistance was negligible and so was like a short circuit and it melted the again. You can buy replacement coils but I didn't want to wait for one so I intend to re-coil it myself. The solenoid would be able to dissipate the heat much better except that the coil is wound on a plastic bobbin which insulates it from the heat sink that is the solenoid body. I intend to re-wind the solenoid directly to the solenoids steel shaft which will allow the heat to be conducted to the solenoid body. I was toying with re-winding with thicker wire to lower the resistance then make up the difference with a power resistor or possibly just running it at a lower voltage. The lathe made it really easy to unwind the coil.
Over the last week we have been doing some of the less exciting things leading up to the first vehicle test.
I have been mainly programming the flight and ground software as well as some wiring. I learnt my lesson on the nitrous thruster project about having un-necessary complex software and ground electronics. For that project I wrote a python program that I used to control the test stand electronics. This in itself wasn't so bad but the program was not well written and thought out. The test stand software/communication proctorial also had random communication interruptions which the test stand software did not handle well. For first test I my "fix" was to have the test stand micro controller reset itself every few seconds (which didn't affect operation) so if it froze it would fix itself.
This time around I decided to use lab-view for control. There is a certain cool factor in writing your own program from scratch to "remotely control your rocket" but there is no point in re-inventing the wheel and lab-view makes the graphical side much quicker and handles serial much better than a python program written by me.
For the flight software I had been giving some thought to using simulink to run the rocket but from a safety perspective I don't really feel comfortable letting a program I diffident write (interpreted from the simulink program) control the rocket so I will still be using Arduino.
Commands are sent to the rocket individually via a 5 character string over serial. I wanted to be able to command individual solenoids manually and also give the vehicle commands which it knew what to do with. For example "S2255" means set solenoid 2 to 255 and "S2000" means set solenoid 2 to 0.
At the moment the rocket will continuously send out Pressure and IMU data every 0.1 seconds which is displayed in the labview program. It also sends diagnostic strings when enabled which says what it is doing program wise.
This weekend I want to do some trial runs filling, pressurising, venting and testing out all the systems. I also want to pressurise to 800PSI to test the tank. I know the burst pressure should be around 950PSI but it is possible this tank could be weaker than the previous one we tested.
I ended up just buying a lighting truss to suspend the vehicle for tethered testing. It is 4m high and can support up to 60KG. Sam started making a wooden truss but considering the lighting one was only going to be slightly more expensive I think it will work out better. Its also potable and comes with a carry bad which could come in handy. I was also worried about the wooden one burning.
The stainless tubing is a continual source of frustration but hopefully it will finished this weekend. If you can work with flexible hose I would highly recommend it over hard tube.
