[altusmetrum] Stage Ignition Logic on TeleMega

Casey Barker casey at barkerzone.com
Mon Mar 2 21:28:37 MST 2015


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 <troj at cox.net> 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:altusmetrum-bounces at lists.gag.com] *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
> altusmetrum at lists.gag.com
> http://lists.gag.com/mailman/listinfo/altusmetrum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gag.com/pipermail/altusmetrum/attachments/20150303/c282e8e5/attachment.html>


More information about the altusmetrum mailing list