First impressions of the Parrot AR.Drone 2.0 Posted on 02 May 2012 at 23:48

I got my brand new AR.Drone 2.0 today. First bummer: the Android app is not yet available. As I have a HTC Desire Z, and no iPhone or iPad, I cannot use the full potential of the new drone. However, the old app is still usable: you don't get to see the video of the new 720p camera, and the absolute positioning feature doesn't yet work. The missing video isn't a real problem, because as a beginner, you really have to fly with the drone in range. The absolute positioning feature would certainly be useful, but again, beginners should start slowly.

Battery

At first, the battery didn't accept the charging. The charger kept blinking red, without the battery being loaded. I'm not sure what the problem is, but it's probably the cells being unbalanced. But one thing is for sure: the battery has much less capacity than what have could been fit into the size of it (1000 mAh instead of 2200 mAh at only 50 grams more). The loader is also awfully slow; the manual states 1.5 hours of loading, which presumably gives you 12 minute of flight time, which I estimate to about 9 minutes hovering, and much less when moving around. This basically isn't enough to even train. As soon as you get a grip on the controls, the battery levels drop to critical levels and the drone shuts down.

Flying

Flying is fun, but even as the drone is a quadro-copter, it takes some practice. For a beginner like me, as soon as the orientation changes from facing away from you, my control goes havoc. Fortunately the indoor hull provides protection. I strongly advise against flying without it indoors. When it hits a wall or some other object, the hull flexes, blocking a rotor and thus initiating an emergency shutdown. As the rotors are made of flexible plastic, no real damage happens. But keep your glue ready (I use Pattex Repair Extreme) to repair damages to the hull itself, which is made of foam plastic. I already broke a part, which was easy to fix with the glue.

I disabled the acceleration sensor based controlling, because it introduced another variable into the whole flying. It certainly is cool to control the drone by tilting your phone (for anyone not familiar with the AR.Drone: it connects via Wi-Fi to your Android or iPhone smartphone, which makes it really versatile), but in my experience, the tilting sensors in recent phones are a bit erratic and non-predictable. Instead you get two areas, the left one, where you control tilting and thus flight direction, and the right one, where you control height and rotation.

The main issue is the short operating time and the long wait for the battery to load again. I ordered some aftermarket batteries with more than double the capacity and a professional charger, which is able to charge the battery in about the same time which it takes you to discharge them. Even with all the built-in stabilization, controlling the drone is not easy and requires some training. Hopefully the additional batteries will allow that, so that I can someday use it outside and at heights more than 2 meters. I also ordered some bearings because I noticed that the rotors have much more clearance than they should have. I don't know if that makes much difference, but having the rotors sturdy seams like a reasonable precondition for controlled flight.

General thoughts

The drone being controlled with Wi-Fi is certainly an ingenious way, because it doesn't require a dedicated remote control. It also provides a return channel for the video feed. On the other side, the lack of a new Android app is really a let down, because by now they could have at least adapted the old one to accommodate the new video format. Wi-Fi also limits the useful range, but then again, a high-bandwidth connection which is required to transmit the video will always have some serious range limitations, or require dedicated directional antennas. I'm not yet sure if the AR.Drone is a real model airplane, or just a silly toy for people with too much money. I have yet to test the camera, and I don't expect cinema quality, but 720p30 at least sounds promising. Recording is done to a USB stick which you can directly put into your drone, or - at lower quality - directly to your phone.

DIY DCF77 Clock Posted on 04 Dec 2007 at 19:05

A year ago I built a DCF77 radio-controlled clock with perfboard and verowire as a present. It contained LED displays for time, date and temperature and a 6x7 LED matrix showing the bits received from the radio module. I used an integrated module as the receiver, which spits out the received signal as simple pulses which can be processed by a microcontroller - in this case an ATMega8.

This time I want to create the clock PCB with normal etching procedures. The verowire method worked, but was not very reliable and it was also a lot of work. Sometimes the coating of the wire would get scratched and then shortcuts would make multiple segments light up in one digit. It also requires high soldering temperatures and creates toxic fumes.

Colums and rows of the custom made LED matrix were directly connected to the microcontroller. This time I will connect the rows to a 8-bit shift register, which frees up some pins on the microcontroller. I will also use an integrated 8x8 LED matrix module from Everlight. This way I don't have the need for a double-sided layout or wire straps on the top side. The status LED will be a bi-color LED which I changed last-minute in the first version to a normal LED because of the lack of an additional microcontroller pin, and the lack of space on the board for a voltage divider to drive the bi-color LED with a single pin.

I removed the voltage regulator for the LED digits and used old-fashinioned resistors. Bacause a printed circuit board is not nearly as flexible (especially with only a single side/layer) as verowire, I had to multiplex not only the LED matrix, but the LED digits too.

The multiplexing led to a serious brightness problem with the LED digits. After soldering in 6 digits, even wires instead of resistors could not bring the digits to the desired brightness. I had to desolder all of them, and bough other ones with lower forward voltages and higher efficiency. I was lucky to get 20 pieces at the local store the day before christmas. I could also have removed two shift registers, which would have saved me a lot of traces and jumpers on the board.

The PWM temperature sensor was replaced with a one-wire type from Analog Devices, which was not optimal. While this new sensor has a much higher precision, and gives a fully prepared, digital numeric value, reading and writing the one-wire bus is very slow. In fact it was so slow, it would lead to subtile flickering on the LED digits, so I only read the value once every minute.

Another problem surfaced when the circuit was nearly completed: the DCF77 receiver would not get very good reception. Sometimes, hours passed and the receiver couldn't pick up a single consecutive minute of time data. This problem did not happen while the AVR programmer was connected. After analyzing the cause, it seemed that the lower voltage( 4.5 volts) the programmer was supplying to the target circuit allowed the receiver to have a much better reception. Because time was running away, I simply soldered in a diode with a sufficient voltage drop to allow it operate reliable at 5 volts. This fixed the problem.

Because of several flaws still existent in this design, I will not release the circuit board files. The next version will include a custom made, more reliable receiver, less shift registers and some other improvements. Stay tuned.


DIY Ambient Orb | The Beginning Posted on 01 Dec 2007 at 19:27

I always wanted a colored LED globe. The Ambient Orb device is such a globe, but with proprietary technology. I wanted to build my own, so that I can create my own light programs, tweak it, and learn some general things.

I want my "Ambient Orb" to have the following properties:

  • High brightness
  • IR remote controllable
  • Computer controllable
  • Respond to surrounding light

For now the computer interface will be provided through a micro controller and an IR transmitter diode. Different solutions would involve RF modules, utilizing plain 433/868/900 Mhz radio, ZigBee, Bluetooth or similar. Integrated modules exist, but development is time consuming.

IR transmission

IR transmission only requires a single integrated 38 kHz IR receiver module which goes for a few bucks. To send data to the orb, a simple "pod" will be constructed, containing one or more matching IR LEDs as required. A micro controller will receive commands via an USB connection and send a modulated 38 kHz signals to the orb. This means only the orbs in the same room as the computer/pod can be controlled. Possible uses for the computer interface:

  • Using as a "Poor Man's Ambilight"
  • Creating a colorful audio visualization plugin for WMP or WinAmp
  • Creating a PC GUI to set up light programs
  • Displaying messenger and mail notifications by color
  • Displaying network/CPU/power status by color
  • Displaying the weather forecast, stock market, Homeland Security threat level...

To be able to control multiple orbs independently of each other, an address switch will be included. More than 16 orbs per room would be overkill, and this switch only takes 4 pins of the micro controller.

Each orb in the room would get a different address assigned, so that each on them can be controlled individually. This approach would even work with simple non-bidirectional RF modules.



Respond to outside lighting

Another special feature will be the possibility for the orb to respond to the outside lighting condition. For this, a color and brightness sensor will be mounted inside. The LEDs will be switched off for a short amount of time, then the sensor will measure the current lighting. Based on this, the micro controller will adjust the brightness and the color of the illumination. While this is a nice effect ("display the same color and brightness currently in the room"), it is also necessary because of the high brightness I want to archive with the orb. The full power level may be right at daytime, but it could be much too bright in the evening or at night.

It would also be possible to integrate temperature, humidity, air pressure and sound sensors. This way the orb could show many different information without a computer. But I don't want to overdo it at the first shot.


Yesterday I went to IKEA and got myself a nice FADO Table lamp. I actually picked up two so I could crash one, or simply build a second orb. The lamp is very cheap, but the cover is made out of mouth blown glass, and no diffusers are needed because the glass is so milky colored.

The base is made of polypropylene and contains a socket for a bulb. I cut away the socket, so I could mount a small breadboard on top of the remaining base, inside the orb.

A short ribbon cable connects the small breadboard inside the lamp to a larger one at the outside, where I can play with different resistors and measure the current flow with a multimeter.

I started with a single RGB LED, and quickly increased this to about 10 LEDs. Each LED allows for up to 30 mA to flow through each color, but even with 10 LEDs, I didn't find the result to be satisfying. This means I will have to order something more powerful to drive the orb.

I also tested the IR receiver component, which works fine inside the orb. The receiver can be oriented in any direction, because the lamp cover will spread the IR light evenly. You simply point the IR remote to the orb, and no matter if the receiver faces you or not, the signals will be visible on the oscilloscope.



Increasing light output

To increase the light output, there are a few different light emitters available. The current RGB LEDs allow ~100 mW per color and LED. Having a red, a green and a blue LUXEON™ at 3 Watts each will thus give plenty of brightness. But having three different emitters placed in the orb bears the risk of having different colored shades visible from the outside. Thus a better approach would be to use one integrated package, possibly with multiple light emitters and an integrated heatsink, which is necessary at high power levels.

Thermal management is a big issue for high-power LEDs. While they have higher efficiency, are usually driven by lower powers and thus do not dissipate as much heat as incandescent bulbs, they also do not tolerate high temperatures.

They also exhibit an inverse temperature/conductivity behavior. They have a negative temperature coefficient, which means when the temperature increases, they allow more power to flow through them. Bulbs have a positive temperature coefficient, which means the higher the temperature, the higher the resistance, thus the lower the current that can flow through them. This prevents bulbs from getting too much current. The inverse behavior, which is a common feature of all semiconductors, means you have to watch the temperature and current carefully, because it can quickly lead to destruction. LEDs also get less efficient at higher temperatures, while incandescent bulbs have increased efficiency because more of the emitted light shifts into the visible spectrum. At low temperatures all they emit is infrared light.