Questions about accelerometer-based alts

Onebadhawk
the model rocket show
SilicdyneTRF
The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Originally posted by UhClem
The RRC2 will fire after apogee and the MC2 will fire at some random
time around apogee.

I discussed the reasons for this in my two NAR R&D reports. In
the first one I document a case where an RRC2 fired about 2 seconds past
apogee. As I recall, the manufacturer considered this to be perfectly
acceptable. I didn't, which is why the two R&D reports. Available on my
web site.
Click to expand...

If your rocket can't take the drogue coming out 2 seconds after apogee, there's something wrong with your rocket. Heck - it should be able to take the main 2 seconds after apogee no problem too. Honestly, if an altimeter can reliably fire within 2 seconds of apogee, I'd be happy with it, as any rocket should easily take that.
 
Getting back to my original question, if I wanted to make an IMU, would a 3 axis accelerometer plus a three axis magnetic sensor be completely sufficient? I'm still not certain whether the magnetic sensors would work while one of its axes is parallel to the field. Perhaps if the were two 3 axis sensors oriented 45 degrees from each other on all axes... but that would be very expensive, not to mention seemingly impossible to get the orientation...
 
Originally posted by cjl
If your rocket can't take the drogue coming out 2 seconds after apogee, there's something wrong with your rocket. Heck - it should be able to take the main 2 seconds after apogee no problem too. Honestly, if an altimeter can reliably fire within 2 seconds of apogee, I'd be happy with it, as any rocket should easily take that.
Click to expand...

My rockets can and have survived non optimal deployments. Just because they can, doesn't mean that they should. Extra stress increases the chances of failure.

Its not like it requires fancy new hardware to get the job done. Just some software that utilizes the information available in an intelligent way.
 
2 seconds after apogee means it's traveling at 64 fps at most. Under drogue, most rockets fall at 50-70fps. It won't stress it at all to deploy at this speed (deploying the main chute puts more stress on a rocket than that).
 
Originally posted by mtwieg
Getting back to my original question, if I wanted to make an IMU, would a 3 axis accelerometer plus a three axis magnetic sensor be completely sufficient? I'm still not certain whether the magnetic sensors would work while one of its axes is parallel to the field. Perhaps if the were two 3 axis sensors oriented 45 degrees from each other on all axes... but that would be very expensive, not to mention seemingly impossible to get the orientation...
Click to expand...

There is some three axis magnetic flight data on my web site that you can play with. Look at the PAC-3 flight log in the level 3 section.
 
The data looks much like I would expect (I've actually been reading though most of your site, and it's very inspiring!). Did you condition the sensor outputs to compensate for offset, sensitivity variation, etc? Also, How did you amplify it, and what was the resolution of your AD converter?

It would be great if you could convert the data into direction. I imagine it would be relatively simple, and could be done with simple arctan functions (though I don't know how hard it would be to actually do that with whatever software tou have).
 
Originally posted by mtwieg
The data looks much like I would expect (I've actually been reading though most of your site, and it's very inspiring!). Did you condition the sensor outputs to compensate for offset, sensitivity variation, etc? Also, How did you amplify it, and what was the resolution of your AD converter?

It would be great if you could convert the data into direction. I imagine it would be relatively simple, and could be done with simple arctan functions (though I don't know how hard it would be to actually do that with whatever software tou have).
Click to expand...

As I say on the web page, I just connected a Honeywell HMC2003 to my RDAS.

I was going to convert the data into directional information but after I saw the high roll rate I knew that was the problem with this rocket. So I didn't have much motivation to plow through the heavy math. Although I have worked out the calibration equations and taken a stab at some code to do the job but it never worked.

As I said, the flight data is available on my web pages and anyone can play with it.
 
Three observations for your consideration.

First, there has been a lot of discussion here about frame of reference and how many g's are measured and when. I think it's pretty simple. If the rocket is speeding up, positive G's. If the rocket is slowing down, negative G's. Period.

Second, in a perfectly vertical flight, you get positive G's during the boost, negative G's at burnout, and -1 G as the rocket coasts to a stop at apogee. In most flights, however, the rocket arcs over such that at apogee, it is roughly horizontal. Since the rocket is moving at a fairly constant speed as it arcs over, the altimeter should be reading 0 G's, plus or minus.

Third, I have examined my G-wiz files from 30 flights. In every single case, the acceleration resolves to EXACTLY -1G near apogee. I have never understood this, since in most flights, the reading should go to zero, plus or minus, as the rocket arcs over. I believe that the programmers have set up the software such that the acceleration resolves to -1G even if the measured value is higher than -1G due to a non-vertical path. This would be a safety measure to ensure that an apogee is always calculated.
 
Originally posted by JimJarvis50
Three observations for your consideration.

First, there has been a lot of discussion here about frame of reference and how many g's are measured and when. I think it's pretty simple. If the rocket is speeding up, positive G's. If the rocket is slowing down, negative G's. Period.

Second, in a perfectly vertical flight, you get positive G's during the boost, negative G's at burnout, and -1 G as the rocket coasts to a stop at apogee. In most flights, however, the rocket arcs over such that at apogee, it is roughly horizontal. Since the rocket is moving at a fairly constant speed as it arcs over, the altimeter should be reading 0 G's, plus or minus.

Third, I have examined my G-wiz files from 30 flights. In every single case, the acceleration resolves to EXACTLY -1G near apogee. I have never understood this, since in most flights, the reading should go to zero, plus or minus, as the rocket arcs over. I believe that the programmers have set up the software such that the acceleration resolves to -1G even if the measured value is higher than -1G due to a non-vertical path. This would be a safety measure to ensure that an apogee is always calculated.
Click to expand...

This is because the accelerometer SENSOR is really reading 0g because it is in a ballistic trajectory (free fall). However 1g is subtracted from this because of the -1g zero calibration on the pad, hence you read -1g.
 
Originally posted by jderimig
This is because the accelerometer SENSOR is really reading 0g because it is in a ballistic trajectory (free fall). However 1g is subtracted from this because of the -1g zero calibration on the pad, hence you read -1g.
Click to expand...

I don't think I agree. When the G-wiz is bench tested, and it's horizontal, it reads zero G's. It should read that way in flight (if the velocity is roughly constant), but it doesn't. But let's see what others think.

Or maybe I should ask, why is 1G subtracted?
 
Originally posted by JimJarvis50
I don't think I agree. When the G-wiz is bench tested, and it's horizontal, it reads zero G's. It should read that way in flight (if the velocity is roughly constant), but it doesn't. But let's see what others think.

Or maybe I should ask, why is 1G subtracted?
Click to expand...

Hi Jim,

I don't know what the GWIZ bench test mode or how it calibrates in that mode.

The reason that 1g is subtracted because if it wasn't it would read 1g on the pad because of the force of gravity. Then while it is waiting to take off it would be busily integrating this 1g and think it was flying.

As mentioned in this thread, acceleration sensors do not measure motion directly, they measure force on a tiny mass in the device. The force on that mass is F=m(a+g) where a and g are vectors. You need to null out g to deduce a.

However you need to know the orientation of the accelerometer to correctly compensate for g. (if pointing up or down, subtract g, if pointing horizontal->subtract 0, any angle in between subtract gxcos(theta)).

Rocket accelerometers lacking the ability to do this just subtract g, the more vertical the flight, the more accurate the measurement.
 
Originally posted by jderimig
Hi Jim,

I don't know what the GWIZ bench test mode or how it calibrates in that mode.

The reason that 1g is subtracted because if it wasn't it would read 1g on the pad because of the force of gravity. Then while it is waiting to take off it would be busily integrating this 1g and think it was flying.

As mentioned in this thread, acceleration sensors do not measure motion directly, they measure force on a tiny mass in the device. The force on that mass is F=m(a+g) where a and g are vectors. You need to null out g to deduce a.

However you need to know the orientation of the accelerometer to correctly compensate for g. (if pointing up or down, subtract g, if pointing horizontal->subtract 0, any angle in between subtract gxcos(theta)).

Rocket accelerometers lacking the ability to do this just subtract g, the more vertical the flight, the more accurate the measurement.
Click to expand...

Well John, we reach an impass, which is why I guess that there are 70 posts on this tread.

The G-wiz and other altimeters detect a launch by some means (either the acceleration or some minimum altitude). Data before the launch is detected is ignored.

Once the rocket is in the air, the acceleration sensor detects changes in velocity with time (which is acceleration by definition). These changes in velocity are the result of the net force acting on the rocket, whether those forces are gravity, the motor or drag. Gravity doesn't need to be compensated for or subtracted or anything else - it's just one of the forces acting to change velocity.

Perhaps we can agree that the actual reading of the sensor at apogee might vary depending on whether the rocket was point up or at some angle. Why then do my 30 files, representing all kinds of flights, always resolve to -1G at apogee? I think it's because the programmers have forced it to that value.
 
Originally posted by JimJarvis50
Three observations for your consideration.

First, there has been a lot of discussion here about frame of reference and how many g's are measured and when. I think it's pretty simple. If the rocket is speeding up, positive G's. If the rocket is slowing down, negative G's. Period.
Click to expand...

An accelerometer in a freely falling body will always measure zero G's absent an external force. Because gravity works on every single electron, proton, and neutron, the accelerometer cannot measure it. Gravity accelerates every single part identically so the proof mass doesn't move with respect to the rest of the sensor. It has to move to generate a reading. (Neglecting servo accelerometers of course.) When the rocket is on the pad it is not freely falling and you measure 1G. During flight the accelerometer will measure the acceleration due to motor thrust and drag.


[/i]
Second, in a perfectly vertical flight, you get positive G's during the boost, negative G's at burnout, and -1 G as the rocket coasts to a stop at apogee. In most flights, however, the rocket arcs over such that at apogee, it is roughly horizontal. Since the rocket is moving at a fairly constant speed as it arcs over, the altimeter should be reading 0 G's, plus or minus.
Click to expand...

The rockets vertical velocity is not constant at apogee unless you have some aerodynamic lift. It is accelerating at -32.2 ft/sec. The accelerometer measures about zero G's (plus some drag) but adjusts this because it knows it is operating in a gravitational field.


[/i]
Third, I have examined my G-wiz files from 30 flights. In every single case, the acceleration resolves to EXACTLY -1G near apogee. I have never understood this, since in most flights, the reading should go to zero, plus or minus, as the rocket arcs over. I believe that the programmers have set up the software such that the acceleration resolves to -1G even if the measured value is higher than -1G due to a non-vertical path. This would be a safety measure to ensure that an apogee is always calculated.
Click to expand...

As previously explained, the altimeter subtracts 1G from every measurement prior to integration because it knows it is operating in a gravitational field.

The RDAS software has an option when graphing flight data to plot the prelaunch acceleration as either 1G or 0G. This only effects presentation of the data and not the performance of the altimeter during flight.

This really isn't that difficult although so many seem to be trying to make it hard. I understand it and have created working altimeter software which proves I understand but I despair of ever explaining it well enough that this sort of discussion never occurs.
 
Originally posted by JimJarvis50
I don't think I agree. When the G-wiz is bench tested, and it's horizontal, it reads zero G's. It should read that way in flight (if the velocity is roughly constant), but it doesn't. But let's see what others think.

Or maybe I should ask, why is 1G subtracted?
Click to expand...

If you're bench testing it and booting it up while horizontal, it will read zero gees. If you bench test it by booting it up while vertical, in the orientation that a rocket would be in on the pad, and then turn it horizontal, it will read -1. If it works like most accelerometer based alts I've looked at, it calibrates the start up value as zero, which if vertical, would make the horizontal reading -1.
 
Originally posted by smurf
Why not just have one charge with two ematches from separate altimeters?
Click to expand...

Because two is better than one? :)

why not?
 
Originally posted by cjl
If you're bench testing it and booting it up while horizontal, it will read zero gees. If you bench test it by booting it up while vertical, in the orientation that a rocket would be in on the pad, and then turn it horizontal, it will read -1. If it works like most accelerometer based alts I've looked at, it calibrates the start up value as zero, which if vertical, would make the horizontal reading -1.
Click to expand...

The G-wiz in particular is calibrated by holding it vertically. One you do this, it reads -1G when pointed up, 1G when pointed down, and 0G horizontal. It stays that way thereafter. That is, it doesn't care what position it is in when it is booted up. I don't know how other acceleration altimeters behave.
 
Well, I can only really see one reason why not. Remember the failure of The Beast on the discovery channel show (the one done by Wildman)? That was caused by his two charges going off at once (one set the other off), and about 50g of black powder forcing the main chute out the side of the tube (hence the tangling...)
 
Originally posted by JimJarvis50
The G-wiz in particular is calibrated by holding it vertically. One you do this, it reads -1G when pointed up, 1G when pointed down, and 0G horizontal. It stays that way thereafter. That is, it doesn't care what position it is in when it is booted up. I don't know how other acceleration altimeters behave.
Click to expand...
It measures +1G when pointed up, and -1G when pointed down.

I don't know how the Gwiz does it, but I would assume the best way to calibrate it would be to take the acceleration reading before liftoff and subtract that from the rest of the data. This would work better for launches at non vertical angles (I mean launched at an angle, not tipping during the flight). If your rocket is going to be launched at, say, 75 degrees, and you assume it will follow that angle straight, then you shouldn't offset it by -1G, but rather -0.966G, since that is the component of gravity that will be measured by the sensor.
 
Originally posted by UhClem
An accelerometer in a freely falling body will always measure zero G's absent an external force. Because gravity works on every single electron, proton, and neutron, the accelerometer cannot measure it. Gravity accelerates every single part identically so the proof mass doesn't move with respect to the rest of the sensor. It has to move to generate a reading. (Neglecting servo accelerometers of course.) When the rocket is on the pad it is not freely falling and you measure 1G. During flight the accelerometer will measure the acceleration due to motor thrust and drag.


OK, I now understand the "subtracting 1G" concept. Sorry for being so slow.


The rockets vertical velocity is not constant at apogee unless you have some aerodynamic lift. It is accelerating at -32.2 ft/sec. The accelerometer measures about zero G's (plus some drag) but adjusts this because it knows it is operating in a gravitational field.

Dave, would you agree that the sensor value at apogee for a vertical flight (-1G for the G-wiz) should be different than the sensor value for an arcing flight (something closer to zero G's)? Isn't it therefore odd that apogee value is exactly -1G for every single flight?

Just so it's clear, what I'm suggesting is that the G-wiz guys have programmed the altimeter so that it is less "late" on non-vertical flights. What do you think?

PS - I messed up the quotes here (this darn board times me out quickly). I hope it's clear.
Click to expand...
 
Originally posted by JimJarvis50
Originally posted by UhClem
An accelerometer in a freely falling body will always measure zero G's absent an external force. Because gravity works on every single electron, proton, and neutron, the accelerometer cannot measure it. Gravity accelerates every single part identically so the proof mass doesn't move with respect to the rest of the sensor. It has to move to generate a reading. (Neglecting servo accelerometers of course.) When the rocket is on the pad it is not freely falling and you measure 1G. During flight the accelerometer will measure the acceleration due to motor thrust and drag.


OK, I now understand the "subtracting 1G" concept. Sorry for being so slow.


The rockets vertical velocity is not constant at apogee unless you have some aerodynamic lift. It is accelerating at -32.2 ft/sec. The accelerometer measures about zero G's (plus some drag) but adjusts this because it knows it is operating in a gravitational field.

Dave, would you agree that the sensor value at apogee for a vertical flight (-1G for the G-wiz) should be different than the sensor value for an arcing flight (something closer to zero G's)? Isn't it therefore odd that apogee value is exactly -1G for every single flight?

Just so it's clear, what I'm suggesting is that the G-wiz guys have programmed the altimeter so that it is less "late" on non-vertical flights. What do you think?

PS - I messed up the quotes here (this darn board times me out quickly). I hope it's clear.
Click to expand...

The altimeter will feel the exact same thing at apogee regardless of rocket orientation. It will feel zero g (unless the rocket arced so far as to have a significant horizontal velocity, as well as the corresponding drag). Since it was calibrated to treat a 1g force as zero (the on-pad calibration value), it will treat 0g as -1. Whether it is horizontal or vertical, it will feel 0g at apogee, and therefore display as -1 (unless, like the R-DAS, you can set it to show that as 0g instead, in which case every single time at apogee, it will appear to be 0g, regardless of orientation).

Here is a question: If the altimeter is falling on a purely ballistic trajectory (let's ignore drag for an instant), could it tell what orientation it was in? Even a 3 axis accelerometer could not, as it would measure 0g in all directions. This also applies for an accelerometer in a rocket at apogee. Since it is not usually traveling very quickly, the drag component is negligible, and it is essentially in a ballistic trajectory. Because of this, it will ALWAYS measure 0g, regardless of orientation (which, as explained earlier, will result in a reading of -1g due to the calibration at startup).
Click to expand...
 
Originally posted by mtwieg
It measures +1G when pointed up, and -1G when pointed down.

I don't know how the Gwiz does it, but I would assume the best way to calibrate it would be to take the acceleration reading before liftoff and subtract that from the rest of the data. This would work better for launches at non vertical angles (I mean launched at an angle, not tipping during the flight). If your rocket is going to be launched at, say, 75 degrees, and you assume it will follow that angle straight, then you shouldn't offset it by -1G, but rather -0.966G, since that is the component of gravity that will be measured by the sensor.
Click to expand...

I have no idea how they handle that in the calculation. The calibration is just a calibration - you want the thing to read 1G when it's point up. I suppose they could account for some launch angle in the calculation because the reading would be slightly different as you point out, but I don't know if they do that or not.
 
Originally posted by JimJarvis50
I have no idea how they handle that in the calculation. The calibration is just a calibration - you want the thing to read 1G when it's point up. I suppose they could account for some launch angle in the calculation because the reading would be slightly different as you point out, but I don't know if they do that or not.
Click to expand...

Actually, the calibration sets the startup value, regardless of what it is, to zero. This is what you really want, as it takes gravity out of the equation and measures the actual acceleration. That way, when the sensor is measuring an apparent acceleration of zero gees, it will read it as the negative of the calibration value. This is because any time it would be measuring zero gees, it would be experiencing an acceleration due to gravity. The calibration perfectly sets this so that it is always going to work properly. Try it sometime - power it up in the bench testing mode while holding it in the vertical position it would be in on the pad in a rocket. Then, lay it horizontal. It should read 0g in the vertical position, and -1 in the horizontal. If you hold it at an angle during startup and calibration, this would be different. If you held it at 45 degrees during startup, it would measure -.7071g when horizontal, and +.2929g when vertical.
 
Originally posted by UhClem
This really isn't that difficult although so many seem to be trying to make it hard. I understand it and have created working altimeter software which proves I understand but I despair of ever explaining it well enough that this sort of discussion never occurs.
Click to expand...

Of everyone who's posted during this entire discussion, it sounds like Dave is the only one who's actually <i>programmed</i> a real, working altimeter. He's not guessing at what happens or how it <i>might</i> work.

Instead of being on his way to school, he's already passed the final exam.

I think I'll go with his explanation.


tms
 
Originally posted by 2muchstuff
Of everyone who's posted during this entire discussion, it sounds like Dave is the only one who's actually <i>programmed</i> a real, working altimeter. He's not guessing at what happens or how it <i>might</i> work.

Instead of being on his way to school, he's already passed the final exam.

I think I'll go with his explanation.


tms
Click to expand...

No, I have done one too and it actually works! Hasn't everyone?
:D

MARS Accelerometer
 
Originally posted by JimJarvis50

OK, I now understand the "subtracting 1G" concept. Sorry for being so slow.

Dave, would you agree that the sensor value at apogee for a vertical flight (-1G for the G-wiz) should be different than the sensor value for an arcing flight (something closer to zero G's)? Isn't it therefore odd that apogee value is exactly -1G for every single flight?
Click to expand...
Sigh.

No. I guess I failed to explain it well once again. The rockets orientation does not matter as the accelerometer cannot measure gravity.

Ever.

I have attached another graph. Compare this to the first one I posted in this thread and tell me which one was the more vertical flight and why.


Just so it's clear, what I'm suggesting is that the G-wiz guys have programmed the altimeter so that it is less "late" on non-vertical flights. What do you think?
Click to expand...

Not a chance. See above. Also. When I first started looking into how altimeters work it was because of a late deployment. As a result of just playing around with the data in a spreadsheet program I was able to determine that the vendor had slightly biased the software towards late deployments. It only took a small bias to make a difference. As a result of complaints from me and others the altimeter software was changed.

A 0.1G bias over 10 seconds accumulates 32.2 ft/sec of velocity error. It requires one second of coast time at apogee to accumulate that much velocity change. So that small error generates one second of error in apogee time per ten seconds of flight time.
 
Originally posted by UhClem
The RRC2 will fire after apogee and the MC2 will fire at some random
time around apogee.

I discussed the reasons for this in my two NAR R&D reports. In
the first one I document a case where an RRC2 fired about 2 seconds past
apogee. As I recall, the manufacturer considered this to be perfectly
acceptable. I didn't, which is why the two R&D reports. Available on my
web site.
Click to expand...

My L3 flight which had two different RRC2 models on board: the first fired 2 seconds late--2 heart stopping seconds late I might add. I didnt see it as too big an issue as the rocket should only be traveling 30MPH or so. Whether that we were at hartsel 8800 launch elevation, and flew to 9500 more had much to do with it, can't say for sure. I don't know that this was by design, but in some ways I would prefer this in at least one case--that of fair amt of weathercock with a wide parabolic trajectory, if I'm thinking about this clearly, gravity turning has prematurely increased the AOA so at the apex of the flight it might be scooting along at a pretty good clip. setting the threshold for a definite descent might get ejection at a lower speed even tho its now "falling". Or is this wishful thinking on behalf of my friend, Jim Amos.
John S
 
I know I've had at least one case where an RRC2X seemed to fire a bit early if anything. I don't have high quality vid (yet), but at the latest, they were dead on.

Here's the vid I have right now (this had 2 RRC2X 25K altimeters in it for deployment):
<object width="425" height="350"><param name="movie" value="https://www.youtube.com/v/WCbryV8zR9U"></param><param name="wmode" value="transparent"></param><embed src="https://www.youtube.com/v/WCbryV8zR9U" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>
 
Chris, Thats at least 1-2 sec early. Maybe Jim needs to get better sensors, but IIRC he precalibrates all. Still he didn't make the finalist list--the NAR proposal to use altimeters mentions MAWD, PICO and Adept iirc. I think Wilke is blowing smoke at the NCR forum as in 5 altimeters, 3 brands in agreement by a couple of percent. Might well depend on how fast he sucks the chamber.
JS
 
It's hard to say based on that video. I really can't wait to get Dave's DVD - the better quality should help see whether it was early or not (I can think of a couple ways to view the video, one way it appears to be dead at apogee, the other it looks early). Not that much of an issue - as I said, the drogue chute on a rocket will hardly cause massive deployment stresses, but it's still nice to have dead at apogee every time.
 
Yea I hear you, if its near enough a dead fall slowing vs pitch over tuff to tell. My recollection was that there was a definite launch angle in which case, I'd expect it to pitch .Plus some weaving via video on the way. Dead falls are rare. I still vote for a tad early,.
JS
 

Similar threads

jepawi
Determination of orientation
Replies
9
Views
807
Adrian A
Adrian A
diyaerospace
Converting angular rates from the body frame to the global frame.
Replies
1
Views
518
jderimig
jderimig
I
Tilt Angle Comparison from Flight Data
Replies
0
Views
614
ihbarddx
I
cerving
The Eggtimer EZ-DD Rocket/Altimeter, a Complete Dual-Deploy Package for $100
2 3
Replies
86
Views
4K
miket6000
miket6000
Sparrowhawk
Question about sensor filtering
2
Replies
52
Views
3K
Sparrowhawk
Sparrowhawk

Latest posts

Back
Top