This is the first in a series of development threads in which I'll discuss some design features and tradeoffs of the upcoming Blue Raven altimeter, and give everyone a chance to provide feedback. I'm going to break up the development thread into topics so it will be easier to navigate as the discussion evolves in the future. Disclaimer: This is a behind-the-scenes look that will discuss features that are likely going to change before the final product, and some of which may need to be abandoned or put off.
Background:
The Blue Raven is a ground-up redesign of the popular Featherweight Raven altimeter, built around a much more powerful microcontroller that has Bluetooth capability. The Blue Raven keeps the same small form factor of the Raven, meaning it will fit in 24mm rockets on up, and it will be compatible with all existing Raven av-bay accessories. I'm investing in a top-quality phone app (Apple and Android) to handle all user interfaces for the Blue Raven, including live data, deployment configuration, data download and graphing, etc. Flight testing will take place this spring and summer, and my goal is to have the Blue Raven available for sale early this fall, for about the same price as the current Raven.
Today's topic is the deployment logic. Similar to the Raven, the Blue Raven has 4 output channels. The Raven is very limited in code space and hamstrung by some early design decisions I made, which meant that the 4 output channels had so share some flight event criteria. Below is the setup screen for the default settings all 4 Raven deployment channels. For example, any of the deployment channels had to use the same value for the velocity threshold Vel1 (400 feet/sec in this case):
View attachment 513527
For the Blue Raven, there is enough memory to let each channel have its own independent thresholds. The Blue Raven will also feature full 6-axis inertial sensing (including gyros) and integration that will provide more options and fault tolerance for deployment than were possible before. Here's what I currently have for the flight events that can go into decision to fire a deployment channel. Keep in mind that while all this flexibility is possible, I'll design the user interface to have good default settings so that someone can just buy-and-fly with confidence, and also provide common setups to select from so that nobody is going to have to make a million choices and enter a whole bunch of parameters unless they want to do something really off-the-wall Each all-cap abbreviated word in bold is a threshold that can be set by the user.
- Barometric altitude above the pad < AGL1
- Barometric Altitude above the pad < AGL2
- Flight angle < FANG1
- Flight angle > FANG2
- Time since liftoff < TVAL1
- Time since liftoff > TVAL2
- Accel-based total velocity < VEL1
- Accel-based total velocity < VEL2
- Barometric pressure increasing
- Barometric-derived upward velocity < BVEL (negative number during descent)
- Fault-tolerant apogee detected (Two of three sensors indicate apogee: accel-derived vertical velocity < 0, baro pressure increasing, gyro flight angle > 90 degrees)
- Motor burnout counter > BURNCOUNT
- 1 second since Apogee channel fired
- 1 second since Main channel fired
- 1 second since 3rd channel fired
- 1 second since 4th channel fired
When all the selected events are true, then the output fires. These set of flight events also opens up the potential for having a set of backup criteria for each channel. For example, the main chute channel can fire with the primary criteria being:
- Fault tolerant apogee detection took place
- Barometric altitude above the pad < 700 feet
- Motor burnout counter >= 1
and then also have backup criteria to fire the main chute:
- Fault tolerant apogee detection took place
- 1 second since Apogee channel fired (avoids getting spoofed by pressure spike if the av-bay isn't well sealed)
- 1 second since 3rd channel fired (3rd channel default would be apogee backup)
- Barometric-derived upward velocity < -150 feet/second
- Accel-based total velocity < -150 feet/second
This way, if an apogee charge is undersized or a dud, the main will have a chance to come out before the rocket falls fast enough to shred. I'm currently thinking of making the backup criteria for the main chute part of the default settings. The trick will be to make this easy to understand and use.
Comments are welcome.
