Using generic quadcopter flight controller for rocketry

[Happy Heyoka]

Last year, I was playing around with an Arduino based unit with GPS and a HopeRF radio module (RFM23 - like strud). I flew it a couple of times to test the radio and my Android tracking app, but it's a pretty clunky way to make it happen (some real limitations on the software and processing side with the Atmega based Arduino stuff).

I did toy with doing a custom board with extra sensors... then I discovered Alibaba and about a zillion Chinese hobby shops selling generic "flight controllers" for the ubiquitous quadcopter/drone market.

So this thread is where I'm going to write up my experiments with using a generic "flight controller" computer for rocketry...

I've chosen a Naze32 rev 6 "10DOF" board to begin with because it has a number of nifty features:
- a barometer (for altitude - good for about 29000 feet ±3 accuracy)
- a magnetometer (compass)
- an inertial unit (3 axis gyroscope/accelerometer)
- a 72MHz ARM CPU (STM32103CB76 - Cortex-M3 32-bit)
- 20k RAM & 128k Flash on the CPU, 16Mbytes external Flash (for recording?)
- 3 serial ports (ie: for telemetry, GPS)
- lots of extra I/O (for the servos and motors usually)
- open source software ("Baseflight", "Cleanflight" etc - bones of a rocket program)
- 36mmx36mm (yes, @Lister, there are variations that are <24mm, minus a few features)
- about 7.5 grams assembled

Oh, did I mention - ubiquitous and incredibly cheap (≈A$20)... I got three Naze32 units plus external GPS/GLONASS modules for about A$120. The $7 Bluetooth serial modules are on their way...

Before you get too excited - the standard Naze32 software doesn't have a profile for "rocket" This is not going to be plug and play for a while yet (fyi, the standard software does support about eleven flavours of fixed and rotor based vehicle!)

Also, the accelerometer tops out at ±16G; so it's not going to accurately record the vertical component of a fast flight (not the end of the world, it'll just be "pegged" on vertical limit during boost phase). From what I read of the docs on the IMU (MPU6500) other axes should fine.

My goal here is to mix and match this with a few other components, first some telemetry, and then once I'm confident, maybe some external FETs to drive recovery stuff or staging igniters. Maybe a single axis airbag accelerometer (good for 100G) at some point.
Oh, OTT, it would probably handle "vertical trajectory maintenance" too

I don't plan at this stage to do anything commercial but I'm certainly going to put any software I write up on Github or something if you wanted to play along.

Anyway, I have one blinking away on my desk right now running the standard software and it's very cute. I'm waiting for some parts to turn up so I can hop into writing the code and debug the thing (it's my first foray into STM32 - I need a JTAG debug dongle that supports it).

Naze32 board, GPS (with additional compass) next to 2.1" payload bay... everything should fit!

Sensor data as captured by the standard "configuration" software.

Sat fix as displayed by standard config software.

[OverTheTop]

I have looked into the naze32 boards before. Very nice. Cheap too! The open-source documentation and code seems to be very well managed too.

I was looking into it for the VTS but went with a challenge of using a COTS (commercial, off the shelf) autopilot. One of the reasons for going for the COTS solution is that I have done too much programming over the years and I don't really want to have to learn another development environment. I just don't have the luxury of available time that I would devote to that.

It wouldn't be too hard to graft in a higher spec accelerometer. I seem to remember there being some SPI busses available. You would probably only need one axis for that one.

Let me know if you want to try some flight testing with the VTS hardware. I'll see what I can do.

[Happy Heyoka]

I have looked into the naze32 boards before. Very nice. Cheap too! The open-source documentation and code seems to be very well managed too.

And there are multiple codebases for the hardware - so comparing who does what with each peripheral is nice if there's some weird register ordering requirement or something.

One of the reasons for going for the COTS solution is that I have done too much programming over the years and I don't really want to have to learn another development environment. I just don't have the luxury of available time that I would devote to that.

totally understand where you're coming from there... I've been playing with ARM stuff lately so it's in the same ball park... the STM32 stuff looks like something I should be familiar with résumé-wise

Let me know if you want to try some flight testing with the VTS hardware. I'll see what I can do.

** cough ** you first
I'm really looking forward to seeing it go up - but if anyone is going to have first opportunity to turn all your lovingly hand crafted rocket into rubble, it should be you!

[OverTheTop]

if anyone is going to have first opportunity to turn all your lovingly hand crafted rocket into rubble, it should be you!

Fair call

[Lister]

if anyone is going to have first opportunity to turn all your lovingly hand crafted rocket into rubble, it should be you!

Fair call

I'll be there to help you pick it up OTT

[Happy Heyoka]

So this is a bit of a status report... this project has come back onto the front burner given that I really could have used some working telemetry last launch...

this is "Hello World" running on a Naze32; something of a learning curve getting the STM32 tools and debugger to co-operate.

Also the very (very) small matter of getting the SwD connectors for the debugger soldered onto the bottom of the Naze32 board.


I now have some software called "Cleanflight" building and deploying on the board - it seems to be the current favourite for the flight controller software. Cleanflight does everything except wash the dishes. It is fairly finicky to configure and a little bit sensitive to overloading the CPU when you have too many features switched on. Also the small matter that by default it needs the remote controller (as in joysticks) set up to "arm" the unit.

Initially I'm going to fly it purely for telemetry; there's a thing called the "Lightweight Telemetry" which provides

G : GPS Frame
A : Attitude Frame
S : Status Frame
O : Origin Frame
N : Navigation Frame (inav extension)

The Status and Navigation stuff are a little bit redundant in the rocketry setting; everything else is pretty obvious.
Time to wires some interface cables to the radios and build a sled for the payload bay and see what I get.

Next step is to "fork" the cleanflight software and to strip away some of the code excess to requirements - like the stuff to do with navigation and all the various vehicles (quadcopter, fixed wing, etc) and flight modes; maybe add some "rocketry" equivalents - "single, multi, cluster etc" and modes like "pad, boost, coast, wait for apogee, deploy 1, deploy 2".

I know some of the other rocketry flight computers are open source so I'm likely to borrow liberally from those. If you have a favourite feature, let me know.

I'd like to keep the configuration (Chrome App) interface intact because it has had a bit of work put into it and is pretty handy with some nice diagnostics for GPS and sensor readings. Have to ditch that picture of the quadcopter tho...

[Viking]

...something of a learning curve getting the STM32 tools and debugger to co-operate.

Would an STLink have made this easier rather than the Olimex?
Interesting choice considering how cheap STLink is.

[Happy Heyoka]

Would an STLink have made this easier rather than the Olimex?

I have a few STLink devices kicking around - both "real" and knock-offs...

I also had the ARM-USB-OCD (the Olimex gadget) and the 0.05" pitch SwD adapter (which none of my STLink gadgets have - they're all 0.1")... I wanted to use the connector rather than solder 0.1 jumper leads to the pads.

The actual problem was getting a functional OpenOCD .cfg up and running for the ARM-USB-OCD + STM32F103CBT6 target (as on the Naze32) in "System Workbench for STM32"; while it uses OpenOCD on Linux, it doesn't come with scripts for anything but STLink targeting ST boards and a couple of other mainstream development boards... so, a few days of drinking too much coffee, swearing at the computer and poking around with the CRO and it's all sorted. I'm like a dog with a bone sometimes

During this time I did a lot of reading in the System Workbench forums and it seems that people have equally as much trouble with STLink debugging too... so would it have been easier? A definite dunno

[Kayboku]

How did you go with this? Did it work?
Ive had the same idea and am currently trying to build it.