doc: add an appendix with examples for configurable pyro channels master
authorBdale Garbee <bdale@gag.com>
Tue, 12 Apr 2022 17:13:44 +0000 (11:13 -0600)
committerBdale Garbee <bdale@gag.com>
Tue, 12 Apr 2022 17:13:44 +0000 (11:13 -0600)
doc/Makefile.am
doc/altusmetrum.txt
doc/pyro-examples.inc [new file with mode: 0644]

index 5ca6137991c54e9cbd7fc2b3d4988bd807e88185..b919bab3e5e71400781d78cf96a8401140479946 100644 (file)
@@ -137,6 +137,7 @@ COMMON_INC_FILES=\
        config-ui.inc \
        load-maps.inc \
        aprs-operation.inc \
        config-ui.inc \
        load-maps.inc \
        aprs-operation.inc \
+       pyro-examples.inc \
        handling.inc \
        release-head.inc
 
        handling.inc \
        release-head.inc
 
index 41e79a2b6886840e62430162ad31701f4278f460..d5305859adb3edd341a08feb1c83389604deed08 100644 (file)
@@ -59,6 +59,8 @@ Keith Packard <keithp@keithp.com>; Bdale Garbee <bdale@gag.com>; Bob Finch; Anth
 
        include::system-operation.adoc[]
 
 
        include::system-operation.adoc[]
 
+       include::pyro-examples.adoc[]
+
        include::handling.adoc[]
 
        include::updating-firmware.adoc[]
        include::handling.adoc[]
 
        include::updating-firmware.adoc[]
diff --git a/doc/pyro-examples.inc b/doc/pyro-examples.inc
new file mode 100644 (file)
index 0000000..051f005
--- /dev/null
@@ -0,0 +1,210 @@
+[appendix]
+== Example Pyro Channel Configurations
+
+       Programming configurable pyro channels on Altus Metrum products that 
+       include them isn't difficult, but in an attempt to aid understanding
+       of the configuration interface and help "keep simple things simple",
+       we offer the following examples of the simplest configurations for
+       common situations, along with some hints on avoiding unexpected
+       results.
+
+       The rich set of conditions provided can be used to configure almost
+       any pyro event you can imagine, for a wide variety of objectives.  
+       But don't be fooled!  Typical events need only one or a few simple
+       conditions to be configured for success.  A key thing to remember is 
+       that *all* configured conditions must be true to allow a pyro channel 
+       to fire.  Trying to include too many conditions often results in 
+       conflicting rules that never allow a channel to fire.  The most 
+       important advice we can offer is, therefore, to try and find the 
+       simplest set of conditions that will do what you need for a given 
+       project.
+
+       === Two-Stage Flights
+
+               Successful completion of a two-stage flight often involves
+               programming of two events.  The first is firing a separation
+               charge, the second is igniting the sustainer's (primary)
+               motor.
+
+               Separation charges are best fired as soon as possible after
+               the previous stage has completed providing acceleration, to
+               minimize drag of the sustainer's coast phase before ignition.
+               Recovery, whether the remainder of the flight is nominal or
+               not, usually works best when the states are separated.  So,
+               the "best" way to configure a pyro channel for a separation
+               charge is to just set "after motor number".  For a 2-stage
+               project, set this to "1".  This will cause the pyro channel
+               to fire as soon as the firmware's flight state machine
+               determines the first motor has burned out.
+
+               Safe ignition of a sustainer (primary) motor requires that
+               it happen after the previous stage burns out, while the 
+               airframe remains mostly vertical, and typically after the
+               sustainer has coasted away from the booster a bit.  A good
+               starting point is thus "after motor number" set the same as
+               the separation charge, which is "1" for a 2-stage rocket.
+               Then "angle from vertical less than" set to some
+               reasonably vertical amount, perhaps 20 degrees.  Then "delay
+               after other conditions" set for the desired duration of coast.
+               Use simulations to figure out what a reasonable value here is,
+               but for typical high power rocketry sport flights that aren't 
+               trying to set records, something like 2 seconds is usually a 
+               good place to start.
+       
+       === Triggered Clusters and Air Starts
+
+               When an airframe has a cluster of motors, one of which is 
+               "primary" and centered, surrounding by a ring of "secondary"
+               motors, you may want to use the launch control system to                        fire the primary motor and use onboard electronics to light
+               the rest of the cluster as soon as launch is detected.  This
+               is particularly true if the primary motor is significantly
+               different in geometry and may take longer to come up to 
+               pressure than the secondary motors.  In this case, a simple
+               configuration to light secondary motors is is "time since
+               boost greater than" enabled and set to "0".  There's
+               really no point in setting an angle limit since no time has
+               transpired for the airframe to change orientation.
+
+               Air starts can use the same simple configuration, but with 
+               the time set to a non-zero value.  However, if air starts
+               are going to light after the airframe leaves the launch rail
+               or tower, add an "angle from vertical less than"
+               condition just you would for a 2-stage sustainer to stay safe.
+
+       === Redundant Apogee
+
+               When flying a board like TeleMega or EasyMega, it's easy to
+               configure a programmable channel to fire a redundant apogee
+               charge.  This is of course not *fully* redundant, since it's
+               always possible that the board itself or its battery could
+               the the failure source, but far more often, pyro events fail
+               due to broken wires, bad connectors, or bad e-matches... so
+               firing two charges from one board can add useful redundancy.
+
+               The simplest configuration for redundant apogee is "flight
+               state after" set to "drogue", and then "delay after other 
+               conditions" set to a second or two.
+
+       === Redundant Main
+
+               Similarly to apogee, configuring a redundant main charge can
+               provide useful redundancy.  What we want is to configure an
+               altitude for deployment lower than the primary main deploy
+               altitude, and then ensure we only trigger on that condition
+               while descending.
+
+               The simplest configuration for redundant main is "flight
+               state after" set to "drogue", which will ensure we're in to
+               the descent phase, then "height less than" set to a number
+               lower than you've chosen for the primary main channel 
+               deployment height.
+
+       === Apogee Above Baro Sensor Limit
+
+               A question we've seen increasingly often is "How does the 
+               Telemega/Easymega detect apogee for flights above 100,000
+               feet?"  Flights above that height are a bit outside
+               our original design envelope, but can be made to work...
+               This is *not* a simple flight, and the configuration for it
+               is also not simple, but we think including this information
+               is important for anyone contemplating such a project with our
+               electronics!
+
+               Our flight computers use a Kalman sensor-fusing filter to 
+               estimate the flight state, which consists of three values:
+
+                       1. Height above ground
+                       2. Vertical speed
+                       3. Vertical acceleration
+
+               Apogee is assumed to be where vertical speed crosses zero.
+
+               Below 30km altitude (about 100k'), we use both the barometer 
+               and the accelerometer to update the flight state, along with 
+               a basic Newtonian model of motion. That works well, pegging 
+               apogee within a few sensor samples essentially every time.
+
+               Above 30km, the barometric sensor doesn't provide useful data, 
+               so we can't use it to update the flight state. Instead, the 
+               Kalman filter falls back to a single sensor mode, using only 
+               the accelerometer.
+
+               At all altitudes, we de-sense the barometric data when we 
+               estimate the speed is near or above mach as the sensor is 
+               often subjected to significant transients, which would 
+               otherwise push the flight state estimates too fast and could 
+               trigger a false apogee event.
+
+               That means the filter is no longer getting the benefit of two 
+               sensors, and relies on just the accelerometer. The trouble 
+               with accelerometers is they're measuring the derivative of 
+               speed, so you have to integrate their values to compute speed. 
+               Any offset error in acceleration measurement gets constantly 
+               added to that speed.
+
+               In addition, we assume the axial acceleration is actually 
+               vertical acceleration; our tilt measurements have enough 
+               integration error during coast that we can't usefully use 
+               that to get vertical acceleration. Because we don't live in 
+               an inertial frame, that means we're mis-computing the total 
+               acceleration acting on the airframe as we have to add gravity 
+               into the mix, and simply adding that to the axial acceleration 
+               value doesn't generate the right value.
+
+               The effect of this is to under-estimate apogee when you base 
+               the computation purely on acceleration as the rocket flies a 
+               parabolic path.
+
+               For flights *near* 100k', all of this works pretty well - 
+               you've got the flight state estimates adjusted using the 
+               barometric sensor up to 30km, then you're flying on inertial 
+               data to apogee.
+
+               For flights well above 100k', it's not great; you're usually 
+               going fast enough through 100k' that the baro sensor is still 
+               de-sensed through the end of its useful range, so the flight 
+               state estimates are not as close. After that, as you're flying 
+               purely on accelerometer data, there's no way to re-correct the 
+               state, so the apogee estimates can be off by quite a bit.
+
+               In the worst cases we have seen, the baro sensor data was 
+               wildly incorrect above mach due to poor static port design, 
+               leaving the state estimate of speed across the 30km boundary 
+               way off and causing the apogee detection to happen far from 
+               the correct time.
+
+               The good news is that correctly determining apogee is not 
+               really all that important at high altitudes; there's so little 
+               density that a drogue will have almost no drag anyways.  Data
+               from customer flights shows a very parabolic path down to 
+               about 50-60k feet, even with a recovery system deployed.
+
+               So, what we recommend is to set up two apogee plans:
+
+                       1. Use the built-in apogee detection, but add a 
+                          significant delay (as much as 30 seconds). This 
+                          will probably fire near enough to apogee to not 
+                          have a significant impact on the maximum height 
+                          achieved.
+
+                       2. Add a back-up apogee which fires after apogee 
+                          *when the height is below about 20-25km*. This 
+                          way, if the flight isn't nominal, and the sustainer 
+                          ends up reaching apogee in dense air, you aren't 
+                          hoping the chutes come out before it gets going 
+                          too fast. And, you get a second pyro channel firing 
+                          at that altitude even if it reached a higher 
+                          altitude before.
+
+               You can wire these two pyro channels to the same pyro device; 
+               you just need to make sure they're wired + to + and - to - 
+               (the manual shows which screw terminals are which).
+
+               The bottom line is that flights to altitudes modestly above
+               the range of the baro sensor with Altus Metrum products can
+               be accomplished safely, but flying "way high" (like 300k') 
+               demands a deployment mechanism which doesn't solely rely on 
+               altimeters (like ours) which are designed for modest altitude 
+               rocketry.  Flights to those altitudes also probably need 
+               active stabilization to make sure they follow the prescribed 
+               trajectory and stay inside their waiver.