Why not just add another condition?
(Angle < X) and (Time > Y) and (Altitude > Z) Figure out where you should be when you stage, subtract a bit to allow for some performance margin, then set accordingly. If you're tumbling you likely won't achieve the altitude at which you want the staging to happen. -Kevin From: altusmetrum [mailto:[email protected]] On Behalf Of Casey Barker Sent: Monday, March 02, 2015 8:27 PM To: Altus Metrum Subject: [altusmetrum] Stage Ignition Logic on TeleMega Hi folks, The AeroPac 100K team flew TeleMegas last year on some, er, "less than successful" two-stage flights. The failures were related to other issues, but they did enlighten us on a few corner cases in TeleMega programming, particularly around second stage ignition. I've been thinking about possible improvements, and I'd like to get your thoughts. I wasn't able help the team much last year, so my understanding of the flights and programming is third-hand. However, I'm told that we conditioned the second stage ignition on ((Angle < X degrees) AND (Time > Y seconds)). Programmers may already see an issue. Our first flight suffered a fin de-lamination during the boost that sent the stack into a tumbling ascent. At some point during that tumble (and after the requisite Y seconds), the sustainer lit. We figured that, while tumbling, the sustainer must've briefly pointed upward < X degrees and satisfied the ignition condition. (I believe on the second flight, we added a "Time < Y+1 seconds" to try and prevent that condition. Unfortunately, that flight failed for entirely different reasons.) Still, if the condition is satisfiable after tumbling, it seems like we'd be better off with some sort of lockout or latch, perhaps a "largest orientation angle seen since launch" condition. Meanwhile, I had some ideas about using clever flight electronics to achieve actual performance improvements. When going for altitude, the second stage ignition time is a tradeoff: If you wait too long, the sustainer arcs over, and you waste energy by going sideways. If you don't wait long enough, you ignite at high speed, resulting in higher sustainer velocity for the duration of the burn, and thus higher drag and wasted energy. (Not to mention the higher chance of fin removal.) So I wondered if we could design an "optimal coast" strategy, such that we wait until the sustainer tips over at least, for example, 5 degrees before igniting, but don't wait longer than Z seconds (in the unlikely event that the sustainer back-slides). This is getting algorithmic, so I'm better off expressing it in pseudo-code: config EarliestIgnitionTime = 15 seconds // Depends on booster motor config LatestIgnitionTime = 25 seconds // Depends on booster motor and sustainer inertia config AbortLockoutAngle = 20 degrees // Depends on TRA regs and/or how far we want to recover config OptimalCoastMaxAngle = 5 degrees // Do you feel lucky? Could sim to determine optimality. variable SustainerAbortMode = False // Persistent state, starts out false loop { if (currentAngle > AbortLockoutAngle) set SustainerAbortMode = True // One-way latch, persists from now on, sustainer aborted. if (SustainerAbortMode == True) loop_again or just exit // Once we abort, we will never, ever light the motor. if (currentTime < EarliestIgnitionTime) loop_again // Booster still burning, haven't separated yet. if (currentTime < LatestIgnitionTime) AND (currentAngle < OptimalCoastMaxAngle) loop_again // Still coasting nearly straight up, so keep going for altitude. // Either the angle is no longer optimal, or we // reached the latest time we wanted to wait, so... light_the_motor() } I doubt that's compatible with the run loop in the firmware, but it expresses the desired conditions. I can even imagine a complex condition using simulation results to develop and program a time (or even velocity) vs. orientation "ignition curve." Hoo-boy. Maybe I've had too long of an off-season to noodle on such things. :) Any thoughts on these ideas? I'm hoping to finally have time to tinker with rockets again soon, so if I were to dig into firmware, any suggestions on how to implement and unit test this? Casey
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
