Inertial Altimeter?

Has anyone given any thought to this idea? Assuming size and weight aren't a factor, what are the problems involved?

Reply to
Kurt Weber
Loading thread data ...

I don't think that you can exclude size and weight if you are using inertia. "X" amount of acceleration for "y" amount of time won't necessarily give you altitude due to factors such as wind, drift, weight of rocket, drag, etc.. A Barometric altimeter gives you readings independent of the physical characteristics of the rocket. Why re-invent the wheel?

Reply to
Edward Deerly

Some commercial altimeters, such as the G-wiz, operate by inertial rather than barometric means.

It can work but it's vulnerable to inaccuracy if the flight is not perfectly vertical.

-dave w

Reply to
David Weinshenker

If you measure inertia in all three axes, can't you detect and account for a non-vertical flight path?

Reply to
David

It's called an accelerometer. Many companies make them for hobby rocketry.

Reply to
Robert DeHate

David, It's hard to say if this would be valid. Thats alot of number crunching for a uController.

You would have to seperate tilt from spin. You might also have to mount the X/Y accelerometer on the rotation axis.

I have not got data from my triple axis accelerometer yet. Hopefully before the end of the year.

RDH8

Reply to
Robert DeHate

That is my intuition, but according to Dave Schultz (DARS), it requires a total of 5 accelerometers. I believe it was

3 together - x, y and z axes with z vertical - and 2 others aft measuring x' and y'. If the rocket rotates, say, about the x or y axis, you won't get any indication of that on the x, y or z accelerometers. But the y' or x' units will sense it.

HTH.

Doug

Reply to
Doug Sams

I believe that would require 6 axes not 3. I'm not aware of any hobby altimeter that is anything more than a one axis device.

Bob Kaplow NAR # 18L TRA # "Impeach the TRA BoD" >>> To reply, remove the TRABoD!

Reply to
Bob Kaplow

When I said "assuming size and weight are not a factor", I meant that the construction of the device would not be constrained by the size and weight of it or the rocket.

Reply to
Kurt Weber

Doug, Actually, you need 6 accelerometers if you want to try and measure the rockets rotation. Two each for roll, pitch, and yaw.

The reason you need a pair in each axis is that the accelerometer cannot distinguish between rotational and linear accelerations. By spacing a pair some distance apart you have a chance at measuring rotational acceleration. Linear acceleration will effect each accelerometer in the pair the same but rotational acceleration will effect wach differently because that are different distances from the center of rotation.

Ideally the center of rotation would be exactly between the two accelerometers but this is very hard to do in a typical hobby rocket. If you built a package that had all of the accelerometers built into it, it would have a couple of problems:

1) The distances between paired accelerometers would be very small and limit their ability to resolve rotation. 2) The electronics MUST know where the center of rotation is.

Even if you went to a three axis accelerometer/rate gyro system you would still need to know the relationship between the sensors and the center of rotation so that you could remove the effects of rotational acceleration from the acceleration measurements. This is not a general purpose solution.

I am not sure if accelerometers would be able to measure the rotational accelerations so lets look at some numbers.

Assumptions:

1) Looking at the roll axis. 2) Accelerometers have a +/- 2G range. 3) Accelerometers are each located 1" from center of rotation. 4) 12 bit ADC

The ADC is able to resolve about 1mG/count or 0.032ft/sec/sec per count. At a distance of 1" from the center of rotation this translates to:

0.032 ft/sec/sec * 12 in./1 ft. * 1 rev./ 6.28 in. * 360 degress/rev

or 22 degrees/sec/sec

Which means that there is a +/- 11 degree/sec/sec uncertainty in each measurement. Because we can combine the readings from two accelerometers the resolution improves by a factor of two but this still doesn't seem small enough.

Then there are other issues:

1) Is a 2G range large enough to avoid clipping the data? 2) Can the random sensor noise be controlled without introducing too much delay in the response?

I am sure that there are more things that I haven't thought of.

This seems like a lot of trouble when MEMs rate gyro's are available.

Doug Sams wrote: >

Reply to
David Schultz

David, So should I add another set of accelerometers? What about some Rate Gyros?

You want to help me crunch the data when I finally get a good flight?

accelerometers

Reply to
Robert DeHate

As soon as you go to 3 axis measurements the math gets heavy and if you want real time calculations and course corrections the computational load is beyond a typical 8 bit micro. Has anyone played with 3 axis digital compassing in rockets? My son's robot team is using PNI magnetic sensors, accelerometers as inclinometers and encoders for autonomous navigation this year. Initial testing looks promising. Gary Deaver ">

Reply to
Deaver

I flew a Honeywell 3-axis magnetic sensor (HMC2003) on a few flights. I didn't do much with the data though. I flew the sensor because that rocket exhibited some dynamic stability issues on its first K powered flight. The magnetic data showed a very high roll rate.

RDAS flight data available on my web site. Look at the PAC-3 flight log in the Level 3 area.

The other tidbit I gleaned from the magnetic data is that magnetic apogee detectors should not be flown off of launch rods/rails made of ferromagnetic materials. A very high chance of triggering at liftoff.

Deaver wrote:

Reply to
David Schultz

Exactly why I did not use a 8 bit micro ;-)

formatting link
With the 'N' flight at LDRS I did not get the code done for the computer. I have to build another rocket to fly it in, and hopefully before the end O the year.

Reply to
Robert DeHate

ferromagnetic

Reply to
Deaver

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.