Re: [Openrocket-devel] Interesting booster recovery observation

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

What I said earlier I meant for lower stages.  I think the upmost stage
should continue using the normal stepper at least until apogee.  After that
it could switch to tumble stepper in order to simulate rocket tumble
recovery.

I know it's a bit ugly to be asymmetric about stages, but in practice it's
common for lower stages to be unstable and use tumble recovery, while upper
stages typically try to be stable (with few exceptions).

Cheers,
   Sampo N.

On Sun, Feb 23, 2014 at 7:19 PM, Kevin Ruland <kr...@su...> wrote:

>  Hi,
>
> I don't think the tumble stepper should be used in the event that the
> rocket begins to tumble under thrust.  At that time, the simulation should
> just put up its hands and say "Unstable"  However, the tumble stepper
> should be aware of ejection & recovery deployment events since that's a
> reasonable flight model.
>
> In the case of NaN, the data is saved, the simulation is marked as
> invalid, but the BugException dialog is presented.  Some users do submit
> bugs for this - even though it's likely an unstable simulation.  Since the
> data is available in the FlightDataBranch, the user could make some plots
> and for example see high amplitude oscillations in the Aoa - or other
> indications of instability.  Odds are people don't bother to investigate
> because - well, we all like to fly stable rockets.
>
> My suggestion is that if a NaN occurs during simulation or if tumbling
> under power is detected, the simulation should be aborted and the user
> presented with a dialog indicating the simulation indicated instability.
> If this exception is not a BugException, we won't get reports on it.
>
> Kevin
>
>
> On 2/23/2014 3:39 AM, Sampo Niskanen wrote:
>
>   Hi,
>
>  I agree that the check for apogee is unnecessary.  If it's tumbling, then
> it's tumbling and should be simulated as such.
>
>  I'm also wondering if the check for powered motors is unnecessary as
> well.  While "skywriting" behavior differs visibly from unpowered tumbling,
> it could be argued that the average trajectory is the same (assuming
> there's approximately equal thrust produced in a circular fashion).
> Ideally, the tumble stepper would still handle the motor burnout / ejection
> charge events, but ignore the thrust.
>
>  I'm not sure has the code been changed so that in case of an exception,
> the simulated data is retained.  I think it should - it allows better
> possibilities for analyzing what went wrong.
>
>
>  Cheers,
>     Sampo N.
>
>
>
>
> On Sat, Feb 22, 2014 at 5:31 PM, Bill Kuker <bk...@bi...> wrote:
>
>> The code waits until the stage is unstable (cg behind cp), the AoA > 20
>> degrees and the stage is past apogee before it switches to the tumble
>> simulator. The AoA check is about the same as the thrust / velocity vector
>> comparison Chris suggests.
>>
>>  Being unstable and pointy-end-sideways while under power sounds like
>> sky-writing to me, so perhaps the tumble transition check could indicate a
>> switch to tumble if unpowered, and a simulation-ending level of instability
>> if under power. It seems like a fair distinction between ending the
>> simulation on a bug, meaning the values are wrong and we do not know why,
>> versus ending the simulation because the flight is outside the regime the
>> simulation is designed to cover.
>>
>>  -Bill
>>
>>
>>
>> On Sat, Feb 22, 2014 at 9:31 AM, Christopher Bunto <cg...@gm...>wrote:
>>
>>> Perhaps you could monitor if the thrust vector diverged from the
>>> vehicle velocity by some value - that would indicate the rocket is
>>> tumbling while under power?
>>>
>>> I'm not exactly super-familiar with the code myself, so I'm just
>>> offering a suggestion.
>>>
>>> On Fri, Feb 21, 2014 at 11:57 PM, Kevin Ruland <kr...@su...>
>>> wrote:
>>> >
>>> > Bill,
>>> >
>>> > That was intentional - kinda of.  I know the final conditions were
>>> decided
>>> > on by Sampo and mine were a little more restricted, however, they both
>>> > included the assumption of reaching apogee first.  Trying to reproduce
>>> my
>>> > thoughts on that it was likely because of the assumption that it is a
>>> > "recovery" mode.
>>> >
>>> > However, thinking about it again, it seems that the transition to
>>> tumble
>>> > recovery should probably only be contingent on the aerodynamics (cp/cg
>>> > relationship), the AoA being large, and that there are no burning
>>> motors.
>>> > However, the tumble stepper would have to allow for recovery events.  I
>>> > don't know if that's possible right now.
>>> >
>>> > We do get lots of bug reports about NaNs in simulations.  These are
>>> likely
>>> > because of unstable models under power.  Do you think there would be
>>> some
>>> > detectable conditions of "skywriting"?  Or do you think that NaNs in
>>> the
>>> > simulation (likely because of significant oscillations) indicate
>>> instability
>>> > and we could abort the simulation with a message instead of a
>>> BugException?
>>> >
>>> > Kevin
>>> >
>>> >
>>> >
>>> > On 2/21/2014 9:34 PM, Bill Kuker wrote:
>>> >
>>> > So I have to admit this is the first time I have even looked at the
>>> > simulation code, but I was noticing that on some of the 3-stage example
>>> > simulations the booster simulation branch aborts early with a divergent
>>> > rotational velocity ("Simulation values exceeded limits"). From there I
>>> > found my way to where the BasicEventSimulation transitions from flight
>>> to
>>> > tumble, and the code there prevents the changeover to tumble if the
>>> stage
>>> > has not yet reached apogee. I really can't convince myself that this is
>>> > correct, if the aerodynamics say it is time to tumble shouldn't it just
>>> > tumble on up and over apogee?
>>> >
>>> > -Bill
>>> >
>>> >
>>> > On Thu, Feb 20, 2014 at 5:03 PM, Bill Kuker <bk...@bi...>
>>> wrote:
>>> >>
>>> >> On both paths, up and down wind, the booster does not have a TUMBLE
>>> type
>>> >> event until near apogee, so I guess it is just dependent on the wind
>>> and
>>> >> fine details at the point the booster separates.
>>> >>
>>> >> -Bill
>>> >>
>>> >>
>>> >> On Mon, Feb 17, 2014 at 3:57 PM, Kevin Ruland <kr...@su...>
>>> >> wrote:
>>> >>>
>>> >>> I suspect the middle stage is marginally stable.  Then depending on
>>> the
>>> >>> random factors, it might actually glide upwind.
>>> >>>
>>> >>> I think when an object begins to tumble, an event is pushed into the
>>> >>> simulation.  Can you check if this event is recorded for the second
>>> stage?
>>> >>>
>>> >>> Kevin
>>> >>>
>>> >>>
>>> >>> On 2/17/2014 2:18 PM, Bill Kuker wrote:
>>> >>>
>>> >>> I am not really sure what the state of booster recovery is, but
>>> running
>>> >>> the second simulation on the three stage many times with no
>>> variation except
>>> >>> for the build in wind gives results like this:
>>> >>>
>>> >>> http://i.imgur.com/ccLU0J6.png
>>> >>>
>>> >>> You see the first stage drop off downwind, then the second stage
>>> heads
>>> >>> downwind most of the time but at least 10% of the time it follows
>>> the arc
>>> >>> upwind, and finally the top stage flys off screen and eventually
>>> parachutes
>>> >>> in on the left.
>>> >>>
>>> >>> It seems really odd to me that the middle stage is falling either 60m
>>> >>> upwind or 40m downwind. Any idea what is up with that?
>>> >>>
>>> >>> -Bill
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> ------------------------------------------------------------------------------
>>> >>> Managing the Performance of Cloud-Based Applications
>>> >>> Take advantage of what the Cloud has to offer - Avoid Common
>>> Pitfalls.
>>> >>> Read the Whitepaper.
>>> >>>
>>> >>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Openrocket-devel mailing list
>>> >>> Ope...@li...
>>> >>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> ------------------------------------------------------------------------------
>>> >>> Managing the Performance of Cloud-Based Applications
>>> >>> Take advantage of what the Cloud has to offer - Avoid Common
>>> Pitfalls.
>>> >>> Read the Whitepaper.
>>> >>>
>>> >>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> >>> _______________________________________________
>>> >>> Openrocket-devel mailing list
>>> >>> Ope...@li...
>>> >>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Managing the Performance of Cloud-Based Applications
>>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> > Read the Whitepaper.
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Openrocket-devel mailing list
>>> > Ope...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Managing the Performance of Cloud-Based Applications
>>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> > Read the Whitepaper.
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Openrocket-devel mailing list
>>> > Ope...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>> >
>>>
>>>
>>>
>>> --
>>>  =-=-=-=-=-=-=-=-=-=-=
>>> Chris Bunto
>>> cg...@gm...
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Openrocket-devel mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Openrocket-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>
>>
>
>
> --
>    Sampo Niskanen   <=>   http://www.iki.fi/sampo.niskanen/
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Openrocket-devel mailing lis...@li...://lists.sourceforge.net/lists/listinfo/openrocket-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Openrocket-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>
>

-- 
   Sampo Niskanen   <=>   http://www.iki.fi/sampo.niskanen/