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:
  • 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.

15 comments:

kert said...

What about more expensive integrated versions of the same AD stuff, like ADIS16405 ?

Its same basic tech though, so probably as noisy.

Anonymous said...

Paul,

I think that building your own GPS receiver is going to be an enormous amount of work. Do you really want that distraction, instead of paying the annoying COCOM limit "tax"? That said, it would be close to your skills and you would almost certainly be able to sell it.

Ian

Paul Breed said...

Building the integrated GPS and IMU hardware is directly aligned with my primary skill set. I also think there is a market for a FPGA based GPS research receiver that is lower cost than the
$6500 NAMURU unit. Given the NetBurner infrastructure for building custom electronics the hardware side is actually pretty easy, and simpler than a lot of custom stuff we build now. The integrated front end chips are getting pretty nice. Until the end of the year I have more time than project $ so at some level its a fit.

Thad Beier said...

Would it be possible to build a receiver for the raw GPS radio signals and do the processing in non-real-time on the ground? For logging purposes this should be fine...you can even use differential GPS to get more accurate data. This really shouldn't tweak the Feds as they are concerned with real time guidance not logging

Anonymous said...

I'm doing the tightly integrated GPS + IMU thing now. Don't underestimate the amount of work involved. I'm going to try to make it open source if I can get permission... would be happy to talk shop about it sometime (weekend pref)

Henry

hhallam@jobyenergy.com

Anonymous said...

Paul, In that case I very much agree with you. I'd give it a shot. Keep me posted!

Ian

Anonymous said...

Fascinating blog, as always.

Thanks!

Sophont said...

Would a modification of Gerald K. O'Niel's ground based Geostar system be practical?

Anonymous said...

Hi Paul,

Have you thought about getting a cheap featurephone with GPS in it? My HTC ATT Flip which I think costs about $65 with an ATT plan has GPS in it. You could probably get an unlocked GSM or 3G phone for maybe $200. You could cannabilize the phone or just use it as is. It would also likely have WiFi in it too, which might be useful. I think they engineer the featurephone/smartphone GPS for pretty extreme acceleration since people tend to drop them.

jak

Paul Breed said...

The acceleration problem is not in the hardware, its in the GPS software built into the chip.

A GPS works by continuously tracking the code and carrier phase and doing some geometry. The problem is that the code and carrier phase tracking does not expect to see 8 to 10G vertical accelerations. If your cell phone GPS or automotive GPS calculates a solution that says your accelerating straight up at 8 G, its a pretty good bet the solution is in error. So the software tracking loops for for terrestrial app GPS won't track these sort of changes. You can widen the loop bandwidth to cover all cases, but this increases the noise. For a high dynamic GPS you can actually reduce the tracking band width and improve the noise situation if you use IMU information to tell the GPS tracking loops where to go.

Most terrestrial GPS solutions have problems with more than 2G of acceleration. So they set the loop bandwidth to track 2G changes. So if you have even a very course IMU where you can narrow the acceleration uncertainty to say +/- one half G your loop can be 4x tighter and more noise immune.

The trick is connecting all the various pieces together in a way that works, converges and is stable. This is called deep GPS IMU integration. One reason it is done in non-rocket apps is to make up for drop outs in GPS such as urban canyons, and tunnels etc...

I'm hoping that doing this purely to enhance the high G tracking will be a little simpler, where the GPS is still primary and all the IMU does is steer the center of GPS tracking loops. I'm even willing to make comprimises where the custom GPS gets its ephemeris, time, visible satellite and initial position info from another GPS greatly reducing the initialization search complexity.
At least 33% of the pages in all the GPS texts I have acquired are dedicated to inital signal acquisition. I'm hoping to reduce that to a single search looking for for the receiver clock offset. The oscillator I've chosen is a $35.00 TCXO wiht 50 parts per billion over a reasonable temp range. Thus reducing even that search to something really easy.

Paul Breed said...

Every Day I encounter Engineers with very little embedded computer experience trying to do things I see as really hard/nearly impossible. (I'd consider myself an embedded expert) There is a very good possibility that I'm exhibiting the same chutzpah in the land of GPS. Some time in the next week or so I'll draw up a block diagram of
what I have in mind and let the people that do this for a living make fun of it ;-)

Blue Lizard said...

Hi Paul,

Can you share how you interface with the ADIS16360? I am trying to build a IMU + vision system. But I got stuck at getting the IMU to work. Currently, I use a ftdi 2232H configure in SPI mode to connect with the IMU. I couldn't even correctly read the product ID register. All I got are zeros. However, if I send all zeros to IMU, I got a reading of 1 back which seems to be the content in the flash memory write count register. I suspect that this is a problem of the clock signal. The IMU data sheet specify it requires SPI mode 3 (CPOL=1, CPHA =1). However, there is no explicit commands for setting this mode in the ftdi chip. Right now I set the idle state of the clock to be high, and had tried clock out data on both rising and falling edge of the clock, but none is working.

Is there any work around of this problem?

Thanks
Sam

Paul Breed said...

I use the Freescale MCF5213 to read the part. My QSPI Settings are:

sim.qspi.qmr=0x8390;
sim.qspi.qdlyr=0;
sim.qspi.qwr=0x1000;

You will have to hunt down the MCF5213 data sheet to see what they mean.

dave w said...

I downloaded the file you linked and plotted it out on a spreadsheet chart - the data look pretty reasonable: the roll during ascent is visible as a rate in the gyro output, the acceleration looks like an HPR launch, parachute ejection and deployment was pretty chaotic (more so than touchdown), it was doing some swinging around under canopy, and everything flatlined cleanly at touchdowm.

I'm in the process of setting up a little guidance feedback test platform - plastic turntable from TAP plastics, model-jet ducted fan unit mounted on a pivot with a model airplane servo linked to swivel it back and forth... once I get the hardware assembled I'll try to code a feedback routine that tries to track the gyro and steer the thruster, so I can feed in rate or position command
signals.

I also tried a little RCS system - couple of solenoid valves, exit orifices, and an "air duster" can for pressure (the stuff is actually R-152, pressure at ambient temp. is about 70 psig...): the good news is that a 1/16" Clippard mini pneumatic fitting will screw right in where the plastic straw normally fits, with a little bit of CA glue for "pipe dope" - the fittings are $4 for a 10-pack from McMaster, so it's no heartbreak to throw them away with the empty cans.

The bad news is that the system only works well for a few shots at a time, and then the can chills down too much and there isn't enough pressure to develop usable thrust pulses... With some code in the Arduino to give a variable pulse rate to the valves based on a signal pulse from an RC receiver, I can spin the platform around with the control stick on the transmitter - for a few seconds, but if I keep pulsing it I soon have too little thrust to overcome static friction. (The workaround would be to turn the can upside down, draw from it in the liquid phase, and include several meters of copper tubing in the line from the can to the solenoid valves to act as a vaporizer coil.)

With the ducted fan the problem is going to be possibly too much control authority (rather than not enough) - I'm planning to keep the fan motor under manual control with the RC system, so I can make real-time adjustments... (Another channel from the RC feed a signal to the CPU so I can try "rate command" or "position command" algorithms.)

Jamie said...

Hi Dave,

Instead of the air duster can you should try CO2. I'm not sure what size you aiming for, but you can purchase 45g carts used for motor bike tire inflation kits. These normally come with a small regulator to release the CO2 at lower pressure. Check out Genuine Innovations website..Or if you have the room you can source some good high pressure N2 (3000psi) systems used for paintball markers?.