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
