The "Salus" Flight Computer

[wetmelon]

So some time ago, I spoke with a friend of mine and he expressed a need for an inexpensive flight computer that could handle his Level 3 rockets. We came up with a list of features, and since then I've worked on building a flight computer that can handle everything he wants to throw at it. Right now we have:

• GPS
• +/- 200g 3-axis accelerometer
• 9-axis IMU with auto-calibrating Kalman filter (+/- 16g 3-axis accel, 3-axis Gyro, 3-axis compass)
• High accuracy, temperature-compensated barometer capable of reading 10mbar (0.145 psi), or ~ 85,000 ft
• 3x Isolated (optional 2nd battery), configurable, high-power outputs for flight events (deployment, staging)
• 4x BEC-powered servo outputs for GNC
• 6-pin Serial output for radio telemetry (With CTS, RTS)
• SD Card Logging
• Beeper/Buzzer
• Battery voltage measurement
• Capable of running on any battery > 7v, up to 16v.
• 32-bit ARM core processor running at 96 MHz
• Arduino compatible
• Fits in a 38mm body tube

The loop runs at 100hz at the moment, primarily due to some nasty undocumented performance issues with the particular IMU I chose. Future plans include a potential upgrade of the processor to one with a floating point unit, replacement of the 9-axis IMU, replacement of the 200g analog accelerometer for a digital +/- 600g accelerometer, possible integrated 933Mhz radio, possible removal of the servo outputs, higher update rate (200hz minimum), integration of GPS and Barometer data into the Kalman filter solution, possible upgrade to a special chip that offloads the EKF processing (currently not on the market, but I can get samples). Also I want to tweak the power rails a bit, likely moving to an SMPS with higher efficiency and wider input range to allow any battery you can think of. Oh, and once it's finalized, it'll be going open-source.

Anywho, just though y'all would be interested in the project. I really want to have the new version up and running ASAP, but I don't know that I can do anything with it before summer, what with school and school-related projects So we'll see.

 

[dhbarr]

How large? I keep hoping someone will jam a ublox onto a femtobeacon to achieve a healthy subset of this, but in a tiny formfactor.

 

[wetmelon]

It's small, but not quite that small. It's about 33mm x 105mm (1.3" x 4.05") right now. I could shrink that a lot by getting rid of the deployment / staging headers and by moving to machine PnP instead of hand-placed + heat-gun. Mounting holes are 1" x 3.75" apart and they're essentially in the corners of the board. It's focused on HPR 38mm or larger, whereas other products like Raven already fill the lower end functionality in a smaller footprint.

 

[dhbarr]

It's small, but not quite that small. It's about 33mm x 105mm right now. I could shrink that a lot by getting rid of the deployment / staging headers and by moving to machine PnP instead of hand-placed + heat-gun. Mounting holes are 1" x 3.75" apart and they're essentially in the corners of the board. It's focused on HPR 38mm or larger, whereas other products like Raven already fill the lower end functionality in a smaller footprint.

GPS, TX, accelerometer, barometer in ~12mm is the holy grail.... Maybe as phone SOCs continue to pack it all in something obvious and inevitable will happen in the 2g range.

 

[VernK]

... replacement of the 200g analog accelerometer for a digital +/- 600g accelerometer, ...

I can understand changing from analog to digital but why do you want a 600g accelerometer? Seems like it would be sacrificing resolution.

 

[wetmelon]

I can understand changing from analog to digital but why do you want a 600g accelerometer? Seems like it would be sacrificing resolution.

Yeah, you sacrifice resolution in general, but the part is significantly better in essentially every other way, and is sensitive to 49 mg/bit, which should be sufficient. Keep in mind, I also have a low-g, high precision accelerometer on board.

I double checked the datasheet for the sensitivity, and realized and it's a 400g accel not 600. It's also user-selectable for 400, 200, or 100g. For most rockets you can probably run it at +/- 100g and be fine, but there's a couple (like the one my friend is building) that would benefit from the extra range available with 400g.

 

[NateLowrie]

Can we get some pics of the board? Personally, while 38mm is nice I would rather see it in a 54mm or 75mm form factor with less length. If really want to get the form factor down, Pick and Place with a smaller part factor like 0402 would be a start, though eventually I would think you want to move most of it to an FPGA to achieve real form factor reduction.

Regarding the IMU: 16g is a bit low for some of the more high performance rocket flights. Would have liked to see 25g or 40g.

Lastly, what do you mean when you mention Ardunio compatibility?

 

[wetmelon]

I've been debating giving out pictures & more detail on the board because it's not really "done", but hey who cares haha.

Both the high g and low g accels will be used in the sensor fusion - you'll lose resolution above 16g but it'll be aight.

It's fully Arduino compatible because it runs on a Teensy 3.2. I've been thinking of going to a Teensy 3.5 or 3.6, but haven't decided if it's worth it. I doubt I'd go to an FPGA, simply because I want it to be open-source and easy for people to modify in the future. Verilog is great and all, but there's a pretty small subset of people who want to write HDLs. Plus then you end up with proprietary hardware and software, all sorts of nightmares there.

Pictures: https://imgur.com/a/HSw6Q

 

[ksaves2]

Very impressive pictures. Kurt

 

[NateLowrie]

I've been debating giving out pictures & more detail on the board because it's not really "done", but hey who cares haha.

Both the high g and low g accels will be used in the sensor fusion - you'll lose resolution above 16g but it'll be aight.

It's fully Arduino compatible because it runs on a Teensy 3.2. I've been thinking of going to a Teensy 3.5 or 3.6, but haven't decided if it's worth it. I doubt I'd go to an FPGA, simply because I want it to be open-source and easy for people to modify in the future. Verilog is great and all, but there's a pretty small subset of people who want to write HDLs. Plus then you end up with proprietary hardware and software, all sorts of nightmares there.

Pictures: https://imgur.com/a/HSw6Q

I am confused on your statement regarding the sensor resolution. If the IMU has a 16g range, when the rocket goes 25g the IMU will read 16g right? If so, won't that invalidate the acceleration portion of the IMU data? Or are you saying you will fuse the larger range accelerometer data to compensate for that?

I agree with you on the FPGA. You trade a lot for what you gain. But boy can you make it tiny. Since you want to keep it open source and accessible to most people it makes sense to not use it.

The board looks good but there is definitely room to shrink everything down. Here's a list of suggestions:

• You should definitely ditch the screw terminals and just provide through holes or pads for wire soldering. Should be able to shorten that section quite a bit.
• Why are you using such a large buzzer?
• Though harder to do, integrating the Teensy 3.2 components on the board instead of using the daughter board will save a lot of room on the top and bottom because you can eliminate the header and have more freedom with the component placement.
• Why do you have the SD card? Is it to log all the IMU data? I see you put the pads in for a SOIC 8 flash chip that wasn't populated. I am just wondering if you need all the space the SD card provides?

Since this is open source, do you have a repo for this yet? I would like to download it and help with development. Beyond making it smaller, what is still remaining as far as development and testing go?

 

[cerving]

There is definitely a place for two accelerometers on a board like this. Most low-medium accels nowadays are 3-axis, the z-axis is good for doing launch detects, while a separate single-axis high-G accel is good for logging performance data. 200G is probably overkill, let alone 400G... 100G is the Holy Grail for acceleration junkies. It basically takes a flying motor case to get there.

 

[wetmelon]

I am confused on your statement regarding the sensor resolution. If the IMU has a 16g range, when the rocket goes 25g the IMU will read 16g right? If so, won't that invalidate the acceleration portion of the IMU data? Or are you saying you will fuse the larger range accelerometer data to compensate for that?

The GPS, low g accel, and high g accel will all be used at low acceleration values. At higher values (i'm thinking > 15g), I'll remove the influence of the low g accelerometer on the observer. The GPS and high G can still be used (maybe, GPS can also have issues with high acceleration levels).

The board looks good but there is definitely room to shrink everything down. Here's a list of suggestions:

• You should definitely ditch the screw terminals and just provide through holes or pads for wire soldering. Should be able to shorten that section quite a bit.
• Why are you using such a large buzzer?
• Though harder to do, integrating the Teensy 3.2 components on the board instead of using the daughter board will save a lot of room on the top and bottom because you can eliminate the header and have more freedom with the component placement.
• Why do you have the SD card? Is it to log all the IMU data? I see you put the pads in for a SOIC 8 flash chip that wasn't populated. I am just wondering if you need all the space the SD card provides?

• Yeah, I think I'll do that for the more permanent version.
• It's a really loud buzzer.
• I considered this, but it about doubles the cost of the Teensy, and means I have to do a lot more placing of small QFNs or BGAs. Wasn't worth it for the prototypes, at least.
• Originally, and I may still consider this for the future, the SD card was actually planned to be used to configure the device. Instead of having to plug the device in, you could just get the SD card and it would load a configuration file from there, instead of storing everything in EEPROM or whatever. I put the SPI Flash memory on board for high speed data logging, but screwed up the footprint and shorted SPI CLK to +5v, which ruins the SD card communication, so I had to remove it. Right now the SD card is doing the logging. At 100hz, it takes 200 microseconds to save 512 bytes of data. So I only need to log every 4th or 5th loop, or at about 20hz. I'm not sure if I'll keep using the flash memory given the write speed and size of the SD cards, tbh. The data is logged as packed binary, and I wrote a python script that parses the binary data out into a CSV.

Since this is open source, do you have a repo for this yet? I would like to download it and help with development. Beyond making it smaller, what is still remaining as far as development and testing go?

I have a CODE repo, but not a hardware repo for it yet. I'll warn you, the code is pretty bad. I couldn't decide at first between a heavily C++ oriented approach or a C oriented one. I've since gravitated towards C, but much of the functionality is still C++ OOP oriented. Even then, it's got global variables and junk everywhere and suffers from some "God Object" issues. I've been using Visual Studio with the Visual Micro plugin for programming, so there's .sln's and .vxproj's and whatnot in there too.

There's only two states - "Waiting for Launch" and "Flight". Although the BNO-055 runs its own Kalman Filter that makes getting quaternian output at 100hz trivial, it also has no "Data Ready" interrrupt and clock stretches like a mofo, so it can take up to 6700ms to read all of the relevant data. That leaves very little time to run a separate Kalman filter to fuse the GPS, barometer, and high-g accelerometer data. It will need to be replaced with something like an MPU-9250 with proper interrupt support if we want to make a decent altimeter.

I'm about to finish the last task before sending it to my friend for flight testing: non-blocking beeping while flying so you can actually find the rocket afterwards

After that, it needs a hardware refresh and a complete rewrite of the code from scratch.

https://github.com/Wetmelon/Salus

 

[ksaves2]

I suspect any commercial GPS chipset receiver is going to go blind anyways during high G flight. Besides the statutory limits, something about it problematic maintaining a lock due to doppler effects.

I see your dilemma with the SD card but since your device will be buried in an electronics bay, it would have to be opened up to slide the card in for programming or plug in a cable to a laptop to do the job.
Unless there was a socket on the bay somewhere for a serial cable connection there would be no convenience to the SD card over a direct connection to a laptop. If one were to save several different programs to be able to pop a card in and out in the field for re-programming sans laptop that might be a weak plus. But then again, some of the darned tablets are pretty easy to carry in the field these days. Kurt

 

[ttabbal]

I'm thinking about doing something like this with an ESP32. So it would be a lot like the Eggtimer Quantum. It wouldn't shock me if he were already working on one for his lineup. I would want to do some other stuff, but they make it easy to work with in the field using any phone or WiFi tablet.

 

[NateLowrie]

The GPS, low g accel, and high g accel will all be used at low acceleration values. At higher values (i'm thinking > 15g), I'll remove the influence of the low g accelerometer on the observer. The GPS and high G can still be used (maybe, GPS can also have issues with high acceleration levels).

The board looks good but there is definitely room to shrink everything down. Here's a list of suggestions:

• Yeah, I think I'll do that for the more permanent version.
• It's a really loud buzzer.
• I considered this, but it about doubles the cost of the Teensy, and means I have to do a lot more placing of small QFNs or BGAs. Wasn't worth it for the prototypes, at least.
• Originally, and I may still consider this for the future, the SD card was actually planned to be used to configure the device. Instead of having to plug the device in, you could just get the SD card and it would load a configuration file from there, instead of storing everything in EEPROM or whatever. I put the SPI Flash memory on board for high speed data logging, but screwed up the footprint and shorted SPI CLK to +5v, which ruins the SD card communication, so I had to remove it. Right now the SD card is doing the logging. At 100hz, it takes 200 microseconds to save 512 bytes of data. So I only need to log every 4th or 5th loop, or at about 20hz. I'm not sure if I'll keep using the flash memory given the write speed and size of the SD cards, tbh. The data is logged as packed binary, and I wrote a python script that parses the binary data out into a CSV.

I have a CODE repo, but not a hardware repo for it yet. I'll warn you, the code is pretty bad. I couldn't decide at first between a heavily C++ oriented approach or a C oriented one. I've since gravitated towards C, but much of the functionality is still C++ OOP oriented. Even then, it's got global variables and junk everywhere and suffers from some "God Object" issues. I've been using Visual Studio with the Visual Micro plugin for programming, so there's .sln's and .vxproj's and whatnot in there too.

There's only two states - "Waiting for Launch" and "Flight". Although the BNO-055 runs its own Kalman Filter that makes getting quaternian output at 100hz trivial, it also has no "Data Ready" interrrupt and clock stretches like a mofo, so it can take up to 6700ms to read all of the relevant data. That leaves very little time to run a separate Kalman filter to fuse the GPS, barometer, and high-g accelerometer data. It will need to be replaced with something like an MPU-9250 with proper interrupt support if we want to make a decent altimeter.

I'm about to finish the last task before sending it to my friend for flight testing: non-blocking beeping while flying so you can actually find the rocket afterwards

After that, it needs a hardware refresh and a complete rewrite of the code from scratch.

https://github.com/Wetmelon/Salus

Code doesn't look terrible. Definitely needs a rewrite with proper interrupt support but it's functional.

My suggestion is to stick with the SD card and parse a text or binary configuration file. It's easier than writing a serial interface and should be easier to configure. I would expect most people to pre-configure the altimeter settings before getting to the field so it shouldn't be an issue. The ESP32 chip is cool, but it would be cleaner to do a serial transceiver like the TRS to control the flight states. You already have the pinout for the serial connection and in flight telemetry would be great.

I think you want to be able to do some type of wireless communication because it makes the pad setup so much easier. With the TRS and quantums I can turn on power via screw switches on the ground and then hoist into position before starting the flight wirelessly.

I can help you with the hardware and software redesigns. I have both Eagle and KiCad so whatever is preferrable.

The servo outputs are eventually going to be for active stabilization?

 

[soopirV]

Color me interested!

 

[UhClem]

Originally, and I may still consider this for the future, the SD card was actually planned to be used to configure the device.

I have been working on some code for a logger that is something like this only more so.

The MSP430 micro-controller has a basic version of eForth including code to access the micro-SD card. The actual application is compiled at boot time from the micro-SD card so it can be programmed to do nearly anything.

The target hardware is actually the software development system.

I designed and built a PCB but it wasn't functional for a couple of reasons. I will likely abandon that because I see that the new Teensy 3.6 includes a micro-SD card socket and more importantly for me, uses the 4 bit SD interface. That will make it a lot easier to log MPU-9250 data at 32KHz. Something that the MSP430 of my current design would be hard pressed to accomplish. 8KHz it is OK with though.

 

[wetmelon]

Nate, I made the first one in Eagle. I no longer use Eagle and have moved entirely to KiCad. I plan on doing a 4-layer board for the next layout, as the 2 layer *worked* but it was a nightmare to layout. I can set up a repo with the required libraries over the weekend.

 

[jderimig]

Nate, I made the first one in Eagle. I no longer use Eagle and have moved entirely to KiCad. I plan on doing a 4-layer board for the next layout, as the 2 layer *worked* but it was a nightmare to layout. I can set up a repo with the required libraries over the weekend.

How was the transition from Eagle to KiCad? Learning, availability of footprint libraries etc?

 

[NateLowrie]

Nate, I made the first one in Eagle. I no longer use Eagle and have moved entirely to KiCad. I plan on doing a 4-layer board for the next layout, as the 2 layer *worked* but it was a nightmare to layout. I can set up a repo with the required libraries over the weekend.

Sounds good. I have worked with KiCad a bit. Am more familiar with Eagle but the switch shouldn't be hard.

Why not just put it in the software repo under a hardware folder? It would make versioning easier.

 

[wetmelon]

Okay, the hardware (KiCad) has been uploaded to the repo. I haven't copied over the hardware libraries yet, so you may have some issues viewing the schematic / board.
I've also copied all of the required software libraries into the "libraries" folder. You'll need to copy them to Documents/Arduino/libraries. You'll also need Teensyduino from PJRC.com (install all of the add-on libraries too)

How was the transition from Eagle to KiCad? Learning, availability of footprint libraries etc?

KiCad is a bit of a strange beast when it comes to workflow, but overall productivity is much better once you get used to the flow. To learn it, I took the completed Salus schematic / board and completely rebuilt it in KiCad, so I wasn't ALSO fighting with the design while learning. It comes with a host of footprints, and there's quite a few on Github that you can find (such as Tinkercad), but honestly making your own is really really easy in KiCad compared to Eagle.

 

[NateLowrie]

Okay, the hardware (KiCad) has been uploaded to the repo. I haven't copied over the hardware libraries yet, so you may have some issues viewing the schematic / board.
I've also copied all of the required software libraries into the "libraries" folder. You'll need to copy them to Documents/Arduino/libraries. You'll also need Teensyduino from PJRC.com (install all of the add-on libraries too)



KiCad is a bit of a strange beast when it comes to workflow, but overall productivity is much better once you get used to the flow. To learn it, I took the completed Salus schematic / board and completely rebuilt it in KiCad, so I wasn't ALSO fighting with the design while learning. It comes with a host of footprints, and there's quite a few on Github that you can find (such as Tinkercad), but honestly making your own is really really easy in KiCad compared to Eagle.

Thanks. I'll check it out tonight.