2 == Example Pyro Channel Configurations
4 Programming configurable pyro channels on Altus Metrum products that
5 include them isn't difficult, but in an attempt to aid understanding
6 of the configuration interface and help "keep simple things simple",
7 we offer the following examples of the simplest configurations for
8 common situations, along with some hints on avoiding unexpected
11 The rich set of conditions provided can be used to configure almost
12 any pyro event you can imagine, for a wide variety of objectives.
13 But don't be fooled! Typical events need only one or a few simple
14 conditions to be configured for success. A key thing to remember is
15 that *all* configured conditions must be true to allow a pyro channel
16 to fire. Trying to include too many conditions often results in
17 conflicting rules that never allow a channel to fire. The most
18 important advice we can offer is, therefore, to try and find the
19 simplest set of conditions that will do what you need for a given
24 Successful completion of a two-stage flight often involves
25 programming of two events. The first is firing a separation
26 charge, the second is igniting the sustainer's (primary)
29 Separation charges are best fired as soon as possible after
30 the previous stage has completed providing acceleration, to
31 minimize drag of the sustainer's coast phase before ignition.
32 Recovery, whether the remainder of the flight is nominal or
33 not, usually works best when the states are separated. So,
34 the "best" way to configure a pyro channel for a separation
35 charge is to just set "after motor number". For a 2-stage
36 project, set this to "1". This will cause the pyro channel
37 to fire as soon as the firmware's flight state machine
38 determines the first motor has burned out.
40 Safe ignition of a sustainer (primary) motor requires that
41 it happen after the previous stage burns out, while the
42 airframe remains mostly vertical, and typically after the
43 sustainer has coasted away from the booster a bit. A good
44 starting point is thus "after motor number" set the same as
45 the separation charge, which is "1" for a 2-stage rocket.
46 Then "angle from vertical less than" set to some
47 reasonably vertical amount, perhaps 20 degrees. Then "delay
48 after other conditions" set for the desired duration of coast.
49 Use simulations to figure out what a reasonable value here is,
50 but for typical high power rocketry sport flights that aren't
51 trying to set records, something like 2 seconds is usually a
54 === Triggered Clusters and Air Starts
56 When an airframe has a cluster of motors, one of which is
57 "primary" and centered, surrounding by a ring of "secondary"
58 motors, you may want to use the launch control system to fire the primary motor and use onboard electronics to light
59 the rest of the cluster as soon as launch is detected. This
60 is particularly true if the primary motor is significantly
61 different in geometry and may take longer to come up to
62 pressure than the secondary motors. In this case, a simple
63 configuration to light secondary motors is is "time since
64 boost greater than" enabled and set to "0". There's
65 really no point in setting an angle limit since no time has
66 transpired for the airframe to change orientation.
68 Air starts can use the same simple configuration, but with
69 the time set to a non-zero value. However, if air starts
70 are going to light after the airframe leaves the launch rail
71 or tower, add an "angle from vertical less than"
72 condition just you would for a 2-stage sustainer to stay safe.
76 When flying a board like TeleMega or EasyMega, it's easy to
77 configure a programmable channel to fire a redundant apogee
78 charge. This is of course not *fully* redundant, since it's
79 always possible that the board itself or its battery could
80 the the failure source, but far more often, pyro events fail
81 due to broken wires, bad connectors, or bad e-matches... so
82 firing two charges from one board can add useful redundancy.
84 The simplest configuration for redundant apogee is "flight
85 state after" set to "drogue", and then "delay after other
86 conditions" set to a second or two.
90 Similarly to apogee, configuring a redundant main charge can
91 provide useful redundancy. What we want is to configure an
92 altitude for deployment lower than the primary main deploy
93 altitude, and then ensure we only trigger on that condition
96 The simplest configuration for redundant main is "flight
97 state after" set to "drogue", which will ensure we're in to
98 the descent phase, then "height less than" set to a number
99 lower than you've chosen for the primary main channel
102 === Apogee Above Baro Sensor Limit
104 A question we've seen increasingly often is "How does the
105 Telemega/Easymega detect apogee for flights above 100,000
106 feet?" Flights above that height are a bit outside
107 our original design envelope, but can be made to work...
108 This is *not* a simple flight, and the configuration for it
109 is also not simple, but we think including this information
110 is important for anyone contemplating such a project with our
113 Our flight computers use a Kalman sensor-fusing filter to
114 estimate the flight state, which consists of three values:
116 1. Height above ground
118 3. Vertical acceleration
120 Apogee is assumed to be where vertical speed crosses zero.
122 Below 30km altitude (about 100k'), we use both the barometer
123 and the accelerometer to update the flight state, along with
124 a basic Newtonian model of motion. That works well, pegging
125 apogee within a few sensor samples essentially every time.
127 Above 30km, the barometric sensor doesn't provide useful data,
128 so we can't use it to update the flight state. Instead, the
129 Kalman filter falls back to a single sensor mode, using only
132 At all altitudes, we de-sense the barometric data when we
133 estimate the speed is near or above mach as the sensor is
134 often subjected to significant transients, which would
135 otherwise push the flight state estimates too fast and could
136 trigger a false apogee event.
138 That means the filter is no longer getting the benefit of two
139 sensors, and relies on just the accelerometer. The trouble
140 with accelerometers is they're measuring the derivative of
141 speed, so you have to integrate their values to compute speed.
142 Any offset error in acceleration measurement gets constantly
145 In addition, we assume the axial acceleration is actually
146 vertical acceleration; our tilt measurements have enough
147 integration error during coast that we can't usefully use
148 that to get vertical acceleration. Because we don't live in
149 an inertial frame, that means we're mis-computing the total
150 acceleration acting on the airframe as we have to add gravity
151 into the mix, and simply adding that to the axial acceleration
152 value doesn't generate the right value.
154 The effect of this is to under-estimate apogee when you base
155 the computation purely on acceleration as the rocket flies a
158 For flights *near* 100k', all of this works pretty well -
159 you've got the flight state estimates adjusted using the
160 barometric sensor up to 30km, then you're flying on inertial
163 For flights well above 100k', it's not great; you're usually
164 going fast enough through 100k' that the baro sensor is still
165 de-sensed through the end of its useful range, so the flight
166 state estimates are not as close. After that, as you're flying
167 purely on accelerometer data, there's no way to re-correct the
168 state, so the apogee estimates can be off by quite a bit.
170 In the worst cases we have seen, the baro sensor data was
171 wildly incorrect above mach due to poor static port design,
172 leaving the state estimate of speed across the 30km boundary
173 way off and causing the apogee detection to happen far from
176 The good news is that correctly determining apogee is not
177 really all that important at high altitudes; there's so little
178 density that a drogue will have almost no drag anyways. Data
179 from customer flights shows a very parabolic path down to
180 about 50-60k feet, even with a recovery system deployed.
182 So, what we recommend is to set up two apogee plans:
184 1. Use the built-in apogee detection, but add a
185 significant delay (as much as 30 seconds). This
186 will probably fire near enough to apogee to not
187 have a significant impact on the maximum height
190 2. Add a back-up apogee which fires after apogee
191 *when the height is below about 20-25km*. This
192 way, if the flight isn't nominal, and the sustainer
193 ends up reaching apogee in dense air, you aren't
194 hoping the chutes come out before it gets going
195 too fast. And, you get a second pyro channel firing
196 at that altitude even if it reached a higher
199 You can wire these two pyro channels to the same pyro device;
200 you just need to make sure they're wired + to + and - to -
201 (the manual shows which screw terminals are which).
203 The bottom line is that flights to altitudes modestly above
204 the range of the baro sensor with Altus Metrum products can
205 be accomplished safely, but flying "way high" (like 300k')
206 demands a deployment mechanism which doesn't solely rely on
207 altimeters (like ours) which are designed for modest altitude
208 rocketry. Flights to those altitudes also probably need
209 active stabilization to make sure they follow the prescribed
210 trajectory and stay inside their waiver.
projects / fw / altos / blob