Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people. - George Bernard Shaw.
Monday, June 07, 2010
Parts Came in...
The sheet of paper the parts are laying on is 8.5x11"
My Welder Sent me this Picture . He still needs to weld the bottom manifold on,
When I ordered this version I did not order the bottom manifold because I had one. alas I was showing the previous version to people and either I left it at FAR, or someone walked off with it.
I've ordered another bottom manifold ring it will be two weeks or so.
Sunday, June 06, 2010
Some Data
I've now flown the simple instrumented HPR 5 times with data recording.
I've learned some things
Flight 1 at FAR Spark fun IMU, GPS and 6DOF Analog devices ADIS16360
GPS did not work at all, Spark fun was noisy, ADIS16360 worked reasonable well
Flight 2 At FAR, shorted battery cable, only goy Spark Fun IMU data.
Flight 3 at Plaster City (Yesterday) OpenPilot 10Hz GPS and ADIS16400 Analog deivces IMU.
GPS lost lock moments abter ignition (10 G or So) ADIS data all looks good.
On board recorder did not work, only have down link telemetry.
Flight 4 at Plaster City (Yesterday) OpenPilot GPS and ADIS16400 Analog deivces IMU.
GPS kept lock till parachute deployment (where the GPS is now pointing at ground).
Take off was only about 6-7G, while the GPS says it kept lock, the altitude data was wrong and did not follow the flight path, onboard data recording worked correctly. (A few minor drop outs, I think the data recording connector is intermittent)
Flight 5 At plaster City Same setup 10-12G launch, GPS lost lock, ADIS16400 data looks good.
Telemetry log only, on-board recorder did not work.
Things I've learned:
My goal is to develop a low cost system, buying a 5K GPS and 10K IMU are not part of the program. I'm really happy with the analog devices IMU, now to solve the GPS. I have one more
gps to try the new Novatel OemStar, I suspect that it may do better, but it is not available in a form that does not have the COCOM limits. I really do want to develop a vehicle in the next 12 months that will exceed 1K knots and 60K ft at the same time. There is an open GPS project based on the old Novatel SuperStar, alas the super star hardware is not available anymore and the base band chip set used on that receiver is not available. I can buy a Novatel receiver that is unlocked but it would be about 2K. As I've said several times this year, I currently have more rocket time than rocket $, I can continue to do interesting things with my leftover LLC hardware, but it does not match the far end goal. The far end goal is a 100Km 5Kg payload rocket that is reusable and can be reproduced for less than 10K.
In the past few years there have been a number of interesting papers, and even some 100% open projects on building software GPS receivers with just a simple front end. There are also a number of GPS front end chips and module assemblies that will directly feed such a receiver.
In looking at these projects its clear to me that a high dynamic GPS receiver with real time 10Hz updates is still beyond state of the art for realtime software only receivers. I want to do some experiments in this area, so I'm bread boarding a MAX2769 GPS front end chip a small FPGA and a high data rate SD card to record about 60 seconds of GPS front end data. So some time in the next month or so I hope to fly a payload that records GPS front end data and can be post processed with the open source software GPS receivers. If this works I might think about developing a 100% open Tightly integrated GPS/IMU using these peices, with the high rate code and carrier loops in an FPGA. Having the IMU data available at the code and carrier phase tracking level can really help the GPS keep lock. The short version is I'm crazy enough to contemplate building my own GPS receiver as I can't find one that meets both my cost and performance targets.
For anyone that cares the raw data file for flight #2 at plaster city is here: http://www.rasdoc.com/data/
The GPS data is at 10Hz and unmodified, the ADIS16400 is shown in the $AIMU lines.
The data is raw from the ADIS16400,(look at that data sheet) the order is Ratex, Ratey, Ratez, Acel X, Acel Y, Acel Z, Magx, Magy, Magz, extra. (I recorded one too many fields)
This flight was a lower acceleration flight on a rocket with big fins so it made a fairly sharp turn into the wind and the flight path was more parabola than straight up. The parachute deployment was also fairly late and abrupt. Looking at the Magnetic data it looks like the rocket rolled about 5 revolutions during the boost phase.
I've learned some things
Flight 1 at FAR Spark fun IMU, GPS and 6DOF Analog devices ADIS16360
GPS did not work at all, Spark fun was noisy, ADIS16360 worked reasonable well
Flight 2 At FAR, shorted battery cable, only goy Spark Fun IMU data.
Flight 3 at Plaster City (Yesterday) OpenPilot 10Hz GPS and ADIS16400 Analog deivces IMU.
GPS lost lock moments abter ignition (10 G or So) ADIS data all looks good.
On board recorder did not work, only have down link telemetry.
Flight 4 at Plaster City (Yesterday) OpenPilot GPS and ADIS16400 Analog deivces IMU.
GPS kept lock till parachute deployment (where the GPS is now pointing at ground).
Take off was only about 6-7G, while the GPS says it kept lock, the altitude data was wrong and did not follow the flight path, onboard data recording worked correctly. (A few minor drop outs, I think the data recording connector is intermittent)
Flight 5 At plaster City Same setup 10-12G launch, GPS lost lock, ADIS16400 data looks good.
Telemetry log only, on-board recorder did not work.
Things I've learned:
- The $125 Spark Fun 9DOF IMU does not like rocket vibration, and the accelerometer saturates on the rocket.
- The $500 ADIS16400 is really pretty good, the data is clean and seems to make sense.
- The low cost 10Hz GPS's are not happy with high acceleration. (To be expected)
- The Max stream 900Mhz Xbee seems to be reliable even with grossly sub optimal antennas.
My goal is to develop a low cost system, buying a 5K GPS and 10K IMU are not part of the program. I'm really happy with the analog devices IMU, now to solve the GPS. I have one more
gps to try the new Novatel OemStar, I suspect that it may do better, but it is not available in a form that does not have the COCOM limits. I really do want to develop a vehicle in the next 12 months that will exceed 1K knots and 60K ft at the same time. There is an open GPS project based on the old Novatel SuperStar, alas the super star hardware is not available anymore and the base band chip set used on that receiver is not available. I can buy a Novatel receiver that is unlocked but it would be about 2K. As I've said several times this year, I currently have more rocket time than rocket $, I can continue to do interesting things with my leftover LLC hardware, but it does not match the far end goal. The far end goal is a 100Km 5Kg payload rocket that is reusable and can be reproduced for less than 10K.
In the past few years there have been a number of interesting papers, and even some 100% open projects on building software GPS receivers with just a simple front end. There are also a number of GPS front end chips and module assemblies that will directly feed such a receiver.
In looking at these projects its clear to me that a high dynamic GPS receiver with real time 10Hz updates is still beyond state of the art for realtime software only receivers. I want to do some experiments in this area, so I'm bread boarding a MAX2769 GPS front end chip a small FPGA and a high data rate SD card to record about 60 seconds of GPS front end data. So some time in the next month or so I hope to fly a payload that records GPS front end data and can be post processed with the open source software GPS receivers. If this works I might think about developing a 100% open Tightly integrated GPS/IMU using these peices, with the high rate code and carrier loops in an FPGA. Having the IMU data available at the code and carrier phase tracking level can really help the GPS keep lock. The short version is I'm crazy enough to contemplate building my own GPS receiver as I can't find one that meets both my cost and performance targets.
For anyone that cares the raw data file for flight #2 at plaster city is here: http://www.rasdoc.com/data/
The GPS data is at 10Hz and unmodified, the ADIS16400 is shown in the $AIMU lines.
The data is raw from the ADIS16400,(look at that data sheet) the order is Ratex, Ratey, Ratez, Acel X, Acel Y, Acel Z, Magx, Magy, Magz, extra. (I recorded one too many fields)
This flight was a lower acceleration flight on a rocket with big fins so it made a fairly sharp turn into the wind and the flight path was more parabola than straight up. The parachute deployment was also fairly late and abrupt. Looking at the Magnetic data it looks like the rocket rolled about 5 revolutions during the boost phase.
Friday, June 04, 2010
Way to go Spacex!!!!!
From the video feed I saw that launch looked perfect.
Way to go spacex!!!!
Way to go spacex!!!!
Good luck to spacex.
I'm eagerly awaiting the spacex web-cast to watch the first F9 flight.
I sincerely hope they have a perfect flight.
It is a new rocket on a first flight so a perfect flight is unlikely.
If they have a problem it will most likely be something they could not test on the ground.
If I were to guess my biggest worries would be:
I sincerely hope they have a perfect flight.
It is a new rocket on a first flight so a perfect flight is unlikely.
If they have a problem it will most likely be something they could not test on the ground.
If I were to guess my biggest worries would be:
- First stage pogo oscillation, the Saturn V had significant issues with this.
- 2nd Stage ignition in vacuum, the first stage Merlin's have a fair bit of ground side support equipment, so the air start is a differnt beast. (The first hotfire scrub was do to an incorrect valve in GSE) A turbo pumped motor is a complex piece and getting the whole choior singing in tune on the first attempt in vacuum is tricky.
Tuesday, June 01, 2010
BP Oil spill and Space Robots
If you have been a long time reader of this blog you probably have a geeky desire to see all the technical details. I've been watching the BP spill response with morbid fascination.
BP looks like it is being very open with the technical aspects of its response.
just take a look at all the videos on this page, the scale and scope of the operation are mind numbing. If that link does not work as a permalink, just look for the June 1 Videos on the LMRP, or go back and watch all of Kent Wells presentations.
I've been watching the the technical videos, diagrams and briefings for at least the last two weeks. I think this whole thing could be used as a pretty detailed response to those space scientists that say don't send humans, send Robots. With the BP spill we have lots of very sophisticated ROV's ,they have reasonable access to the surface for repair, adjustment and tool change out, a round trip operating delay of ~10 micro seconds and yet the whole process looks painfully hard. Trying to do any serious resource extraction or heavy construction remotely without direct onsite human intervention is currently significantly beyond state of the art. We need Humans on site.
We need humans in space. Go F9-Dragon!
BP looks like it is being very open with the technical aspects of its response.
just take a look at all the videos on this page, the scale and scope of the operation are mind numbing. If that link does not work as a permalink, just look for the June 1 Videos on the LMRP, or go back and watch all of Kent Wells presentations.
I've been watching the the technical videos, diagrams and briefings for at least the last two weeks. I think this whole thing could be used as a pretty detailed response to those space scientists that say don't send humans, send Robots. With the BP spill we have lots of very sophisticated ROV's ,they have reasonable access to the surface for repair, adjustment and tool change out, a round trip operating delay of ~10 micro seconds and yet the whole process looks painfully hard. Trying to do any serious resource extraction or heavy construction remotely without direct onsite human intervention is currently significantly beyond state of the art. We need Humans on site.
We need humans in space. Go F9-Dragon!
Subscribe to:
Posts (Atom)