Featherweight Blue Raven Development Thread: Deployment logic

[dvdsnyd]

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.

Thanks for the update Adrian. Hoping to hear how your flights went over the weekend!
Dave

 

[Adrian A]

Thanks for the update Adrian. Hoping to hear how your flights went over the weekend!
Dave

I ended up posting over in the inertial navigation thread. Another set of flight tests on Saturday.

 

[Adrian A]

Development status update:

The pre-production panel of 10 units was successful, with no hardware or parts changes required.

A production test fixture PCB that will enable programming and calibration of a panel of 10 units should be ready for me to populate by early next week.

The assembly of the first production run of 240 units is scheduled in the assembler's queue with expected completion (if there are no problems or delays) around December 20.

I'll be unavailable between Dec 23 and Jan 2, and while it's just barely possible I could have a few units of hardware calibrated and tested this year, the real schedule driver is software.

The embedded software on the board that does all of the sensing, calculating, logging, deployments, and data downloading is basically done for the USB serial interface. There are a last couple of tweaks I'm going to make and test this weekend. What's barely started though, is the Bluetooth interface. The first Bluetooth capability I'm focused on is the over-the-air firmware updates. My app developer has successfully implemented over-the-air firmware updates on our own iOS and Android apps using development boards and example embedded software. I'm hoping to be able to merge that capability from the examples to my own Blue Raven code base this week or next week. When that is eventually successful, we could conceivably make the Blue Raven available to users who are happy to use a command line interface over USB serial, can live with default deployment settings, and who would initially just use the Bluetooth for firmware updates from an Android or iOS testflight-based app. That "eventually successful" point could be next week or it could be early next year, because I'm still pretty far down on the learning curve for this part of it. The phone app capability and the Blue Raven features accessible by phone will get added piece by piece after that going into next year.

 

[majordude]

The embedded software on the board that does all of the sensing, calculating, logging, deployments, and data downloading is basically done for the USB serial interface.

USB C?

 

[Adrian A]

USB C?

Micro-B.

 

[Adrian A]

Back on the topic of deployment logic, I have been spending some time on the backup main check for excessive descent rate. Based on my recent flight test data, including a big av-bay pressure leak of the apogee charge, I think I have the check pretty reliable, and I'll verify it this with more flights this weekend. But as I was trying a high-altitude simulated flight, I ran into the problem that at high altitudes, the air density is low enough to make the drogueless descent velocity significantly higher. For very high flights it could be quite high indeed. But with the density lower, a higher speed deployment of the main would be survivable because of the lower dynamic pressure and forces. So it occurred to me that I should have the Blue Raven dynamically compensate the threshold for this check based on the measured barometric pressure, which is a reasonably close stand-in for density. As a user, you could still specify a max descent velocity based on your near-sea level expectations for how fast your rocket will come down on the drogue, and how fast it can be going without damage, when it deploys the main. Let's say -200 feet/second, based on an expected drogueless descent velocity of -125 feet/second. At 32,000 feet, the air is about 1/4 the density, so with the aerodynamic drag proportional to V^2, the compensated velocity threshold would be divided by the square root of the density, and the Blue Raven would use 400 feet/second instead.

 

[GrouchoDuke]

But as I was trying a high-altitude simulated flight, I ran into the problem that at high altitudes, the air density is low enough to make the drogueless descent velocity significantly higher.

Yep, do that check based on q instead of descent rate & you should be good to go. Standard atmosphere table to approximate density based on pressure. (For others in the future, don’t use temp from your baro sensor for anything just in case that’s tempting.)

 

[cerving]

Yep, do that check based on q instead of descent rate & you should be good to go. Standard atmosphere table to approximate density based on pressure. (For others in the future, don’t use temp from your baro sensor for anything just in case that’s tempting.)

Yup, the temperature sensors in the baro's are only good in relation to themselves they're not very responsive or sensitive, certainly not enough for an accurate delta temperature going from ground level to several miles in 60 seconds or less. For calculating AGL altitudes it's OK because the error is going to wash out, more or less.

 

[Adrian A]

I think it's not so much the sensitivity or responsiveness, which I find excellent; it's just that it's measuring the board temperature inside the av-bay and has no way to measure the ambient air temp outside the rocket.

For the purpose of this compensation, it's easiest for me to just use the pressure, since it's already available without any other calculation, and the density ratio follows along pretty closely with the pressure ratio even ignoring the temperature:

 

[GrouchoDuke]

I think it's not so much the sensitivity or responsiveness, which I find excellent; it's just that it's measuring the board temperature inside the av-bay and has no way to measure the ambient air temp outside the rocket.

Yep, totally agree. With a cool-looking carbon fiber rocket baking in the desert sun for 30+ minutes before launch, that PCB-mounted temp sensor doesn't stand a chance of being accurate.

Since we don't have density sensors, using pressure with an assumed temp profile to calculate density is the best way I can think of to approximate q...which is what should work best for scheduling events & limits against for subsonic recovery descents (instead of just airspeed).

 

[Adrian A]

Development status update: My assembly vendor delivered the first production run early, so the hardware is for sure not the pacing item.

The programming/test board was delivered, and I have done about half of the assembly for it when I'm taking a break from firmware development. I still need to write most of the test fixture software

On the firmware front, I have been working long hours in the last 3 weeks, focused entirely on getting Bluetooth working. So far there are just baby steps to show for it. The good news is that I have my own code base now that can do over-the-air firmware updates using the Featherweight phone app on Android and iOS. The bad news is that I haven't integrated this capability with the rest of the Blue Raven functionality yet, and the first part of it that I tried has run into a serious stumbling block.

Using the USB interface (which has been the basis for all my development flight testing so far) might turn out to be mutually-exclusive with using the BLE functions when using the chip vendor's drivers. Searching the support forums, I found other users have run into the same problem. I have a support ticket opened but it's unclear when if ever this problem will be solved. In the meantime I will work on integrating the rest of the Blue Raven functionality into the new Bluetooth framework.

In the long run, the USB interface has always been optional; from the start of this project, the Blue Raven is intended to use the Bluetooth phone interface to do everything the user needs. But in the short term this puts a stumbling block in my plans to make available some beta test units to users comfortable with a command line interface while the Bluetooth phone interface progresses. I may want to put in a temporary capability to use a Bluetooth command to turn the Bluetooth off, and then have a USB command that can turn the Bluetooth back on. (or just power cycle). I'll be mulling this over while I try to make progress in other areas and I wait for the vendor support to get back to me.

 

[manixFan]

Hmm, not sure I would have seen that coming. One of the joys of hardware development.

I don't recall if you have a programming button on the BR. If so, could you use that to toggle between the BLE/USB interfaces? Otherwise, I like the idea of having the unit power up in BLE mode and then requiring a command to flip it to USB seems (only one command, and default is BLE, which makes sense for the unit).

As is typical for these sorts of projects, two steps forward and one step back! Good luck resolving the issue and thanks for the update.


Tony

 

[TonyL]

Hi Adrian,
seems like a USB back door is desirable so that a pcb does not become a brick from a Bluetooth issue. If you could detect the USB connection to turn off the Bluetooth and default back when it is disconnected, that seems the most transparent [and idiot resistant]?

br/

the other Tony

 

[Adrian A]

Hi Adrian,
seems like a USB back door is desirable so that a pcb does not become a brick from a Bluetooth issue. If you could detect the USB connection to turn off the Bluetooth and default back when it is disconnected, that seems the most transparent [and idiot resistant]?

br/

the other Tony

That's a great idea. I'm not sure what it would take to detect the USB connection that way, but it's worth looking into.

 

[jbr]

so how is the android tracker software coming?
I know many are waiting to buy trackers and have android

 

[Adrian A]

so how is the android tracker software coming?
I know many are waiting to buy trackers and have android

I'm focused on getting the Blue Raven and its phone app (iOS and Android) done. Then adding tracker functionality to the new app is next on the to-do list, which I will be sometime next year.

In the meantime, for those who don't already know this, a used iPhone costs about $100 on eBay, and can be used without a cellular data plan for rocketry tracking.

 

[Adrian A]

My kids and I took a long-postponed trip over the holidays, and this week I’ve been catching up on orders and recovering from some fierce jet lag. In the meantime, my chip vendor customer support actually got back to me and has offered to create a full source code example that runs the USB and BLE concurrently on their development board. Not sure how long that will take, but I’m grateful for the help and I have plenty to do while they are working on that.

Where I left off before the trip, I was running into problems running the debugger on my own BLE application after making the low-level modifications necessary for it be updatable over the air. I’m having to modify and troubleshoot the linker and startup scripts, which I’ve never needed to do before. Two steps forward, 1.9 steps back.

 

[Adrian A]

I have some progress to report tonight. The chip vendor helpfully got back to me with a new embedded software example that runs Bluetooth and USB concurrently. I have been gradually adding the rest of my existing Blue Raven software into that example, and although I haven't gotten very far on that yet, it looks compatible so far. I have my own real-time task sequencing running in parallel with the Bluetooth sequencing, and the timing margin looks good. I have a basic USB status function outputting while maintaining the Bluetooth connection. Over the next 1-2 weeks (if no major issues) I will be completing the movement of the existing flight code into this new framework and then making the modifications needed for over-the-air updates.

 

[Adrian A]

I have some progress to report tonight. The chip vendor helpfully got back to me with a new embedded software example that runs Bluetooth and USB concurrently. I have been gradually adding the rest of my existing Blue Raven software into that example, and although I haven't gotten very far on that yet, it looks compatible so far. I have my own real-time task sequencing running in parallel with the Bluetooth sequencing, and the timing margin looks good. I have a basic USB status function outputting while maintaining the Bluetooth connection. Over the next 1-2 weeks (if no major issues) I will be completing the movement of the existing flight code into this new framework and then making the modifications needed for over-the-air updates.

All of the flight functionality is moved over to the new project and there is only one minor migration-related fix I need to make. Running a simulated flight while the Blue Raven is connected to the phone over Bluetooth is working well.

However, the example provided by the chip vendor support team hangs on an unhandled interrupt if it runs 16.0 seconds without having a Bluetooth connection. This is very repeatable on the un-modified example and I hope/expect the support team should be able to help me fix it within a few days.

The other near-term hurdle is to do the modifications to this project to enable over-the-air firmware updates. I'll probably start on that again tomorrow. This might require more vendor support, based on my experiences trying to do this for other example programs in December.

Once those two hurdles are cleared, I plan to do two things in parallel: 1. Work with my app developer to start connecting the hardware to the app via Bluetooth. Due to a holiday he will be taking at the end of January, this will hopefully start early February. 2. Open up a limited beta test program for people who are comfortable using a serial command line interface to work with the hardware, and who are fine using default deployment configurations.

 

[kjs]

Adrian - Good to hear the progress, Sorry to hear the troubles, And fully aware that I totally didn't have the bandwidth to have been able to contribute...!

Best wishes and I'd still like an early unit to work with when you get a chance!!

 

[Adrian A]

The two hurdles I mentioned in post # 109 have been overcome. I have verified that I can use the Featherweight Blue Raven phone app to connect to the Blue Raven over Bluetooth, command it to load and run a different version of the firmware, and then use that firmware to load and run a new version. All with USB and the rest of the Blue Raven functionality working! Everything else from here is just low-risk development that my app developer and I can handle by ourselves. I've been worrying about getting to this point for about a year now. Somehow I'm still nervous.

I'm going to start writing a guide to the USB interface that my developer and intrepid beta testers will be able to use.

 

[Adrian A]

I started on the USB guide and then realized I really need to have a fairly complete user's manual available for beta testers before they get their units, and then have an appendix for the USB interface parts. I'm maybe halfway done.

Currently I'm working on the production test fixture and its software. The goal is to be able to program, calibrate and test 10 units at a time, unattended, while recording dozens of data points for each unit. I figured out some missing pieces about how it can be done, so I'm more confident it's possible for it to meet the goal, but there is a ton of work to get there. When it's done, I can have someone else process the boards from the assembler output to being ready to ship, and >100 per day would be possible.

 

[rfjustin]

I started on the USB guide and then realized I really need to have a fairly complete user's manual available for beta testers before they get their units, and then have an appendix for the USB interface parts. I'm maybe halfway done.

Currently I'm working on the production test fixture and its software. The goal is to be able to program, calibrate and test 10 units at a time, unattended, while recording dozens of data points for each unit. I figured out some missing pieces about how it can be done, so I'm more confident it's possible for it to meet the goal, but there is a ton of work to get there. When it's done, I can have someone else process the boards from the assembler output to being ready to ship, and >100 per day would be possible.

How are you set for Beta testers? I've got (2) two stagers eager to help....

 

[Adrian A]

How are you set for Beta testers? I've got (2) two stagers eager to help....

I need to refresh my list since it has been quite a while since I last asked for people interested.

Once I get far enough in my production test fixture to be sure I don’t need to re-spin the board, I’ll switch back to working on the manual. Then a little more code cleanup and double-checking that the app can be updated remotely and I can open up the beta testing. So hopefully within about 2 weeks or so.

 

[Adrian A]

Development status update:
The following on-board functions are complete:

• Measure and record 3-axis acceleration +/-400 Gs and at high resolution +/- 32 Gs, with 500 samples/second
• Measure and record 3-axis gyro rates up to +/- 2000 degrees second, at 500 samples per second
• Convert gyro rates to rocket quaternion attitude at 500 samples/second, and record
• Calculate and record rocket tilt angle, roll rotations, and predicted tilt angle + 3 seconds
• Inertial navigation: Combine 3-axis gyro and acceleration measurements to calculate and record velocity and position in 3 dimensions
• Measure and record barometric pressure and temperature at 50 samples/second
• Use the above measurements to control 4 output channels based on up to 20 independent criteria, with 11 user-settable thresholds for each of the 4 channels, including advanced options such as rocket tilt, predicted tilt, burnout counters, apogee deployment failure detection, and primary and backup deployment logic for each channel.
• Measure and record battery voltage, total deployment current, and voltage of each of the 4 output channels at 50 Hz
• Produce a flight summary that includes not only basic metrics such as maximum altitude and speed, but also advanced metrics like horizontal velocity at deployment, boost tilt efficiency, velocity at main chute deployment
• A realistic simulated flight capability that handles multi-stage flights and allows simulated events like motor ignition or main chute deployment to be connected to each output channel's actual output during the simulated flight so that the deployment channel settings can be verified pre-flight with high confidence.
• USB micro serial interface for running the simulation, watching live measurement status, downloading all data, performing accel calibrations, and limited access to pre-canned deployment options
• Beeping of battery voltage and deployment channel continuity, 3 LEDs for Bluetooth status, recording status, and flight readiness status

Planned on-board feature improvements via software update:

• Current limiting on each output channel so that arbitrarily large batteries can be used safely
• Preserve data recording in the event of a power interruption mid-flight
• Select a separate aux analog channel for recording at 500 Hz
• (longer term) On-board Bluetooth connection to current or future Featherweight GPS trackers for GPS/inertial data fusion and long-range reporting of Blue Raven data

The following Bluetooth interface features are complete:

• Connection over Bluetooth to a custom app running on iOS and Android
• Over-the-air updates to embedded software on the board

Planned Bluetooth interface and phone app capability is work, in this approximate order:

• Use the local time from the phone in recorded data
• Simplified interface to set up common deployment settings for primary/backup apogee deploy, primary/backup main deploy, 2nd stage ignition, etc with pre-filled logic and key adjustable thresholds
• Accessibility to all deployment options via "custom" view
• Live data "flight ready GO board" that shows sensor health and deployment channel continuity and allows channels to be armed or disarmed
• Flight simulation interface that lets the user select the number of stages, acceleration and duration of motors, etc, and initiates a simulated flight
• Automatic download and display of flight summary data as soon as the user approaches the rocket for retrieval

(The Blue Raven will go on sale when the interface features above are complete, while working on the following via over-the-air software updates) :

• Flight log to store and retrieve data from any previous flight
• Remote deployment charge test interface
• Automatic download of 500 Hz and 50 Hz flight data as soon as the user approaches the rocket for retrieval
• Sharing of recorded data via phone applications like email, cloud file storage etc.
• On-screen plotting of a selectable subset of all measurements
• Other features that I've forgotten or as requested

The price of the Blue Raven will be $175 when it goes on sale. The beta test program has started, with the Blue Raven available at a discount in exchange for feedback on existing features and documentation before the full feature set is available. Send me a private message if you would like the link to order a beta test unit.

 

[SolarYellow]

Just because I'm too lazy to go back and read everything, this will be the same form factor as Raven 4 and work with your existing 24mm AV bay kits, right?

 

[Adrian A]

Just because I'm too lazy to go back and read everything, this will be the same form factor as Raven 4 and work with your existing 24mm AV bay kits, right?

Yes, it has the same outer dimensions (0.8" x 1.8"), mounting hole locations, and connector pinout as the Raven4, so it is 100% compatible with all Raven installation accessories, like the Power Perch, Featherweight minimum diameter av-bays, etc. Also, with its rounded corners and ability to be launched in any orientation, it can work with a new Pancake av-bay accessory for flat-mounted installations I plan to release this year.

 

[SolarYellow]

Awesome! I'm not really ready to be a help beta testing, but I pho shizzle have plans for one (hopefully) of these little bad boys.

 

[Lamp]

I'm looking forward to getting a couple of these Adrian! I have the whole Raven series except the 4...(I never got around to getting one before they sold out).

Any idea on when the production run will be complete and they go on sale? I understand there are still things that need to be sorted out. I'm not in any great urgent rush, but I'm sure they will all be sold quickly.

 

[Adrian A]

Any idea on when the production run will be complete and they go on sale? I understand there are still things that need to be sorted out. I'm not in any great urgent rush, but I'm sure they will all be sold quickly.

The first 250 units were built in December and I have all the key parts for 750 more, so I should be able to avoid ever running out.

I don’t know how long it will take to complete the critical features of the phone app and add the Bluetooth services on the firmware side, since I’ve never done that before. I’d like to be ready by the end of February but it could take longer.

Thanks to the people who have contacted me for the beta testing. I’m pausing adding more people for now until I ship out the beta test orders that have already been placed. I’m trying to do in the next couple of days so they can arrive before the weekend.

My current focus is on the fixture for automated programming, testing and calibration that I’ll use in production. I could have manually tested and shipped some beta test units already, but I think it’s a better to spend a few days getting the automated system running on the beta units since that work is necessary before the start of production. Also this way the beta test units will be processed consistently.