Very little rocketry has been happening lately because of exams and another project I have been working on. A friend of mine has been working on an idea for a while suggested that we apply for the iLab "incubator" program (not really thinking we would get in) which is a startup accelerator program. Everything happened pretty quickly, over a the course of a weekend we finished a proof of concept and got past the first round. Then we went to a 4 day assessment and got into the program which provides funding and mentoring. I will talk about it eventually but we want to keep the product quiet for now. Last week I quit my job to work on it time so I wont be able to afford to keep the workshop next year or have a particulary big rocketry budget. The timing of everything worked out fairly well because the lease on the workshop ended last month (we got a 1 month extension to move everything out) so I will be moving back into my garage. Also I am graduating at the end of this year so now was the ideal time to leave my job (was a cadet at Baulderstone (Australian construction engineering company)). I am planing on going a masters next year but depending on how the startup goes I might postpone it.
I have mixed feelings about the workshop. It was great to have a dedicated space where you could make noise late at night but it was also expensive and I feel like we could have done more with the money. Someone pointed out to that the real value is having a location that you can test at and I think that is right. Being able to just walk outside and test something in a fairly remote location (known is around on the weekend) was great and I think I took it for granted. In future testing will be a day or weekend long activity.
So I am not entirely sure what will be happening rocketry wise. I am meeting with Burren and Sam tomorrow night to discuss things. I have been wanting to turn choked flow into more of a group as opposed to myself driving things and now might be a good time to do that. Realistically I don't think I will have enough time or money to work on any large rocketry projects for a while. I was thinking that a good way to start more group orientated stuff and attract more members is to start a new project from scratch to build up everyones skills. The hovering rocket was good but I was really the only one who could do/was interested in the programming/electronics and Bart was the only one who understood the control in-depth. I was thinking a cool project to develop team wok/skills could be another nitrous oxide bi-propellant thruster with a electric nitrous decomposition pre chamber. I think that if we could demonstrate a simple proof of concept and made everything open there would be a good chance of getting some money from kickstarter but it will depend on what everyone else wants to do. Something else I have been itching to try out is a roll stabilised clear payload for a HPR which could be used to stabilise a camera.
Also on the 15th I tested thruster 2 again with the 20Kg load cell. The results were pretty much the same, just slightly smoother and higher resolution. Thrust was slightly lower than expected with a max of about 4.5Kg but I think that was because of calibration.
Considering that thrust would be used in the top %30 its range this is probably good enough to fly the rocket. Also I think we could improve this significantly by making the injector smaller.
I always figured that the thrust roughness was random but I thought I would do a FFT to see if it actually was.
As it turns out there is allot of thrust variation at 31Hz which is the frequency the solenoid pulses at. I really wanted to believe that the roughness was just some artifact of the setup or issue with the engine but its clearly not. Highly Sensicial! Makes me wonder how much the roughness can actually be minimised.....
We tested engine 2 (naming system for the engines on the vehicle) last night. There were a few issues with the new test stand but we got some good data.
We did 4 tests ramping the duty cycle from 0-254 and holding at each duty setting for varying times. The title of the plots is Time_Dwell where time is the total test time in milli seconds and dwell is the time spent on each duty cycle. So for example 4000_500 has 8 thrust settings and spent 500ms on each setting. The first test was only for 3 seconds but it seemed a bit short so I extended it to 4 seconds.
The red is a 10 point moving average of the thrust which gives a general idea of what the thrust is doing. I was actually surprised at how well the smoothed thrust matched the input.
I probably wont upload video for future static tests as it takes time to edit and is not particularly exciting. If anyone wants to see the video let me know and I might just upload it unedited.
On the 4th test (4000_50) the peroxide ran out towards the end.
Apart from two small leaks another problem was that the load cell would not register any thrust bellow 1.8Kg of force, which is why I didn't bother converting the raw thrust readings to load for the above plots. This is probably why the thrust only starts at around 50. The other thing is that because the range of the load cell is 0-100Kg and we are measuring 7Kg at max, we are not getting particulary good resolution. I am not sure how much this contributes to the roughness however. I have ordered a 0-20Kg load cell which should give better resolution.
The other problem is that I couldn't manage to get the arduino to record data faster than about 100Hz. Some cycles were faster than others I slowed it down to 66Hz so it was recording at a consistent rate. It should be allot faster than that so either my programming is horribly inefficient or sending data over serial is a bottleneck. I will give recording to SD a go or otherwise get a faster Arduino (have been waiting for an excuse to get a Due...). Programming outside the arduino environment is another option.
Anywhoo, now we have a consistent test to see how well the thrusters are working we can start tweaking them. Next step is to test engines 1 and 3 to see how they compare then we can start making modifications. The first thing I want to test is what changing the injector size does. At the moment we have 3 1.5mm holes which I suspect has too low of a pressure drop.
Plumbing is not installed yet because I was missing a few bits and pieces. The good thing about the design is that the hovering rocket thruster+mount only requires two bolts to remove from the rocket and one to attach to the test stand. The frame itself was kindly donated by Ashley from Advanced Rocketry Queensland. We modified it slightly by putting a cross beam which the load-cell is bolted to. I will pickup the remaining fittings and we should be able to get it finished tomorrow night.
Also I found a new supplier of budget pressure transducer which I am highly excited about! I had been looking since the old supplier ran out of the surplus stock they had and finally found a new one! They key word was "pressure sender".... They are brass which is not idea but will be at the top of the tank so shouldn't be exposed to much liquid peroxide. They also stock 0-500PSI instead of 0-2000 as the old ones were, so should give better resolution. eBay store is here if anyone is interested.
I have been doing some research lately into pressure vessel bursts in order to get an idea of the lethal distance in the event of a burst/explosion. I thought I would share an example as it might be useful to others.
In a pressure vessel burst there are two things that can hurt you, the pressure/shock wave and fragments of the vessel. In this post I will go through calculating the "overpressure" - the pressure above atmospheric and the impulse - The force due to the overpressure/ fast moving air.
What does that mean? Well, in a explosion, the pressure time relationship at a point some distance away from the blast will look like this:
The overpressure is the highest pressure experienced at the point and the impulse being the integral of the overpressure experienced as a force or wind. What does it mean? Well 10PSI or 0.069MPa will result in death of most people.
Internal Pressure:$P_1=3.5MPa$
Ambient Pressure:$P_0=0.1MPa$
Tank Volume: $V=9L$
Height of tank (mid point) $H_s = 1m$
Tank Diameter: $D=0.24m$
Tank Length: $L=0.5m$
Gamma: $\gamma=1.4$ (nitrogen)
Distance at which pressure damage is calculated: $D=5m$
Ambient speed of sound $a_0 = 340m/s$
Assumptions: Cylindrical pressure vessel at ground level with vertical orientation. All energy gets released from the vessel. In reality as much as %30-%40 would get transferred into fragments depending on the material and failure conditions.
The above plot shows scales standoff distance vs scaled side-on peak overpressure for a variety of burst pressure ratios. So our scaled side-on peak overpressure is around 0.04
$\bar{P_s}=0.04$
Scaled Side-On Impulse:
Above is scaled standoff distance vs scaled side-on impulse. Scaled side-on impulse is around 0.03
$\bar{i_s}=0.03$
Correct for tank geometry:
The above plots are only true for a spherical pressure vessel in free air. In reality the ground reflects the shock wave generated when the vessel bursts and increases the pressure. Also a cylindrical pressure vessel can result in a higher overpressure depending on its orientation.
It is generally accepted that the ground doubles the effective length of the vessel for a upright cylinder
$L'/D = 2*L/D$
$=4$
Interestingly, for a horizontal vessel:
$L'/D = L/D^\frac{1}{2}$
The ratio of vessel height to diameter:
$H/R = H/D/2$
$=8$
The above are plots of Scaled standoff radius vs overpressure and impulse ratios (correction factors) for L/D and also H/R we can see we need that we need to multiply our scaled side on peak overpressure by 1.6 and 1.3. Also we need to multiply the impulse by 1.2 twice to account for the height and geometry.
$\bar{P_s}=0.04*1.3*1.6$
$=0.0768$
$\bar{i_s}=0.03*1.2*1.2$
$=0.0468$
Side-on peak overpressure:
So the side on pressure is simply the scales value multiplied by the atmospheric pressure.
In the next post I will go into calculating the distance fragments from the explosion could travel. Fragments are what you would really want to worry about for a small, thin walled pressure vessel. They are much more dificult to account for because the fragmentation depends much more on the vessel and failure conditions.
On Sunday we tested the addition of the attitude loop again with much better results compared to the previous test.
One problem we were having is that sometimes one of the engines would not get going ( would spray out un-catalyzed peroxide) so the vehicle would immediately fly to one side triggering the fail safe. In previous tests I warmed up the engines manually but for consistency I have started using a auto warm-up routine. I tweaked the routine by increasing the time for engines 1 and after test 2 which helped but they are still too short.
I got all my goals done with the exception of ordering the new transducer which I couldn't do because they were out of stock. The real time clock worked well and made it much easier to sort through the log. Amusingly I diffident have enough time to get a clock to put in the video (my camera doesn't do it) so matching the log times up with the video while editing was painful. Nick is going to get a old computer to use as a clock for the next test.
The new stilts worked well at keeping the rocket stationary until take off but ironically the best hovers came after this because the engines had warmed up. Part of the problem is that the wall of the engines is really thin (1.5mm) so doesn't keep the heat. We got a good tip to try insulating the engines which we will try. Wood is not the ideal material for use with peroxide but after a small fire following test one we soaked them in water and had no more issues. We should look for a aluminum alternative.
After the test we started planing the new test stand and tonight we got most of it built. I dident get any photos of it but the new design is much better than the old one. We designed the stand so it would be easy to swap engines between it and the rocket.
We also took apart engine 2 tonight:
This was the supposedly "bad" or otherwise inconsistent engine. Basically it would cloud up easier and more often became unstated. I was quite happy to find that there was very little damage to it. There was a small amount of channeling at the top on one side so we might want to think about having more or thicker anti-channeling rings in future engines but overall I think it has fared really well. The layers of silver mesh in-between stainless were fairly bonded together but I think this is to be expected. Buren and I had a long discussion (more of an argument) about the cause of the inconsistancey. He thinks its because the silver is fused and I think it is because there isn't enough compression. It would have been a much better use of out time to just open up one of the other engines to see if it was fused, as according to his reasoning it shouldn't have been. While they are open we are going to replace the galvanized bolts with stainless ones as they have started to rust. I also want to make the injector home much smaller because I think it will help with the unstarts.
So our focus now needs to be ensuring that all engines are consistent, or at least make sure we thoroughly understand what the differences are (and preferably their cause) because we cant really go too far with the control system when we don't have a consistent platform to test on. I wanted to try some static tests this Sunday but know one else can make it (Buren has to go to some sort of "zombie walk"). I will see if I can get the new stand finished on Saturday and try to get someone else help me test. Now is the wrong end of the semester for rocketry but there is a simple solution.....work harder! I have also started doing some work for a guy that sells inspection robots. I fixed a underwater robot yesterday then took it for a spin in the river which was really cool.
Goals:
Before Saturday:
Order Compression fitting from swagelok - Wednesday
See if 4wd place is open on Saturday - If not buy tank online
Its been a bit of a hodgepodge lately so I wanted to set some goals:
By Sunday:
Get and install real time clock on flight controller so logs can be easily compared to video
Order new pressure transducer - Try to figure out why they keep breaking. Possibly they need a better regulator.
Implement new logging system for compatibility with Matlab - One main log and one for auto commands with no text
Fix issue with control system that caused problem with last test
Write Auto warmup routine & command - 5 pulses @ 15 for 20ms
On Sunday:
Test the attitude loop again.
Lower test stand and make new fatter legs (from PVC pipe?)
Check that the lower rocket cant hit anything before test
Come up with basic design for new vertical test stand and start making frame
Uses current flight tank instead of nitrous bottle
Engine + extensions bolt directly to load cell adapter plate
Use Arduino instead of labview for easier controll and higher speed logging
Use flight computer on test stand or get dedicated controller?
Re-use old stand that is under one of the benches?
If we can get all the bits for the new stand by next Tuesday we should be able to put it together then. If the attitude loop goes well on Sunday (maintain a vertical hover taking off from the legs) we might not have to test the engines but I would still like to get a good thrust curve by varying the duty cycle linearly as it will be useful later on.
Yesterday I had to be somewhere else so we didn't end up meeting.
Yesterday we tried a test of the attitude loop. I made a mistake when implementing Barts controller and as a result the vehicle didn't really show any control.
So we didn't really learn anything new control wise, except that if you have to reverse inputs to get the outputs the right way around there is probably a another problem. One of the issues we had in previous tests is that the rocket was always swinging when starting so had sideways velocity which caused it to drift and as a result it was difficult to see how much control it had. This test we used stilts to take off from which would then fall over from the exhaust.
They were too tall and the vehicle fell over once when pressurising and once when warming up the thrusters. It was a really windy day but the legs do need to be shorter and probably wider. This means we need to lower the vehicle. Our aim for future tests is to load only enough peroxide for a few seconds of hover and only test from the platform. This will ensure all tests are consistent in terms of pressure, orientation and velocity at take off.
When it was clear that the vehicle had no control we decided to do a through test of all the engines by pulsing them individually. It seems like there is a problem with engine 2. We are going to do some flow rate tests on Tuesday and will probably take it apart. I do remember it having less compression than the other two because the injector was slightly. This would cause a lower pressure drop and a higher flow rate which is what we are seeing.
At some stage we will probably need to take all the engines off and test them on the test stand to get better data on their thrust response. This will involve making a new test stand as the one we have now never gave very good results. There are a few reasons but it was not designed for the current engine and the engine is not restrained well. The new one will be test the engine vertically because the engines seem to behave differently vertically compared to horizontal. I also know much more about the thrust settings we need for the vehicle.
Buren and I also did some experimenting with methods of making plastic bladders from plastic sheet which could turn our flight tank into a positive expulsion tank. The idea is to insert the bladder and tube into the top 3/8" hole so we don't have to open the tank. We first tried joining PE film with a flame then with a hot edge which didn't work particularly well as the film would just melt. We then used hot glue which worked really well with a edge to press tow sheets together. We managed to make a fairly good bladder using this method. On tuesday night we will try butting it into the test tank we blew up. Teflon film/sheet seems to be fairly available so thats what we would use for a peroxide compatible bladder. I was thinking about also buying a plastic welding gun so we could use use polyethylene or another plastic to weld it together. It would be easier to join the sheets because the teflon wouldn't melt. The other method of joining would be epoxy but I don't think we could keep it all together well enough while setting. We have only been making "pillow" bladders so far but we are aiming for something like this eventually:
On Sunday we tested the vehicle for a third time with satisfying results. Last test we didn't get enough flight time to determine if the control system was working so we were all keen to see if we could get a controlled hover this time. In total we did two tests. In the first (3L of %85) the vehicle barely had enough power to lift off and we were were worrying that the engines might have gotten poisoned so we tried again with 1.5L of %90. There was a huge difference with clear exhaust and the engines having plenty of power in the second test.We have been using %85 for a while now because I thought it might be damaging/melting out catalyst but I don't think it is an issue with the stainless interleaved pack design we are now using (last pack was solid silver). I think will use %90 for future tests as the performance is much better. In total we got about 9 seconds of total hover in the second test although it was not supporting itself for some of the individual runs.
The only change we made to the control system was to fix the PI code to so it would update every cycle instead of every 4th or 5th as it was doing last test. The hops were not by any means perfect but the part of Bart's control system we were testing (inner velocity loop), worked well resisting rotation and we were all satisfied with the results. The main problem we were having is that when warming up the thrusters with a quick pulse before a test (they cool down quickly) the vehicle would start rocketing and so would usually have some sideways velocity which caused the vehicle to drift sideways during hovers. The other problem was that it is difficult to control the throttle manually so the vehicle would usually not have enough thrust or shoot up.
Here is the log of Roll angle, Rate and PI output for a 2.6 second hover:
As can be seen roll angle started at close to 0 and stayed within +- 0.8 Radians. I havent talked to bart since the test but I at-least am really happy with the performance considering that the system doesn't take the actual angle into consideration and only reacts once the vehicle has started to fall over so will naturally oscillate somewhat. The other thing is that Ki and Kp constants were calculated assuming 4L of peroxide and we only started with 1.5 so the system will want to under and overshoot. The changing system properties is something we need to start thinking about how to address. Next step is to add in the position loop.
We are somewhat divided on where to focus now. I think we should work on getting the altitude loop working with the laser rangefinder so we can maintain a level hover. A thought that we should work on getting absolute position so we can eliminate the sideways drift issue which would enable us to more easily refine the stabilisation system. His argument was that we already have a functioning rocket and we could dead-recon to get position for short periods if we started from stationary so why add something new. A also thought of a good idea which was starting on chocks which would fall away as soon as we take off. This would allow us to warm up the thrusters without starting the vehicle rocketing on its tether. It could also give us a fixed reference to start dead-reckoning from.
I recorded the first test in high speed at 400fps. It was really cool to see the vehicle fighting the tether in slow motion and you can see the vehicle making individual corrections and oscillating. It will take a while to edit as its really long in real time but when I get some time I will upload it. The unedited second test is on youtube here if anyone wants to see it.
After the test we were discussing future work and decided that it would be good (and useful) have a long term goal/challenge to work towards. One idea Marco/A came up with was to be able to drop the rocket from a height and have it stabilise itself and land automatically. The current vehicle probably wouldn't have enough power to recover from a high height (maybe 20m) but wewould start by knocking it off the top of the test stand. We would probably need a positive displacement tank otherwise pressurisation gas would get in the thrusters when it falls over. We would also need a better IMU as the Arduimu goes crazy at large angles.
I am not sure if we will be able to test again this weekend as I have to go to a first aid course all day Saturday and have some uni work to catch up on so we will probally test the following Sunday.
We have been going through the log from the test last sunday and picked up on a problem, The PI values not updating as fast as they should be. The stabilisation loop runs at 31Hz (same speed as the solenoids pulse at) however the PI values were updating slower. Bart figured out that we (or more specifically I) was not using the Arduino pid library properly. The library has two ways of updating itself, Automatic and Manual. Auto mode works like it sounds, the library updates values itself. Quasi-conservatelly, in manual mode you call an update command yourself. I was looking at an example which used auto mode but also called updates manually so that how I did it but apparently the manual updates were not doing anything.
Here is Pitch, Pitch PI output and Z acceleration for the longest test.
Despite the PI values not updating at the speed they should be the PI looks like it has some sort of control. I think that the rocket must have run out of peroxide because the deceleration ocors partway into the test. Either this of the steady state thrust (after the initial spike) was not enough to counter gravity. Either way the program did a good job to stabilise the rocket after it landed on the string because dropping it by hand on an angle (you can see it was at 0.6 rads when it hit) makes it go everywhere. Possibly I am just seeing what I want to see..... It could just be that the the rocket just bounced on the test stand....
Sam and Bart excited for the test!
The Improved Quick Disconnect:
My laser range finder and interface board came today. I nearly got pulled over by the police on the way back from collecting it at the post office because I was measuring the distance to the car in-front as I was driving..... excuses I thought of post-scare included... "Officer, anyone could see I trying to keep a optimal distance from the car in-front"and "What am I doing?... Well clearly I am calibrating my speedometer". If I have some spare time before sunday I will mount it on the rocket so we can get some data.
Yesterday (Saturday) we tried another tethered flight test. The main aim of the test was to test the roll control program. The test went fairly well but after warming up the engines and dialling in the correct amount of thrust so the vehicle would just list off we only got a few seconds of auto hover before the peroxide ran out which wasn't enough time to see if the program worked. The thrust was also a bit low so although it did look like it was stabilising itself it didn't actually lift off. It was dark by the time we had vented the tank so we decided to pack up and try again next Sunday.
We had a few issues with the vent solenoid during the test. I accidentally installed it the wrong way around when installing the quick disconnect earlier in the week and because it only seals one way, when the quick disconnect released for the first time so did the pressure in the tank. We switched it around which was not the best safety wise as although the tank was pretty much depressurised the vehicle still was filled with peroxide. Also because the new line we are using to pressurise is so small (1/8") it takes ages to fill and we burnt out the solenoid when filling for the first time. I decided just to not use it after we had fixed the direction problem (as we don't need the vent solenoid to fill, its just quicker when its open and reaches a slightly lower pressure) which only meant that we couldn't vent at the end of the test without dumping the rest of the peroxide. The pressure transducer was working for this test which was useful good because filling took so long. I had been having great trouble getting it working (reading the transducer voltage), I eventually figured out that my particular Arduino clone needs its VREF pin connected to a something (5V) as the internal VREF doesn't seem to work or is set very low.
Burens quick disconnect worked brilliantly and was probably the best part of the test. When it was fired it came cleanly away and retracted to the top of the stand. Here is a clip of it in action:
We also tried out Sam's GUI control program which looked great but had a few teething problems. It seemed to work well when testing before the test but when we tried it out it was cutting the time of the commands short by one digit so we just switched back to manual commands. I am looking forward to using it for the next test as it makes control much easier than typing out strings and also eliminates errors, it is easy to put an extra 0 on the string and send a pulse for 10 seconds instead of 1.
It is about time we fixed a few minor annoyances on the vehicle. Firstly we need a bettwe way to mount the control box. At the moment the box is screwed together from its underside then bolted to the vehicle. We need to take it off and open it quite a bit and screwing and bolting takes a long time so I usually just tape it closed and zip tie it to the rocket. It would be great if we could just clip it to the rocket. Also it is annoying to have to open the box every time to get the SD card out. A sd card extension cable is one option but a simpler idea would be to just add in functionally to download the file from the controller after the test. We might be able to do this over LAN because the Arduino has a ethernet port on it. Another thing that is annoying it how we fill. At the movement we fill with a funnel through the front 1/4" port and just before the test screw in the pressure relief plug. The port is in a bit of a awkward position and it is difficult to fill and install the plug. Also we ahev to put thread tape on each time and occasionally when unscrewing a little tape gets in the tank. It would be great to have some sort of quick disconnect system where we can just pop off and on the plug and having the filling stem out from the tank.
On Tuesday night I was about to try out the
control system out with compressed air and
was fiddling with a 5V wire when I shorted it on something and fried the Xbee.
I am not entirely sure how this happened since what I touched wasn’t connected to
the xbee but the end result is it now only outputs dots over serial and won’t
respond to any commands (programing or otherwise). Luckily everything else was
fine. The lesson…. Fuse your electronics! I have ordered a replacement, hopefully they will get
here before the weekend.
We have a new member to the group. Bart Hertog is a control systems engineer living in the Netherlands. Bart will be working on the vehicles control system and implementation.
Bart has designed a system that is based on two PI loops for roll control. There is a inner velocity loop that takes roll rate and an outer position loop that takes absolute position.
The plan was to test/tune the velocity loop on Sunday (yesterday) but after a full day of programming on Saturday I was tired, frustrated and starting to make mistakes so I decided postpone a week rather than rush to test something that was not ready.
Bart also had a really good idea to stop an auto hover if the roll/pitch became greater than 45 degrees. This is a really good safety mechnism.
If you think of the output from the control loop as a desired torque the main problem so far has been how to best convert the torque into 3 thruster forces in a way that maintains the desired thrust and also stays within the limits thrust that the thrusters can actually produce. Also the fact that we don't know exactly how much thrust the thrusters can output doesn't help.
We still need to make a proper battery mount to avoid the last minute duct tape we used after the battery came loose last time.
Buren has re-made the remote quick-disconnect with two solenoids which seems to work well so we shouldn't need to use the line cutter for the next test. He has also made a counterweight system so the solenoid and line will be automatically pulled to the top of the test stand after it is disconnected from the vehicle.
Nick is currently looking into a RTK gps system. He wanted to use a beagle board as the fixed base station but I would prefer to just use a computer. We will probably want to get another data modem just for the RTK system.
Sam is working on the control GIU which sends strings out via serial.
Determining altitude is trickier than it may seem. An IR range finder will not work due to the heat of the engines and ultrasonic wont work because of the noise. The only real options left are Radar or a laser.
I have looked lots of laser range finders but they are all either expensive or not suited to my application. There are plenty of cheap "laser tape measures" but all display the distance on a built-in screen and attempts by others to modify them have been limited to hacking the segment display. Parallax make a reasonable priced sensor but it uses triangulation (with a camera) instead of time of flight and I think that the cloudy exhaust might interfere and also only works at 1Hz. There are heaps of industrial ones but none under 1K$.
Today I came across this:
Its a board by Porcupine Electronics that connects to a fluke 411D (laser range finder) and outputs the distance data over USB and serial.:
The display and keyboard is removed and replaced
Apparently it can output at 10Hz with +- 3mm accuracy from 10cm to 30m. Also it will be quite light as the housing can be removed and the electronics themselves wont weigh much.
As it turns out the reason the plots of roll and pitch (refer to last post) looked so strange is because the script I wrote to extract them from the log file couldn't handle variable length strings and as such had a preference for positive numbers. Here is what it should look like:
I have also been doing some vibration testing of the IMU. One of my main concerns is that the vibrations from the solenoids/engine thrust will mess with the IMU's measurements. My first thought for generating vibration was to use a vibration motor but I didn't have one handy and I couldn't find any information on the frequency of my mobile phone vibrator so I used a large speaker (subwoofer).
Here is a plot of roll and pitch with the IMU on the speaker housing with a sine wave sweep from 20-300Hz. When stationary roll and pitch have an error of about +-0.3 degrees.
Sin sweep from 10-100Hz (horizontal scale is wrong):
I noticed that some frequencies sounded much louder than others. At first I thought this was because the ear filters out some frequencies but feeling the enclosure some frequencies definitely felt like they had a higher amplitude.
I used a iPhone app called "Vibration" to measure the amplitude of the speakers vibration (20-300Hz) which can be seen bellow (vertical axis is G's). The other option was to get the IMU to output raw acceleration data.
As can be seen the amplitude is highest at about 100Hz and 250Hz. I these are natural frequency of the speaker/housing? I am also not sure what filtering the speakers do so its possible that they filter out certain frequencies.
Because the amplitude of the vibrations vary so much I don't think any firm conclusions can be drawn but it is clear that there are some frequencies that affect the IMU more than others. Keeping in mind that the IMU was experiencing some fairly severe vibrations in excess of 2G's at peak (it was a really big subwoofer) I am happy with how it performed.
An improvement for future work would be to compensate for amplitude by scaling the raw accelerometer and data (dont think you need to change gyro data) however I am not entirely sure how you would do this in a way that didn't mess up the DCM algorithm that calculates orientation. An alternative would be to use a more consistant vibration source.
Also the test I had planed on doing tomorrow has been canceled because Buren and Sam couldn't make it. Its probably just as well because I still haven't implemented the basic roll control I wanted to test and there will be lots of bugs to fix. I have made a basic test platform which consists of 3 LED's to simulate the engine so we can see if all the axis/directions are right.
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.
