Featherweight Blue Raven Development Thread: Inertial Navigation

[Adrian A]

Besides the Bluetooth and phone interface, the biggest upgrade goal from the Raven to the Blue Raven is the ability for the on-board sensors to keep track of the rocket's orientation and movement in 3 dimensions throughout at least the ascent, and ideally post-deployment as well. This capability enables a check for flight angle before igniting an airstart, can improve detection and response to of a flight anomaly like a loss of stability or an airframe failure, and just provides more insight into how the flight went when reviewing the data later. Inertial navigation can complement GPS location by extrapolating where the rocket is going if the fix is lost or if the rocket goes above the u-Blox 8 max reporting altitude of 50 km.

Inertial navigation depends on gyroscopes that sense the rocket's rotational rates in all 3 axes, and a bunch of math to convert those measurements into a mathematical representation of the rocket's orientation. This is how spacecraft work. The first spacecraft I worked on, the Mars Surveryor '98 mission lander and orbiter, used these bad boys, the Honeywell MIMU:


With people for scale



It weighs over 4 kG, requires 25 Watts of 28V power and cost several million dollars, but it does one thing really well, and that's measure the angular rate really accurately. That's something you need if you are trying to point your antenna back at earth from Mars, or point your trajectory correction maneuver burn just right so you'll skim through the upper atmosphere instead of burning up. Their key specification is that when they keep track of the attitude, noise and other errors will cause only 0.005 degrees of "random walk" error over the course of 1 hour. Honeywell still makes them. O.k., so that's one end of the scale. Most spacecraft these days, especially smaller and less expensive ones, rely more heavily on star tracker cameras to keep track of their attitude, and use worse-performing gyros that can go for shorter amounts of time before significant errors build up. Gyros like these from Sensonor:


This one weighs 55 grams and has 0.15 degrees/sqrt(hour) of random walk. It still costs several thousand dollars. Compared to the MIMU it's 80x lighter, 800x less expensive, uses 16x less power, but at 0.15 degrees/sqrt(hr) its performance is 30x worse.

The accel/gyro chip used in the Blue Raven costs about 1000x less than the Sensonor unit above, its weight is about 1000x less, it uses about 1000x less power, but its noise performance is no slouch at 0.3 degrees/sqrt(hr) of angular random walk, which is only 2x worse than what's used on cost-sensitive spacecraft. But the noise is just one of several factors. Another factor is the bias stability. If you hold the gyro still (on the pad for example) and measure the rates which should be zero, that's the rate bias. You can subtract that bias off of future measurements, but how valid is the assumption that what you're subtracting off doesn't change over time? Let's measure that. Below is an overnight bias stability measurement I made with the rev 1 Blue Raven, which used a 9-axis inertial chip that has been used in several other rocket applications.



Last night I did the same test with the chip I'm using for the rev 2 of the Raven I assembled yesterday, and got this result:


The units are in degrees/second x 100, so at the end of the overnight run, the worst axis of the new Blue Raven had 0.1 deg/sec different gyro bias than it started with. Overall, the new chip bias stability is about twice as good as the one I used in rev 1, so I'm pretty happy with that. Over the time scales used for rocket flight, the bias stability with time won't be an issue. Other factors will dominate the inertial navigation errors.

On Sunday I'm planning for a test flight that will have a Featherweight GPS tracker, Raven4 and the Blue Raven, and I'm hoping to collect enough data to be able to figure out how good the inertial navigation accuracy can be.

 

[waltr]

Adrian, Excellent post about IMUs and Gyros.
Thanks

 

[UhClem]

Allan variance is frequently used to quantify gyro stability and noise.

Example

 

[dvdsnyd]

How did the flight perform?
Inertial data is something I've been hoping for in either a stand-alone unit or built into an altimeter!
Looking forward to your progress! Thanks for documenting!
Dave

 

[G_T]

Very interested!

Gerald

 

[FredA]

What happens to the gyros when you hit them with 50G's acceleration?
I doubt they will yield valid data during boost and might not recover to anything accurate for a period of time afterwards.
Good experiment - hope I'm wrong - looking forward to your data after the flight.

 

[Adrian A]

How did the flight perform?
Inertial data is something I've been hoping for in either a stand-alone unit or built into an altimeter!
Looking forward to your progress! Thanks for documenting!
Dave

I haven't flown it yet; I've been struggling with my new flash recording. The way I'm doing the buffering and queueing is more flexible and capable than what I did on the Raven4, but it's taking much longer than expected to get it fully working.

 

[Adrian A]

What happens to the gyros when you hit them with 50G's acceleration?
I doubt they will yield valid data during boost and might not recover to anything accurate for a period of time afterwards.
Good experiment - hope I'm wrong - looking forward to your data after the flight.

Good question. Time will tell. The test rocket I'm borrowing for now isn't currently set up for high-G flights, but soon I'll be flying smaller rockets with higher Gs.

 

[G_T]

Not just 3 axis linear acceleration limits and affects (plus shock and vibe which may impose different limits), but max rotation rates about each axis (assuming 3 axis gyro). What would be the rate limits for the gyros? Rotation rate about the rocket's axis can get rather high. What is the sample rate you are figuring on? On the rocket's roll axis, the sample rate doesn't necessarily have to be super high as long as one doesn't run into the Nyquist limit, though high rate is useful for roll stabilization applications to reduce sample delay related correction undershoot/overshoot. For the other axes I'd expect a pretty decent sample rate would be desired.

Once upon a time I had to write tracking/guidance software overnight on a project during a trial. I had to throw in alpha-beta tracking of all the inputs with outlier rejection (dropping glitchy data samples produced by the rather stupid interface) which was then used as input to the actual tracking algorithm which I also wrote that night. And what I was actually tracking was located at a distance from the actual sensors (don't ask). Even had multiple sensors for accel and rates for each axis... when they were working! Fun times. Turned out what I wrote worked with half the error over time compared to what was then in use, over a timeframe of a number of hours, which is the longest we ran before getting another good GPS fix.

Good luck!

Gerald

 

[Adrian A]

I had a good test flight yesterday, with the Blue Raven flying along with a Raven and GPS tracker. I think I finally have the quaternion propagation and flight angle calculations correct.

With these gyro rates (in degrees/sec):

I got this quaternion:


and this flight angle (in degrees):


That final landed angle is 84 degrees, which is pretty close to what the accelerometers say at that time, which is 89 degrees from the X axis of the Blue Raven. I still need to take a look at what the initial rocket motion was on the rail to compensate for any mounting misalignments to see if that makes that comparison better or worse. Next up, full 6-DOF velocity and position propagation throughout the flight!

 

[RockeTiltometer]

Adrian - you should fly it with an RTOM3 to check accuracy of your tilt output ! Frank

 

[Adrian A]

I got a trial license for Matlab to test out algorithms on the raw flight data, and I'm pretty happy with the results so far:



Above is a plot of the vertical velocity as computed by the Blue Raven inertial navigation, compared with GPS telemetry and an estimate based on the axial accelerometer only, assuming an unchanging vertical orientation (which is what the Raven currently does). What I can't get over is that after the boost, coast, chute deployment with some pretty violent dynamics, descending with some pretty big swings and spins under the chute, and then the touchdown impact, the inertial navigation kept track of the attitude so well that that the propagated vertical velocity is almost perfectly zero after touchdown.


A few other observations: The GPS estimator got freaked out by the 20G boost and put out bad solutions for vertical velocity until partway through the coast. The accel-only estimate is not too bad until parachute deployment; it only diverges noticeably from the attitude-aware estimate during the last part of the boost, when the rocket wiggled by 16 degrees. At first I thought the wiggle might have been caused by the thrust going briefly off-center when the motor spit out the liner, which is clearly visible in the acceleration plot:



But then I realized that the tilt really started moving at about 0.2 seconds, well before the liner was spit out of the motor, so it's probably just a misalignment of the thrust with the center of gravity, causing torque throughout the burn.

At any rate, with part of the burn happening when the rocket was at up to 16 degrees tilt, that explains why the accel-only version of the vertical velocity is over-estimating the peak vertical velocity a little.

At the chute deployment, the accel-only estimate diverges completely with the inertial nav estimate, as expected, since the payload by had already done a 180 degree turn immediately following the deployment.

Next up is the horizontal velocity and comparing the 3D inertial nav flight path with the flight path from the GPS. (In case you can't tell, I'm pretty happy to have this as my full-time job now)

 

[Adrian A]

Looking at the horizontal velocity estimation, it didn't turn out as well as the vertical velocity:

There's a pronounced offset in the horizontal velocity estimate that occurs during the apogee parachute deployment. Apparently the impulse from the deployment charge isn't getting recorded correctly. This is at least partly due to the fact that for the high-G accelerometer recorded data, I filter it before recording to flash. The Blue Raven wasn't doing the full 3D velocity estimation on board at the time of the flight, so I'm post-processing the recorded data with Matlab to see what the algorithm would have done, and the filtering took away most of the impulse from the charge. Since the rocket is nearly horizontal when the charge went off, that would explain why the horizontal velocity was affected a lot more than the vertical velocity. Well, now I have confirmed that I want to use the unfiltered data for the on-board velocity estimation for all 3 axes. I'll need to do another flight to see how much that will help.

Focusing on the pre-deployment part of the flight, there are a few interesting things:


Again, the GPS puts out garbage initially until its estimators converge on the right solution about a second after the boost.

Defining some terms here, what I'm calling the tilt angle is the angle between the long axis of the rocket and vertical. This is the angle that is most important for making decisions about airstarts, because it's the direction the rocket will go once the airstart motor lights. The trajectory angle is based on the path of the rocket through the sky. The difference between the two will mostly be caused by winds. If there is a strong crosswind and the rocket is launched initially straight up, it will pitch over into the wind, and its tilt angle will be higher than the trajectory angle, because the rocket's airspeed will be in the upwind direction and the wind blowing it back will cancel out some of the horizontal velocity. Conversely, if you want maximum altitude despite a crosswind, you should angle the rod downwind somewhat so that after the rocket weathercocks coming out of the tower, the rocket tilt will be zero for the motor burn even while the rocket is moving sideways due to the cross wind. In that case, the tilt would be near zero and the trajectory angle would be high initially and then drop as the rocket speeds up. For the flight data above, the rocket weathercocked into the crosswind, so the tilt is higher than the trajectory angle initially. After the rocket slows down vertically, the trajectory angle higher becomes higher than the tilt angle because the crosswind is still blowing it sideways.

 

[Adrian A]

It's been a while since I posted an update, and I have flown quite a few more times since then. It looks like I got lucky with that July flight in how well the inertial navigation worked for vertical velocity. I think it helped that that flight had relatively little roll. More typical for me are flights like I had yesterday, where the tilt angle works well, but there was enough roll rate (>10 revs during ascent) to make the inertial propagation after apogee unreliable. Not too surprising if there's 4500 degrees of roll, a 2% scale factor error will mean the roll orientation at apogee is 90 degrees off. I have a calibration test fixture that may be up to the task of calibrating the gyro scale factor for at least relatively slow rotations, but we'll see

Here are some plots from yesterday:


If you look closely you can see the baro altitude estimate exceeding the GPS altitude. This is very rare, because usually it's warm enough outside for the air to be less dense than what is assumed in the standard atmosphere model. Yesterday I drove through some -5F valleys to get to the launch site, which was 5F when I got there. It warmed up some by the time I launched, and the interior of the av-bay measured about 26F during the flight from the electronics and the sun warming it up. As is typical, the GPS didn't keep up with the actual flight until close to apogee.

That's a little more obvious at this zoom level:

Here is the tilt from the gyros and the GPS flight path angle:



The GPS flight path angle is bogus until it got caught up to the flight dynamics a few seconds into the flight.

Here's from a screen capture from the video I took of the liftoff:

Based on the silver tower length of 6', the rocket was 27.5' off the ground. Zooming in on the altitude plot, that was 0.34 seconds into the flight:

At that point the tilt estimate was 16 degrees. From the screen grab it looks like the rocket was tilted about 17 degrees relative to the horizon, so that seems like it's within the margin of error. Also, the GPS flight path angle and the tilt both passed through 90 degrees within about 0.15 seconds of each other. This has been true for the other flights I have seen, so I'm pretty confident now in relying on the tilt for staging check, etc.

Here's the horizontal and vertical velocity:


It's a pretty good match with the GPS until it falls apart after apogee deployments.

The roll rate and roll angle are body-relative measurements, so I just do a simple integration of the roll rate to get the total roll angle, here about 8.3 full rotations before apogee.


Next I'll show some accel and gyro results, but I think I need a new post.

 

[Adrian A]

Here are the accel and gyro raw-ish data (the Y-axis scale on all the gyro rates in this post is too low by 10x. I fixed it in the next post but I'm too lazy to re-do all the graphs in this one)




The accel data is from the +/-32G accel except when the +/- 400 G accel says it's over 32G, in which case it is used. The gyro data is just raw degrees per second in the sensor axes. The Blue Raven prototype was aligned with +X up for this flight. I'll zoom in on some of the more interesting bits. First, ignition to apogee deployment charge:


The motor thrust and then the drag are clearly visible. We'll zoom in on the lateral accelerations in a minute

For the gyros, the roll rate is in blue, and is mostly dependent on the velocity.

There are a few interesting things when zooming in more on the gyro data:


The first part is when the rocket was bouncing in the tower on the way out. Then there's the big tilt shown in the last post before it mostly straightens out. But then when the rocket is going it fastest from about 1 second to 5 seconds, there is an extra high-frequency oscillation, mostly just shown on the Z axis:


I wonder if this is from fin flutter? It's only strong from 0.8 seconds to 5 seconds in the flight, when the rocket is going over 500 ft/sec.

Here is the accel data from the apogee deployment:


With small rockets and fairly aggressive charge sizing, that can result in some pretty huge accelerations, 125 Gs for the deployment charge and over 200 Gs when it came to the end of the shock cord 0.15 seconds later. I did have 3 reefs in the cord, which you can also see. Here's the gyro data from the same period:

 

[Adrian A]

(continued)


The gyro rates in the apogee deployment weren't very extreme at first, since the whole separation just occurs in a line. But then they max out the sensor range at 18.3 seconds, after the shock cord rebound. The sensor spec range is +/- 2000 deg/second, but they over-achieve a little bit.

The voltages and currents are recorded during the deployment firings also. Here is the zoom in on Apogee:




The firing pulse was 1 second long, and you can see the current going up. I'll need to fix that zero-offset on the current. The apogee continuity voltage goes back to a mid-range value after the firing, which is fairly common from deployment charge residue.

The main deployment is similar:


Here the 3rd channel, which was not connected, got some deployment charge residue on it that caused a bit of a reading during and after the main chute firing.

Ok, that was a lot of graphs and data! Not all of it fascinating, but any of it can be useful when something goes wrong.

 

[FredA]

Ok, that was a lot of graphs and data! Not all of it fascinating, but any of it can be useful when something goes wrong.

Awesome Dataset - and SO great to have should one need to dig into a flight in detail.
Kudos to the data collection & presentation.
Extra bonus Kudos for the flight-dynamics estimation work.

 

[AllDigital]

Adrian, this data is great. Keep it coming!

Your altitude comparisons between the baro, accelerometer, and GPS look very consistent with my DIY boards. I have been testing a new Ublox Max-M10 GPS (with helical antenna) and it has been doing a much better job at holding onto satellites on launch. In a low gee test last weekend (8 gees / 400 mph) the GPS started with 18 sats, lost 2 at launch, and then regained three at the top. With the improved GPS (and a slower flight) my GPS line is tracking closer to the baro, but still has some lag off the pad.

I am also running two accelerometers. The "big one" is a 200G and the more accurate one is a 32G. You can see in my data below from last weekend the 200G has a higher error rate on integration. The 32G is closer to the baro/GPS lines. In all of my flights the accelerometer integration always runs a little higher than the barometer, regardless of temperature (sampling accelerometer at 400hz and baro at 40hz).

BTW -- can you share the gyro you have been testing with? The overnight drift spec was fantastic.

-Mike

 

[Neutronium95]

@Adrian A What orientations will the Blue Raven work in? From your build threads, and previous Ravens, I know that having it vertical and flat on a bulkhead should both work, but I don't know if having it horizontal will work. I'm looking at doing a build where space will be at a premium, but I won't have quite enough space to lay it flat.

 

[Finicky]

Adrian, Awesome and amazing work !

With regard to gyro scaling factor calibration, you might get a laugh out of this. The photos show how I calibrate the roll axis gyro(s) on my NoseCams. (I currently don't calibrate pitch or yaw) The Nosecams already have a motor with a fairly nice rotary encoder inside of them, and I utilize this for the calibration process. I run a bit of calibration code while spinning the entire nose with a drill at various speeds. The code is trying to null out the drill rotation by spinning the nose shell. The code is using the roll axis gyro reading to determine the actual spin rate. So if the calibration constant is even slightly incorrect, then the nose rotational position will drift slightly over time. I've got a bluetooth connection to the nose so I can dynamically type in different calibration guesses until I get one that looks good. I can usually get a gyro gain correction value out to three significant figures.

Before I start the calibration process I use a really slow EWMA filter to get the gyro zero offset. I let that stabilize for about 10 seconds (sampling at 100Hz) before I start the actual calibration process.

For a while I thought about having different scaling factors depending on the rotational direction, but for the flights I was doing I found it wasn't worth the trouble.

 

[Adrian A]

Adrian, this data is great. Keep it coming!

Your altitude comparisons between the baro, accelerometer, and GPS look very consistent with my DIY boards. I have been testing a new Ublox Max-M10 GPS (with helical antenna) and it has been doing a much better job at holding onto satellites on launch. In a low gee test last weekend (8 gees / 400 mph) the GPS started with 18 sats, lost 2 at launch, and then regained three at the top. With the improved GPS (and a slower flight) my GPS line is tracking closer to the baro, but still has some lag off the pad.

I am also running two accelerometers. The "big one" is a 200G and the more accurate one is a 32G. You can see in my data below from last weekend the 200G has a higher error rate on integration. The 32G is closer to the baro/GPS lines. In all of my flights the accelerometer integration always runs a little higher than the barometer, regardless of temperature (sampling accelerometer at 400hz and baro at 40hz).

BTW -- can you share the gyro you have been testing with? The overnight drift spec was fantastic.

-Mike

Are you propagating the attitude with quaternions from the gyro, or are you using a vertical assumption?

The gyro is the same you're using, the LSM6DSO32.

@Adrian A What orientations will the Blue Raven work in? From your build threads, and previous Ravens, I know that having it vertical and flat on a bulkhead should both work, but I don't know if having it horizontal will work. I'm looking at doing a build where space will be at a premium, but I won't have quite enough space to lay it flat.

Any orientation at all should work. On the pad it measures the gravity direction, and then just after ignition it measures the initial motion direction and uses that for the rocket axis vector.

Adrian, Awesome and amazing work !

With regard to gyro scaling factor calibration, you might get a laugh out of this. The photos show how I calibrate the roll axis gyro(s) on my NoseCams. (I currently don't calibrate pitch or yaw) The Nosecams already have a motor with a fairly nice rotary encoder inside of them, and I utilize this for the calibration process. I run a bit of calibration code while spinning the entire nose with a drill at various speeds. The code is trying to null out the drill rotation by spinning the nose shell. The code is using the roll axis gyro reading to determine the actual spin rate. So if the calibration constant is even slightly incorrect, then the nose rotational position will drift slightly over time. I've got a bluetooth connection to the nose so I can dynamically type in different calibration guesses until I get one that looks good. I can usually get a gyro gain correction value out to three significant figures.

Before I start the calibration process I use a really slow EWMA filter to get the gyro zero offset. I let that stabilize for about 10 seconds (sampling at 100Hz) before I start the actual calibration process.

For a while I thought about having different scaling factors depending on the rotational direction, but for the flights I was doing I found it wasn't worth the trouble.

Interesting. If the nosecone motor is keeping the measured gyro rates at zero, do you use another method to calibrate the scale factor?

 

[Finicky]

Are you propagating the attitude with quaternions from the gyro, or are you using a vertical assumption?

The gyro is the same you're using, the LSM6DSO32.


Any orientation at all should work. On the pad it measures the gravity direction, and then just after ignition it measures the initial motion direction and uses that for the rocket axis vector.


Interesting. If the nosecone motor is keeping the measured gyro rates at zero, do you use another method to calibrate the scale factor?

In my design the gyros are in the nose shoulder and so they spin with they rest of the rocket (or in this case whatever speed the drill is spinning at). There were pros and cons to putting the gyros below or above the motor and I chose to put them below. So I still need to get the scaling factor.

 

[Adrian A]

In my design the gyros are in the nose shoulder and so they spin with they rest of the rocket (or in this case whatever speed the drill is spinning at). There were pros and cons to putting the gyros below or above the motor and I chose to put them below. So I still need to get the scaling factor.

Ah, that makes sense. Do you know how much different was your calibrated scale factor compared to the datasheet value?

 

[Finicky]

I have a few different systems built. They all use an ISM330DHCX for the primary and an ICM20649 for the secondary 6DOF sensors.

For the three different (primary) ISM330DHCX, I've currently got roll axis scaling factors of 1.00625, 1.005 and 1.002.

For the three different (secondary) ICM20649, I've currently got roll axis scaling factors of 1.00217, 0.9979 and 1.003.

Some of those sig figs are nonsense. When you are typing in numbers to get a "best" setting sometimes you go with something that feels lucky LOL.

I never actually looked at what the data sheets said. Not sure I would have trusted it anyway. For what it must cost the fab to make these chips, I think they are amazing.

I keep saying that it might be time to recheck the scaling factors to see if a season of flight wear-and-tear has changed anything, but I haven't noticed anything unusual in the flight data or the flight videos to indicate there is an issue.

 

[Neutronium95]

Any orientation at all should work. On the pad it measures the gravity direction, and then just after ignition it measures the initial motion direction and uses that for the rocket axis vector.

That's great to hear.

 

[Adrian A]

Some more flight data, from a redundant setup within a 29mm rocket. The goal here was to see how the inertial nav of two Blue Ravens compare on a very aggressive flight on a small rocket

This flew on an H410 Vmax. If the burn rate were as advertised it would have had about 120 Gs. As it was, the burn duration was 0.55 seconds, with a peak of 80 Gs. So pretty much all of the delta-V was measured with the less-accurate 400G range accelerometers. Still, I think they did pretty well.





I have a filtered baro velocity that's on-board now for use in detecting a failed apogee deployment. It matches well with the inertial data, up until about 34 seconds into the flight, then both inertial measurements diverge together for the rest of the flight. The gyro data shows what happened at that time:


Zooming in:


The X axis gyro hit the max range limit of -2293 deg/sec. The zoomed view is kind cool for showing how repeatable the gyro data is between the two units (solid and dashed).

Here's the acceleration data, first zoomed out:


The highest peak Gs was the shock of the main charge going off a few mm from the sn 7 Blue Raven. I dialed down my BP to 0.28 grams for this flight but it looks like I should go lower for this rocket. Second highest was the landing impact. Zooming in on the main deployment shock:


I was a little mystified at first by the double impulse. The negative direction is expected for the first pulse because the pressure is pushing the av-bay down while it's pushing the chute up. But the second pulse has a single data point at -250 when I would expect a positive direction when the slack gets taken out of the kevlar. I think this is another case of exceeding the int16 size I'm using to store the accelerations, and the single measurement of -250 is really +405.36 Gs. Which with this little rocket isn't as crazy as it sounds, since the front half of the rocket is only about 0.5 lbs, meaning the kevlar withstood a peak force of about 200 lbs.

Here's a closeup of the motor burn:


The little rough spots in the accel readings before the ignition are from the beeps, I believe. Zooming in on the first quarter second:



Based on the inertial nav vertical position, the rocket cleared the tower at 0.98 seconds after ignition, and you can see the lateral Gs clear up after that. I don't think the axial noise at 0.06 to 0.08 seconds is from tower impacts, since they spike up as well as down, but I guess it's possible.

Here's the tilt measured by the two Blue Ravens in the first part of the flight:



They both detected a 90 degree tilt (apogee) within 0.04 seconds of each other.
Zooming in:


At first I was surprised that the two units weren't more synchronized, though they are within 1-2 degrees of each other, but then I remembered that they were constrained in the av-bay a little differently. Serial number 7 was squeezed between the two bulkheads by some judicious tensioning of the threaded rods. SN4 had a looser fit because the av-bay closeout didn't really lock it into place. So I think these differences in tilt measurements during the 80G burn may have been real.

Bottom line, the gyros do just fine under heavy accelerations, shocks of hundreds of Gs, and rates that exceed their limits. Check out the gyro zero offset shift from prelaunch to landing after this violent flight, after I zoom in vertically across the whole flight:

(oops ran into the max attachment limit.) Instead of the graph, I'll just say that the gyro rates measured on the and the gyro rates on the ground after the flight were identical, exactly zero with a few points of 0.1 deg/sec noise and no measurable shift in offset. Basically the only contributor to navigation errors for rocket flights of this duration are gyro scale factor errors (the integrated roll for these two sensors was different by 0.9%) and if it goes past the 2200 deg/sec range of the gyro.

 

[Neutronium95]

This flew on an H410 Vmax. If the burn rate were as advertised it would have had about 120 Gs. As it was, the burn duration was 0.55 seconds, with a peak of 80 Gs. So pretty much all of the delta-V was measured with the less-accurate 400G range accelerometers. Still, I think they did pretty well.

I think that I might have missed this earlier, but will the Blue Raven actually be able to record accelerations up to 400G?

I've had a few designs on the drawing board that could possibly exceed 200G, and I was thinking that I'd need to make my own data logger to see the true acceleration. If the Blue Raven can do that, that would save me a ton of time and effort.

 

[Adrian A]

I think that I might have missed this earlier, but will the Blue Raven actually be able to record accelerations up to 400G?

I've had a few designs on the drawing board that could possibly exceed 200G, and I was thinking that I'd need to make my own data logger to see the true acceleration. If the Blue Raven can do that, that would save me a ton of time and effort.

Yes, it does. Currently the logging works fine up to +-327.68 Gs. To correctly log values beyond that I would need to use a different scale factor for storage.

 

[Neutronium95]

Yes, it does. Currently the logging works fine up to +-327.68 Gs. To correctly log values beyond that I would need to use a different scale factor for storage.

That's good to know. I'll need to revisit my sims to see if that will be high enough for the really stupid design I'm working on. Should be more than enough for anything else I want to fly.