Thanks for the input. Actually, in the case of the first flight, I believe the whole stack was *probably* high enough to trip any altitude conditions we'd have reasonably set on it. The altitude data we got back was a bit confused though.
Still, it's a good idea, and I think we added that condition on the second flight. Casey On Mon, Mar 2, 2015 at 6:56 PM Kevin Trojanowski <[email protected]> wrote: > 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 >
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
