Well, I haven’t updated my blog for 3 months. Now I’m on vacation to see relatives in Chicago, so I thought I’d finally get around to writing an update.
I’ve been spending the last few months working more on my many other projects. Some highlights include a DMX RGB Pan/Tilt Gobo, and this elevator plugin for Minecraft. I’ve also of course been hard at work on the FC1 though!
Here’s the summary:
- Built my testing quadcopter! More on that in a minute…
- Major overhaul of FC1 software and drivers. It actually worked (ish)!
- Seriously, the FC1’s firmware was very complicated and took like the whole month.
- Developed Node.JS client to help with FC1 debugging and PID tuning over serial.
- Hacked my DualShock3 to work with the FC1 and fly the drone.
- Got a real RC transmitter from FlySky!
- Designed rev 4.4. Adds fairly robust curcuit and shorting protection.
- Started to turn the FC1’s firmware into actual firmware by hacking together a custom board for the Arduino IDE’s custom-boards-manager. This also means that the FC1 actually lists properly as an “FC1” by “BBRYCE Technology” when you plug it in!
- Improved stability and balancing of FC1’s motion processor, upgraded power controller and created proper firmware for it using the I2C bus to talk to the CPU.
- Finalized v1.0 of GPS expansion board, based on the latest cutting-edge Venus commercial GPS module. The MSRP is going to be around $24.
- Worked on getting the firmware aspect fully working with Arduino’s board manager.
- Made a Processing sketch to display motion data output from the FC1 in 3D.
- Um… Wrote this blog post?
Some of the inner workings of the FC1’s firmware:
Developing the firmware did take quite a lot of work and research, so I thought I’d share some of it.
The FC1’s firmware is neatly divided into sensible categories, and features can be enabled and disabled by the user using define constants, or on the fly through the FC1 API. There are even drivers for various peripherals available, for example, a driver to read from a PPM-based RC receiver. Anyway, these sections are split up similar to how the code is.
I’ve begun work on the user-accessible API here, including many functions and globals. The Arduino loop() and setup() functions are in here, so just forget they exist. The FC1 timer library should be used for most user code and delay() should never be used anywhere!
I also keep my rather long software TODO list here. The hardware TODO list is separate.
All of the FC1 motion processing happens here and of course on the MPU. The auto-calibration is also handled here. Yaw, pitch, and roll are calculated in degrees (all math is float and not double to save memory) and movement along forward/backward, left/right, and altitude are soon to be working. Altitude will be absolute thanks to the FC1’s onboard altimeter, for absolute x and y movement, you’d need the GPS expansion module.
The motion processor drivers also took a lot of research to get working, as there’s not much on the internet on how to use the InvenSense DMP, especially on the new MPU9250, which you can’t even buy breakout boards for yet, except on eBay. Fortunately I was able to find some code on the outskirts of the internet, which used a driver designed by InvenSense for another platform with some modifications, and a custom wrapper around that, which I made improvements to and put in the FC1 firmware.
Not much happens here since all the way back in v3.7.0, the major motion sensor overhaul, but the PID initialization is handled here.
This is where the magic happens. The PID algorithms (more on PID, as well as the library I used here) are designed to take an input (user code or one of the available RC transmitter drivers) and use it to drive an output (the motors) based on a sensor (the calculated motion coordinates). The output from the PIDs are then used to power the quadcopter’s motors using a surprisingly simple power distribution formula. This is all you’d need to change in order to support different types of crafts and flying vehicles.
Of course, this whole section can be disabled if all you want is a motion sensor that produces no output. For example, if you wanted to take advantage of the FC1’s (impressively stable and reliable) sensor-fused motion sensing to collect 3D motion tracking data for a camera rig, all you need is #define NO_OUTPUT and some double-sided sticky tape!
This is of course what you’d expect. Convenient definitions of pins, ports, peripherals, and I2C device addresses as labeled on the FC1. It also incudes an enum of commands that can be sent to the power controller, so I need to be update it after writing new versions of power controller firmware.
The FC1 firmware’s user configurable compile-time config options are available here. This file will of course be moved out of the actual firmware at some point, so that it can actually be modified by the user. For now, it’s simply to keep track of what I’ve decided are the default config options.
I’ll probably post all this code on GitHub eventually, but I keep it on my Dropbox for now.
And now for out feature presentation…
Drone Assembly and More: With Pictures!
Ah, yes. The parts. Let’s get started!
First, we need to assembly the frame.
Unfortunately, it didn’t come with any instructions, but I figured it out!
Next, let’s unpack those motors…
There. Installed on the drone.
Now we can install the ES… Um… Yeah, that’s not happening.
Jump-cut to a week later and we’ve got these adorable little 12A ESCs!
Finally, a quick trip to NovaLabs to solder and make sure the motors spin the right way round.
Some additional photos are available here.
The FC1 isn’t quite flying yet, it needs better PID tuning, but it’s cool to hold it and feel it resist being pushed in various directions.
Last but not least, I wanted to mention that a new expansion board is in the works. This one provides precision optical stabilization to your drone using a low-cost imaging sensor originally intended for use in USB mice.
If you want to see our vacation photos, check our Google+
Anyway, as always, thanks for reading!