So, maybe I'll try a three-stager

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Perhaps a sustainer fin got damaged when the booster collided with the sustainer. The damaged fin may have then subsequently failed when the speed reached Mach 3.7.

It would have been nice to be able to find one or more fins. I suspect they drifted further south than the sustainer parts into the Quinn River basin area, and you just can't go there without a buggy of some sort. For months, I tried to protect the leading edges from any damage prior to the flight. Although there are no views showing damage, it might not have taken much to leave them vulnerable.

Jim
 
That has to be one of the most amazing/interesting flight reports ever - kudos for camera placement on all the right parts. Did you get video from any electronics in the sustainer?
Given how well you put your rockets together and that the sustainer lit at 17K AGL (21K MSL) I would guess that damage from the booster caused the fin failure rather than aero heating.

P.S. I beat Tony by a good couple of minutes on guessing that a booster hiccup caused some problems :)
 
Well, I don't mean to get everyone thinking too hard about this particular pic. It's just one aspect of maybe a half dozen interesting aspects about this flight. Here's another pic with another clue, but give me a while to work out the data so things make sense.

Jim

Wow!

A closeup of rocket exhaust at altitude while supersonic. Call the Smithsonian. That's pretty rare.

Greg
 
That has to be one of the most amazing/interesting flight reports ever - kudos for camera placement on all the right parts. Did you get video from any electronics in the sustainer?
Given how well you put your rockets together and that the sustainer lit at 17K AGL (21K MSL) I would guess that damage from the booster caused the fin failure rather than aero heating.

P.S. I beat Tony by a good couple of minutes on guessing that a booster hiccup caused some problems :)

The inset picture in the video is from the sustainer. You can see the booster fly by at one point.

I have no reason to believe that the sustainer would survive an O3400 if launched from the ground. I don't think it can be done with composites without ablatives. The strategy was to get as high as possible. We were 10K below the plan, and the rocket survived to the end of the motor burn, but there is no way to know for sure that it would have survived the high-speed part of the flight even if we had reached the planned altitude, particularly if there was some damage.

Jim
 
Wow, in spite of the failure of the overall flight it was very informative from many respects. I gotta believe it was quite the 'what the heck' moment watching the video for the first time and seeing what happened. I watched the flight at BALLS and it didn't occur to me that the motor hiccup could have caused the issues it did.

Great info and thanks for the post mortem.


Tony
 
Based on that picture, would you consider the flight failure "really unfortunate"?

I was referring to an in-air collision here. To think that they collided twice is "extremely unfortunate."
 
Amazing flight and events.

Another item to add to my FMEA for my extreme flight planning. I thought I had thought of everything.... Thanks Jim for providing the shoulders to stand on for the rest of us....
 
That had to be a pretty substantial chuff/unstart of the booster motor for all three avionics systems to measure it as a burnout.

I think it speaks more to the burnout detection algorithms.

If the firmware is looking for a single sample of acceleration showing negative G's, then that would be susceptible to this sort of thing. Better would be to look for the acceleration to be below some threshold for a period of time. Determining the best threshold and duration could be hard and as soon as you do, someone will do something outside of that envelope.
 
Do you have acceleration telemetry from the booster? Be interested to see what that shows about the motor.
 
I think it speaks more to the burnout detection algorithms.

If the firmware is looking for a single sample of acceleration showing negative G's, then that would be susceptible to this sort of thing. Better would be to look for the acceleration to be below some threshold for a period of time. Determining the best threshold and duration could be hard and as soon as you do, someone will do something outside of that envelope.

Dave, I think you're right. For our flight, if the motor had indeed burned out at the point where it spit the grains, then the acceleration would have decreased to -5 G's. The actual was about -1 G. So, the motor was still producing an acceleration of 4 G's (i.e., significant), although the rocket was slowly slowing down. I think any reasonable algorithm would need to call burnout at that point. The Raven, as best as I can tell, would call burnout with any negative acceleration. Kate requires negative acceleration for a second. It is noteworthy, though, that had the motor performed exactly as expected, my program of burnout plus 2 seconds for the separation charge might still have resulted in a problem. I guess one lesson learned is don't use long-burn motors for booster motors, because you don't exactly when burnout will occur. I suppose in this flight I could have set the separation charge to acceleration less than -3 G's, but I can imagine motor scenarios where that wouldn't work either.

Jim
 
I guess one lesson learned is don't use long-burn motors for booster motors, because you don't exactly when burnout will occur. I suppose in this flight I could have set the separation charge to acceleration less than -3 G's, but I can imagine motor scenarios where that wouldn't work either.

Jim

I have been doing my own planning for a high alt 2 stage flight. I do not believe the burnout of the booster determines the optimal time is to separate the stages. You want stage separation at the point when the sustainer will decelerate less if separated than if was still tied to the booster. In the case of a draggy (relative) booster this might occur when the booster motor is still burning at a low thrust level). If the interstage connection is under tension then the sustainer should be separated.
 
The Raven, as best as I can tell, would call burnout with any negative acceleration.
The Raven documentation says the threshold for burnout is a velocity delta of -5 FPS, after whatever filtering is applied to the accelerometer prior to integration. You're right that this is not much negative acceleration.

"Unlike the burnout counter used in other altimeters, this version will not mistakenly trip if a launch rod snag or noisy motor burn causes a brief drop in the motor thrust." For some definition of brief.
 
What calculations did you make which integrate booster inertia independent of motor burnout for determining sustainer separation time?
 
What calculations did you make which integrate booster inertia independent of motor burnout for determining sustainer separation time?

I am not sure you are asking. If you are asking relative to my post then I will answer.

You can do a calculation based on drag ratio of sustainer/booster and mass ratio of sustainer/booster to determine if the interstage coupler will be in compression or tension when the rocket acceleration is less than 0. If the coupler is in tension then you separate once the acceleration of the rocket goes negative. If the coupler is in compression that you delay separation as long as possible prior to sustainer ignition.
 
I don't understand your question ...

Jim

Rephrased:

What calculations do you use to determine the amount of time the booster mass after burnout is still providing acceleration to the sustainer?

Or:

Time from booster burnout to stage separation.

Are you relying your simulation program calculations only or are you calculating inertia and drag factors separately then comparing against simulator values?

And since we are on the topic of Raven3 algorithms, do you think you are out-flying the capabilities of the Raven3 (as well as the two other computers you had on board, apparently) since they incorrectly detected the anomaly?
 
I am not sure you are asking. If you are asking relative to my post then I will answer.

You can do a calculation based on drag ratio of sustainer/booster and mass ratio of sustainer/booster to determine if the interstage coupler will be in compression or tension when the rocket acceleration is less than 0. If the coupler is in tension then you separate once the acceleration of the rocket goes negative. If the coupler is in compression that you delay separation as long as possible prior to sustainer ignition.

This was exactly my question. What are those mass ratio and drag ratio equations?
 
.. I guess one lesson learned is don't use long-burn motors for booster motors, because you don't exactly when burnout will occur....
I can see the advantages in a long burn motor in terms of reduced stress on the stack while under thrust but obviously there are always trade-offs and unforeseen consequences.

At least now you've now educated a lot of us on new things to watch out for when attempting high performance/altitude staged flights. And yet another area needing refinement in on-board electronics. I downloaded the video and have watched it numerous times. Just a crazy sequence of events and some of the coolest in-flight footage ever.


Tony
 
Rephrased:

What calculations do you use to determine the amount of time the booster mass after burnout is still providing acceleration to the sustainer?

Or:

Time from booster burnout to stage separation.

Are you relying your simulation program calculations only or are you calculating inertia and drag factors separately then comparing against simulator values?

And since we are on the topic of Raven3 algorithms, do you think you are out-flying the capabilities of the Raven3 (as well as the two other computers you had on board, apparently) since they incorrectly detected the anomaly?

In this case, I just used the RasAero simulation to verify a less negative acceleration after separation (to show that the parts wouldn't collide after separation). The plan was to activate yaw/pitch control about 5 seconds after burnout, so I just needed to separate the parts somewhere within that interval.

The Raven and the other computers didn't exactly determine the correct burnout, but I should have done a better job anticipating the issue and coming up with a better plan for stage separation. That's one of the challenges in staging - anticipating what might happen and programming to account for it as best as possible. Kip and I learned a few things about burnout on our flights!

Jim
 
Definitely some of the most amazing footage I've ever seen. I saw one picture of your camera mounted on the sled but did you happen to take any other photos of your camera mounts? Especially the upwards facing camera. You just do so much exotic work that I was wondering if you did anything more than a simple hole in the airframe.
 
Definitely some of the most amazing footage I've ever seen. I saw one picture of your camera mounted on the sled but did you happen to take any other photos of your camera mounts? Especially the upwards facing camera. You just do so much exotic work that I was wondering if you did anything more than a simple hole in the airframe.

For the side-facing camera, I have ~1" holes in the bay and ~ 3/4" in the air frame. I cover the hole in the bay with a quartz microscope slide.

The upward facing camera is one of the "better" key chain cameras. An 808 #16. Just before we cleared the launch area, I remembered that I brought it (attaching it wasn't on the checklist - it was sort of an afterthought). I slathered the back of it with superglue and stuck it on a fin. So much for exotic camera mounts!

Speaking of check lists, we put one together for this flight. It turned out to be very helpful and we followed it almost exactly as written. I gave the task of checklist management to Dan DeHart. He's an airline pilot. Pretty clever, eh? Dan (and the checklist) are in 6 of the 12 pictures below. Check list is attached if anyone is curious.

Jim

View attachment Detailed Checklist.doc
 
The upward facing camera is one of the "better" key chain cameras. An 808 #16. Just before we cleared the launch area, I remembered that I brought it (attaching it wasn't on the checklist - it was sort of an afterthought). I slathered the back of it with superglue and stuck it on a fin. So much for exotic camera mounts!
You just *superglued it to a fin*!?? :eek::eek::eek: I wouldn't have thought that would hold up at H-motor speeds, never mind the crazy speeds you manage to hit. Clearly it worked though. I'm losing track of how much stuff I've learned from this one thread, I can't wait to see where you go next with this project.
 
You just *superglued it to a fin*!?? :eek::eek::eek: I wouldn't have thought that would hold up at H-motor speeds, never mind the crazy speeds you manage to hit. Clearly it worked though. I'm losing track of how much stuff I've learned from this one thread, I can't wait to see where you go next with this project.

I was expecting not to get the camera back, but my experience is that these upward-facing videos can be pretty interesting. It actually turned out to be very hard to remove the camera. When I pried it off, it took the paint with it. Although I got the electronics bay back, my little quartz window was broken, and that managed to damage the camera just enough to where it is no longer usable. To bad. That camera took some interesting (re-posted for the nth time) videos. RIP.

https://youtu.be/mWOicBydGzc
https://youtu.be/eHloNCGlYz4

The quartz window has been fixed and the camera can be replaced.

When we were searching for the parts, we were not able to find the stabilization section. We had literally given up the search and were heading off the Playa when my wife spotted it. As it turns out, it survived the collisions and the fall (it's a tank). That's good, because it would not be trivial to replace it. From the on-board data and from other data, we learned that the stabilization system would probably not have worked had it stayed attached to the sustainer. When the booster spit the grain casings, it induced a turn that exceeded the gryo maximum. Since the rocket had a slight tilt at that point, it would have probably caused the sustainer to cone during the coast phase, which probably would have resulted in exceeding the tilt criteria for the flight. We are currently increasing the span of the gyros to allow 1000 degrees per second maximum, because it seems like there are too many things that happen with rockets that can cause the gyros to see short-term values greater than 500 degrees per second. There are some other upgrades as well, such as allowing the gyros to drift-correct right up to the launch point. I'm working towards testing the revised system in my two-stage "test rocket", with no sustainer motor, sometime in the next few months. I think Marlin would let me do it at Asa.

After that, I have no firm plans. I'd love the try the two-stage flight again, assuming it could be approved (it's just a matter of time, I think, before it will no longer be permitted). I'd need better leading edges for that, and there are some possibilities floating around there. Or, maybe I'll try a three-stager?

Jim
 
Back
Top