Featherweight Blue Raven Development Thread: Deployment logic

[Adrian A]

Very impressed with the Blue Raven thus far, but had a question regarding disarming channels and flight readiness. If I were to power up the Blue Raven with my avionics bay open and immediately disarm all my pyro channels, then finish a few preparations and close up my avionics bay before rearming on the pad, does the live data give any indication there was some event that would cause any issues proceeding with a flight?

For example, I powered up the BR and disarmed the apogee channel that had an ematch connected. While the BR was beeping indicating it was ready for flight, I swung it enough that it thought there was a launch event and the beeping stopped. I then rearmed the apogee channel and it was showing green because it had continuity, but the altimeter was not beeping. Is there any indication on the live data stating it shouldn't be flown in the event i cant hear beeping?

The disarmed channels are highlighted red in the live data screen even if they have continuity. Anything in the live data screen that is highlighted red, whether an out-of-bounds sensor, or a channel that is disconnected or disarmed, is a potentially a reason to be no-go for launch.

 

[watheyak]

Adrian and other smart people-

I have a question about the Blue Raven default Apogee deploy. I think I know the answer, but I'd like some clarification for my own peace of mind.

My current project, in my typical fashion, has the av-bay in the very tip of the nosecone. This means that the static port will me in a spot where it's angled into the relative wind, which means there will be some (lots) ram air pressure affecting the accuracy of the readings while under boost.

I've used this exact same configuration to a similar speed with a stock, straight from the box Raven 4, successfully, multiple times.

As best I can tell, the Blue Raven will ignore any increasing baro pressure if the gyro based tilt hasn't exceeded 90 degrees and the accel based velocity is less than zero. Seems like that would work.

Some of my consternation comes from the fact that the backup apogee charge seems simpler and mimics the Raven 4 logic. So to my simple, non-programmer brain, I'm worry that I should swap the default Apo to Raven 4 logic?

Sorry for the 1000 word essay. Thanksnin

 

[Conway Stevens]

Adrian and other smart people-

I have a question about the Blue Raven default Apogee deploy. I think I know the answer, but I'd like some clarification for my own peace of mind.

My current project, in my typical fashion, has the av-bay in the very tip of the nosecone. This means that the static port will me in a spot where it's angled into the relative wind, which means there will be some (lots) ram air pressure affecting the accuracy of the readings while under boost.

I've used this exact same configuration to a similar speed with a stock, straight from the box Raven 4, successfully, multiple times.

As best I can tell, the Blue Raven will ignore any increasing baro pressure if the gyro based tilt hasn't exceeded 90 degrees and the accel based velocity is less than zero. Seems like that would work.

Some of my consternation comes from the fact that the backup apogee charge seems simpler and mimics the Raven 4 logic. So to my simple, non-programmer brain, I'm worry that I should swap the default Apo to Raven 4 logic?

Sorry for the 1000 word essay. Thanksnin

Scott, its my understanding and in my use similarly that the blue raven and raven 4 have the same exact stock out of the box configuration and deployment design. So it shouldn't be affected any more than the Raven 4

 

[Adrian A]

Adrian and other smart people-

I have a question about the Blue Raven default Apogee deploy. I think I know the answer, but I'd like some clarification for my own peace of mind.

My current project, in my typical fashion, has the av-bay in the very tip of the nosecone. This means that the static port will me in a spot where it's angled into the relative wind, which means there will be some (lots) ram air pressure affecting the accuracy of the readings while under boost.

I've used this exact same configuration to a similar speed with a stock, straight from the box Raven 4, successfully, multiple times.

As best I can tell, the Blue Raven will ignore any increasing baro pressure if the gyro based tilt hasn't exceeded 90 degrees and the accel based velocity is less than zero. Seems like that would work.

Some of my consternation comes from the fact that the backup apogee charge seems simpler and mimics the Raven 4 logic. So to my simple, non-programmer brain, I'm worry that I should swap the default Apo to Raven 4 logic?

Sorry for the 1000 word essay. Thanksnin

The default settings for the apogee channel will be fine for your flight.

Here is my Mach 2.5 flight from Saturday at Airfest, with a similar av-bay porting configuration:



The red line is the baro altitude, and the blue line is the accelerometer-based altitude. The filtering and persistence on the "baro pressure increasing" check is conservative enough that this flight was not interpreted as having "pressure increasing" until a couple of seconds after the actual apogee.

In the Blue Raven, pressure increasing is one of the three votes for apogee detection, and the apogee detection is a majority vote of the three sensor methods. So even if the baro pressure increasing check went prematurely, the other two votes (gyro-derived angle > 90 degrees) and (vertical-assumed axial accelerometer velocity < 0) would still go true at apogee.

The default for the 3rd channel is for it to be a backup apogee channel based on barometric pressure increasing while the total velocity < 400 feet/sec. This does mimic the Raven 4's primary apogee deployment criteria. The new Blue Raven apogee criteria used in the Apo channel are more tolerant to faults because the gyro angle check works well, and voting 2 of 3 is more tolerant for off-nominal situations than having an "and" of the baro and axial accel checks. So honestly it might actually be better if the default values for both the Apo channel and the 3rd channel (apogee backup) use the newer apogee detection.

A flight that goes high enough to go above Earth's sensible atmosphere, and which can tumble end-over-end before apogee in a nominal flight, is another story that calls for a different strategy...

 

[watheyak]

The default settings for the apogee channel will be fine for your flight.

Here is my Mach 2.5 flight from Saturday at Airfest, with a similar av-bay porting configuration:

View attachment 603353

The red line is the baro altitude, and the blue line is the accelerometer-based altitude. The filtering and persistence on the "baro pressure increasing" check is conservative enough that this flight was not interpreted as having "pressure increasing" until a couple of seconds after the actual apogee.

In the Blue Raven, pressure increasing is one of the three votes for apogee detection, and the apogee detection is a majority vote of the three sensor methods. So even if the baro pressure increasing check went prematurely, the other two votes (gyro-derived angle > 90 degrees) and (vertical-assumed axial accelerometer velocity < 0) would still go true at apogee.

The default for the 3rd channel is for it to be a backup apogee channel based on barometric pressure increasing while the total velocity < 400 feet/sec. This does mimic the Raven 4's primary apogee deployment criteria. The new Blue Raven apogee criteria used in the Apo channel are more tolerant to faults because the gyro angle check works well, and voting 2 of 3 is more tolerant for off-nominal situations than having an "and" of the baro and axial accel checks. So honestly it might actually be better if the default values for both the Apo channel and the 3rd channel (apogee backup) use the newer apogee detection.

A flight that goes high enough to go above Earth's sensible atmosphere, and which can tumble end-over-end before apogee in a nominal flight, is another story that calls for a different strategy...

That's all so awesome. Thanks Adrian.

Now I'm excited to slo-mo record my ground test. Tomorrow hopefully.

 

[VernK]

A flight that goes high enough to go above Earth's sensible atmosphere, and which can tumble end-over-end before apogee in a nominal flight, is another story that calls for a different strategy...

To meet TRA requirements for redundancy, the Blue Raven is going to be used as a backup on Kate flights to ultra high altitudes. Potentially including space shots. When you say that will call for a "different strategy" do you mean a firmware change is going to be needed? Or are you saying the the user just needs to make an adjustment to the settings? If so, what settings do you recommend?

 

[Adrian A]

For an exo-atmospheric flight, we have seen that rockets can start tumbling on the way up when the air density gets low enough. In a flight like that, the gyro-based attitude is not a good indicator of apogee because the assumption of near-zero angle of attack goes out the window. If the rocket is tumbling fast enough and if the altimeter is mounted far enough from the CG, then the centripetal acceleration could theoretically also throw off the simple integration of the axial acceleration like was used in the Raven4. This was not a problem for the USC Traveller team's space shot, where the Raven4's accelerometer-based apogee detection was accurate enough for doing the apogee deployment. In another rocket with more spin and a higher tumble rate, it could be an issue.

The Blue Raven's Earth-relative velocity estimate accounts for the rocket's attitude throughout the flight, even if it is tumbling, and so it should provide the Blue Raven's best apogee estimate. So for exo-atmospheric flight I would set up the Blue Raven's the primary logic using the ECI Vvel < 0 check for the primary deployment logic, along with the usual checks for channel armed, liftoff and motor burnout count.

The Blue Raven also can fire any of its channels based on a secondary set of deployment logic. In this case I would use the secondary logic to cover the case of an in-flight failure that happens before it leaves the atmosphere. This secondary logic would be just like the default apogee deployment logic, but with the addition of a check for altitude < 120,000 feet, so that it it won't deploy on the way up for the exoatmospheric tumble case.

 

[Dave Stephens]

Hi,
We are looking for an altimeter for a 29mm rocket that is very tight in the nose cone where a Blue Raven would go. Is it possible to get an example without the terminal blocks for the separation charges supplied lose but not soldered in place ? We intend to directly solder the leads to the explosive charges.

 

[Adrian A]

Hi,
We are looking for an altimeter for a 29mm rocket that is very tight in the nose cone where a Blue Raven would go. Is it possible to get an example without the terminal blocks for the separation charges supplied lose but not soldered in place ? We intend to directly solder the leads to the explosive charges.

I recommend cutting most of it off, and then you can de-solder each of the pins for the connector block.

Also, consider this:

https://www.featherweightaltimeters.com/store/p24/Blue_Raven_29mm_kickstarter_pre-order.html

 

[Adrian A]

Back on the deployment logic thread, today I'm releasing via TestFlight and FireBase a new firmware update that improves the apogee detection to cover a corner case that a user brought to my attention.

This user had a rocket that lost all of its fins shortly after liftoff, and then proceeded to rotate 180 degrees (without the fins it was stable going backward), and continued upward. At apogee, the rocket continued travelling tail-first as it arced over and started descending.

In the Blue Raven, apogee is detected with a 2-of-3 voting algorithm, with the three votes coming from three different sensors:

• Barometric pressure sensor, heavily filtered to ignore pressure transients, detects when pressure is increasing
• Axial accelerometer calculates when the upward velocity becomes negative, assuming the rocket is vertical
• Gyro sensors integrate the rocket attitude and detect apogee when the tilt is > 90 degrees

The goal is that even if one sensor completely fails during the flight, the Blue Raven will still correctly detect apogee.

For this user's flight, the first check based on the barometric pressure worked fine, but the problem was with the last 2 votes. The axial accelerometer check is designed to ignore the gyro-based rocket attitude information, in case the gyro sensor has a problem. But in this case the gyros were fine. It was the rocket stability had a problem. The whole time it was facing backwards, the drag was pushing in the same direction as if the motor were still thrusting, so the axial accel check never calculated that the upward velocity went below zero.

The gyro did correctly observe the 180 degree change in attitude, but by the time the baro sensor check detected increasing pressure, the rocket had rotated back to less than 90 degree tilt, and so the baro-based vote and the gyro-based vote were never true at the same time.

This firmware update improves the gyro apogee check by latching it true for the rest of the flight after the first time the rocket exceeds a 90 degree tilt angle. If a rocket does a 180 or skywrites, the gyro-based check will vote for apogee, and apogee will be detected as soon as one of the other two checks (for example the pressure sensor) vote for apogee detection. There is a new entry in the flight event register for the gyro check, labeled "Tilt Exceeded 90 deg". Now all three votes for apogee have their own flight event register markers that you can plot along with the rest of the flight, so now the behavior of the apogee detection is more transparent.

 

[kjhambrick]

Woo Hoo !

Thanks for the update, @Adrian A !

I installed Version 1.0.5 ( 270 ) / fd31408 in my Blue Raven ( s/n 0236 ) last night and did a little testing.

The incremental improvement for apogee detect sounds like it might save a rocket or two over time.

Nice !


Thanks for the new low_rate Field: Tilt Exceeded 90 deg ( Field #44, Excel Col[ AR ] - formerly a Reserved field ).

Will the 'Tilt Exceeded 90 deg' flag also be set in the low rate stream, even on a normal flight when / if the tilt angle exceeds 90 deg ?

That might be handy for automatic post processing scripts.


I LOVE the new summary.csv file !

One request for the sunmary file when you can: it would be nice to include the Firmware Version so I can process a mix of older or newer high_rate and low_rate files by first reading the summary.csv to set the input.csv columns.

And if you can, maybe add the Blue Raven Serial Number to the summary.csv if it's available because ...

After upgrading from version 245 to 270, I tried renaming my Blue Raven again from 'Rocket Name' to 'kjh_01' and when I did that, the Android App always downloaded a bogus set of flight data at boot as I reported last fall.

If I know the Blue Raven Serial Number for a flight, then Rocket Name won't matter to me.


Thanks again Adrian, great update !

-- kjh

 

[Adrian A]

Woo Hoo !

Thanks for the update, @Adrian A !

I installed Version 1.0.5 ( 270 ) / fd31408 in my Blue Raven ( s/n 0236 ) last night and did a little testing.

The incremental improvement for apogee detect sounds like it might save a rocket or two over time.

Nice !


Thanks for the new low_rate Field: Tilt Exceeded 90 deg ( Field #44, Excel Col[ AR ] - formerly a Reserved field ).

Will the 'Tilt Exceeded 90 deg' flag also be set in the low rate stream, even on a normal flight when / if the tilt angle exceeds 90 deg ?

That might be handy for automatic post processing scripts.

Yes.

I LOVE the new summary.csv file !

Thanks!

One request for the sunmary file when you can: it would be nice to include the Firmware Version so I can process a mix of older or newer high_rate and low_rate files by first reading the summary.csv to set the input.csv columns.

Good idea

And if you can, maybe add the Blue Raven Serial Number to the summary.csv if it's available because ...

I think that's doable.

After upgrading from version 245 to 270, I tried renaming my Blue Raven again from 'Rocket Name' to 'kjh_01' and when I did that, the Android App always downloaded a bogus set of flight data at boot as I reported last fall.

When you change the name, i would expect the app to download the latest flight, since it might be hearing from a second Blue Raven that was in the same flight. But that should only happen once. Does it continue to happen for you after the first time? If so, does it still happen, even after you run a new simulation with the new name?

 

[kjhambrick]

When you change the name, i would expect the app to download the latest flight, since it might be hearing from a second Blue Raven that was in the same flight. But that should only happen once. Does it continue to happen for you after the first time? If so, does it still happen, even after you run a new simulation with the new name?

Yes it does download a bogus file more than once when the Blue Raven is booted and the App is restarted.

I deleted several bad files from the flights dialog this morning after I renamed Blue Raven s/n 0236 from kjh-01 back to "Rocket Name"

All I saved is one of each bad file. This is a screen shot from my Samsung:

Note that the "Rocket Name" file at 01:52:29 was preceeded by one good file for kjh-01 and then the two files at 01:52:29 were followed by a couple more "Rocket Name" files.

All the bad files had the same timestamp ( 01:52:29 ).

The Android App would go into Download mode immediately after I booted the Blue Raven via the Mag Switch on my Featherweight 29mm Av-Bay until I renamed my Blue Raven "Rocket Name"

Each set of downloads takes 5 min or so on my phone so I didn't let it go too long before I 'unnamed' my Blue Raven from "kjh_01" back to "Rocket Name" and the downloads stopped on boot.

I didn't think to save all the flights !

I can set up a test later today and send a screen shot of the flight dialog showing all the flights

Would it be useful to attach example Summary, Low_Rate and High_Rate files for the bad files ?

Thanks again Adrian !

-- kjh

EDIT: these are pages from my Rocket Notebook for today.


I can see where I renamed the Blue Raven on Page 2 at 01:52.

The App re-downloaded the bad files 5-times until I renamed the Blue Raven as "Rocket Name" at 02:30 on Page 3

 

[Adrian A]

Thanks for taking the time to try this out and document.

I haven't been able to recreate this problem on my Android. I renamed a Blue Raven and power cycled it, and there was no attempt to re-download flights that were already there.

I ran a simulation with the new name and downloaded the data, then changed the Blue Raven name and power cycled it. The simulated flight data was not re-downloaded. I commanded the app to "forget" that Blue Raven, and then when it re-connected, it did download the flight again since the names no longer matched and the app no longer knew the relationship with the Bluetooth address.

I'm guessing that the issue you're having might have to do with older data that was stored on the phone. I would recommend for you to export any data you want to keep long-term and then delete and re-install the app, which will wipe away all the old flights. Not everyone will have to do this, but it might help you with the situation you have run into.

There might be something special about using "Rocket name" since that's the default name when a unit is first programmed. I would rename the Blue Raven to what you want, then delete and re-install the app and let me know if you're still having a problem with re-downloading flights.

 

[kjhambrick]

Thanks Adrian !

I've got a three new Blue Ravens scheduled for Monday delivery ( Thanks $1M for the new discount program )

I am thinking it will be important to set them up with unique names so I can identify rockets and flights.

I've decided to dedicate specific Blue Ravens to my Power Perch and to my working Featherweight 29mm and 38mm Av-Bays.

I'll probably go with Av-Bay Names because my 29mm Av-Bay fits in two, maybe three rockets, my 38mm can fly in two rockets and the Power Perch already flies in two rockets.

I'll delete all my old files and try naming my Blue Ravens and let you know later next week after I test the two Av-Bays and the Power Perch with dedicated Blue Ravens.

Thanks for taking time to look at this oddity ( not really a problem unless I rename Blue Raven S/N 0236 )

And OBTW ... if you ever hear of a working 24mm Featherweight Av-Bay looking for a new home, I'll have a 'spare' Blue Raven and I've already got a 24 mm coupler ready to fly in a 24mm min diameter Rocket

-- kjh

 

[Cooperr]

I'm having a very buggy experience with deployment settings in the Android app. I will select a channel, save settings to the altimeter, and come back to find it changed. Sometimes it appears to show me as editing one channel but will save the settings to another, so settings keep getting written and overwritten in the wrong channels. Any recommendations?

Edit: Another issue is in the main menu when I have an altimeter connected, tapping on a channel often opens the wrong channel. Seems like the actual buttons are shifted over to the left compared to the icons, like if I click on Main or 3rd in this screenshot it's opening 4th.

 

[Adrian A]

I'm having a very buggy experience with deployment settings in the Android app. I will select a channel, save settings to the altimeter, and come back to find it changed. Sometimes it appears to show me as editing one channel but will save the settings to another, so settings keep getting written and overwritten in the wrong channels. Any recommendations?

Edit: Another issue is in the main menu when I have an altimeter connected, tapping on a channel often opens the wrong channel. Seems like the actual buttons are shifted over to the left compared to the icons, like if I click on Main or 3rd in this screenshot it's opening 4th.

This is a problem that cropped up in the last build that we released, and we have been working on fixing it this week. The fix got done this morning and I tested and pushed it this afternoon. The fixed build 278 is available through TestFlight and Firebase, and it should be available through the Apple App Store soon if it’s not already. It should be available through Google Play soon.

 

[kjhambrick]

Thanks Adrian !

I received an email notification from the Firebase App Distribution last night and I've updated Blue Raven S/N 0236 to build 278 / fd31408.

I've done one simple Sim so far and everything looks fine !

-- kjh

 

[Cooperr]

This is a problem that cropped up in the last build that we released, and we have been working on fixing it this week. The fix got done this morning and I tested and pushed it this afternoon. The fixed build 278 is available through TestFlight and Firebase, and it should be available through the Apple App Store soon if it’s not already. It should be available through Google Play soon.

Great to hear, just installed it.