Casey, If you used time in the essence that nasa does, then you would have a very narrow range of possible altitudes that would be optimal to acceptable for each measurement in time. This would cause you to want to look at time and altitude in a relationship, rather than as independent values. This would in effect mean a lockout prior to optimal altitudes. In most space programs the lockout would necessitate an abort since the “under altitude” initiation, may place a vehicle outside of the LZ. The rate of change in angle, would be another metric you could use as a gage, marked by more change in time, and less change in velocity and altitude.
Being this is also a political issue lately,-- The tighter you make those relationships, the more often you botch a valid launch. Yet, as you point out, actual fight dynamics are hard to program for, so there may always be a failure that gets “un-sensed”. Implementing something we don’t entirely grasp can be a dangerous thing for some of us.(like me) Clay From: Casey Barker Sent: Monday, March 02, 2015 10:28 PM To: Altus Metrum Subject: Re: [altusmetrum] Stage Ignition Logic on TeleMega 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
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
