Featherweight Blue Raven Development Thread: Deployment logic

[Adrian A]

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):



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.

 

[BDB]

Adrian, this is going to be the Cadillac of altimeters. Thanks for all of the ingenuity and hard work. Sign me up when it becomes available.

 

[Sandy H.]

As a customer who opted in early and then took some time off, I am still thrilled with my Raven 1. Personally, I haven't gotten too involved with Bluetooth etc., but see that as a very logical way to go for most individuals. I always have a laptop with me, so I don't really care about wireless vs. wired during setup, but I do like seeing stuff on a big screen and I'm sure you'll keep functionality for laptop users as well, so no concern.

Overall, I have little to nothing to suggest at this point, other than iterate as you see fit, because I personally believe the Raven was a step change in rocketry altimeters and data acquisition, not just an iteration. When the guy who makes a step change wants to do something new, watch and adopt is what I'm thinking. I look forward to seeing what you come up with and look forward to owning one or two if it adds to my desired areas for study/flight profiles. The Raven is tough to beat. You did the altimeter equivalent of the Boston album based on the technology at the time. I know GPS and other neat technologies are much more common now (and I did buy Eggtimer stuff as well) but when Featherweight releases a new album (altimeter, you get it), I'll buy it just like I would buy a new Boston album.

Sandy.

 

[kalsow]

Just a random thought..... How about describing when events occur relative to macro-features instead of micro sensor readings? For example: Ignition, Motor 1 Burnout, Motor 2 Burnout, Vertical Coast, Off-vertical Coast, Slow coast (before, but near apogee), Apogee, near Landing, Landed. The only additional parameter would be a delay time after each specified event. "near Landing" is a bit weird. There you'd like to specify a "negative delay" that is before the actual landing. It would would use the current descent rate and altitude to determine time to landing. In this model experts (e.g. Adrian, VernK, bdale, ...) could determine the best way(s) to use the available sensor readings while mere mortals could easily program their altimeters and fly rockets.

My $0.0001.

 

[Adrian A]

As a customer who opted in early and then took some time off, I am still thrilled with my Raven 1. Personally, I haven't gotten too involved with Bluetooth etc., but see that as a very logical way to go for most individuals. I always have a laptop with me, so I don't really care about wireless vs. wired during setup, but I do like seeing stuff on a big screen and I'm sure you'll keep functionality for laptop users as well, so no concern.
Sandy.

Thanks for the support, Sandy. For reviewing data, how do you feel about having zoomable plots on the phone/tablet and then being able to email the data to yourself for plotting in Excel, etc. on your own on your computer? (I'm not currently planning to create a new laptop application for plotting the Blue Raven data)

 

[Adrian A]

Just a random thought..... How about describing when events occur relative to macro-features instead of micro sensor readings? For example: Ignition, Motor 1 Burnout, Motor 2 Burnout, Vertical Coast, Off-vertical Coast, Slow coast (before, but near apogee), Apogee, near Landing, Landed. The only additional parameter would be a delay time after each specified event. "near Landing" is a bit weird. There you'd like to specify a "negative delay" that is before the actual landing. It would would use the current descent rate and altitude to determine time to landing. In this model experts (e.g. Adrian, VernK, bdale, ...) could determine the best way(s) to use the available sensor readings while mere mortals could easily program their altimeters and fly rockets.

My $0.0001.

Yes, my plan is to have the user interface be at the higher level like you suggest, with, for example, a selection available called "deploy at low altitude" which would be the default for the main chute channel, where the sensor selections are taken care of and the user just selects the altitude.

 

[Sandy H.]

Thanks for the support, Sandy. For reviewing data, how do you feel about having zoomable plots on the phone/tablet and then being able to email the data to yourself for plotting in Excel, etc. on your own on your computer? (I'm not currently planning to create a new laptop application for plotting the Blue Raven data)

That's workable for me. Chances are, though, that I'll be on a way outdated iOS, so that might cause issues. I am definitely an outlier when it comes to smartphone use, so definitely don't take my random use case drive development at all.

Looking forward to seeing behind the curtain as the new product develops!

Sandy.

 

[cwbullet]

I am excited. My support goes back to the Parrot. I have a Raven 4 I am still pending a flight. I looked forward to the smaller Swallow or what every ti was called at the time.

I appreciate your efforts.

 

[TonyL]

Hi Adrian,
I very much like the idea of more inertial axes. I am a fan of the macro events programming for ease of use, but would still like access to the individual parameters for programming special circumstances.

My wish list still includes some 100Hz channel voltage data logging...

br/

Tony

 

[OverTheTop]

My wish list still includes some 100Hz channel voltage data logging...

^^^ What he said. Unused channels can be used to monitor other modules for supply voltages or even control loop responses. 50Hz would probably satisfy me in this regard, but I'll take 100Hz if it's going .

 

[tollyman]

If it is compatible with existing products I don't suppose you will be moving away from the common positive wiring architecture or adding any switch terminals? I think those would be my items to change. But I'm sure in order to fit the form factor that's what has to be done

 

[Neutronium95]

Will it be possible to arm this over Bluetooth? While I haven't used it personally, wireless arming does seem like a useful feature.

 

[Ronz Rocketz]

So does this mean no more plugging into an adapter to download?

I'm not sure if it's polite to mention competitors but what I like is the ability to download the CSV file from the website and insert into Race Render software to overlay the video.

 

[rocketace]

I am excited. My support goes back to the Parrot. I have a Raven 4 I am still pending a flight.

I also I started with a Parrot (V2). Its barro sensor is messed up but I still use it to record acceleration on my high G flights over 100Gs.
Supper exited about the Blue Raven!

 

[Adrian A]

Hi Adrian,
I very much like the idea of more inertial axes. I am a fan of the macro events programming for ease of use, but would still like access to the individual parameters for programming special circumstances.

My wish list still includes some 100Hz channel voltage data logging...

br/

Tony

I was thinking of you and I have reserved space for one analog channel at 500 Hz. Normally it would be current but I'd like to make that selectable. There is alos a pad on the board for an aux analog input in addition to the channel voltages. Would you prefer to solder a wire onto a pad, or use one of the terminal inputs?

-Adrian

 

[BDB]

Thanks for the support, Sandy. For reviewing data, how do you feel about having zoomable plots on the phone/tablet and then being able to email the data to yourself for plotting in Excel, etc. on your own on your computer? (I'm not currently planning to create a new laptop application for plotting the Blue Raven data)

^^^^^ This is the best feature of the Jolly Logic Altimeter 3. I have been known to fly it on dual deploy flights just so I can get the data via BT on my phone and analyze it while walking back to the flight line. I honestly open the JL app from time to time just to see the beautifully formatted graphs and to remember the great flights.

Will it be possible to arm this over Bluetooth? While I haven't used it personally, wireless arming does seem like a useful feature.

^^^^^ I have been assuming that arming via BT is included in this version--at least I sure hope so. That would be an excellent feature for safely arming sustainers for 2-stage flights.

 

[Adrian A]

^^^^^ I have been assuming that arming via BT is included in this version--at least I sure hope so. That would be an excellent feature for safely arming sustainers for 2-stage flights.

This is good feedback. My plan has been to make the defaults work such that when you power up the altimeter, the connected channels are armed, just like with the current Raven4 and most other altimeters. Flying after forgetting to arm an apogee or main chute deployment is a lot more dangerous than having a charge go off accidentally, and a lot more likely since the first would just take a rocketeers oversight and the second would require several electronic failures.

Also, for high powered airstarts the software running on the Blue Raven should count as one activation inhibit anyway, following the conservative assumption that one set of software running on one processor can do do the worst thing it can do after just one failure. In other words, if the Blue Raven software messes up on an airstart enough to ignore an altitude check and a verticality check and a motor burnout check, then who is to say it wouldn't also ignore a lack of an arming command? Someone flying a high powered airstart should have 2 other separate physical inhibits that interrupt power to the system (for example one power switch to turn on the altimeter and a separate switch in series with the airstart igniter) until the rocket is vertical on the pad.

But perhaps I should consider adding a checkbox in the deployment channel setup macros for something like "armed at power up" vs "armed by command", with default macros for apogee and chute deployments armed at power-up, and macros for airstart and stage separation to be armed by command. That way, it could provide a little more piece of mind to someone launching a high-powered airstart by letting them walk back to the edge of bluetooth range before arming the airstart.

 

[Adrian A]

So does this mean no more plugging into an adapter to download?

I'm not sure if it's polite to mention competitors but what I like is the ability to download the CSV file from the website and insert into Race Render software to overlay the video.

Yes, no adapter board would be required. Just in case people don't already know, the Raven4 has its own USB connector so that no adapter board is required for it either, and the Featherweight GPS Tracker system also already downloads recorded flight data over bluetooth to your phone.

I'm not currently planning to host a website that stores flight data; your phone will store the data internally and share it out as needed over email, etc., and that way we don't have to mess with people signing up for yet another account with a username and password (a pet peeve of mine)

 

[BEC]

I'm not currently planning to host a website that stores flight data; your phone will store the data internally and share it out as needed over email, etc., and that way we don't have to mess with people signing up for yet another account with a username and password (a pet peeve of mine)

I'm not really in the target market for your device as I'm fly almost exclusively LPR, but since I use bluetooth devices that use both of these approaches (AltimeterThree and FS Mini) I find both the local storage/interactive graphs/share by email approach and the upload to an online log approach have their pluses and minuses. I think, though, I like the automatic local storage and interactive graph approach (AltimeterThree) better. The only real negative is backing the data up for flights that you don't export to .csv and email elsewhere. The iPhone backup is a big monolithic thing — there is no way to manipulate or backup the data in the AltimeterThree app separately from the entire phone's backup. FlightSketch, when you do a local download, saves its .csv files in a folder accessible through the Files app, which makes it possible to back it up separately, or move a bunch of data to a different machine fairly easily.

So....if I could just make the software come into existence, I'd want an application to work like AltimeterThree's does, but store the files on the device where they can also be accessed separately. This way they could also scratch Ron's itch about feeding them to RaceRender....but then your email export approach (like Jolly Logic's) actually supports that capability anyway, just in a different way than Ron is accustomed to with the FS data.

But as I say, I'm not a likely customer, so this advice is worth exactly what you paid for it....a few moments to read, and that's it.

 

[BDB]

But perhaps I should consider adding a checkbox in the deployment channel setup macros for something like "armed at power up" vs "armed by command", with default macros for apogee and chute deployments armed at power-up, and macros for airstart and stage separation to be armed by command. That way, it could provide a little more piece of mind to someone launching a high-powered airstart by letting them walk back to the edge of bluetooth range before arming the airstart.

That's something I would appreciate. I really like the ability to remotely arm for air starts and even for dual deploy. That said, if the default setting had the deployment channels armed at power-up, I could imagine that integrating a wifi switch to either remotely turn on the altimeter or to remotely arm the air start igniter would also solve the problem.

 

[Adrian A]

I'm not really in the target market for your device as I'm fly almost exclusively LPR, but since I use bluetooth devices that use both of these approaches (AltimeterThree and FS Mini) I find both the local storage/interactive graphs/share by email approach and the upload to an online log approach have their pluses and minuses. I think, though, I like the automatic local storage and interactive graph approach (AltimeterThree) better. The only real negative is backing the data up for flights that you don't export to .csv and email elsewhere. The iPhone backup is a big monolithic thing — there is no way to manipulate or backup the data in the AltimeterThree app separately from the entire phone's backup. FlightSketch, when you do a local download, saves its .csv files in a folder accessible through the Files app, which makes it possible to back it up separately, or move a bunch of data to a different machine fairly easily.

So....if I could just make the software come into existence, I'd want an application to work like AltimeterThree's does, but store the files on the device where they can also be accessed separately. This way they could also scratch Ron's itch about feeding them to RaceRender....but then your email export approach (like Jolly Logic's) actually supports that capability anyway, just in a different way than Ron is accustomed to with the FS data.

But as I say, I'm not a likely customer, so this advice is worth exactly what you paid for it....a few moments to read, and that's it.

Brad,

That's actually quite helpful, thanks.

 

[Sandy H.]

Brad,

That's actually quite helpful, thanks.

This is a curious question, not a request for feature. If the device can talk to a phone (or tablet) via bluetooth, would it be difficult to talk to it via bluetooth on a PC to grab a file? I'm personally fine with the idea of using a command line to type in some really gross looking commands, but if the file was either a *.csv (or similar) or a binary with an interpreter that could then convert it to a *.csv etc., that would be interesting to me.

As i mentioned above, I tend to be way out of date on my iOS, mainly due to the forced changes and 'hidden' features that happen as old phones upgrade to newer iOS. I still use my original iPhone5s purchased in 2013, on the original battery and it lasts about 36 hours between charges. My newer phone (2016 SE, I think) also lasts at least that long, all assuming a couple of hours use. My wife has had to upgrade 3 times so far due to battery life alone. I am also typing this on a Windows 7 computer that is rock solid. The Windows 11 computer I have is pretty sweet, as it boots up in about 30 seconds after it crashes a few times a day. This one does take about 5 minutes, but last time I rebooted was 2 weeks ago after a backup. Before that it was over a hundred days. . .

Anyway, as I said above, I'm an outlier for sure, but if there are some options that would allow 'command-line level' access for both upload of configuration and download of data, I would not complain. I imagine you do the development in that arrangement mostly and then have to make a UI that most people can tolerate, but I could be mistaken.

Again, curious question, not a feature request. It would be much better to serve 99.999999% of your customers who keep their phones somewhat up to date than the one or two guys who don't.

Sandy.

 

[Adrian A]

Anyway, as I said above, I'm an outlier for sure, but if there are some options that would allow 'command-line level' access for both upload of configuration and download of data, I would not complain. I imagine you do the development in that arrangement mostly and then have to make a UI that most people can tolerate, but I could be mistaken.

Sandy

You’re correct. The Blue Raven prototype I’m using for development has a USB connector for a serial interface, and I’m using that for telemetry and commands while the mobile app is being developed. I’ll probably still keep it and publish the commands like I did for the Featherweight GPS ground station.

 

[RocketPro]

I love the addition of parameters and more detailed specification of the events.

I would like to be able to set the input criteria to be “sticky” or to latch once it occurs. Once true, always true depending on my setting. This would provide coverage for some corner cases.

Secondly, something that I discovered back in the day when the Mission Control was available was that too much flexibility and programability is daunting and intimidating for many “entry level” users. You may be able to increase your user base by having a “basic capabilities” page in the configuration software that hides all the complexity. I did that for the interface software that I wrote for the Control.

Good luck and looking forward to getting my hands on the new units next year!

 

[Adrian A]

I love the addition of parameters and more detailed specification of the events.

I would like to be able to set the input criteria to be “sticky” or to latch once it occurs. Once true, always true depending on my setting. This would provide coverage for some corner cases.

Secondly, something that I discovered back in the day when the Mission Control was available was that too much flexibility and programability is daunting and intimidating for many “entry level” users. You may be able to increase your user base by having a “basic capabilities” page in the configuration software that hides all the complexity. I did that for the interface software that I wrote for the Control.

Good luck and looking forward to getting my hands on the new units next year!

Yes, I plan/hope to have an interface where the user starts out with the default for each channel as top-level option like "main chute deploy" that then displays the subset of options, like deployment altitude, that are useful for that top-level choice. One of the top-level options would be "custom" which would have all the possible options and parameters. I don't know yet how hard it will be for the mobile app team to make all these context-sensitive choices, but I'll find out soon.

Agreed on the option to latch the output on (until landing?), at least in the custom settings dialog. The Raven4 has this feature also, though I don't know how often it gets used.

I'm working toward having the Blue Raven available this year!

 

[Grog6]

Just remember, inthe software, to set the SkyNnet function to 0.

 

[FredT]

But perhaps I should consider adding a checkbox in the deployment channel setup macros for something like "armed at power up" vs "armed by command", with default macros for apogee and chute deployments armed at power-up, and macros for airstart and stage separation to be armed by command. That way, it could provide a little more piece of mind to someone launching a high-powered airstart by letting them walk back to the edge of bluetooth range before arming the airstart.

This is good feedback. My plan has been to make the defaults work such that when you power up the altimeter, the connected channels are armed, just like with the current Raven4 and most other altimeters. Flying after forgetting to arm an apogee or main chute deployment is a lot more dangerous than having a charge go off accidentally, and a lot more likely since the first would just take a rocketeers oversight and the second would require several electronic failures.

Also, for high powered airstarts the software running on the Blue Raven should count as one activation inhibit anyway, following the conservative assumption that one set of software running on one processor can do do the worst thing it can do after just one failure. In other words, if the Blue Raven software messes up on an airstart enough to ignore an altitude check and a verticality check and a motor burnout check, then who is to say it wouldn't also ignore a lack of an arming command? Someone flying a high powered airstart should have 2 other separate physical inhibits that interrupt power to the system (for example one power switch to turn on the altimeter and a separate switch in series with the airstart igniter) until the rocket is vertical on the pad.

But perhaps I should consider adding a checkbox in the deployment channel setup macros for something like "armed at power up" vs "armed by command", with default macros for apogee and chute deployments armed at power-up, and macros for airstart and stage separation to be armed by command. That way, it could provide a little more piece of mind to someone launching a high-powered airstart by letting them walk back to the edge of bluetooth range before arming the airstart.

Adrian-
I am very much in favor of a remote arming option for use in upper stages. That way I could power up the Raven on the pad before the rocket is raised to vertical and then remotely arm the device when the rocket is in launch position. This eliminates the need to climb a ladder or launch tower.

Fred

 

[thzero]

Brad,

That's actually quite helpful, thanks.

Having to "email" data from AltimeterThree is the absolute worst. The Bluetooth part is nice for arming, for quick check of results in the field, etc... even if has issues with connecting (at least on Android).

 

[Adrian A]

Having to "email" data from AltimeterThree is the absolute worst. The Bluetooth part is nice for arming, for quick check of results in the field, etc... even if has issues with connecting (at least on Android).

The AltimeterThree graphs the data on your phone, correct? If you're emailing data from it, is it for deeper post-flight analysis? What made the emailing difficult?

 

[thzero]

The AltimeterThree graphs the data on your phone, correct? If you're emailing data from it, is it for deeper post-flight analysis? What made the emailing difficult?

It does do a lightweight graph on the phone yeah. Its a just a xlsx output of more of the semi-raw values; its somewhat formatted (which is annoying) but gives Time, Pressure, Altitude, Xacc, Yacc, Zacc, TotalAcc values.

As far as email, its just clunky, but that may be more about Android than anything. Its a share option from the app, which then leads you through the share system in Android to get to email, drive, etc. Using drive, if hooked up to google ecosystem, is a bit easier - still goes through the Share option. It would be nice if an app offered integration, so that it was more seamless especially in the field.