Hybrids and Accelorometer based Altimiters

Joanne Worley: "Is that a chicken joke?"

Randy ; )

I've used black sky's altacc without problems on numerous flights.

Koen

I believe most of the failures where with Hypertek and RDAS altimeters. The Hypertek has a pulsation in thrust that interfered with the launch detection with an accelerometer. Barometric altimeters should be immune. If an accelerometer has proper hardware and software filtering and a good launch detect algorithm, they will work. I believe the G-WIZ does not have problems with Hyperteks. I've all ways used a missile works and have never had a problem. Gary Deaver

Howdy folks. How is everyone this fine day?

Hybrids, you say?

No problems at all. Just like big honkin' rockets...too easy.

They just LOOK like a pain in the rear...but as evidenced by my flattened skull (having been beat repeatedly about the head by hybrid fanat...er, I mean "enthusiasts"), appearances must be deceiving.

;-)

With Hyperteks, IIRC, the high voltage arc can also be a problem if launch detect wires, or other electronic elements are down around the fuel grain.

The GWiz units work just fine with Hypertek motors. The RDAS will work if you have the BETA firmware. I think it is v3.65 ?? Anyway, you can also do break wire but you need to keep any long wire runs away from the Hypertek ignition coil. Altacc's have worked for some and failed for other people. It might depend on what version you are on. I've read of dual Altacc's not deploying on a Hypertek and of other people having good success. I always use a Gwiz for backup when I fly a Hypertek. My RDAS works with the new firmware.

Good luck....

Geoff

So someone was awake during the NARAM 44 R&D presentations. :-)

I have hardware/software in flight test at the moment. Not much in the way of flying as all three launches that I wanted to attend during November got weathered out. Yuck.

Flight test software uses both acceleration and pressure data and runs on a PIC 16F628 poking along on a 4MHz clock doing 64 samples per second. The filter requires eight 32X16 bit multiplies which sucks up most of the computation time. A pressure only filter requires three multiplies. This answers the real time question.

There has been an update for the RDAS firmware in the works for a long time to fix the hybrid problem. I don't think that it has been released and I seriously doubt if it uses a Kalman filter. AED has not said what their solution to the problem is. They consider their algorithms proprietary.

Oh, my NARAM R&D report covered only a pressure sensor based Kalman filter with the purpose of improving apogee detection. Cleaning up of acceleration data with the new and improved filter is just gravy. :-)

Once I verify that the software is working OK (I found several bugs on the first, and so far only, flight.) I will hitch a ride on a Hypertek to see what the data looks like.

Details of current work on my web site. Including post processing Kalman filters for the RDAS and AltAcc plus code for the Roctronics hardware that I am currently testing.

So someone was awake during the NARAM 44 R&D presentations. :-)

I have hardware/software in flight test at the moment. Not much in the way of flying as all three launches that I wanted to attend during November got weathered out. Yuck.

Flight test software uses both acceleration and pressure data and runs on a PIC 16F628 poking along on a 4MHz clock doing 64 samples per second. The filter requires eight 32X16 bit multiplies which sucks up most of the computation time. A pressure only filter requires three multiplies. This answers the real time question.

There has been an update for the RDAS firmware in the works for a long time to fix the hybrid problem. I don't think that it has been released and I seriously doubt if it uses a Kalman filter. AED has not said what their solution to the problem is. They consider their algorithms proprietary.

Oh, my NARAM R&D report covered only a pressure sensor based Kalman filter with the purpose of improving apogee detection. Cleaning up of acceleration data with the new and improved filter is just gravy. :-)

Once I verify that the software is working OK (I found several bugs on the first, and so far only, flight.) I will hitch a ride on a Hypertek to see what the data looks like.

Details of current work on my web site. Including post processing Kalman filters for the RDAS and AltAcc plus code for the Roctronics hardware that I am currently testing.

See Kurt? D'eys simple!

steve

They can. The posts about barometric altimeters working fine are correct. - they sense the change in air pressure and use that to detect launch.

Accelerometer based altimeters are the ones that have potential problems. They detect launch based on some predetermined criteria - generally over some period of time to avoid false starts. For example, an RDAS (made by AED) needs to see 2.5g for .25 seconds to detect a launch. The issue with some hybrid motors is that they 'pulse' - they have big peaks of thrust followed by a lull. As a result, it is possible that the RDAS never sees more than 2.5g for .25 second, and does not detect a launch. Obviously, this is bad, since if no launch is detected, no ejection charge will be fired.

Not all sizes and types of hybrids have this characteristic, so it's problematic. For example, when I flew a J-Hypertek, the thrust profile was very similar to a regular solid motor. I've seen plots of M motors that exhibit much more of the 'pulsed' thrust characteristic.

Fortunately, the RDAS does have a 'breakwire' launch detect option, which you can use with or in place of the g-switch. This works by having two contacts shorted with a wire that runs outside your rocket, and is broken when the rocket launches. The post about the high voltage system used to launch Hypertek motors being a concern is right on, since the high voltage can induce voltage in an adjacent wire. In the RDAS, the breakwire connection goes right to the CPU and if it carries an induced voltage, it can fry the chip. This has actually happened, with dramatic results.

I use a breakwire system that consists of two metal pins shorted by a small metal clip. The metal clip is tied to the launch stand with string to eliminate the above possibility. Others use a short piece of solder with a string tied through it to achieve the same result.

Other altimeters can by used with hybrids based on how they detect launch. I know the guys at AED who make the RDAS have re-written the code so that it will work properly with hybrids. There are several other accelerometer based altimeters do have launch detect code that works with hybrids. You should verify compatibility with the manufacturer before using with a hybrid.

As an aside, you can also have a launch detect failure with a solid motor as well. With the RDAS for example, if you greatly under power your rocket, the thrust of the motor might not be able to accelerate it to much over 2.5g's. Add in system noise, and if at any time during the launch detect phase, the thrust drops below the threshold level for even one sample, no launch detect. Another good example might be a really hard chuff followed by the motor not igniting.

Hybrid motors will allow you to fly HPR without a LEUP, but they do increase the overall complexity of the entire flight. The GSE is much more complicated and more costly, you have to have a much longer motor mount than an equivalent composite motor, and you need a timer or altimeter to deploy the chute. And if you are using BP to deploy the chute there is some question as to the need of a LEUP to do even that. Still, I like hybrid motors - they definitely have a 'rocket scientist' factor to them.

This is probably the longest answer to such a short question in a while, but, hey, at least it's on topic.

Good luck,

Tony.

Ps. This is not meant to be a criticism of the RDAS, rather an example of some of the real-world issues that have to be considered with any altimeter. I have an RDAS and think it's one of the most versatile altimeters on the market. I just wish the dollar wasn't so weak right now ? it's pushed the price of them sky high.

My son's robot team's new controller uses a 18Fxxxxx pic chip. I believe it has a hardware multiply and 10 bit AD on chip. From what the kids tell me the thru put is an order of magnitude better than the previous generation of PIC's. Also EEprom write times are slow. A serial flash chip can be written to much faster than an EEprom. Alittle more over head for the buffers. Maybe the 2 together could give you the time for your filter. Gary Deaver

What is the hybrid motor "noise" model that you used in designing your filter? Alan

I didn't incorporate the hybrid motor noise into the design process at all. If I had some idea what the noise was really like, maybe I could. But that would make the filter specific to a particular motor. Not something I want.

What I did do was measure the variance of the random noise present in the sensors themselves. This is then input into the Kalman filter to determine the gains. Because computation of the gains requires more horesepower than a PIC has, I use a constant gain Kalman filter. The gains are computed on a PC and then stored in the onboard EEPROM.

Because I have no idea of what number to put on process noise, I set it in relation to the acceleration sensor noise. This is then used to "tune" the filter to get a reasonable response. If you tell the filter that the model has very low noise, then it smooths the data a lot. And it is easy to go overboard and smooth it too much. But it is fun to play with. :-)

Alan J> >

The 16F628 is more than fast enough. I had hoped to be able to do 128 samples/second but 64 is more than adequate. If I really wanted to do better than 64 SPS then I could just increase the clock frequency anywhere up to the rated 20MHz limit. This would easily allow 256 SPS. I am also storing 16 seconds of flight data (altitude, velocity, and acceleration in engineering units plus raw sensor data) at 64 SPS and another 512 seconds at 2 SPS into a serial EEPROM.

I played around with my RDAS data sets quite a bit to determine the limits of the filters performance. One of the things I tried was reducing the sample rate to as low as 2 SPS. Filter performance was still excellant although it adds a little complexity to the apogee deployment event if you want better than +/- 1/2 second performance. But it isn't hard because all you do is monitor the velocity and acceleration. When velocity is less than acceleration multipled by the time step (1/2 second in this case), then apogee will occur before the next sample. A little extra math will determine the time. So you just set an interupt to go off prior to the next sample time that initiates the apogee event.

No big. :-)