Lately I've seen a number of things that almost fly, and they reminded me of a project idea that I put in the queue a long time ago: a printed circuit board-based quadrotor. Fiberglass, like the FR4 used in PCBs, is actually a pretty nice structural material - lightweight and stiff. So why not integrate the electronics and the structure into a single printable frame? I named it "4pcb" after the URL for Advanced Circuits, where you can go to print your very own. (Though now that I think about it, Myrocopter would have been a cool name, too.)
I've actually helped with a quadrotor before:
It was built by high school students as part of the Edgerton Center summer engineering class in 2010. You can see the details in this Instructable, the first and for some time only Instructable on how to build a quadrotor. (Credit goes to June K. for the write-up.) This one has a pulltruded carbon fiber frame and is built mostly from Hobby King parts. It uses 7" props, two right-handed and two left-handed, and is controlled by feedback from gyros and accelerometers.
The nature of the control system is what appealed to me about building a quadrotor, and I pretty much drew it up from scratch the way I knew it would work. The internet does have a lot of good and bad information on the topic, all of which I skipped over. But if you're new to this game you might want to read some of the following:
- The basic idea, and why you need counter-rotating props.
- My surprisingly well-traveled white paper on the angle estimating filter.
- Sensors and filtering sections from my other Instructable.
- Code and tuning sections from the quadrotor Instructable.
Props to Welkin U. for translating my ranting into workable code for the Edgerton quadrotor - it did in fact fly stably, if only for about 10 seconds at a time. I think with a bit more work on the yaw control, and a lot more pilot training, it would have been almost easy to fly.
Anyway, now I want to build a small one.
I settled on a 4" prop (4x2.5) and pretty much the tiniest motor that Hobby King sells, the HXM1400-2000. Despite its size, this is a 12-slot, 16-pole brushless outrunner.
|Yes, 16 poles!|
And it is an incredibly nice little motor. The build quality seems a lot higher than other tiny motors I've seen, including the ones from our last quadrotor. For example the can does not feel like it's going to separate from the motor and fly away under load. The prop adapter that it comes with actually fits the prop, and the whole assembly (motor and prop) weighs only about 10 grams. With the 4x2.5 prop and a 7.4V supply, reviews suggest the thrust will be about 50 grams.
And I've somehow made it several paragraphs into a post without talking about motor control yet. Well, I can fix that. I was browsing for a piece of enabling technology: an integrated sensorless control IC. There are plenty of cheap, small brushless ESCs on Hobby King and elsewhere, but what's the point of a PCB quadrotor if I still have to zip tie ESCs to it? Also, there's a fundamental bandwidth limit with RC ESCs due to the ~20ms gap between servo PWM pulses. We definitely battled with this limit on the Edgerton quadrotor, and a smaller quadrotor will need an even faster control loop.
So, I was very happy to find this:
It's part of Toshiba's line of small, integrated motor control chips. The TB6588FG is the brushless version. They contain both the power and the signal electronics, so it really is almost like having an ESC on a chip. You do have to add a few passives.
|Okay, a lot of passives.|
But still you get a sensorless ESC in about a 1"x1" PCB footprint with no wasted weight for packaging or heat sinking. It has some features you wouldn't get on a cheap RC ESC too: analog speed input (very high bandwidth), adjustable frequency PWM, adjustable timing, over-current protection, and some others. But there are also a few drawbacks: It's designed for higher voltages (7-42V), so running it off a 7.4V battery is borderline. It also may have issues with the extremely high electrical frequency of these motors. The datasheet mentions an optional commutation frequency limit, but doesn't say what happens when you turn the limit off. Only one way to find out.
Since I'm working in EAGLE, I have to live within the constraints of the 100mmx80mm board size limit. That's one of the reasons I put this project on hold originally - I figured I might have to go back to FreePCB or some other layout program to do it. But recently I remembered that the board size limit only applies to placing components. The free version of EAGLE will definitely let you create a board outline (dimension layer) and even traces that go outside the limits. So, I just had to place all the components in the 100mmx80mm dashed rectangle in the title picture, which has the origin at its lower-left corner.
After laying out a single ESC block, I just had to copy-paste three times and - oh right, this is EAGLE, FML.
As it turns out, even the already convoluted process of copy-pasting a group of components and wires in EAGLE is not enough to get you through this one. If you do so in the schematic, an unorganized batch of new components inserts itself into the bottom-left corner of your board. If you try to do so in the board, it just yells at you. A combination of Googling and random screwing around got me to a workable solution:
- Close the board file. This breaks the link that automatically inserts new components into the board when you copy-paste schematic groups.
- Copy-paste the group in the schematic. If you don't know how to copy-paste groups in EAGLE, you might want to figure that out first.
- Open the board. It will now yell at you because the board and schematic are not consistent.
- Copy-paste the group on the board. Make sure the board group contains exactly the same elements as the schematic group. (Same components and nets.)
- If you have not re-named any nets, or used any power supply nets, then you are probably done. If you have, go on to Step 6.
- Power supply nets and user-named nets copy properly on the schematic, but not on the board. On the board, GND becomes GND1, VCC becomes VCC1. USERNET becomes USERNET1, OTHERNET1 becomes OTHERNET2. It either appends the number 1 to the name, or if there already is a number, it increments. Depending on your intentions, you may have to change the net name on either the schematic or the board. Usually for power supply nets, you'd be renaming the board nets to GND, VCC, etc. But for user nets, you may actually want the automatic number incrementing. In that case, you can update the schematic net names appropriately. The ERC shows the inconsistent nets. Once you have cleared all these, you're done. Unless...
- The numbered nets (N$1, N$2, etc.) should increment properly on the board and the schematic when you copy-paste. But, I found that if you have extra nets on the board that are not present on the schematic, it offsets the net numbering on the board. For example, the 20 motor mounting holes I had were numbered N$25 through N$44. They were not represented by anything in the schematic. So, to avoid the problem, I had to rename all the nets associated with these isolated vias so that there were exactly the same quantity of numbered nets on the schematic as on the board. Only then could I successfully execute Steps 1-6. So maybe this is actually Step 0.
And after all that:
|Three hours to copy-paste three instances. WHY!?|
Now that I know how to do it, it would probably only take me five minutes or so to copy-paste a block of this complexity in the future. And I'm not sure I can blame EAGLE, since it does do a reasonable job of re-syncing net and component numbers, or at least telling you when it makes a mistake. But dammit, there must be a better way!
After that adventure, routing the few remaining signals was easy. I opted for an Arduino Mini this time, just due to the space constraint. The sensors are on a Sparkfun Razor 6DOF IMU, which I would link to but Sparkfun seems to have discontinued it within the last day or two. I've got a few buffered, but it does bother me that they're ditching the only analog-output 6DOF board, and that I will have to rework the documentation for this and other projects that relied on this part. >_<
For wireless control, an XBee radio module is hidden on the bottom layer. These have become my standard for custom RC, one of the building blocks I can rely on to just work. The XBee link has several advantages over normal RC Tx/Rx systems. First, it is not constrained by the 20ms servo PWM period, so the control bandwidth can be higher. It can have bidirectional data transfer, which is useful for debugging and real-time data visualization (virtual quadrotor!). And since the other end of the XBee goes to my laptop, I can control it with any USB HID controller.
The full layout is in the title image above, and in high-res here. Lead time on the boards will be about 10 days, so the next update will be in a couple weeks. Back to tinyKart...