Featherweight Blue Raven Development Thread: Deployment logic

[Adrian A]

Adrian, for use with Staging will this have a Tilt lock out so that if a certain angle or more is achieved in flight the second stage would not be fired? And would that tilt/angle be adjustable?

Yes, that's the plan, and included as part of the default settings for airstarts.

 

[phyzzld]

The Blue Raven will be capable of using Bluetooth to exchange information wirelessly during the flight with a separate GPS tracker that could be in another part of the rocket (e.g. the nosecone), and deliver it to your phone in real-time.

Does this mean that GPS based deployment is a possibility with the Blue Raven?

Jeff

 

[Adrian A]

Does this mean that GPS based deployment is a possibility with the Blue Raven?

Jeff

It could be in theory. But as of now, with all the inertial data that also available to the Blue Raven, the deployment choices are as discussed above. Is there a deployment logic condition you are interested in that you have in mind for GPS data?

 

[phyzzld]

It could be in theory. But as of now, with all the inertial data that also available to the Blue Raven, the deployment choices are as discussed above. Is there a deployment logic condition you are interested in that you have in mind for GPS data?

I was mainly thinking of situations where barometric could be a problem, such as high altitude or if the required altimeter placement is in a bad spot like the nose cone tip.

Jeff

 

[Adrian A]

I was mainly thinking of situations where barometric could be a problem, such as high altitude or if the required altimeter placement is in a bad spot like the nose cone tip.

Jeff

That makes sense.

My current plan for the default apogee detection is to recognize apogee after two of the following 3 conditions are true:

• Gyro-based attitude estimate detects that the rocket has pitched over >= 90 degrees
• Accelerometer-based vertical velocity estimate drops below zero
• Barometric pressure (when accel-based velocity is < 400 feet second) is increasing.

This should be tolerant to problematic baro pressure sensing or any single sensor failure.

 

[Rocket501]

That makes sense.

My current plan for the default apogee detection is to recognize apogee after two of the following 3 conditions are true:

• Gyro-based attitude estimate detects that the rocket has pitched over >= 90 degrees
• Accelerometer-based vertical velocity estimate drops below zero
• Barometric pressure (when accel-based velocity is < 400 feet second) is increasing.

This should be tolerant to problematic baro pressure sensing or any single sensor failure.

For the super-high altitude flights, it might also be nice to have an option for a timer-based apogee option.

Also, in the case that there should be a separate GPS module that can communicate with the Blue Raven, could please consider making a high-altitude one with the u-blox 9 (or other that can be similarly configured to work at up to 80km and extreme vertical velocities) so that combined with the blue raven, for space shots, this would provide a good way to get a fairly accurate estimate of apogee on rockets too small to carry something like a Kate altitude-unlocked gps.

 

[VernK]

Also, in the case that there should be a separate GPS module that can communicate with the Blue Raven, could please consider making a high-altitude one with the u-blox 9 (or other that can be similarly configured to work at up to 80km and extreme vertical velocities) so that combined with the blue raven, for space shots, this would provide a good way to get a fairly accurate estimate of apogee on rockets too small to carry something like a Kate altitude-unlocked gps.

By the way, although the ublox 9 does operate up to 80km (as advertised) it does NOT operate at the extreme vertical velocities that are mentioned in its datasheet. I have tested the ublox 9 and the velocity limits are exactly the same as the older ublox chips. When I asked ublox about it, they said the Kalman filter can operate to the extreme vertical velocities listed in the datasheet but actual velocity is still limited by the legal restrictions on consumer GPS units. (That's sure a strange way to write the data sheet. I find it very misleading!)

The ublox 9 is still a very nice GPS unit if you are staying under 80km but unfortunately, it is not a high speed GPS.

 

[Rocket501]

By the way, the ublox 9 does operate up to 80km (as advertised) but it does NOT operate at the extreme vertical velocities that are mentioned in its datasheet. I have tested the ublox 9 and the velocity limits are exactly the same as with older ublox chips. When I asked ublox about it, they said the Kalman filter can operate to the extreme vertical velocities listed in the datasheet but actual velocity is still limited by the legal restrictions on consumer GPS units. (That's sure a strange way to write the data sheet. I find it very misleading!)

The ublox 9 is still a nice GPS unit if you are staying under 80km but unfortunately, it is not a high speed GPS.

Extremely disappointing but thank you for letting me know. That is indeed very misleading and it is much better to find out like this than in an actual flight.

 

[Adrian A]

For the super-high altitude flights, it might also be nice to have an option for a timer-based apogee option.

Also, in the case that there should be a separate GPS module that can communicate with the Blue Raven, could please consider making a high-altitude one with the u-blox 9 (or other that can be similarly configured to work at up to 80km and extreme vertical velocities) so that combined with the blue raven, for space shots, this would provide a good way to get a fairly accurate estimate of apogee on rockets too small to carry something like a Kate altitude-unlocked gps.

Yes, timer-based is an option. You could also use any combination of the other flight events listed in the first post of this thread. The Blue Raven is also capable of having both a primary and backup deployment configuration available for each of the 4 channels, where either set of conditions can cause the output to fire. This could be useful to cover some off-nominal flights, for example if you'd like to fire the main early if the apogee charge was a dud or too small to make the deployment happen.

It will be a while before I make a new version of the Featherweight GPS tracker. In the meantime I'm focused on making the Blue Raven's inertial propagation as good as it can be. Given the sensor performance available now, I think it could potentially be comparable to GPS accuracy, at least until the first deployment. Later I will also work on working on incorporating data from the current Featherweight GPS into the Blue Raven's real-time estimates.

 

[Chad]

Is there any chance of open sourcing the firmware like AltusMetrum and some others do?

I helped out on the flightsketch mobile app a little bit. If you want any help bringing the GPS mobile app to Android or anything else drop me a PM. My time to spend on this stuff is wildly unpredictable but happy to lend a hand if you want one.

 

[cwbullet]

I appreciate meeting and having a discussion on the Blue Raven and trackers with you at Spaceport. Any plans to dust off the Sparow?

 

[thzero]

I appreciate meeting and having a discussion on the Blue Raven and trackers with you at Spaceport. Any plans to dust off the Sparow?

African or European?

 

[Adrian A]

Is there any chance of open sourcing the firmware like AltusMetrum and some others do?

I helped out on the flightsketch mobile app a little bit. If you want any help bringing the GPS mobile app to Android or anything else drop me a PM. My time to spend on this stuff is wildly unpredictable but happy to lend a hand if you want one.

Thanks for the offer. I don't think open-sourcing the firmware is something I want to do.

I appreciate meeting and having a discussion on the Blue Raven and trackers with you at Spaceport. Any plans to dust off the Sparow?

It was nice to meet you too. Not any time soon for the Sparrow. First up is finishing the Blue Raven. Then updating the Tracker and ground stations. After that (1 year+) I'll look closer at creating a lower-end device.

 

[Adrian A]

...Aaaaaand the Ravens are sold out. That was faster than expected. About 10 in the last week. I need to get going on that pre-production Blue Raven panel. Today the latest rev of the PCB should arrive for me to assemble a prototype.

 

[Adrian A]

Based on some discussion over in the airstart forum, I have updated the options for deployment criteria with airstarts in mind:

1. I added a nominal ascent check that goes persistently false if the tilt angle ever goes past a user threshold (default 60 degrees), even if it comes back around again later. This is to lock out an airstart if the flight goes really wrong and the rocket tumbles, but happens to point back upright again after skywriting.
2. I added a "future angle" that calculates how much the trajectory will bend over from gravity 3 seconds from the current time, and added a check for greater than this angle. This allows a strategy of "wait as long as you can but ignite before the angle gets too large." The estimation into the future is used to account for the fact that airstarted motors take some time to come up to pressure, with 3 seconds being a conservative approach. See the thread in the airstart section for more discussion and lots of graphs and analysis.

 

[Cameron Anderson]

Any info on release date or pre-ordering?

 

[Adrian A]

Any info on release date or pre-ordering?

A couple of weeks ago I verified and tuned the Bluetooth antenna implementation, and yesterday I sent out a panelized version of the board designs to get fabricated. Since it's a new design I'm going to have the assembler just assemble one panel of 10 units so I can check that out and work on my production calibration setup in November. The earliest that the first production run of hardware will be completed is mid-December. The good news is that I have all the parts I need for that. I hope to have the app released by then also, but there's a lot of uncertainty about how long that will take.

 

[Adrian A]

I have been doing some more flight testing, and have some data from a couple of flight that convinced me to change the criteria for the default backup main deployments. Due to rocket building and prepping errors on my part, in two flights on one day I had both a flight that had a premature backup main deployment, and a main deployment at the nominal time when an earlier backup main deployment would have come in handy.

First, the premature main flight. This was on a 54mm fiberglass test rocket that I set up to fly two Blue Raven prototypes and a GPS tracker, to gather more data on inertial navigation, since I could compare the data from all 3 units. I used an av-bay that I made for a team rocket with John Wilke and Warren Musselman a million years ago, that accommodates 2 Ravens across from each other in a 54mm av-bay:


(Ravens not shown in this view, but you can sorta see the header pins on each side where they go)
I may commercialize a 54mm av-bay like this in a few months after the Blue Raven is available. This particular version was made to clamp around a 54mm coupler that was slit and glued inside a regular-sized 54mm coupler. Unfortunately, the slit in this inner coupler allowed deployment charge gas to get in, which was compounded by having inadequate vent holes for the av-bay. The result was that the pressure transducers saw a huge pressure spike at apogee:



This next plot shows all the conditions that were checked for main deployment. I zoomed the time in to the first 20 seconds of the flight:



The solid lines are the primary deployment criteria: Liftoff detected and apogee detected and the apogee output fired and altitude < AGL_1 threshold (700 feet) and burnout count > 1. The apo fired criteria goes true 1.5 seconds from the initial signal to allow deployment charge transients to be done with. This works for the primary criteria, because the altitude check only goes (falsely) high for a brief moment when the apo charge fires, but the apo_fired check doesn't go true until after that pressure transient has passed. The backup criteria are in dashes: Liftoff and total velocity < VEL1 criteria (400 ft/sec) and baro velocity less than the BVEL criteria (-200 feet/sec). Here the baro velocity check got spoofed by the deployment charge transient, and because the velocity was already low, the backup charge fired. I thought about putting a filter on the baro velocity check, but it would add quite a bit of delay to something that's pretty time-critical, and it would have a hard time filtering out the biggest pressure spikes. Instead, I'm changing the default main backup settings to wait for the apogee charge to be fired before looking for descent rate too high.

Now for the second flight, I had my rocket named "Shot" to gather data on inertial navigation for higher-G, higher-velocity flights, flying on an ancient AT H125 single use motor:



Yes, the rail is intentionally angled away from the flight line, partly to collect data on flights that start out a little non-vertical. This rocket is also dual-deploy, with 1 Blue Raven prototype and a tracker in the nose. Unfortunately, I didn't use a Featherweight 29mm av-bay for this one, and instead used another homemade av-bay of mine that had a loose connection on the apogee charge. Here you can see the apogee continuity voltage dropping out during the flight:


The time when the apogee charge should have gone off was about 20.5 seconds. But no continuity, no deployment, so the rocket had a ballistic descent until the main chute deployed:


The tracker led me right to the nosecone containing the tracker, and the ripped parachute, with a broken shock cord. The rest of the rocket was nowhere to be found. At first I didn't think to look at the recorded tracker data that I downloaded to my phone in the field to see what the GPS coordinates were when the main deployed. But after I realized that when I woke up with a start one night, I went back to the field and the location of the chute deployment coordinates, and as soon as I took a few steps toward the coordinates where I recovered the nose cone, there was the forward body tube and part of the aft tube:


Note the impressive zipper of this fiberglass body tube. I'm impressed that the chute was that strong. The velocity at deployment was 430 feet/second:



This is the scenario that the backup main deployment was supposed to avoid. The problem can be seen again with the recorded flight events for the main deployment channel:


Again, the solid lines are the primary deployment criteria, and the main fired when the altitude got down below the AGL1 criteria of 700 feet. The backup main deployment (dashed lines) was supposed to go off when the baro velocity got lower than -200 feet/second, which happened around 26 seconds into the flight. But because of being concerned about mach effects spoofing the baro sensing, I also had a check for velocity < VEL1 criteria, and with this relatively horizontal flight, the velocity was too high except for a relatively short time around apogee, and it was too high when the baro velocity backup criteria became true. With the new criteria, where i use the apo_fired rather than velocity < vel1, the backup main deployment would have happened at a survivable velocity and the apo_fired check would have prevented it from being affected by any apogee charge transient events, etc.

Time for dinner!

 

[manixFan]

(Regarding post #78 just above):

So many sayings come into play here: "you can't make an omelet without breaking a few eggs", "we learn more from our failures than our successes", "if things are not failing you are not innovating", etc. It's really cool to get insight into your development process and to see the sausage being made - how failures lead to improvements. While it's unfortunate for you that your flights were 'sub-optimal', future users of the Blue Raven will surely benefit. Plus your analysis also shows the value of all the data that the Raven collects. It's one of the main reasons I like flying the it so much - all that data becomes very useful when things don't work out as planned.

Thanks for sharing the update and looking forward to hearing when production units are available.


Tony

 

[jry]

One thing to consider when devising the logic for apo_fired (to avoid pressure transients caused by deployment) is this: your firmware may not the source of the deployment, which can be true when another redundant flight computer is on board, and fires before the Raven.

 

[FredA]

One thing to consider when devising the logic for apo_fired (to avoid pressure transients caused by deployment) is this: your firmware may not the source of the deployment, which can be true when another redundant flight computer is on board, and fires before the Raven.

IMO, proof of resilience in this arena should be required for any intended for redundant usage. Fliers are forced [for L3 certs] to mix and match without any knowledge, let alone assurance, that they play nice together.

 

[Adrian A]

One thing to consider when devising the logic for apo_fired (to avoid pressure transients caused by deployment) is this: your firmware may not the source of the deployment, which can be true when another redundant flight computer is on board, and fires before the Raven.

Thanks for the feedback.

The apo_fired criteria is based on when the Blue Raven fires its apo channel. If another altimeter fires first and causes a pressure transient, the criteria for the Blue Raven's backup main would not be met because the Blue Raven hadn't fired yet. If the Blue Raven apogee channel fires first and then a different altimeter or another channel of the Raven fires and causes a pressure transient, the backup main logic could see that as excessive descent rate and fire. For the backup apogee charge to cause a pressure transient would almost certainly mean that the first charge was a dud, so the chances of these circumstances lining up are pretty low. But it does make me wonder if there is something I could do to make the descent rate criteria more immune to deployment pressure transients. I'll look into adding a persistence check to see if I can do that effectively without adding too much delay.

 

[cerving]

IMO, proof of resilience in this arena should be required for any intended for redundant usage. Fliers are forced [for L3 certs] to mix and match without any knowledge, let alone assurance, that they play nice together.

AFAIK, different altimeters are not a L3 cert requirement. It was not for mine...

In general, an altimeter's data download will show that "something" happened if another device fires a drogue charge first. That should not significantly affect the operation of the altimeter, however.

 

[SolarYellow]

Thanks for the feedback.

The apo_fired criteria is based on when the Blue Raven fires its apo channel. If another altimeter fires first and causes a pressure transient, the criteria for the Blue Raven's backup main would not be met because the Blue Raven hadn't fired yet. If the Blue Raven apogee channel fires first and then a different altimeter or another channel of the Raven fires and causes a pressure transient, the backup main logic could see that as excessive descent rate and fire. For the backup apogee charge to cause a pressure transient would almost certainly mean that the first charge was a dud, so the chances of these circumstances lining up are pretty low. But it does make me wonder if there is something I could do to make the descent rate criteria more immune to deployment pressure transients. I'll look into adding a persistence check to see if I can do that effectively without adding too much delay.

Maybe calculate a descent accel value? Might be able to implement it as simply a delta between running averages if that makes the math much easier.

If the descent rate appears to be changing at significantly greater than 1g plus reasonable accounting for drag after burnout, you could assume it doesn't reflect the actual descent rate.

 

[cwbullet]

AFAIK, different altimeters are not a L3 cert requirement. It was not for mine...

I looked at the rules and concur. Not a requirement but I have heard a couple taps suggest it. Sounds like a preference?

 

[FredA]

AFAIK, different altimeters are not a L3 cert requirement. It was not for mine...

I didn't say they were.
People pick altimeters without any knowledge of how TWO interact.
Two of the same, two different.
They all appear to be developed and tested as single entities yet our governing bodies want two in an ad hoc arrangement to play nice for an L3 cert....without testing or validating the configuration let alone verifying that was even a design criteria.

Designed for single use - used in [random] pairs - without testing said pairs

 

[cerving]

Tripoli has made it clear that they are not going to regulate electronics beyond what is in the unified HPR code. AFAIK, any two deployment altimeters should be fine together... deployment algorithms are all pretty similar. We've seen this similar-different argument before... two identical altimeters could fail identically, but two dissimilar ones "could" have a bug that makes them incompatible. Take your pick... they're both extremely unlikely, especially compared to the mechanical things that could go wrong with a deployment (undersized charges, stuck couplers, stuck chutes, snapped shock cords, etc. etc. etc.)

 

[Adrian A]

Minor status updates: My surface mount assembly vendor expects to ship the first production pathfinder panel of 10 units on the 15th. I hope to have my production calibration fixture mostly operational by then so I can evaluate the first 10 units for hardware errors. If there aren't any problems the next 240 units will get built after that.

I'm still doing some minor tweaks of the embedded software based on flight tests, and I'm getting ready to fly a prototype again tomorrow on a new 29mm test rocket with a 32G flight followed by a 133G flight, if the wind cooperates and I don't screw up the deployment charges again.

My phone app developer has the new Featherweight phone app performing over-the-air embedded software updates on a vendor development board. Integrating Bluetooth software with the rest of the Blue Raven embedded software is my last big software task after getting the production test/cal fixture running. I have verified and tuned the Bluetooth hardware performance on the Blue Ravens using test code. Once the production hardware is done (probably not the schedule driver) and I get Bluetooth running with the rest of the Blue Raven software (a big step), and Blue Raven over-the-air firmware updates are working with the phone app (another big step), then I can start thinking about letting Beta testers get started with serial commands/data over USB while we work on the phone app and the rest of the Bluetooth functions.

 

[Cameron Anderson]

Minor status updates: My surface mount assembly vendor expects to ship the first production pathfinder panel of 10 units on the 15th. I hope to have my production calibration fixture mostly operational by then so I can evaluate the first 10 units for hardware errors. If there aren't any problems the next 240 units will get built after that.

I'm still doing some minor tweaks of the embedded software based on flight tests, and I'm getting ready to fly a prototype again tomorrow on a new 29mm test rocket with a 32G flight followed by a 133G flight, if the wind cooperates and I don't screw up the deployment charges again.

My phone app developer has the new Featherweight phone app performing over-the-air embedded software updates on a vendor development board. Integrating Bluetooth software with the rest of the Blue Raven embedded software is my last big software task after getting the production test/cal fixture running. I have verified and tuned the Bluetooth hardware performance on the Blue Ravens using test code. Once the production hardware is done (probably not the schedule driver) and I get Bluetooth running with the rest of the Blue Raven software (a big step), and Blue Raven over-the-air firmware updates are working with the phone app (another big step), then I can start thinking about letting Beta testers get started with serial commands/data over USB while we work on the phone app and the rest of the Bluetooth functions.

Beta tester...this guy, right here!

 

[rocketace]

If there aren't any problems the next 240 units will get built after that.

So....When can we preorder This will be so much easier to make my 2-stage 54mm with redundant electronics. Current set up is a Raven4, Tiltometer3, and wifi-switch.... This would turn 3 units with their own batteries and switches into 1.