Question about sensor filtering

[Sparrowhawk]

Hi! I'm in the process of programming a flight computer that I developed from the ground-up, and I was curious if people had insight into the best ways to solve for rocket position and orientation. I've seen a lot of information on Kalman filtering, but as far as I can tell those algorithms function best under a constant-acceleration environment, which is obviously not the environment a high-power rocket experiences. The board has a 6DOF IMU (LSM6DSO32) and a barometric pressure sensor (DPS368XTSA1), and also includes the Adafruit Ultimate GPS breakout board.

I'm somewhat of a data junkie, so in addition to apogee detection I do want to try to solve for the approximate location and orientation of the rocket in 3D space to gain insight into the flight characteristics and better approximate the max altitude reached. I'd love some suggestions on what the best way forward would be!

 

[cls]

Hi, others will chime in about filtering. There's a lot in there...

For solving apogee, remember the barometric altitude is the true altitude, the accelerometer integrated distance is the true distance... Voila, two sides of a triangle. Pythagoras tells you the short side is the distance downrange.

Use the magnetometer at apogee vs at launch to tell you the azimuth downrange.

Could use GPS for azimuth. Do not use GPS for altitude, solutions have huge errors. The pilots will chime in here about WAAS and all that.

 

[cls]

Oh BTW, record the GPS position stream and look at it in Google Earth. Especially vs the baro + accell data. Fun fun fun!

 

[Sparrowhawk]

Could use GPS for azimuth. Do not use GPS for altitude, solutions have huge errors. The pilots will chime in here about WAAS and all that.

I've seen in other threads on the forum that GPS loses lock because of high Gs during ascent, and that the location updates from GPS aren't nearly fast enough to use as a sensor input. Is that the case, or could I really use it for azimuth?

EDIT on that second point, the GPS breakout I'm using claims to do 10 updates per second which is still not really fast enough but better than I was expecting

 

[waltr]

Do a search in this forum and read about various methods.

The GPS I use (Egfinders) never have the correct altitude and do seem to lose lock on the way up. I read that some are much better so you will need to Test to verify how good the one you have works at high velocity.

I and others have tried Magnetometer for orientation but the math becomes very ugly. Best down with a Quaternion fusion algorithm. Look up the Python AHRS library for doing the fusion (open source code) and documentation.
Also beware that most sensor fusion code uses the Accelerometer as the Earth reference (1G = direction down). This does not work in a rocket once it leaves the pad.

A Gyro is better to calculate orientation in a rocket.

Do have fun with this project.

 

[rocket_troy]

You're basically wanting to build an INS? That's no easy task. There are some off-the-shelf solutions such as the MTi-7 (I can verify it works well), but not dirt cheap. Lots of serious heavy math generally requiring quaternions for proper fusion support although there are libraries available for various processors for the INU part.

Also, just about every cheap GNSS module will state a max 4g limitation on acceleration, but this doesn't seem like a hard & fixed rule. Some appear to perform beyond that, although that might also depend on antenna quality, ground planing, impedance matching & positioning.

TP

 

[Sparrowhawk]

Also beware that most sensor fusion code uses the Accelerometer as the Earth reference (1G = direction down). This does not work in a rocket once it leaves the pad.

A Gyro is better to calculate orientation in a rocket.

Gyros will experience drift though right? As far as I'm aware a Kalman filter uses the accelerometer to correct for this using earth reference, so how is gyro drift corrected without that reference frame?

You're basically wanting to build an INS? That's no easy task. There are some off-the-shelf solutions such as the MTi-7 (I can verify it works well), but not dirt cheap. Lots of serious heavy math generally requiring quaternions for proper fusion support although there are libraries available for various processors for the INU part.

Also, just about every cheap GNSS module will state a max 4g limitation on acceleration, but this doesn't seem like a hard & fixed rule. Some appear to perform beyond that, although that might also depend on antenna quality, ground plaining, matching & positioning.

TP

yeahhh I guess I am... I assume my best shot is to start by establishing a reference frame on the ground, without relying on earth's gravity somehow. Not sure how.

 

[jderimig]

In addition to being a data junkie I hope you are also a vector matrix math junkie, or will enjoy learning.

3D inertial navigation can be tough but totally doable. You will have to implement the math to transform between 3 coordinate systems or reference frames. These are the sensor frame, the vehicle frame and the earth frame. Going from the sensor frame to the vehicle frame is rather trivial as its just a permutation operation.

After that your process will be:
1. Use your gyro integration to determine the transformation matrix or quaternion to get your accelerometer readings transformed to earth frame accelerations.
2. Integrate these transformed earth frame accelerations twice to get the 3D earth frame displacements.

In the Kalman sense the above are prediction estimates. Those happen at a high frequency or sampling rate. Occasionally at a lower frequency you correct those predictions with data provided by your baro and gps. You do not need continuous data from these low rate sensors to have a reasonable prediction-correction cycle.

For a rocket flight which is relatively short duration you do not need to worry about gyro drift. Other sources of error accumulations will be larger.

 

[Sparrowhawk]

In addition to being a data junkie I hope you are also a vector matrix math junkie, or will enjoy learning.

3D inertial navigation can be tough but totally doable. You will have to implement the math to transform between 3 coordinate systems or reference frames. These are the sensor frame, the vehicle frame and the earth frame. Going from the sensor frame to the vehicle frame is rather trivial as its just a permutation operation.

After that your process will be:
1. Use your gyro integration to determine the transformation matrix or quaternion to get your accelerometer readings transformed to earth frame accelerations.
2. Integrate these transformed earth frame accelerations twice to get the 3D earth frame displacements.

In the Kalman sense the above are prediction estimates. Those happen at a high frequency or sampling rate. Occasionally at a lower frequency you correct those predictions with data provided by your baro and gps. You do not need continuous data from these low rate sensors to have a reasonable prediction-correction cycle.

For a rocket flight which is relatively short duration you do not need to worry about gyro drift. Other sources of error accumulations will be larger.

Oh boy I guess I'll have to do some reading on linear algebra, I don't take it until next semester . Thankfully the small amount of matrix math I have done was for a Desmos 3D engine, so I'm a little bit familiar with transformation matrices and quaternions. A little bit...

So would I use accelerometer readings on the pad to determine the initial orientation relative to the earth, and then after launch do as you said with integrating the gyro readings to transform the rocket's frame relative to the earth, subsequently integrating the accelerations?

How fast should my sensor poll rate be in order to avoid integration errors due to a low sampling rate? The code I have working currently can poll at roughly 500hz, probably a bit more if I reduce the amount of data written into storage (which I'll have to do anyway to not fill up the onboard flash chip within the first minute ). However, that code is just polling sensors and writing to storage, I haven't implemented any code yet for detecting flight events.

 

[jderimig]

Oh boy I guess I'll have to do some reading on linear algebra, I don't take it until next semester . Thankfully the small amount of matrix math I have done was for a Desmos 3D engine, so I'm a little bit familiar with transformation matrices and quaternions. A little bit...

So would I use accelerometer readings on the pad to determine the initial orientation relative to the earth, and then after launch do as you said with integrating the gyro readings to transform the rocket's frame relative to the earth, subsequently integrating the accelerations?

How fast should my sensor poll rate be in order to avoid integration errors due to a low sampling rate? The code I have working currently can poll at roughly 500hz, probably a bit more if I reduce the amount of data written into storage (which I'll have to do anyway to not fill up the onboard flash chip within the first minute ). However, that code is just polling sensors and writing to storage, I haven't implemented any code yet for detecting flight events.

Getting an initial orientation on the pad from the accelerometers is harder than you think. Co sine of 3 degrees is 0.9986 so you need accuracy with less than 0.14% to resolve a 3 degree tilt (rough calc). Its best just to aim your rocket straight up and assume vertical at t=0.

100 hz sampling rate is good enough. Your bottleneck when you are doing 3D rotations and integrations is going to be your floating point calculations. There will be a bunch at each sample. If you're polling that has alot of overhead. If your sensors have FIFO's you want use those and do burst reads of the data, or use a really fast processor.

What processor are you planning on using?

 

[Sparrowhawk]

Getting an initial orientation on the pad from the accelerometers is harder than you think. Co sine of 3 degrees is 0.9986 so you need accuracy with less than 0.14% to resolve a 3 degree tilt (rough calc). Its best just to aim your rocket straight up and assume vertical at t=0.

100 hz sampling rate is good enough. Your bottleneck when you are doing 3D rotations and integrations is going to be your floating point calculations. There will be a bunch at each sample. If you're polling that has alot of overhead. If your sensors have FIFO's you want use those and do burst reads of the data, or use a really fast processor.

What processor are you planning on using?

It's not quite "planning", the board is on the table next to me . But anyway it's an Atmega1284P on a 16MHz clock. The sensors do have FIFO, although I wasn't really sure what it is or how it is used.

In terms of floating point calcs, it seems to me that using quaternions instead of rotation matrices significantly reduces the number of them needed, right?

In terms of accuracy, I get 16 bits out at a resolution of 70mDPS/LSB at the highest gyro measurement (+/-2000DPS), and 0.976mG/LSB at the highest accel measurement (+/-32G). However, I am considering dropping the measurement range to increase accuracy on the pad and switching when the boost starts

 

[cls]

I've seen in other threads on the forum that GPS loses lock because of high Gs during ascent, and that the location updates from GPS aren't nearly fast enough to use as a sensor input. Is that the case, or could I really use it for azimuth?

EDIT on that second point, the GPS breakout I'm using claims to do 10 updates per second which is still not really fast enough but better than I was expecting

What I meant was, the GPS vertical solution is under determined, has large error bars. The x y solution, latitude and longitude, is quite well determined, so is reliable.

The FAA went to some effort to get better vertical solutions from GPS. I don't understand it, hopefully someone will chime in with info.

 

[jderimig]

It's not quite "planning", the board is on the table next to me . But anyway it's an Atmega1284P on a 16MHz clock. The sensors do have FIFO, although I wasn't really sure what it is or how it is used.

In terms of floating point calcs, it seems to me that using quaternions instead of rotation matrices significantly reduces the number of them needed, right?

In terms of accuracy, I get 16 bits out at a resolution of 70mDPS/LSB at the highest gyro measurement (+/-2000DPS), and 0.976mG/LSB at the highest accel measurement (+/-32G)

I hate to be a downer but I don't think that processor will be up to the task. Also do not confuse resolution with accuracy and repeatibility. The zero offset drifts on mems sensors.

 

[Sparrowhawk]

I hate to be a downer but I don't think that processor will be up to the task. Also do not confuse resolution with accuracy and repeatibility. The zero offset drifts on mems sensors.

On that first part, I'm starting to come to that realization myself... I'm still going to try though! If nothing else, it's good programming practice and data for a revision 2.
And on the second part, that is a very good point

 

[jderimig]

What I meant was, the GPS vertical solution is under determined, has large error bars. The x y solution, latitude and longitude, is quite well determined, so is reliable.

The FAA went to some effort to get better vertical solutions from GPS. I don't understand it, hopefully someone will chime in with info.

Currently with the better GPS engines the vertical std.error is about 2x the horizontal. So the vertical is useable if you take this into account.

 

[jderimig]

On that first part, I'm starting to come to that realization myself... I'm still going to try though! If nothing else, it's good programming practice and data for a revision 2.
And on the second part, that is a very good point

It will still be a good platform to code and optimize your algorithms. Then you can port the code over to a different processor when you need to run faster.

 

[Sparrowhawk]

It will still be a good platform to code and optimize your algorithms. Then you can port the code over to a different processor when you need to run faster.

Yeah. I'll see what I can do with this board, but at least I got it funded by the aerospace club so it's mostly a time loss

 

[rocket_troy]

Currently with the better GPS engines the vertical std.error is about 2x the horizontal. So the vertical is useable if you take this into account.

Is that using L5?

TP

 

[jderimig]

Is that using L5?

TP

Multi-constellation consumer chipsets on L1 are good enough. I'll trust GPS over traditional baro implmentations based on SAM. But I wouldn't use it to trigger an apogee event though...

 

[jderimig]

Yeah. I'll see what I can do with this board, but at least I got it funded by the aerospace club so it's mostly a time loss

I recommend moving over to an ARM platform, its the future, not 8bit machines.

 

[cerving]

Hi, others will chime in about filtering. There's a lot in there...

For solving apogee, remember the barometric altitude is the true altitude, the accelerometer integrated distance is the true distance... Voila, two sides of a triangle. Pythagoras tells you the short side is the distance downrange.

Use the magnetometer at apogee vs at launch to tell you the azimuth downrange.

Could use GPS for azimuth. Do not use GPS for altitude, solutions have huge errors. The pilots will chime in here about WAAS and all that.

The integrated z-axis accelerometer distance is not necessarily in a straight line... in fact, there's a pretty good chance that it is not. In the Proton altimeter, we use the filtered baro altitude vs. the filtered accelerometer distance as a poor man's tilt indicator... if they're relatively close then you're probably pointing "up". For a true non-baro altitude determination, you need a full 6 DOF IMU, plus a high-G accelerometer in the z-axis, and a bunch of math. If you have a magnetomer and know which way you're pointing at t=0, you should be able to use that to locate your rocket on a map too, although GPS is a lot easier.

GPS apogee can work as long as you have enough time to recover the fix that you're going to lose when you hit the launch button, and you don't violate whatever COCOM rules are built into the GPS' firmware. I have found that flights of 10K+ generally produce reasonable GPS altitude readings after apogee... for shorter/lower flights, not so much.

 

[waltr]

Lots of good advice posted and agree.
1- processor will be good to sample and record sensor data but not for double precision math.
2- Gyro do drift but slowly and rocket flight is short so ok. Just need to obtain Gyro Offsets just before launch and apply to in-flight gyro measurements. This is what Quad copter controller's do.
3- 100Hz sampling would be fine. I do 50Hz in a logger and results are good.

I recommend using that processor and simply LOG all the data with sub-microsecond time stamps. Then post flight analysis and to work out the math.

 

[waltr]

GPS apogee can work as long as you have enough time to recover the fix that you're going to lose when you hit the launch button, and you don't violate whatever COCOM rules are built into the GPS' firmware. I have found that flights of 10K+ generally produce reasonable GPS altitude readings after apogee... for shorter/lower flights, not so much.

Ok, thanks for explaination Cris as my flights are well below 3k feet and GPS altitude is never correct with the eggfinders. Did figure is was COCOM restrictions causing this.

 

[jderimig]

GPS apogee can work as long as you have enough time to recover the fix that you're going to lose

My implied caveat with GPS apogee detection is you need to allow a larger "drop" threshold for triggering because when the chip changes it's constellation you can have large discontinuous moves in reported altitude. It is normal to see 30 meter shifts in altitude as gps acquires and updates its constellation. Nothing that a good algorithm can't account for but you need to be thoughtful about it. Baro sensors (if there is still air) and integrated acceleration are still mostly monotonic, gps is not always.

 

[Sparrowhawk]

I recommend using that processor and simply LOG all the data with sub-microsecond time stamps. Then post flight analysis and to work out the math.

Yeah, that's what I'm thinking might be the best option. I am still going to give the full code a shot to see if I can't get something to work, but we'll see! I was planning on doing a revision 2 of the board anyway at some point

 

[John Beans]

I would second the idea to just grab and store the integers from the sensors, then post-process.
Focus on low-power processing, form factor, and convenience of operation for flight days.
If you do that, you can have a smaller solution that doesn't take a lot of fuss while you're at the field.

 

[Sparrowhawk]

My one concern with that is I do want to have an orientation track for multi-stage rockets, where I really want to have an attitude lockout so S2 won't ignite if it's on its side.

 

[John Beans]

My one concern with that is I do want to have an orientation track for multi-stage rockets, where I really want to have an attitude lockout so S2 won't ignite if it's on its side.

Yes, but you can do this just by accumulating gyro integers. You don't need to calculate a quaternion with floating points, etc.

 

[Sparrowhawk]

Yes, but you can do this just by accumulating gyro integers. You don't need to calculate a quaternion with floating points, etc.

Okay. I think my mental image of gyro drift is far more severe than it actually is

 

[jderimig]

Yes, but you can do this just by accumulating gyro integers. You don't need to calculate a quaternion with floating points, etc

Interesting. How exactly would that work?

For example. You have a 20 degree clockwise rotation about x-axis. Rocket then rotates 180 degrees about z-axis. Then there is a continuing clockwise rotation about x-axis.

What is the gyro accumulating scheme to get the attitude of the z-axis ?