A bunch of groups (including us) are working on open source I2C ESCs, which will be cheaper, better and easier to integrate into quadcopters than commercial ESCs. Here's one such project.
This guy is also working on "cloning a Chinese clone" of the MikroKopter quad controller. He reports:
"Everything works as planned.
Features over the ChinaFC-1.35:
* 4 layer PCB with proper ground / power plane * Pan/Tilt/??? servo output like on OEM MK 2.x * 3V reg for Spektrum-satellite receiver * Switching DC/DC regulators instead of 7805 * MK-compatible molex connector for distribution board for I2C/Power/Buzzer * $68 BOM cost"
They also note that Ascending Technologies is offering a15,000 Euro sponsorshipfor a team doing UAV research. Proposals due by February 13th.
And I can't help but notice that there's a bit of Berkeley robotics cluster forming. Along with all the UC Berkeley research, there's DIY Drones, Berkeley Bionics (exoskeleton makers), 510 Systems (who made Google's robotic streetview cars) and the work at theLawrence Berkeley National Lab.
Ground Control Station is a GUI based on GTK+, the platform is a quadrotor developed several GTK+ widgets capable of display telemetry data. These widgets are made to look like to real flight instruments in order to allow easy feedbacks for the user/pilot.
Features:
-Input Device 3D connexion 6Dof Mouse form manual navigation -Automatic mode GoTo (coordinate selected on map click) -Comunication Socket streaming UDP -GUI Compatible for any Linux machine with GTK+ (Debian Ubuntu ...) -HUD with Artificial Horizon -Incorporate GPS map show -Suppoert mjpeg streaming for augmented reality HUD -Telemetry control -Hhow inertial data -Compatible UAV client FoxG20
groundstation
The is the first version of the ground control station. In this version, the GUI is devided into 5 tabs. The first one showing the telemtry widgets needed. The second tab is quite the same as gpsd_viewer. The third tab provide an easy show UAV data, the fourth tab show the motor and battery status, and the final tab provide a set the comunication.
You might remember this blog post by Marko Klein Berkenbusch on using a hacked mouse sensor for position control of a quad. With some help from Marko himself, I've mostly repeated his results on a branch of ArduCopterNG and thought I should share how I did it as it's slightly different. Please note that this is not official ArduCopterNG code, there's no support or anything for it.
excel sheet which can be used to view the image from the evalboard and check you've got the focus ok
How to put it together:
solder on the 6 pin headers on the eval board so you can connect the stk500 programmer and ftdi cable
glue the lens mount to the bottom of the eval board. make sure it's perfectly centered over the pinhole of the mouse sensor
screw the lens into the lens mount (don't screw it in all the way)
upload the modified firmware to the sparkfun evaluation board using the stk500 programmer
Focussing the lens:
connect connect your arduino ide to the eval board using the ftdi programmer and it should immediately start outputting x,y coordinates and surface quality number.
If it just appears garbled it's probably outputting in binary press <space> to view the menu and press 'm' to switch it to ascii mode..
the third number displayed is the surface quality, try screwing in/out the lens to get a better (i.e. higher) surface quality. note: if it's dark you might need to point the lens at a light.
download an image by pressing 'p' and copy/paste the values into the excel sheet. adjust the lens, taking shots until it seems like a reasonable image
Playing with ArduCopter - all of the interesting code is in the Mouse.pde and Mouse.h.
I attached the mouse's ftdi pins to the arducopter Oilpan's telemetry port (on the front of the oilpan). The mouse sends serial commands (in binary) and a parser in the arduCopterNG code picks these up at 20hz.
In particular the mouse_calculate function does the compensation for pitch and roll. 20x per second it compares it's roll/pitch to the previous iteration and estimates what x/y it should receive from the mouse:
The expected x/y = the change in roll * pixel resolution of the camera / field of view of lens * magic number
(this magic number seems to be 5 for my set-up)
it then subtracts this estimate from the real x/y it received leaving only the horizontal movement.
the mouse_position_control shows the PID contorller to correct for the x/y movements from the mouse (this is a pretty normal PID controller).
Some good reference material on other people using mouse sensors for altitude hold, obstacle avoidance.
We're going to be redesigning this site next week, bringing better layout and content categories, and one of the improvements is finally updating the photo on the front page. Rather than Funjet that we're so tired of, the photo box will rotate through a set of photos that illustrate the range of UAVs covered here, from planes to quads to helis, to maybe screenshots of Ground Stations.
One of those photos or images can be yours! Please post cool pictures of your UAV or anything else you'd like considered for permanent front page rotation in the comments below. It's best if you upload them to the site first; if they're selected for the slot, I'll just "feature" them and they'll automatically appear. This site gets a million page views a month. Your UAV can become famous!
Last note: the role of that top box is to give newcomers a sense of what amateur UAVs are and what this site is about. So pictures should be clear, well taken (in focus, well lit) and ideally look like a UAV and not just another RC plane.
One interesting and rather different feature is that I tried to use a .NET micro framework board (FEZ DOMINO) to do the balancing... it did not work so I moved to a basic Arduino, thinking it's the garbage collector and especially the switching from one thread to another that caused the instability... Right now it still doesn't work :) and it looks it's because I was using the Euler angles rather than the raw gyros outputs.
So I'm really wondering if I shouldn't go back the the .NET board?
There si VERY little on the net about this, except a few people saying that it can't be done because of managed code not being real time, etc. ... Most people "complain" about the garbage collector kicking in unexpectedly, but with my code it would run every 5-10 seconds and take 3-5ms, which to be honest is negligeable... there was definitely something else stopping my quad from proper stabilisation !
Right now, it still doesn't fly as I've been having several issues with the IMU and Wii motion gyros lately, but even just the experience of building it was a really pleasant and interesting one !
Anyhow, I would love to hear any feedback or experience with this kind of board, or eventually a Java based one !
I needed some ultrasonic range finders for my project. But most of the commercial sensors like Parallax’s PING sensor and other similar products are quite expensive, especially if multiple units are needed. So I thought why not building it myself?
In this week , I'm working to port APM_ADC , APM_RC , APM_EEPROM , WIRE and other library to Arm Platform . We' add the support of Radio reciver, gyro and acc sensor that using SPI bus. EEPROM .
We're ready to fly. We need some debug on i2c bus and start to do preflight check.
In the picture you can see my first proto of Quadfox that using Arm Cortex3 Microcontroller instead of AVR 8 bit. So at the end of this week i recived the first Multipilo32 , then I have yet ready a lot of code to test on it.
Posted by Zach Bayne on January 24, 2011 at 5:30am
"Aerial drones are now used by the Texas Department of Public Safety; the Mesa County Sheriff's Office, Colorado; the Miami-Dade County, Florida, Police Department; and the Department of Homeland Security. But what about privacy concerns? 'Drones raise the prospect of much more pervasive surveillance,' said Jay Stanley, a senior policy analyst with the American Civil Liberties Union's Speech, Privacy and Technology Project. 'We are not against them, absolutely. They can be a valuable tool in certain kinds of operations. But what we don't want to see is their pervasive use to watch over the American people.'"
Posted by Markus Jahn on January 24, 2011 at 2:28am
I just got finished my octocopter with Arducopter electronics. It is built to carry DSLR and should fly 7-8 minutes with 1000g payload. Copter is actually just a quad which has two ESCs and motors on each end. It proved to be really stable platform on first tests last weekend.
I fly with 5000 mAh 14.8V Lipos and have eight 750kv/100W motors. Still the flight time with such a heavy camera will be short. But actually from previous experience I know 5 minutes is long enough for photographing a target. After that you can land, change battery and make a plan for next 5 minute flight.
Posted by James Cann on January 23, 2011 at 5:30pm
Following the death of the Ugly Pink Quad's 4th thruster, Entirely accidentally, I am going for a tri-rotor design, on
a 1/4" plexiglas base, with 3 Futaba S3003 servos for vectoring thrust.
The Nano that was originally being used for the Ugly Pink Quad, and now the Tri, well...it died, so in comes the DFRobot RoMeo.
My initial idea is going to be to use the thrusts of the three ducted fan units to stabilize horizontally and control altitude, while using vectoring to produce the X-Y translations and yaw motions as needed.
Given the wide, flat body and the ability to vector thrust, I might be able to use the plexiglas as a lift-generating device to aid battery life when not merely hovering.
Given that lift, and position can be somewhat decoupled, it may end up a very stable platform for cameras and such, even in breezy conditions.
I hope to have the IMU stream stabilizing the platform by mid-week.
First test with the AFSoftwareSerial for COMMs with the ArduIMU seem promising.
I see the trend for quadcopters is now to use more and more Arm 32 bit processors, which are obviously more than enough for balancing :) and have the advantage of offering enough remainin power for extra jobs.
Here's my attempt at interfacing a LM3S8962 (from LuminaryMicro / TI) with the Wii Motion Plus gyroscopes.
After spending some time trying to figure out how to install / work with IAR and FreeRTOS, I discovered (on this site) the CooCox environment and its real time OS, and I must say I'm much pleased with its usability and easy of use..
Posted by Tim O'Brien on January 23, 2011 at 1:00pm
Using an Phillips NXP LPC20148 ARM7 processor, a Nintendo Wii motion+, and some xbees I've made a really stable platform for quads. (mode details here) It is running FreeRTOS which makes it very expandable in the future. My old frame flew great with it, but I wanted something smaller. Enter my new carbon fiber mini-quad:
Here's the plug-and-play LPC flight controller. The motion+ is inside and wrapped in foam. The XBee plugs in to its' socket on the top. The ESCs plug in back.
Here's the remote. I can easily adjust the PID gains, and it sends them to the flight computer before taking off (there's no eeprom on the LPC). You should see the difference 0.05 on the pitch and roll I term makes in stability.
Not bad for an computer engineering undergrad in their spare time, with no class credit, and on the budget I get as a photojournalist for our paper, eh? This is remote v1.5, and remote v3.0 is in the works. Here's a sketch I drew a couple of weeks ago.
Everything's open source! I hate seeing people's cool project, wondering how it works, then getting the promise of OSS sometime in the future. I want to see how asap. Well here's how I did it: The remote code. The copter code.
So, having spent the last couple of years experimenting with UAV systems I felt the need to try something that would stay on the ground. I have been fascinated by rock crawlers, the latest RC off-road trend. They seem the be the ideal platform for a land based all terrain rover system. Traction and maneuverability is very impressive.
Last week I got a HBX 1/8 scale crawler kit, and started modifying it for my needs. So far the system is FPV capable (out to about 2km), but autonomous GPS navigation is planned for a later stage.
- HBX 1/8 Crawler
- 1W 1.2ghz video link
- ServoCity Pan-Tilt system
- GoPro Hero HD camera
- 500mW 433mhz two-way radio modem
- Teensy 2.0 onboard computer / serial to servo converter
And best of all, I don't have to go out in the cold to operate it!
Here a video of the new Quad Rotor Observer (QRO) v6 with a GoProHD Wide on board.
Flight controller hardware: KKmulticontroller "BlueBoard" from Minsoo Kim's ( http://kkmulticopter.kr ) and based on the board of Rolf R Bakke
Flight controller firmware: XXcontroller_KR_v1_4a based on assembly code by Rolf R Bakke converted by Mike Barton modified by Minsoo Kim and Jean-Louis Naudin
Today I'm working on IDE for Multipilot 2.0 . I found different kind of approach available For developing application on Arm Cortex A3 microcontroller.
Actually I'm studing this kind of platform :
Xduino , Maple IDE and CooCox IDE.
The first two ide are Clone of official Arduino project . This kind of ide use same Arduino Java ide and add support for gcc arm compiler instead of gcc . Normaly support usb uploading of firmware don' support jtag debugging. The Maple is better of xduino at the moment. The standard arm library is wrapped for using same arduino language sintax. Is not yet fully compatible with original arduino sintax.
The second one instead is a Eclipse ide , that include support for makefile automatic production , gcc compiler , linker, debugger and support Jtag interface for debug and upgrade firmware.
Support a lot of functionality of ARM micro , is available a micro operating systems that support task and preemptive multitasking.
Personally I prefer second kind of approach , more professional approach not for entry level programmer . The first kind of approach is very good for people that normaly use arduino for development of his application .
My idea at the moment is to support all kind of systems .. actualy the second kind of ide don't support the arduino .pde application ,but i think that is possible to develop a wrapper class and a mod for eclipse that support this kind of improvment.
I would like to "formally" announce two open source projects related to optical flow / programmable vision sensors. These are based on some of the optical flow techniques developed at Centeye, but in the spirit of "open source" are meant to be hacked/modified/copied any way a user deems fit. In both cases, the source code has been opened up under a modified FreeBSD license, while the board design has been released under a Creative Commons Attribution-ShareAlike license, the same license that applies to the Arduino boards.
The first project is the CYE8 sensor, an optical flow sensor based on an Atmel ATmega644 (possibly to be replaced by an ATmega1284) 8-bit processor, and using a Faraya64plus sensor head. (A "sensor head" is a vision chip wire bonded to a 9mm x 9mm PCB with a board to board connector on the other side.) We fabricated our first two iterations last year (the first one described here), and are now readying the third iteration this month.
The hardware of the second project was introduced in a recent blog post and is based on the Sparkfun Arduino Pro Mini platform (which uses a similar but smaller Atmel microcontroller) and comprises a simple shield board that interfaces the Arduino with a sensor head. Currently we have used only a FarayaSmall sensor head, but this board will support other chips as well.
At the current time, these projects are hosted on another open Ning network Embedded Eye, since we are trying to capture a broad set of applications beyond drones. If these projects take off, we can set up Huddle spaces accessible across both Ning networks, or move the project elsewhere. (I'll take suggestions- I'm still learning about how to do projects like this.) The CYE8 project is located here and the Arduino-based project is located here. These forum pages include initial board designs and source codes.
Based on interest, we will likely also launch projects built around an Atmel AVR32 processor (faster than the AVR8's) and/or an XMOS quad-core processor (if you have real need for speed).
One common theme of these two projects (which has strengths and weaknesses) is that they utilize vision / image sensor chips designed by Centeye. (This is not a requirement of the license- it is just how they were designed.) The strengths are that since we designed the vision chips, we can probably reveal as many details of the inner workings of these chips as we want. We all have heard complaints of chip manufacturers being too vague about what is inside, so I hope that this is a welcome change. The weakness is that we basically have to burn new wafers every time we want more sensors, so they are not as available as, say, a part from Digikey.
We are actually going to start a new run of silicon soon with the intent of increasing manufacturing quantity. It is tempting to use this as an opportunity to explore semi-open chips designs. I'd be happy to share a (virtual/real) beer with anyone interested in discussing (whether here, at EE, or directly) the various issues associated with the design and manufacture of chips of this type.
Posted by Aaron Curtis on January 19, 2011 at 9:00am
I've now gone around one full circle on the UAV wheel: I built her, flew her, and crashed her. It has been great fun so far and I can't wait to get in the air again. Before I do, however, I thought I would write something so that other beginners could learn from my mistakes.
Anticipation and Assembly
I decided sometime last April to buy an ArduCopter spent several months in breathless anticipation. I got home from Antarctica early this January to find the package had arrived and feverishly started building. A few little issues I encountered during construction:
- When connecting the ESCs to the power distribution board, the wiki guide advised me to solder them directly on. My ESCs had Deans connectors on them, so I chopped them off and soldered them on per the wiki instructions. Only later did I find the electronics assembly PDF, which advised soldering female deans connectors to the power board so that the ESCs could be disconnected. After finishing the copter, I found four female deans connectors in my kit which were for this purpose and wished I had followed the PDF rather than the wiki, so that I would have easily removable ESCs.
- The method for mounting the ESCs and dealing with the motor wires is unclear in the wiki instructions. This is probably because there are so many ways to do it, and also different types of arms. In the end, I velcroed my ESCs to the curved plastic supports of the protective dome, braided my motor wires, and wrapped them around the quad arms to take up the slack. In theory I guess the motor wires could go through the inside of the arms, but the arms that came with my kit had "half holes" i.e. they only have the slots for the wires on one side of each arm. Also, the slits for wire insertion are at the very end of the rods, so the motors mount right on top of the slits and it seems difficult to get the wires into the slits as the plastic motor screws are in the way. Not sure how this is supposed to work, it seems like maybe the "wires inside the arms" idea was abandoned during the design at some point.
- I cranked down too hard on one of the screws for the motor mounts, and cracked one of the thin clear plastic pieces below the motor and arm. This comes back to haunt me later in this blog entry!
- I forgot to solder 5 of the pins on the 6-pin header that connects the ArduPilot with the ArdIMU. This had the surprising result that the ArdIMU worked, but only in CLI mode. I was quite embarrassed when Sebastian on the forum suggested I check my soldering and it became clear why the ArdIMU was not initializing in normal mode!
First and second "flights"
Once I'd figured out my new Turnigy 9x and finished calibrations, I headed out to a nearby field with a couple of friends. After a good deal of testing I gritted my teeth and eased up the throttle. The hum whirred into a buzz and then... two of the propellers popped off, launched high into the air!
It reminded me of the Gemini test scenes in the movie The Right Stuff. I scratched my head for a while and eventually concluded that, unlike the motor mount screws, you really need to crank down on the propeller attachment chuck.
Props securely fastened, I tried again. This time, the copter got 3m up into the air and began to fly away from me quite quickly. Thinking I would bring it down and consider a recalibration, I eased off on the throttle. Cindi Lou (that's the copter's name) descended a few feet while still drifting away from me and then promptly flipped over at a little under 1m from the ground and attacked the grass! My friends tried to contain their laughter as I inspected the damage, which was disabling but not catastrophic: cracks in the top and bottom plastic sections of the forward motor mount. Here are a few photos of the damage, and a video of both attempts.
Recovery
Eager to get back in the air, I ordered the $30 crash kit from the Fah Pah store. I would have preferred to order from DiyDrones (since they're in the US, not Thailand) but it seems they only sell full replacement frames and replacement arms. Not content to wait for delivery, I picked up some plastic repair epoxy from Ace Hardware and set about mending the motor mount. It looks fairly solid, but I'm not sure if I would be jeopardizing the rest the Cindi Lou should I attempt to fly on the repaired mount. My impatience to fly again is competing with my better judgment here...
Lessons learned
I'm not certain whether the crashed was caused by my poor construction job, or my poor piloting. I wonder if the pre-existing crack in the bottom motor mount section contributed to the crash. Either way, the crack in the top section was certainly caused on impact with the ground. One take-away message is to tighten the propeller chucks hard, but not the motor mount screws. Perhaps a more important one is to make sure the copter's horizontal motion has stopped entirely before attempting to land!
.jpg)
