My son (Paul A) spent the better part of the last two weeks helping some friends finish the plumbing and fixtures for a static firing. I went out Sunday to wire up some sensors and record data for the event. beyond that I can't talk about it much. All of the stuff Paul A and I were responsible for worked correctly. All the plumbing worked and I logged good data. Both Murphy and Marvin were present at the test. Marvin who??? Marvin the Martian of course, his favorite line "And right about now there should have been an earth shattering Kaboom!" It was nice to see everyone from FAR and work on a project with them. It was also nice as a father, to see skilled, competent, successful adults, impressed by my sons skills and work ethic. Being a father has been a hard job, but its nice to see that my son is starting to learn a lesson that took me at least 10 years longer to learn. Happiness and satisfaction can not be purchased. All too often we think I'll be happy as soon as I buy a new motorcycle,car, house,wardrobe etc... I'll be happy as soon as I'm promoted to manger, VP etc.... I strongly believe that happiness is earned by creating or doing something that has value. The sense of satisfaction earned by accomplishing something hard can not be oversold. I also think that the creation of tangible things with your own hands is of great personal value. You can not purchase this feeling.
While I was out at FAR waiting for other parts of the project to come together I flew the helicopter, the GPS finally works correctly in flight! Alas the Compass does not because the GPS antenna has magnets in the bottom and sits above the compass sensor. Arghhhh!
Tuesday, December 18, 2007
Saturday, December 08, 2007
Christmas Copter/Fun
One of my issues with working on the helicopter has been getting time to actually test. I can only really work weekends and evenings. If the weather is bad on the weekend, that means no testing for the whole week. I just discovered that people fly RC helicopters at night. (the previous link is not me)
I bought a pair of lit blades and some glow wire to give it a try. I'm not the worlds best RC pilot, I can hover nose in, nose out and fly around a little, but not a whole lot more. So I was worried about flying the big trex with 3K worth of electronics on it and crashing it. So I went to the hobby store today and bought some night blades for my little Trex. $45.00 worth of blades seems like a good price to see if I can fly at night. I wired up the glow wire and went out and tried flying it. I flew off three full battery packs in drive way at night, the test was both a success and a bit of fun. So now I have the confidence to be comfortable flying the big trex in an open field at night!
My wifes comment "oh thats pretty it matches our Christmas lights, a Christmas copter!"
I bought a pair of lit blades and some glow wire to give it a try. I'm not the worlds best RC pilot, I can hover nose in, nose out and fly around a little, but not a whole lot more. So I was worried about flying the big trex with 3K worth of electronics on it and crashing it. So I went to the hobby store today and bought some night blades for my little Trex. $45.00 worth of blades seems like a good price to see if I can fly at night. I wired up the glow wire and went out and tried flying it. I flew off three full battery packs in drive way at night, the test was both a success and a bit of fun. So now I have the confidence to be comfortable flying the big trex in an open field at night!
My wifes comment "oh thats pretty it matches our Christmas lights, a Christmas copter!"
A glimpse at the software details....
I want to try and give a glimpse of the details involved with some thing as simple as a swapping the GPS. Ive been working with a GARMIN GPS-18 5Hz gps, it has a serial interface that spits out NMEA sentences. NMEA is a standard protocol. If all you want out of the GPS is position then the GPS units are almost interchangeable. They almost all support the NMEA sentence...GPGGA.
The simple way to process the NEMA sentence is to load the whole thing into a character buffer and parse it. The Netburner library has a nicely written serial driver that makes talking to the serial port pretty painless. Open the port and read characters from it. The serial driver is intrrupt driven, so if you get busy and don't read characters, nothing is lost. To fit this reading and parsing into the main control loop is as simple as adding code to check to see if GPS chars are available and then jumping to a routine to read and process the chars.
You duplicate this three times, GPS, IMU and Telemetry commands.
I thought I'd try to unclutter the main task loop and be a little more efficient. I'm the original author of the Netburner serial driver, so modifying things at the driver level was not too scary. I modified the serial driver to parse the GPGGA sentance one charactor at a time in a state machine and then post to a semaphore to tell the main task that new GPS data is ready. This is a nice routine because it spreads the GPS parsing out in time and has the minimum possible delay.When the sentence checksum is validated the data is ready, all of the floating point data fields have already been parsed out. So the main task only gets notified when data is actually ready. After the GPGGA I expanded the system to capture the proprietary garmin PGRMV sentence that gives me north, east and vertical velocity. Again its all clean and works well. The state machine now knows how to parse two sentences and ignore the others.
This data is processed by the main data processing task. In addition to using it internally it also sends telemetry frames off on the maxstream radio to be displayed and recorded on the ground.
The display program receives a data structure and logs, plots and displays things based on the received data frame type. (The processing for the IMU data is almost identical)
Now I want to upgrade the GPS to the Crescent Vector. The obvious software differences are:
Humm I really want to know vertical velocity... digging in the crescent vector manual I discover that they have a binary message that has vertical velocity, in fact the single binary message has ALL the GPS data I have been capturing in a single message. The Crescent also has heading capability, alas it only outputs heading in a NMEA sentance, not a binary one. so my parsing state machine needs to process a mixed stream of Binary and NMEA messages.
The Binary message is nice in that it starts with $BIN so the beginning looks like a NMEA message, and the simple approach would be to just branch on this NMEA message ,
Its not that simple. My state machine resets its state to 0 whenever it sees a '$' beginning of message,but with the GPS sending binary data there is no guarentee that the binary data won't contain a '$' this breaks my state machine, so now the state machine knows if it is parsing a NMEA or binary data set and reacts accordingly. Also note that in a serial stream of chactors 1234.5678 there is no ambiguity on how to interpit the data. In a binary stream its a little bit more complicated. The GPS sends binary data as a IEEE754 double. standard format, but the GPS sends data in littel endian or intel format and the Coldfire processor I'm using uses big endian or Motorola format.(See Endian). SO I have to convert formats before I use the data. This is still a big win, because the endian conversion is much more efficient than parsing ASCII. Note that I'm already doing the endian conversion on the PC display software so this was not unexpected.
Once I'm parsing the GPS message the system stops responding reliably to telemetry commands....argghhhh! The problem is that If I keep the telemetry link busy sending data from the helicopter to the ground there is no time for the ground station to send data back. Up to this point the telemetry data stream was not too big for the down link pipe, switching from 5 to 10hz GPS pushes me over the edge. So now I write and debug a telemetry throttling routine that tries to keep the telemetry link idle for 50% of the time by throwing away data based on its age and priority.
All seems to be working except none of my telemetry frames have a spot for the GPS heading information, I'd like to keep both the GPS and IMU heading data, so I add a new GPS heading frame type to both the helicopter and the display software. Both areas are pretty modular so this is an easy fix. I label the new data with the same data type tag as the IMU heading data.... .
without remembering that the IMU heading is not floating point but a 0->65536 binary heading.(I worte the IMU parser and display code framework for my air lander over a year a go and have not really modifed it) Hence the GPS heading display is all messed up on the PC so I spend some time debugging the helicopter code to try and figure out why my parser is not properly parsing the GPS heading, only to eventually discover its a problem on the PC side.
This is now almost complete. At some future date I will add HOP and VDOP and signal to noise reporting. I'm now ready to take the whole helicopter outside and see how it works as an assembly. (I've been testing with two external GPS antennas on the roof. The GPS informs me that the antennas are 49.6 cm apart and that my roof has a heading of 172.3 degrees)
I really enjoy reading technical blog posts that give you a sense of the problems and struggles involved with building hardware. In an Ideal world I'd like to cover all of the project in this much detail. The reality of time and the need to sleep conspire against this. I've never been a skilled word smith so writing this saga took 25% as much time as struggling through the code. I don't have the patience to document everything to this level, but I'm going to try and do more posts at this level of detail.
The simple way to process the NEMA sentence is to load the whole thing into a character buffer and parse it. The Netburner library has a nicely written serial driver that makes talking to the serial port pretty painless. Open the port and read characters from it. The serial driver is intrrupt driven, so if you get busy and don't read characters, nothing is lost. To fit this reading and parsing into the main control loop is as simple as adding code to check to see if GPS chars are available and then jumping to a routine to read and process the chars.
You duplicate this three times, GPS, IMU and Telemetry commands.
I thought I'd try to unclutter the main task loop and be a little more efficient. I'm the original author of the Netburner serial driver, so modifying things at the driver level was not too scary. I modified the serial driver to parse the GPGGA sentance one charactor at a time in a state machine and then post to a semaphore to tell the main task that new GPS data is ready. This is a nice routine because it spreads the GPS parsing out in time and has the minimum possible delay.When the sentence checksum is validated the data is ready, all of the floating point data fields have already been parsed out. So the main task only gets notified when data is actually ready. After the GPGGA I expanded the system to capture the proprietary garmin PGRMV sentence that gives me north, east and vertical velocity. Again its all clean and works well. The state machine now knows how to parse two sentences and ignore the others.
This data is processed by the main data processing task. In addition to using it internally it also sends telemetry frames off on the maxstream radio to be displayed and recorded on the ground.
The display program receives a data structure and logs, plots and displays things based on the received data frame type. (The processing for the IMU data is almost identical)
Now I want to upgrade the GPS to the Crescent Vector. The obvious software differences are:
- It provides Heading information
- It updates at 10Hz
- It does not support the garmin PGRMV sentance.
- None of its NMEA sentances have vertical velocity.
Humm I really want to know vertical velocity... digging in the crescent vector manual I discover that they have a binary message that has vertical velocity, in fact the single binary message has ALL the GPS data I have been capturing in a single message. The Crescent also has heading capability, alas it only outputs heading in a NMEA sentance, not a binary one. so my parsing state machine needs to process a mixed stream of Binary and NMEA messages.
The Binary message is nice in that it starts with $BIN so the beginning looks like a NMEA message, and the simple approach would be to just branch on this NMEA message ,
Its not that simple. My state machine resets its state to 0 whenever it sees a '$' beginning of message,but with the GPS sending binary data there is no guarentee that the binary data won't contain a '$' this breaks my state machine, so now the state machine knows if it is parsing a NMEA or binary data set and reacts accordingly. Also note that in a serial stream of chactors 1234.5678 there is no ambiguity on how to interpit the data. In a binary stream its a little bit more complicated. The GPS sends binary data as a IEEE754 double. standard format, but the GPS sends data in littel endian or intel format and the Coldfire processor I'm using uses big endian or Motorola format.(See Endian). SO I have to convert formats before I use the data. This is still a big win, because the endian conversion is much more efficient than parsing ASCII. Note that I'm already doing the endian conversion on the PC display software so this was not unexpected.
Once I'm parsing the GPS message the system stops responding reliably to telemetry commands....argghhhh! The problem is that If I keep the telemetry link busy sending data from the helicopter to the ground there is no time for the ground station to send data back. Up to this point the telemetry data stream was not too big for the down link pipe, switching from 5 to 10hz GPS pushes me over the edge. So now I write and debug a telemetry throttling routine that tries to keep the telemetry link idle for 50% of the time by throwing away data based on its age and priority.
All seems to be working except none of my telemetry frames have a spot for the GPS heading information, I'd like to keep both the GPS and IMU heading data, so I add a new GPS heading frame type to both the helicopter and the display software. Both areas are pretty modular so this is an easy fix. I label the new data with the same data type tag as the IMU heading data.... .
without remembering that the IMU heading is not floating point but a 0->65536 binary heading.(I worte the IMU parser and display code framework for my air lander over a year a go and have not really modifed it) Hence the GPS heading display is all messed up on the PC so I spend some time debugging the helicopter code to try and figure out why my parser is not properly parsing the GPS heading, only to eventually discover its a problem on the PC side.
This is now almost complete. At some future date I will add HOP and VDOP and signal to noise reporting. I'm now ready to take the whole helicopter outside and see how it works as an assembly. (I've been testing with two external GPS antennas on the roof. The GPS informs me that the antennas are 49.6 cm apart and that my roof has a heading of 172.3 degrees)
I really enjoy reading technical blog posts that give you a sense of the problems and struggles involved with building hardware. In an Ideal world I'd like to cover all of the project in this much detail. The reality of time and the need to sleep conspire against this. I've never been a skilled word smith so writing this saga took 25% as much time as struggling through the code. I don't have the patience to document everything to this level, but I'm going to try and do more posts at this level of detail.
Friday, December 07, 2007
Gingerbread cookies and GPS
I've been experimenting with a Crescent Vector GPS from Hemisphere GPS. It uses two antennas 1/2 meter apart to gove heading as well as GPS position at 10Hz. The only problem is that the helicopter test bed (and the rocket) is an electrically noisy place. So I built an adapter module that has an isolated DC-DC converter, a logic isolator and RS-232 level converters on a small PCB. I then needed to mount the whole thing in some kind of shielded enclosure. I've been reading the "Jack Crossfire blog" about the trials and tribulations of making a autonomous UAV helicopter. He used an altoids tin to shield his GPS, I'm using a gingerbread cookie tin. (Altoids was too small for the vector).
The back side....
With the top on....
And finally a picture of the carbon fiber frame that mounts to the helicopter and holds the two GPS antennas.
I should be ready to fly this contraption tonight, but Southern California are in the midst of a big rain storm and thats not conducive to flying the helicopter.
The back side....
With the top on....
And finally a picture of the carbon fiber frame that mounts to the helicopter and holds the two GPS antennas.
I should be ready to fly this contraption tonight, but Southern California are in the midst of a big rain storm and thats not conducive to flying the helicopter.
Sunday, December 02, 2007
Helicopter testing an a new notional vehicle.
I reviewd the telemetry from the last helicopter flight and I think I have finally resolved all my issues with telemetry and hardware. No glitches in either control or data , my telemetry logger logged correctly to SD media so I will never again loose telemetry data from a failure to save, or a dead laptop battery. I got no GPS data, but it's probably because I did not give ehough time for the GPS to lock prior to flight and it did not acquire in the high vib helicopter environement. I'm planning to swith GPS receivers before the next flight in any case.
A new notional vehicle. And a plan forward.
The big question with insufficient data is:
Are our rocket motors really robust for multiple firings and throttling?
We have fired multiple times for long runs within an hour, we have throttled, but we have also had failures. We need to run the motor through several simulated missions. That is follow the LLC flight throttle profile and restart in less than 1/2 hour. Until we have done that several times we do not know if we have a workable design or not.
If our motors work then we will probably continue with a 4 motor vehicle. If they do not we will probably develop a single larger motor. The notional design for the vehicle branches on that question.
Assuming we have a working motor the the current notional design is as shown above. The key is that the weight is supported by a simple pad under the tank and the landing gear only keeps the vehicle from tipping over.
If the motors don't work then we are probably going to build a single engine vehicle with spherical tanks. There are really only two configurations that seem to make sens, the Quad and the Pixel design. Pixel has balance feed problems, but is structurally more efficient. The one drawback I see to the armadillo module design is the mass of the landing gear and the fact that the motor is very close to the ground. I've ordered some hemispheres from AMS industries and they should be here some time in January.
A new notional vehicle. And a plan forward.
The big question with insufficient data is:
Are our rocket motors really robust for multiple firings and throttling?
We have fired multiple times for long runs within an hour, we have throttled, but we have also had failures. We need to run the motor through several simulated missions. That is follow the LLC flight throttle profile and restart in less than 1/2 hour. Until we have done that several times we do not know if we have a workable design or not.
If our motors work then we will probably continue with a 4 motor vehicle. If they do not we will probably develop a single larger motor. The notional design for the vehicle branches on that question.
Assuming we have a working motor the the current notional design is as shown above. The key is that the weight is supported by a simple pad under the tank and the landing gear only keeps the vehicle from tipping over.
If the motors don't work then we are probably going to build a single engine vehicle with spherical tanks. There are really only two configurations that seem to make sens, the Quad and the Pixel design. Pixel has balance feed problems, but is structurally more efficient. The one drawback I see to the armadillo module design is the mass of the landing gear and the fact that the motor is very close to the ground. I've ordered some hemispheres from AMS industries and they should be here some time in January.
Tuesday, November 27, 2007
Tank and Helicopter Testing.
Today at lunch I flew the helicopter again and I seem to have solved all the electronics glitches. I changed from a 72Mhz RC Rx to one of the new 2.4Ghz units and it was much smoother. I'll analyze the recorded telemetry in the next day or so and post the results.
This afternoon my son started hydro testing all of the vehicle tanks. We had planed to test the entire vehicle with plumbing and everything, but with recent tank failures on the test stand and our sample heat treated tank we decided to individually test the vehicle tanks. The tanks were designed to be hydroed to 500PSI. However for the 90 second vehicle we did not ned to go so high. We backed off to 450PSI and still did not fair well. We tested all 8 tanks and got the following results: Failures at 350, 385,415 and 435. Four tanks passed all the way to 455. Since thanks are welded together in pairs we have one good pair, that will go on the test stand. The rest of the vehicle tanks are probably scrap. All four tanks failed in exactly the same way, at the interface between the endcap and the tubular tank. The weld stayed attached to the end cap and the weld pulled away from or failed at the tubular part of the tank. The tubular part is 6063 and the end cap 6061 so this failure mode sort of makes sense.
This result really complicates the decision process. What do we have from last years effort? We have 1/4 of a vehicle tank. We have some structure. We don't have valves, plumbing electronics we can use. We think (confidence 80%) that we have motors that will work. Do we scrap the design for a simpler solution or do we fix what we know is broken? There is a strong desire to start over from scratch. If I were to start again I think I'd build a 3/4 scale pixel. However this would mean scrapping the one part we think we have working the motor. Arghhhh decisions and only 11 months to be ready.
This afternoon my son started hydro testing all of the vehicle tanks. We had planed to test the entire vehicle with plumbing and everything, but with recent tank failures on the test stand and our sample heat treated tank we decided to individually test the vehicle tanks. The tanks were designed to be hydroed to 500PSI. However for the 90 second vehicle we did not ned to go so high. We backed off to 450PSI and still did not fair well. We tested all 8 tanks and got the following results: Failures at 350, 385,415 and 435. Four tanks passed all the way to 455. Since thanks are welded together in pairs we have one good pair, that will go on the test stand. The rest of the vehicle tanks are probably scrap. All four tanks failed in exactly the same way, at the interface between the endcap and the tubular tank. The weld stayed attached to the end cap and the weld pulled away from or failed at the tubular part of the tank. The tubular part is 6063 and the end cap 6061 so this failure mode sort of makes sense.
This result really complicates the decision process. What do we have from last years effort? We have 1/4 of a vehicle tank. We have some structure. We don't have valves, plumbing electronics we can use. We think (confidence 80%) that we have motors that will work. Do we scrap the design for a simpler solution or do we fix what we know is broken? There is a strong desire to start over from scratch. If I were to start again I think I'd build a 3/4 scale pixel. However this would mean scrapping the one part we think we have working the motor. Arghhhh decisions and only 11 months to be ready.
Sunday, November 18, 2007
Back in the swing
Starting to get back into it. I made some sugar rocket parts for Kevin of FAR on the Lathe. This generated a bunch of aluminum chips that swiftly made their way into the house. Since I'm trying to reduce the amount of $$ spent on the
"Calm angry wife with aluminum chip in her foot by purchasing flowers"
budget line item.
I've decided that the lathe needs to move away from the exit door. I can do this by swapping the lathe and a work bench. So next week I need to move some power wiring and add another layer of waterproof sheet rock and or stainless steel sheeting behind the lathes new home. I'm also going to install a troll at the exit door whose job is to throw you to the ground and remove all the metal chips. If you know anyone marketing such a creature please let me know.
On a slightly less serious note I flew the helicopter a number of times on Saturday and all the electronics seem to be working.I've got GPS, IMU, Ultrasonic altitude sensor, compass, RC receiver,telemetry transceiver and netburner cpu all running on an electric Trex 600. I finally solved the GPS problem by moving it to the end of the tail boom. It is all functional, with the current setup the RC receiver is hooked to the CPU and the servos are all driven by the CPU. Right now the CPU just echoes the RC receiver commands and the vehicle is flown manually, but it proves out all the hardware. These tests included the ground telemetry box and RF to Ethernet translator I was showing at the xprize cup. There were a bunch of guys at FAR for a solid motor class and one of them captured me flying the helicopter.
"Calm angry wife with aluminum chip in her foot by purchasing flowers"
budget line item.
I've decided that the lathe needs to move away from the exit door. I can do this by swapping the lathe and a work bench. So next week I need to move some power wiring and add another layer of waterproof sheet rock and or stainless steel sheeting behind the lathes new home. I'm also going to install a troll at the exit door whose job is to throw you to the ground and remove all the metal chips. If you know anyone marketing such a creature please let me know.
On a slightly less serious note I flew the helicopter a number of times on Saturday and all the electronics seem to be working.I've got GPS, IMU, Ultrasonic altitude sensor, compass, RC receiver,telemetry transceiver and netburner cpu all running on an electric Trex 600. I finally solved the GPS problem by moving it to the end of the tail boom. It is all functional, with the current setup the RC receiver is hooked to the CPU and the servos are all driven by the CPU. Right now the CPU just echoes the RC receiver commands and the vehicle is flown manually, but it proves out all the hardware. These tests included the ground telemetry box and RF to Ethernet translator I was showing at the xprize cup. There were a bunch of guys at FAR for a solid motor class and one of them captured me flying the helicopter.
Monday, November 12, 2007
Tanks, good news bad news...
We originally hydroed one tank to failure. It failed at 495 PSI.
We made the end cap that failed thicker, and assumed we fixed the problem.
Today I asked my son to hydro the test stand to 500 PSI since we had not done so. The first tank in the test stand failed at 475. He then hydro tested the tank we had heat treated. It failed at 425. So to complete the set we tested the other tank on the test stand to failure it failed at 560PSI. All three failed in exactly the same spot in the weld between the end cap and tank end. Its clear that our quality control needs some work. On Tuesday we will hydro all 8 tanks on the actual vehicle and see how that goes. Its really hard to tell if the failure is in the heat effected zone on the margin next to the weld, or if the welds them selves are too thin.
We made the end cap that failed thicker, and assumed we fixed the problem.
Today I asked my son to hydro the test stand to 500 PSI since we had not done so. The first tank in the test stand failed at 475. He then hydro tested the tank we had heat treated. It failed at 425. So to complete the set we tested the other tank on the test stand to failure it failed at 560PSI. All three failed in exactly the same spot in the weld between the end cap and tank end. Its clear that our quality control needs some work. On Tuesday we will hydro all 8 tanks on the actual vehicle and see how that goes. Its really hard to tell if the failure is in the heat effected zone on the margin next to the weld, or if the welds them selves are too thin.
Support the troups.
Every year for the last 6 years I've supported http://www.lbeh.org/
Its an effort to buy plane tickets for enlisted men and women to allow them to fly home for the holidays. Its an all volunteer's effort last year they spent 96% of what was donated on the troops.
(2.5 % of the take went to PayPal fees.)
This is the one and only time of the year I'll post a request on the blog.
Its an effort to buy plane tickets for enlisted men and women to allow them to fly home for the holidays. Its an all volunteer's effort last year they spent 96% of what was donated on the troops.
(2.5 % of the take went to PayPal fees.)
This is the one and only time of the year I'll post a request on the blog.
Sunday, November 11, 2007
Valves, Valves,Valves and Valves...
We started this project last year looking for light weight actuators. We assumed that we could just use off the shelf ball valves.
When we sit down and evaluate the response time needed and the hysterisis of ball valves then we realize that in the small sizes we need ball valves are problematic. There is slop between the ball and the stem and rotationally the ball valve is not very linear. We have also had leak and wear problems with our ball valves. So given the actuator we like we are now trying to find a better valve to go under it. Today we manually tested the following valves with 200 PSI liquid nitrogen:
Large O2 rated solenoid. (Cryogenic solenoids are larger and heaver)
Failed stuck open.
Buttery fly valve we were using as a throttling vale as the only valve.
Failed Leaking, very very non-linear.
SwageLoc Plug valve with 4 different kinds of alternate o-rings including
$70.00 of Kalrez o-rings.
All rotating seals failed at Ln2 Temperatures.
Small Brass Ball Valve.
Froze Solid and Jammed.
Small SS Ball valve.
Worked, sealed and had signiifcantly more hysteresis at LN2 temps than at room temperature.
For my next bout of insanity Paul builds a valve....
This is my "Simple" custom valve idea. I build a small linear valve in a copper plumbing tee. Making cryogenic seals work is hard, so I cheat. I add some heat to the end of the thin wall stainless to keep the seal end warm. The force necessary to operate this valve is within the range of the small fast robot servos I've been using. the valve is operated by pulling the stainless rod in and out. The Cage pins are there to make the ball stay in place. I'm concerned that the flow will make the ball chatter. If the seals give me trouble I can go to an electroformed bellows.
From Servometer
This makes me wonder if I should try a stock off the shelf.... bellows valve
When we sit down and evaluate the response time needed and the hysterisis of ball valves then we realize that in the small sizes we need ball valves are problematic. There is slop between the ball and the stem and rotationally the ball valve is not very linear. We have also had leak and wear problems with our ball valves. So given the actuator we like we are now trying to find a better valve to go under it. Today we manually tested the following valves with 200 PSI liquid nitrogen:
Large O2 rated solenoid. (Cryogenic solenoids are larger and heaver)
Failed stuck open.
Buttery fly valve we were using as a throttling vale as the only valve.
Failed Leaking, very very non-linear.
SwageLoc Plug valve with 4 different kinds of alternate o-rings including
$70.00 of Kalrez o-rings.
All rotating seals failed at Ln2 Temperatures.
Small Brass Ball Valve.
Froze Solid and Jammed.
Small SS Ball valve.
Worked, sealed and had signiifcantly more hysteresis at LN2 temps than at room temperature.
For my next bout of insanity Paul builds a valve....
This is my "Simple" custom valve idea. I build a small linear valve in a copper plumbing tee. Making cryogenic seals work is hard, so I cheat. I add some heat to the end of the thin wall stainless to keep the seal end warm. The force necessary to operate this valve is within the range of the small fast robot servos I've been using. the valve is operated by pulling the stainless rod in and out. The Cage pins are there to make the ball stay in place. I'm concerned that the flow will make the ball chatter. If the seals give me trouble I can go to an electroformed bellows.
From Servometer
This makes me wonder if I should try a stock off the shelf.... bellows valve
Thursday, November 08, 2007
Wednesday, November 07, 2007
The most common misconception.
I've had at least 50 people tell me the following:
(Including more than one scientist with a hard science PHD)
Why not put your rocket engine on top so the vehicle will be naturally stable.
This is wrong. It jives with our natural experience of the world, but it is wrong.
A rocket has no natural preference for thrusting UP. The rocket will thrust in whatever direction you point it. This is unusual in out natural experience. It you hang something on a rope the rope has the natural tendency to dangle straight down and only apply force in the up direction. If you attach something to a balloon the balloon only pulls straight up.
So given that the rocket will thrust in whatever direction its pointed and has no natural tendency to point up the rocket can't add any stability.
So if the motor can't add stability is there anything you can do for gravity to add stability? If the gravity field was uniform it would operate on the center of mass appling no torque to the vehicle and thus no stability. On the surface of the earth this is basically the case. The gravity field varies with the square of the radius. In orbit this slight difference can be used to stabilize a spacecraft, but on the surface the effect is so slight as to be undetectable. (On a 2meter high object gravity is 0.999999969 as strong on the top as it is on the bottom)
Our intuition is not completely wrong with respect to where the rocket motor goes, if it's center of thrust is not pointing through the center of mass then the rocket engine will apply a torque and the vehicle will spin. The current unreasonable rocket design has four engines that must be balanced to keep the vehicle from spinning, so in this sense a single rocket motor pointing toward the center of mass would keep the rocket pointed in a constant direction, but that direction would not be preferentially up without some kind of external control.
(Including more than one scientist with a hard science PHD)
Why not put your rocket engine on top so the vehicle will be naturally stable.
This is wrong. It jives with our natural experience of the world, but it is wrong.
A rocket has no natural preference for thrusting UP. The rocket will thrust in whatever direction you point it. This is unusual in out natural experience. It you hang something on a rope the rope has the natural tendency to dangle straight down and only apply force in the up direction. If you attach something to a balloon the balloon only pulls straight up.
So given that the rocket will thrust in whatever direction its pointed and has no natural tendency to point up the rocket can't add any stability.
So if the motor can't add stability is there anything you can do for gravity to add stability? If the gravity field was uniform it would operate on the center of mass appling no torque to the vehicle and thus no stability. On the surface of the earth this is basically the case. The gravity field varies with the square of the radius. In orbit this slight difference can be used to stabilize a spacecraft, but on the surface the effect is so slight as to be undetectable. (On a 2meter high object gravity is 0.999999969 as strong on the top as it is on the bottom)
Our intuition is not completely wrong with respect to where the rocket motor goes, if it's center of thrust is not pointing through the center of mass then the rocket engine will apply a torque and the vehicle will spin. The current unreasonable rocket design has four engines that must be balanced to keep the vehicle from spinning, so in this sense a single rocket motor pointing toward the center of mass would keep the rocket pointed in a constant direction, but that direction would not be preferentially up without some kind of external control.
Monday, November 05, 2007
The Agony of the valves.
After spending a few days at XPC it's very clear that our system is too complex.
KISS Keep It Simple Stupid.
The temptation is very great to start over from scratch and redesign everything. If I were to start again I would design something that looks a lot like pixel or the Armadillo Quad, a Single engine. The counter to this is that the only thing we really need to finish our vehicle is fast robust reliable valves. Its always tempting to trade the devil you know for the invisible devil lying in the green grass on the other side of the fence. Everyone I've talked to in Alt space has had valve problems of one kind or another.
My core problem is that I need very fast (50 to 100msec) control of the engine thrust to maintain reliable attitude control. Our vehicle is relatively small so that it's overall rotational inertia is low, and the motors are on the very outside of the vehicle this combines to require fast/precise control of the motor thrust.
How fast?
We can do some freshman physics and figure that out.
Lets assume that the vehicle is 2m diameter sphere.
(This is a slightly pessimistic view of our inertia the vehicle will be more stable than this)
I=2 mr^2/5 =2m/5
We are hovering with 4 motors. The total required lift is mg
So the force for each motor is mg/4
The motors are thrusting on a 1 meter lever arm from the Cg.
Now assume we can very the thrust in 1% steps around nominal.
Assume we increase the thrust in one motor by 1% and decrease the opposite motor by 1%
torque=1 * 2%mg/4
angular acceleration alpha=torque /I =(1*0.02mg/4)/(2m/5)
alpha = 0.0125g (notice m drops out)
or assuming g=9.8m/sec
alpha = .1225 radians/sec ^2
If we want 1 degree control of the vehicle 1 degree = 0.01745 radians.
The rotation is just like linear acceleration angle = (alpha*t^2)/2
So for 1% motor change a 1 degree error occurs in t=.53 seconds.
We would like our control to be about 5x to 10x the speed hence we need a 50msec valve.
How do we get such fast control:
Monster actuators and normal ball valves.
Pros:
95% Off the shelf.
Cons:
Lots of hysteresis (3 to 5%), Seals wear out quickly.
Hysteresis really complicates the control system.
Voice coil driven piloted spool valves.
Pros:
Such things exist for Hydraulic systems.
Control response as fast as 15msec 0 to 100%
Hysteresis 0.1% Basically a perfect valve.
Cons:
No off the shelf valves will work for LOX
Heavy
Expensive.
Serious engineering effort to build such a valve in a Lox compatible way.
More complicated Odd combinations.
One can start doing things that add significant complexity:
Adding modulated water injection.
Modulating just the fuel supply while leaving the LOX on a slow actuator.
Using a pile of fast solenoid valves
One fast Solenoid valve as trim with Slow ball valve following.
Pros:
Potentially the lowest cost option.
Cons:
Violates KISS
Requires a lot of development testing.
I'm sure I'll post more on this in the coming days and weeks.
KISS Keep It Simple Stupid.
The temptation is very great to start over from scratch and redesign everything. If I were to start again I would design something that looks a lot like pixel or the Armadillo Quad, a Single engine. The counter to this is that the only thing we really need to finish our vehicle is fast robust reliable valves. Its always tempting to trade the devil you know for the invisible devil lying in the green grass on the other side of the fence. Everyone I've talked to in Alt space has had valve problems of one kind or another.
My core problem is that I need very fast (50 to 100msec) control of the engine thrust to maintain reliable attitude control. Our vehicle is relatively small so that it's overall rotational inertia is low, and the motors are on the very outside of the vehicle this combines to require fast/precise control of the motor thrust.
How fast?
We can do some freshman physics and figure that out.
Lets assume that the vehicle is 2m diameter sphere.
(This is a slightly pessimistic view of our inertia the vehicle will be more stable than this)
I=2 mr^2/5 =2m/5
We are hovering with 4 motors. The total required lift is mg
So the force for each motor is mg/4
The motors are thrusting on a 1 meter lever arm from the Cg.
Now assume we can very the thrust in 1% steps around nominal.
Assume we increase the thrust in one motor by 1% and decrease the opposite motor by 1%
torque=1 * 2%mg/4
angular acceleration alpha=torque /I =(1*0.02mg/4)/(2m/5)
alpha = 0.0125g (notice m drops out)
or assuming g=9.8m/sec
alpha = .1225 radians/sec ^2
If we want 1 degree control of the vehicle 1 degree = 0.01745 radians.
The rotation is just like linear acceleration angle = (alpha*t^2)/2
So for 1% motor change a 1 degree error occurs in t=.53 seconds.
We would like our control to be about 5x to 10x the speed hence we need a 50msec valve.
How do we get such fast control:
Monster actuators and normal ball valves.
Pros:
95% Off the shelf.
Cons:
Lots of hysteresis (3 to 5%), Seals wear out quickly.
Hysteresis really complicates the control system.
Voice coil driven piloted spool valves.
Pros:
Such things exist for Hydraulic systems.
Control response as fast as 15msec 0 to 100%
Hysteresis 0.1% Basically a perfect valve.
Cons:
No off the shelf valves will work for LOX
Heavy
Expensive.
Serious engineering effort to build such a valve in a Lox compatible way.
More complicated Odd combinations.
One can start doing things that add significant complexity:
Adding modulated water injection.
Modulating just the fuel supply while leaving the LOX on a slow actuator.
Using a pile of fast solenoid valves
One fast Solenoid valve as trim with Slow ball valve following.
Pros:
Potentially the lowest cost option.
Cons:
Violates KISS
Requires a lot of development testing.
I'm sure I'll post more on this in the coming days and weeks.
Wednesday, October 31, 2007
Unreasonable Plans
I enjoyed visiting with all the people that stopped by to visit at the Xprize cup.
It was really heartbreaking that Armadillo did not win anything. Watching this unfold shows how hard this problem really is and makes me realize how very far from being ready we really are. I've been trying to work up a plan of action for the next year and the rough outline looks something like this:
1)Start working on the command and control code on the Helicopter to get the telemetry and mission planning stuff out of the way. This can be done close to home without the major expedition aspects of going out to FAR. Id like to have this 100% resolved by Christmas.
2)Work on resolving my valve issues, this will probably be one of the following:
3)Resurrect the test stand even if it means making new tanks and resolving our engine igntion issues once and for all. Before we do any vehicle work I want to run a motor on the test stand with throttling and simulate a full LLC mission including the 30 minute turnaround. I want to do this over and over until we get it right. This may get as involved as developing a new injector and igniter design. I'd like to start this testing in January.
4)Once 1,2,3 are done rebuild the vehicle and start tethered testing. If all goes well I could see tethered testing as soon as Febuary 1 ~ 4 months from now. After watching Armadillo I know I want to make some architectural changes. The primary one will be for the vehicle to automatically test all its valve actuators and sensors with minimal human intervention.
When I get to the point of testing a full vehicle I need to find a different transportation method. I'd be inclinded to buy a used flatbed or Box truck, but I can't park that near me, so I'd need to find someplace in San Diego to park it without spending a fortune. Anyone with an empty lot in San Diego where I can park a 20' box truck off and on for a year?
It was really heartbreaking that Armadillo did not win anything. Watching this unfold shows how hard this problem really is and makes me realize how very far from being ready we really are. I've been trying to work up a plan of action for the next year and the rough outline looks something like this:
1)Start working on the command and control code on the Helicopter to get the telemetry and mission planning stuff out of the way. This can be done close to home without the major expedition aspects of going out to FAR. Id like to have this 100% resolved by Christmas.
2)Work on resolving my valve issues, this will probably be one of the following:
- Rework the tonegowa driven valves for less backlash and better electronics. (Open servo based?) This is my preference.
- Use higher pressure Butterfly valves as the sole valve. This is my sons preference.
- Design a custom valve using either rotary or poppet style valves. This is no-ones preference. (I'm thinking a bearing supported plug valve sort of like this)
3)Resurrect the test stand even if it means making new tanks and resolving our engine igntion issues once and for all. Before we do any vehicle work I want to run a motor on the test stand with throttling and simulate a full LLC mission including the 30 minute turnaround. I want to do this over and over until we get it right. This may get as involved as developing a new injector and igniter design. I'd like to start this testing in January.
4)Once 1,2,3 are done rebuild the vehicle and start tethered testing. If all goes well I could see tethered testing as soon as Febuary 1 ~ 4 months from now. After watching Armadillo I know I want to make some architectural changes. The primary one will be for the vehicle to automatically test all its valve actuators and sensors with minimal human intervention.
When I get to the point of testing a full vehicle I need to find a different transportation method. I'd be inclinded to buy a used flatbed or Box truck, but I can't park that near me, so I'd need to find someplace in San Diego to park it without spending a fortune. Anyone with an empty lot in San Diego where I can park a 20' box truck off and on for a year?
Tuesday, October 23, 2007
Good Luck to Armadillo
I will be leaving for Holloman some time Wednesday afternoon.
Before I go I want to wish armadillo the best of luck in their NG-LLC efforts.
I will be rooting for them!
They have worked very hard and have been a real class act.
Good luck to John and the rest of the Armadillo team!
Before I go I want to wish armadillo the best of luck in their NG-LLC efforts.
I will be rooting for them!
They have worked very hard and have been a real class act.
Good luck to John and the rest of the Armadillo team!
Long night we are ok...
The wind switched directions and it looks like the witch fire will not reach the coast. Our thoughts are with the 500,000 people that have been evacuated and don't know the status of their homes. It looks like 1200+ homes have been destroyed in the last 36 hours. There are still areas in San Deigo county where people are still losing homes. If the wind switches we could still be at risk, but
it looks 200% better than is did 24 hours ago.
it looks 200% better than is did 24 hours ago.
Monday, October 22, 2007
San Diego fires
We live in Solana Beach, the city has just said
"Everyone is being asked to plan, pack and evacuate ahead of
being required to do so. "
It looks like the witch creek fire is likely going to burn all the way to the coast. Where it crosses I5 and hits the coast is pretty much up in the air. It looks like its going to cross somewhere near our house +/- 5 miles. We live in a fairly dense residential neighborhood, if it gets to us this fire is going to be a truely note worthy disaster. I'm going home from work to join the rest of the family and get prepared to leave. It probably won't be to the coast for another 12-18 hours , but it looks like nothing is going to stop it. Wish us luck, we hope to see all of you this coming weekend at Holloman. I'll let everyone know how it turns out Tuesday.
Paul
"Everyone is being asked to plan, pack and evacuate ahead of
being required to do so. "
It looks like the witch creek fire is likely going to burn all the way to the coast. Where it crosses I5 and hits the coast is pretty much up in the air. It looks like its going to cross somewhere near our house +/- 5 miles. We live in a fairly dense residential neighborhood, if it gets to us this fire is going to be a truely note worthy disaster. I'm going home from work to join the rest of the family and get prepared to leave. It probably won't be to the coast for another 12-18 hours , but it looks like nothing is going to stop it. Wish us luck, we hope to see all of you this coming weekend at Holloman. I'll let everyone know how it turns out Tuesday.
Paul
Friday, October 19, 2007
Unreasonable Ideas
For awhile I've been contemplating making some personal or political posts on this blog. I don't really want to mix the messages that way. Today I started a new blog unreasonableideas with a sad personal note. I'll continue posting rocket stuff here, and I'll post personal stuff there.
Wednesday, October 10, 2007
We will be displaying at XPC.
I've been having an internal debate about coming to the Xprize cup as an exhibitor or strictly as an observer. Unlike the other teams that are are looking to raise capital and awareness, we are not yet trying to do that. So I was hesitant to spend the money necessary to transport stuff to the show. I've decided that it would serve my larger goals of showing that small teams and individuals can do significant things in "space development" so we will be there.
We will be bringing the complete vehicle minus some valves and plumbing.
We may also bring the test stand carcass, the test helicopter, and and a video display. If you are coming to the show stop by and say hi.
On a personal note I went to the Plaster Blaster event last Saturday and spent the day watching a huge array of people launch rockets of all shapes and sizes. It was my first trip to a high power rocket event. The Xwing (http://rocketdungeon.blogspot.com/2007/10/empire-struck-back-may-x-wing-rip.html)was very cool, but all in all I found the event somewhat depressing. There were several cool projects, but none of the projects seemed to be advancing the state of the art. In some ways it seemed like a conspicuous consumption event. To be fair I saw a lot of families there and that was a very cool aspect to the event. My wife chastised me for this attitude, and said who am I to be judging other peoples efforts. She is probably right.
Lastly I've not done ANY thing on the rocket in the last month, I needed the break. I've been trying to catch up at work, organize my office and play some video games... (online chess and replaying all the original starcraft scenarios.)
We will be bringing the complete vehicle minus some valves and plumbing.
We may also bring the test stand carcass, the test helicopter, and and a video display. If you are coming to the show stop by and say hi.
On a personal note I went to the Plaster Blaster event last Saturday and spent the day watching a huge array of people launch rockets of all shapes and sizes. It was my first trip to a high power rocket event. The Xwing (http://rocketdungeon.blogspot.com/2007/10/empire-struck-back-may-x-wing-rip.html)was very cool, but all in all I found the event somewhat depressing. There were several cool projects, but none of the projects seemed to be advancing the state of the art. In some ways it seemed like a conspicuous consumption event. To be fair I saw a lot of families there and that was a very cool aspect to the event. My wife chastised me for this attitude, and said who am I to be judging other peoples efforts. She is probably right.
Lastly I've not done ANY thing on the rocket in the last month, I needed the break. I've been trying to catch up at work, organize my office and play some video games... (online chess and replaying all the original starcraft scenarios.)
Wednesday, September 19, 2007
400 Days till XPC 2008
I will boldly predict that there will be NG-LLC prize money for 2008. We only have ~400 days until the 2008 XPC, 280 days till the FAA permit app must be accepted. What are our plans? In no particular order...
1)Simplify.
Make one valve work, not two,
Go to blow down pressurization (for at least the 90 sec vehicle.)
2)Add more diagnostic automation.
Add some more feedback to the open loop vales so we can automagically determine their health.We need both position and current feedback from each valve. I may convert the valves to www.openservo.org derived control electronics.
3)Build a more robust vehicle.
Most plumbing, stainless not aluminum.
sturdier landing gear.
4)Find a more benign transport system.
5)Try other fuels and gasses
IPA (cleaner) and E85 cheaper.
Do at least one burn with 100% Nitrogen pressurization.
With our long thin tanks it might not be as bad as it is for Carmacks Spherical tanks. I've been told that a shot of He followed by N2 pressurization is not bad. the Russians use Nitrogen to pressurize their Lox tanks, and Nitrogen is a Lot Lot Lot cheaper than Hydrogen.
(Self presurized Lox might be similar....)
7)Put better data logging software in place.
( I write embedded S/W for a living and the shoemakers kids have no shoes.)
8)Convert the simulator to a hardware in loop tester.
9)Make the control system fly the helicopter, and publish ALL the results.
10)Try a impinging injector rather than a pintile.
11)Try Charles Pooleys Lox pre-burner idea.
12)Build and leave set up a good valve and injector flow test setup.
1)Simplify.
Make one valve work, not two,
Go to blow down pressurization (for at least the 90 sec vehicle.)
2)Add more diagnostic automation.
Add some more feedback to the open loop vales so we can automagically determine their health.We need both position and current feedback from each valve. I may convert the valves to www.openservo.org derived control electronics.
3)Build a more robust vehicle.
Most plumbing, stainless not aluminum.
sturdier landing gear.
4)Find a more benign transport system.
5)Try other fuels and gasses
IPA (cleaner) and E85 cheaper.
Do at least one burn with 100% Nitrogen pressurization.
With our long thin tanks it might not be as bad as it is for Carmacks Spherical tanks. I've been told that a shot of He followed by N2 pressurization is not bad. the Russians use Nitrogen to pressurize their Lox tanks, and Nitrogen is a Lot Lot Lot cheaper than Hydrogen.
(Self presurized Lox might be similar....)
7)Put better data logging software in place.
( I write embedded S/W for a living and the shoemakers kids have no shoes.)
8)Convert the simulator to a hardware in loop tester.
9)Make the control system fly the helicopter, and publish ALL the results.
10)Try a impinging injector rather than a pintile.
11)Try Charles Pooleys Lox pre-burner idea.
12)Build and leave set up a good valve and injector flow test setup.
Subscribe to:
Posts (Atom)