This isn’t going to be a full post, but I wanted to mention that my PCBs for my power supply came. I’ve got the OLED display working, and will get the other peripherals working shortly. There will be a full post in a couple day’s time.
Sorry for not posting in a long while, but I’ve been busy with school. First, the quadcopter is still not finished, but my goal is to have it finished before next year.
Now onto the main topic of this post. As you probably know, I have a power supply project that I’ve been working on for quite some time. When I started my quadcopter project, it got pushed to the backburner, but I still kept slowly tweaking it. It’s back now, though, and better than ever.
While working on my quadcopter, I started using the Xmega series from Atmel. I really like these now, and their power and amount of I/O available make them great candidates for many projects. For Halloween, I built a 10-channel light controller that can be chained together with other control boards to greatly expand the number of channels. I didn’t finish it in time, but now I might be able to use it for Christmas (light shows anyone?). Since I wanted a large number of PWM channels per board without using something like a TLC5940, I used an Xmega A4.
One of the problems with the old power supply design was the display size and update rate. Adafruit stocks some OLED display modules, both in monochrome and color. OLED displays are known for their amazing contrast and sharpness, due to the fact that the pixel itself is light-emitting. A traditional LCD relies on either a backlight or reflected light to provide contrast. The LCD I was using previously communicated over I2C, which is a slower interface than SPI. It could have been the library I was using to control it, but I was not happy with the update rate I got with it. The OLED display that I got from Adafruit uses SPI, allowing me to push more data to it, faster. The physical size is smaller that my previous display, but since this is a graphical display, I can make the text as big (or as small) as I want.
While probably a bit overkill for the task, I also chose to use an Xmega A4 for my power supply. One of the Xmega’s advantages, besides the clock running at 32MHz at 3.3V, is the multiple SPI ports. Now I can update the DAC / read the ADC or update the display at the same time. This will hopefully give me a huge performance boost in update speed. Using the Xmega also gives me more pins to use, so I don’t need to use an I/O expander like before.
The rest of the design is pretty much the same as before, but with a couple improvements. Instead of using buttons, my rotary encoders are going to be the kind with one built in. This will help me create a more intuitive menu system than I could have in the past. Also, the tolerance of the critical resistors has been increased to 0.1%, which is more possible and cheaper now that I’ve switched to SMD parts. Hand assembly would take longer this way, but I can also just put down solder paste and stick the whole thing on my reflow skillet.
The boards and parts have been ordered, so here is a rendering done with eagleUp and Google SketchUp and a screenshot from Eagle.
I finally got the revision C control boards in the mail, along with a Ponoko order for some lasercut acrylic. I won’t go into detail over the new boards, because I did that in a previous post, but the new ones have USB for debugging and uploading new programs from Xmegaduino.That was the goal, at least. I figured that the RTS line on the FT232 would be used as reset, like normal. This is not the case, however. The DTR line is. Oh well. Luckily, I can use my AVRISPmkII clone to upload programs just as easily. There is also one other issue, and that is that I used some 0402 resistors accidentally. You can see in the first picture by the headers that I had to improvise with some 0603′s.
The acrylic plates that I got from Ponoko are great. They don’t serve any real purpose, but I figured that it would look cool and protect the control board from flying debris in the event of a crash. To get the shape exactly the same as the PCB, I exported only the dimension layer in EAGLE, brought it into SolidWorks to clean it up and create a .dxf file that Inkscape would like, and imported into it the template from Ponoko.
I’m also (finally) starting to work on modifying the AeroQuad code for use on my Xmega. For someone new to actual AVR programming (setting up registers and bit-level operations), work is going slowly, but I’m getting there. I hope to be flying in a week or two.
I was also on Adafruit’s weekly show-and-tell. You can watch the video here.
Along with any revision comes along changes, and this one is no different. First off, let me start off by saying that I am not abandoning the MPU-6050. It is a excellent chip, but it is not all-powerful. I am moving to a more traditional setup with this revision, with a separate accelerometer, gyroscope, and magnetometer. The accelerometer will be an ADXL345 from Analog Devices, the gyroscope will be the venerable ITG-3200 from InvenSense, and the magnetometer will be the HMC5883 from Honeywell. The reason for the switch to this setup is because of the lack of examples for the MPU-6050, and because I found out about the AeroQuad project.
The Xmega is also getting downsized. I finally came to the conclusion that I don’t need ALL of the pins on an A3, so an A4 will be replacing it. This is both to help reduce the size of the board, and to become compatible with the Akafuino X, an Arduino compatible powered by an Xmega A4. Also, just for kicks, I am going to overclock it. I’ve heard of people going as high as 80MHz with the Xmega, so I might as well give it a try. The specific one that I plan on using is the version with USB capability, but I will just use a FT232 for communication.
There will also be multiple ways to power the board. All options go through an AP1117 3.3V regulator, but now there is more than one way to get there. The main input is through a standard JST connector. The secondary input comes from the BEC circuit on one of the motor ESC’s. The third option isn’t useful during flight, but is there anyway, and that is through USB.
So, quite a big turn in the project at this point, but I think these changes will be for the best. I (and many of my friends) want to see this thing fly, and fly well. Development will continue on Rev B, as I want to get that MPU-6050 up in the air.
Whoops! This was supposed to be posted almost a week ago! Ah well…
So, time for some updates on tinyCopter. I finally ordered propellers! The ones I got are GWS 3-blade 7×3.5 in both normal and reverse rotation. I ordered them from RC Dude Hobbies, and they shipped all the way from Nevada to Michigan in just 2 days! And that was standard shipping! I am really happy with their service, and will order from them in the future.
Once I got the props installed on the motors, I fired one up, using my Arduino to generate the servo signals. I had the copter in my vice, so I loosened it up and upped the throttle. The end started to pull upward, indicating that with all four motors going, there will be plenty of lift.
You can also see in the picture a purple PCB next to the battery. That is a 2 cell LiPo charger based on the LT3652 from Linear. I have it set to the full 2 amp charging current it supports, and my 1300mAH battery says it is rated for a 5C charging current – which seems quite high if you ask me – so I should be good to go there. Still, I might charge it outside the first couple of times, just to be extra safe. You can find the files for it up on GitHub.
I’ve started to work on revision C of the tinyCopter control board. There are a couple changes that I’m making, so I’ll go over those.
First, I moved the GPS module out from under the xmega. This way I shouldn’t have to deal with interference issues. Since I had trouble with my on-board power supply, I replaced the TPS61200 boost converter with an AP1117 3.3V linear regulator. I also added two LED’s to be used for status indicators. I’m also shrinking the main part of the board to reduce weight a little.
I figured I’d take some pictures of tinyCopter so that you people can see what I’m actually building (these are on Flickr, so you could just add me as a contact there and see all of my cool pictures).
There. As you can see, the frame is made from aluminum u-channel. I am using Turnigy 1811 2000Kv motors because they were inexpensive, but I probably should have bought more powerful ones. By my estimates, these should hover tinyCopter at anywhere between 30 and 60 percent throttle. I recently (as in today) just bought some HobbyKing brand 6 amp ESC’s and a Turnigy 1300 mAh 2S battery. I’ve also built a 6 DOF IMU board just in case I can’t get the MPU-6050 working.
Progress! This is exciting. After struggling with a pesky compiler issue, I managed to get an LED blinking on my tinyCopter control board. Yes, I managed to get a 32MHz microcontroller with 256K of flash and 16K of RAM to blink an LED. Good use of resources there folks.
Anyway, the issue that I have been having – and it is still there, trust me – is in the creation of a custom board definition for Xmegaduino for my specific setup. Xmegaduino comes with a couple of options for boards, but all of them use the xmega A1. I have a xmega A3. I didn’t think that there would be any issues because the devices in the A series all have the same basic peripherals, just different pin-counts. The problem, however would soon show up.
I got the board definition finished and just copied the pins_arduino header file from a Sparkfun variant just to see if my variant would compile. Cue the obscure compile error! I looked at the error and it said ‘TCF1′ undeclared. What?! The blink sketch I tried compiled just fine for the Sparkfun board, why won’t it work for mine?! I went back and took a look at the only thing that I changed in my board defintion from the Sparkfun one. It was the MCU type, obviously. I had changed it to atxmega256a3, because that is the device that I am using. When I changed it back to atxmega128a1, which is what the Sparkfun board has, the code compiled perfectly. Then I went digging through the avrdude header files for various devices and found the one for my xmega a3. I searched ‘TCF1′ and it was RIGHT THERE! I don’t know what the issue is, so if anyone else does, please let me know.
You probably read that and though that I never got anything to work. The issue is still there, so what I did was set the board in Xmegaduino to the Sparkfun one, found the compiled .hex file, and burned it to my chip using AVR Studio. It’s a pain in the butt, but if I can’t get the ‘TCF1′ undeclared issue sorted out, this will have to do.
The point of this post is to say that now I can work on the code for my quadcopter.
Now that school is out, I will have more time to work on my projects. First off, I got a new AVR programmer so now I can get to work on the quadcopter control board. I also started putting together the frame. I started over on the 74C922 emulator because I was having trouble with my previous code. The code for the power supply is slowly getting worked on, but I think I may re-do some parts of it because they aren’t as efficient as I would like. So far on that I can: use the display, set the output voltage and current with the DAC, read the drawn current and output voltage with the ADC, read the button inputs, and read the encoders. To do: Make the voltage output match the read voltage from ADC and make a simple menu system for controlling the supply.
On a completely unrelated note, my friend and I had some fun with my tennis ball mortar. Check it out below!
So, while I am waiting on parts to build my quadcopter, I am also working on building a 7400 series drum machine. That’s right, 7400 series drum machine. I wish I had designed this, but I am _very_ slowly building this: 7400 Drum Machine. Why the sudden interest in 7400 chips? My grandpa stopped by a couple days ago with some real goodies. An entire tackle-box PACKED with mostly 7400 chips. There are also some 4000 series and several LM566 VCOs, EPROMS, and various other chips. It turns out that I now have most of the chips needed to build that drum machine.
There are a couple snags, though. Matt (the creator) used a couple (nowadays) rare chips in the design. One of them is the 74C922 16-key encoder. Yes, you can still buy these from some places, but they go for about twenty bucks a pop. Ouch.
Since I’m not entering any contests, like Matt did, I figured I might cheat a little bit. The 74C922 is a pretty simple chip; all it does is scan a 4×4 switch matrix and output BCD – binary coded decimal. It stores the last key pressed and toggles a “data available” output when a valid entry is made. This sounds like the perfect task for an AVR with some custom code.
Thus the 74C922 Emulator was born. My goal is to create an *almost* drop in replacement using an ATTiny2313. It will not be perfect, because the ‘tiny is 20 pins and the 74C922 is 18, but one should easily be able to make an adapter to plug my chip in.
There will be some people who call this “dirty” or “uncool” because I reverted to a microcontroller to replace basic logic chips. Okay, get me a 74C922 for 5 bucks – shipped. It isn’t cheating when you have to use modern technology to replace things that are no longer available.
You can take a look at the code on github as I develop it. I just started before I typed up this post, so it is not even close to being done, but it is there anyway.