RC Fireworks Ignition System

Hi there 🙂

It's been kind of a while since we published the last article. Actually the topic of this one is pretty cool and can be used for many purposes such as mole hunting 2.0 :D.

So everything started with an idea. A simple idea. "Hey! we should drop fake bombs from our R/C plane!". Then, "Hey, smoke would look great on this R/C plane!", and finally, "Hey! We should launch fake rockets from our R/C plane!" (and yes, we are grown up people with employement... 🙂 )

We started doing it by hand, firing the smoke and the firecrackers with matches just before to take-off. It was nice, but we had to hurry and we could not decide on when the smoke/firecracker should be launched.

The principle

After looking on the Internet for automatic ignition systems, we came up with our personnal DIY system, which, while not perfect, gives pretty neat results!

There isn't that many options to automatically light a firecracker's wick:

  • We can use the principle of a lighter, that is, having an embedded tank of flammable gaz, a system to generate a sparkle, and an automatic valve.
  • Or we can use a thin steel wire and put a large current run it so it would become incandescent.

 

The first solution would involve a too complicated system for the sunday DIYers that we are. Also, we were not sure how it would behave with all the relative wind there is on a plane. We decided to adopt the second method.

To have a reliable and effective ignition system, the key is to reach a temperature that would effectively light the wick, but not TOO hot in order not to destroy the wire or even the plane's battery.

First version

The coil

So we started by using a wire that came from a stranded wire (itself coming from an old computer power supply unit). We took 3 or 3 strands, twisted them, cut around 10cm (4inches) of it and shaped it as a coil around the wick. then, we put our protective glasses, gloves, and put the power. the coil instantly melted, ligthing up the wick! So it worked 🙂

This coiled cooper wire, when a hight enough current flows through it, get very hot and burn.
This coiled cooper wire, when a hight enough current flows through it, get very hot and burn.

The switch

We only had to find a way to put the power when the plane was in the air. That was a tricky question because in an R/C plane even if you have a very powerfull battery that can provide 300 or 400W easily, you still need a switch that will withstand this kind of power. But in a plane you also have the PWM output of servos comming from the R/C receiver. Several solutions here : the most aesthetic one is to buy/design an electrical relay that is triggered by a channel of your R/C controller. but as I said, we where in a hurry to make this plane in the air, so we opted for the most epic switch ever: a servomotor with hot-glued wires on it that make contact when we trigger a channel on the transmittor. Effective, very ugly, that was perfect!

A really basic servo switch that is used to enable current flow through the ignition system.
A really basic servo switch that is used to enable current flow through the ignition system.

So it worked like this for a few flights, with the obligation of crafting a new coil for each successful ignited firework. kind of boring after a few ones... So we decided to improve a little the system.

The improved version

Basic physics..

I had some steel wire remaining from an old project (a hot-wire cutting table to cut airfoils out of foam blocks). I knew that it could become very hot without breaking by experiment it back then. So we first got some wire, and measured the electrical resistance per meter which was around 10ohm per meter. Let call it Rw.
The resistance of a wire is proportionnal to its length. So we have:

R=R_w*L


By experimentation, we also knew that a power of around 100W would do the trick : it's enough to provide very big sparks, but not enough to damage the battery and to reduce the autonomy of the plane. So to calculate the length of the wire we need, it's really easy physics :

it's a simple resistive circuitry, so we have the famous

U=R*I \to R=\frac{U}{I}


Also the power consumed is given by

P=U*I \to I=\frac{P}{U}

Injecting the ohm equation gives us

R=\frac{U^{2}}{P}

We inject the very first equation giving us

R_w*L=\frac{U^{2}}{P} \to L=\frac{U^{2}}{P*R_w}

Only very basic math and physics here. Applying it to our problem gives us (the average voltage on a plane that is flying with mid throttle on 3S is 11V).

L=\frac{11V^{2}}{80W*10\Omega/m} \approx 15cm \approx 6inch

On the Bixler...

That is a neat result because it allows for a small enough wire to be shaped as we want to make it easier to lock the wick. We decided to cut it in half and put it each side of the Bixler's wing. We cut a can and glued it to protect the wing from the rocket's projections. We also doubled the circuitry with 2 switches to have another ignition system to light up smoke 🙂

The tail of the rocket is inserted inside the plastic tube, and the wick is holded inside the wire's loop.
The tail of the rocket is inserted inside the plastic tube, and the wick is holded inside the wire's loop.
The smoke bomb is placed in the hole, and its wick is holded inside the wire's loop.
The smoke bomb is placed in the hole, and its wick is held inside the wire's loop.
We can see the rocket that is holded inside the plastic tube with tue wick pinched on the hot wire.
We can see the rocket that is held inside the plastic tube with the wick pinched on the hot wire.

Here is an amazing video demonstrating the rockets and the smoke bombs, it also features some night flights with the Bixler 2!

Magnometer calibration

All of our smartphones have an integrated compass. It can be very useful when you are looking for in which direction you should start heading while walking. However, you have probably noticed that sometimes, the direction showed by our phones can be quite...wrong! It happens when the compass has not been calibrated correctly. But if you try to turn the compass around in every direction, you'll probably notice that the direction arrow finally takes the right direction. Why? Because the smartphone is doing a "live" calibration as you move the compass.

What you should keep from this introduction is that compass calibration is fundamental ! Don't intend on using a magnetic sensor in your project unless you have it calibrated. Otherwise, the data you'll be using will probably be inaccurate, if not completely random 😀

Back to basics
What does a magnetometer do?

"Well, it obviously gives you your heading!"

"NOPE! (Chuck Testa)"

The magnetometer gives you a three dimensional vector of the magnetic field it senses. This magnetic field is a combination of both the earth's field and of the magnetic field created by all the surrounding objects. And this second magnetic field is far from being negligible,  especially in our hobbyist projects where there's electronics (and motors) all around.

Theoretically, the measured magnetic field should :

  •  be centered around 0
  • always have the same strength

If we could represent it in 3D, it should basically look like a perfect sphere centered in 0.

In reality :

  • it is not centered around 0, because of the presence of other magnetic fields around the sensors(such as other magnets, electric wires) : it is hard iron distortion.
  • it does not have a constant strength, because of the presence of other ferromagnetic materials around the sensors, which skew the magnetic field. This is soft iron distortion.

What we get is essentially a potato-shaped magnetic field (because of soft iron distortion), that is not even centered (because of hard iron distortion).

Calibration techniques
Hard Iron distortion

Hard iron errors introduce an offset in the magnetometer data

\mathbf(Field_{magnetomer} =Field_{earth} +Field_{hard iron})

 

To get this offset is pretty simple : we keep track of the maximum and minimum values the magnetometer outputs on each axis while moving it in space. From what we know the maximum and minimum should be centered around 0, so we get the offset by :

 x_{offset} = \frac{x_{min} + x_{max}}{2}

We can then subtract the measured offset from each raw measurement in order to get  hard iron free data.

Soft Iron distortion

Here, the work consist in transforming a potato in an orange. Or, transforming an ellipsoid into a sphere, if you prefer. It's actually easier than it sounds. There are  obviously mathematical formulas that involve matrices but let's keep it simple here.

Let's say earth magnetic field's value is F. It is the norm of the vector given by the magnetometer. While we've seen it should be the same on the three axes, experience shows it's not. So let's assume we have measured the maximum magnetic field Fx for the x axis,Fy for the y axis, Fz for the z axis.

We then calculate the average field value F by :

 F = \frac{F_x+F_y+F_z}{3}

Let's assume that F = 1. If F_x = 0.8, it means that F_x is only 80% of the average field value. Hence the potato. Now if we simply multiply all the incoming x values by F/F_x, the potato effect, will be gone, as we expand the range of the x values so that it is no longer 80% of what it should be, but 100%.

Scale_x = \frac{F}{F_x}

Final equation

If we no combine the two equations and use vectors, we get:

\mathbf(Field_{corrected} = Scale * (Field_{raw} - Offsets) )

Scale transforms the potato into an orange(soft iron distortion) and the Offsets vector brings it back in the center(hard iron).

Calibration process

The calibration consist in getting the min/max values of x/y/z fields, and then calculations the offsets and scale factors. The more you move the magnetometer in all directions, the more efficient your calibration will be.

Using calibration data

// We get the raw values here  in mx,my,mz

//(this is pseudo code)

mag.getHeading();

// Now we apply the calibration data

mx = (int)((scale_x)*(mx-x_offset));
my = (int)((scale_y)*(my-y_offset));
mz = (int)((scale_y)*(mz-z_offset));

Results

Using Processing and  a slightly modified version of this program, I was able to quickly draw the 3D representation of the magnetic field. The video shows the before/after.

 

As you can see, hard irons distortion was HUGE before calibration. I could never have gotten reliable readings without correcting them. Soft iron errors were also present, and completely removed by the calibration. 🙂

 

 

 

 

 

The drone parachute

Let's talk about parachutes.

Multicopters can become deadly weapons if the motors stop spinning as they should. There are so many reasons for a failure to happen (bad motors, bad battery, radio problems,etc...)  that it is absolutely necessary for the pilot to anticipate it, especially if you intend to flight over people's head!  We made the choice to never fly directly above people, but if you're willing take that risk,  you might be interested into getting a parachute on your drone . That's why we designed last year a DIY parachute for our quadcopter  🙂

The principle is very simple : the parachute is carefully folded  in a tube on top of which lies a lid that a servomotor keeps closed. At the bottom of the tube, a big spring pushes strongly the parachute towards its top end. So if the servo lets the lid go, the spring will push the parachute in the air.

It may be hard to believe, but the parachute will fit in the tube !
It may be hard to believe, but the parachute will fit in the tube !
The spring is separated from the parachute by a CNC milled ring.
The spring is separated from the parachute by a CNC milled ring.

I recommend you use a strong spring, so the parachute is entirely pushed out when the servo releases the lid. The spring we used is 10cm long, has 8 turns and is 3.5cm wide. It can be fully compressed under pressure, which is what we wanted here, in order to get the smaller parachute we could.

A hook holds the string to the bottom plate
A hook holds the string to the bottom plate

One of the major problems with parachutes is that the air needs to get "under" the parachute envelope in order to make it act as it should. If it doesn't , the parachute will become useless. We followed the method described in the following video :

 

This is how the parachute looks before we insert the actual parachute. The spring will eventually be pressured until its minimum lenth
This is how the parachute looks before we insert the actual parachute. The spring will eventually be pressured until its minimum lenth
We used a glass fiber bottom plate as it needs to resist to a lot of pressure
We used a glass fiber bottom plate as it needs to resist to a lot of pressure
Bottom plate. It can attached to your frame by screws or zip-ties (we love them :) )
Bottom plate. It can attached to your frame by screws or zip-ties (we love them 🙂 )

Parachute surface calculation

 

Obviously, your parachute's surface needs to match the weight of your copter, and the desired landing speed you would like to reach. I think a commonly accepted falling speeds sits around 5m/s (18km/h).

We found in the past a pretty useful formula that gives the diameter of tissue to use depending on the weight you want to slow down and its expected falling speed:

 Diameter = \frac{70*\sqrt{m}}{V}

, with m in grams and V in km/h.

 

For our 1kg drone, it gives us a diameter of 122cm. As you can see, the parachute can quickly become huge compared to the size of your multicopter, and you should maybe start thinking about where to place it on your drone from the very beginning of its conception.

For our quadcopter, we used a slightly smaller parachute (taken from a distress rocket) than the 120cm recommended size given by the formula, which led to higher falling speeds than the expected 5m/s, but it stayed slow enough to keep the drone intact after many, many test flights ! 🙂

Parachute ready for insertion
Parachute ready for insertion
See, it fits ! :)
See, it fits ! 🙂
Ready to go!
Ready to go!
The servo arm is under a lot of pressure here.
The servo arm is under a lot of pressure here. We used the TGY-53317M servo for this parachute.

 

Here's the final video 🙂


Comment if you have any question ! 🙂

PiWeather : How to communicate wirelessly between an Arduino and a Raspberry Pi

If you wonder what PiWeather is, check out the first article I wrote !

Raspberry Pi FTW !
Raspberry Pi FTW !

One of the key part of this project is to first determinate what technology to use to transmit the data and second how to encode the data to send. What I wanted was:

  • Reliability
  • Low power design
  • Good range (enough to cover a small house)
  • Ease of use
  • Something cheap
  • Something that could work simply on the Arduino and Raspberry Pi side

RF chip

A standard 433 MHz RX/TX couple

My first choice was spontaneously to pick 433MHz RX and TX as they are incredibly cheap and can reach a pretty long range if you associate them with the right antennas. The problem with these is that the very low-level side of the transmission. If you put the TX pin high, the RX pin will go high too, and that's it. You really have to do all the encoding by yourself, and if you want it to be really reliable, you must provide a way to ensure all your data were transmitted correctly (like a CRC).  I first thought I would have to cope with this and handle all this low-level part by myself on both the Pi and Arduino's sides, when I stumbled upon the one RF chip I needed: the 2.4GHz nRFL24L01+.

nRF24L01+
The nRF24L01+ used on my first prototype.

The nRF24L01+ was exactly what I needed: cheap, low power, easily connected to a Pi or an Arduino through SPI, built-in CRC, both RX and TX at the same time, multi pipe, and more!

It also is really easy to use through SPI: just give it the bytes you want to send (up to 32), and send it to the address of your choice. The same thing goes for the RX mode, it can even generate an IRQ when a message has come!

I used the library from Stanly Seow on both Arduino and Raspberry's side, and it works pretty good! One flaw of the Pi's implementation is that it doesn't use interrupts generated by the nRFL2401+, so it kind of stalls the Pi polling the chip. I modified it a bit to use interrupts from the great WiringPi library, allowing my program to sleep 99.9% of the time. I will get into these details in an other post, stay tuned 😉

Okay, so I know how data will go from my sensor units to the Pi. But what am I going to send?

Messages

So far, I've thought about sending the following data to the Pi from the sensor units:

  • Temperature
  • Pressure
  • Humidity
  • Wind speed
  • Wind direction
  • Rain metrics
  • Unit battery level, to detect low voltage

Also, my units needed some kind of address or unique ID so the Pi could easily recognize them, so I added an ID in the list of things I could possibly send. I could have decided of my own encoding format, but what if I change in the future the things I send and in which order, etc? You can see now that encoding the data in a forward compatible way is really not that simple!

I actually never thought about encoding myself the data 😀 It was just to show you that it is definitely not a piece of cake. I knew exactly what I needed to use : Google Protocol Buffers

From the Google website , "Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler". You can find libraries to use them in almost any available language, from a micro controller with 2kB of RAM running C code, to a server running PHP or Python.

So how does it work?

You first describe the messages you want to send in a file having the .proto extension:

message SensorData{
 required int32 id=1;
 optional bool binding= 2;
 optional float temperature = 3;
 optional int32 battery_level = 4;
 optional float pressure = 5;
 optional float humidity = 6;
 optional int32 type = 7;
 }

message is the keyword required to start defining a message. Then it looks a bit like a mix of a C structure and enum declaration. You define your fields and attribute them a unique ID (ex : the field temperature has the ID 3), and then add if your field is optional or required in the message. In this case, each of my sensor units will have to send its ID to the Pi during a transaction so the Pi know who it is talking to, but some sensors will retrieve temperatures, some wind speed, some pressure, so I made all the other fields optionals.
If I want in the future, to add a new data to my message SensorData, such as windspeed, I can just modify my the proto file like so:

message SensorData{
 required int32 id=1;
 optional bool binding= 2;
 optional float temperature = 3;
 optional int32 battery_level = 4;
 optional float pressure = 5;
 optional float humidity = 6;
 optional int32 type = 7;
 optional float wind_speed = 8;
 }

And you know what the great part about this is? It will be backward compatible with the existing sensor units using the "old" messages! So no need to re-flash the existing sensor units if I had optional fields in my messages, which is a very, very nice thing 🙂 I won't get more into details for GPB here, their website has tons of examples of how to use them!

To actually use these messages, you need to translate them into the language you are using. I chose to use NanoPb, which is a very good implementation of protocol buffers for embedded systems. It has a tiny footprint (less than 2kB!) and generates all the code you need to include in your project, so no need to link against a lib, which is always good news 😉

NanoPb takes the proto file and creates the associated C structures, encoding/decoding functions for my messages. The generated structure looks like this:


typedef struct _SensorData {
 int32_t id;
 bool has_binding;
 bool binding;
 bool has_temperature;
 float temperature;
 bool has_battery_level;
 int32_t battery_level;
 bool has_pressure;
 float pressure;
 bool has_humidity;
 float humidity;
 bool has_type;
 int32_t type;
} SensorData;

Let's say my sensor unit has both a temperature sensor, and a humidity sensor. If I want to send the data to the Pi, I can do like so:

 SensorData message;
 uint8_t sensorDataBuffer[32];/*Maximum size you can send with the nRF24L01*/
 pb_ostream_t stream;

 message->has_temperature=true;
 message->temperature=sensor.temp();
 message->has_humidity=true;
 message->humidity=sensor.humidity();
 message->id=42; /*The unit ID*/

/*Let's encode this with nanopb*/

 stream = pb_ostream_from_buffer(sensorDataBuffer, sizeof(sensorDataBuffer));
 pb_encode(&stream, SensorData_fields, message);

/*Now our encoded data is in the sensorDataBuffer, ready to be sent ! */
 nRF24.send(sensorDataBuffer);

It's as simple as that, and very powerful. I think protocol buffers are really the right way to go for size constrained embedded applications such as this one. But don't think they are only used for small applications, they can be so powerful that they are wildly used in different industries to send big loads of data, through nested messages for example 😉

So that's it, I introduced you the chip I use to make the communications, and the format I adopted for the messages my sensors send wirelessly. I think I will go back on this in a coming article where I will define exactly how the software I developed works.

Cheers 🙂

PiWeather weather station : introduction

The weather station project (codename : PiWeather)

It's been quite a while we haven't posted anything here, but it doesn't mean we're not working on cool things !

A few months ago, I thought it would be cool and useful if I could monitor temperatures inside and outside of my apartment. This way I could know when to open the windows or close them in summer when it gets warmer outside than inside, and the other way around. Then I figured that I might as well add other data, such as pressure, humidity, maybe wind speed and others if I gather the time and the energy to go through with my project, which I admit, rarely happens 😀

Anyway, things are now moving with the project so now is the time to write here. The idea for this first article is to introduce briefly what I will do and how I am planning to do it. I will update this article in the future with links to the latest articles I post about the PiWeather project.

Architecture

The PiWeather main architecture
The PiWeather main architecture

As you probably guessed from the project's codename, the central unit is a Raspberry Pi. The Pi itself does not host any sensor. It will instead be connected wirelessly to them, or more precisely, to what I will call from now on “sensor units”. These sensor units will be Arduino based (what a surprise!) sensor platforms. I mean by this that a sensor unit can host more than one sensor on board, like both a pressure sensor and a temperature sensor for example.

Goals

My goals are :

  • No wires : While the Pi will be connected both to a power source and through Ethernet, the sensor units must be wireless.
  • Plug and play sensors. Just put a battery inside a sensor unit, and you're done. No complicated setup on the computer, through switches, nor command lines.
  •  Longest possible battery life for the sensor units. If you have to change batteries every other week, then being wireless has in fact no point.
  •  Web interface to monitor and access all the logged data
  •  Use cheap parts

There are probably tons and tons of similar projects on the Internet, and I don't really care. The point is as always to have fun, learn, design, and do something useful...Okay, it's not always useful 🙂

Technical topics

On a technical side, the topics I will try to approach during this long journey are:

  • The sensors I used or plan to use
  • Low power Arduino design
  • Arduino development in Eclipse
  • Raspberry Pi program cross compilation
  • Communicate wirelessly between an Arduino and a raspberry Pi
  • Google protocol buffers
  • Symfony 2 PHP framework
  • Create a daemon for Linux
  • Interrupts on Raspberry Pi
  • PCB design
  • Case design (if I make to this stage obviously :D)
  • Twitter Bootstrap
  • Javascript
  • jQuery
  • mySQL
  • phpmyadmin

This list is not exhaustive, but it shows that this project approaches a very broad range of domains and languages .

The articles won't be a series of tutorials. Nothing I will do is new, I will instead focus more on how  all of these things work together, and how the design evolves through time.

And this ends this introduction post 🙂

Follow our RSS feed if you want to hear more about the PiWeather project !

The tricopter

The tricopter
The tricopter

Hi everyone!

We have been pretty busy since we got our Ardupilot and setting it up was so easy and fun that we decided that it could be fun to get another multicopter with a  "ready to fly" flight controller, so we would just have to take care of building the frame ! We decided to build a multicopter and use it with a cheap multiwii board from hobbyking 🙂

As great as the Ardupilot is, we didn't want to pay 180$ again for a flight controller, and we thought that this time we didn't need a full fledge controller, with GPS and telemetry; just something to have fun with. So we started to look for a cheap multiwii board, and we found "the one" on hobbyking: the Multiwii 328P flight controller.

Our Multiwii flight controller

The price of this thing (28$...) is actually pretty insane, and I would recommend this board to anyone who would like to work with IMUs, to track motion and position, not just to power a multicopter! Just plug it into your computer, launch the Arduino IDE, select Arduino Duelmilanove 328 in the board list and you're ready to go! We definitely should have bought something like this when we started to work on our quadcopter, it woud have been so much cheaper than buying the sensors separately and would have avoided so much troubles with soldering/ fitting everyhting on a tiny PCB !

We decided to build a tricopter because we always thought that their flight behavior seemed really nice and we wanted something a bit smaller and a bit more nervous than our quadcopter. Our quadcopter was a pretty standard one, with arms 25 centimers wide, a good size to get stability and space to carry a GoPro and a FPV setup. We decided to make the tricopter is a bit smaller, with motors 20 centimeters away from the center of the tricopter triangle and to use the same Turnigy SK3 1130kv motors as on our quad. They work great and we had 3 motors left, so no need to buy new ones ! And with these motors, the tricopter would have enough power to carry a GoPro 🙂

While we took the "hardcore" approach with our full carbon quadcopter, designing it with CATIA, cutting it with a CNC mill, the tricopter construction was quite the opposite. It took us just a couple of hours to build it from scratch with no real plans. The hardest part was the rear servo mecanism, as it always is with tricopters.

Tricopter
The rear motor of the tricopter
Tricopter
The rear part is made of an aluminum part and a Meccano part screwed together and attached to the servo on one side, and to bearings on the other side.
Tricopter
The rear digital servo is a Turnigy TGY-2216MG.

Everything is made of carbon fiber, so it's pretty lightweight and power efficient. We get more than 11 minutes of flight with a 2200 mAh 3S LiPo battery.And it flies very, very well. Tricopters are very fun to pilot, there behavior is really close to an Heli behavior, it kinds of floats in the air and vertical descents can be very fast and stable. The yaw control is obviously much stronger than on a quadcopter so it can be maneuvered easily in very small areas. It carries a GoPro and its case without any problems, so we think it's the perfect toy to play with if you want to film withou stabilization nor FPV!

Tricopter
The zip-tied multiwii, a receiver, a 3S battery, and you're good to go 🙂
Tricopter
The bottom part fo the tricopter, with space for FPV equipment.

If you are considering building a drone, you should really consider building a tricopter. It may be harder to figure out how to handle the yaw servo, but it's so fun to play with! Go for it 🙂

A little video where we used the tricopter (80% of the footage)

Stay tuned for more fun with drones and other things 🙂

Animal motion detection : an Arduino project for photography

Hungry (angry?) pigeon
A real angry bird.

I'm going to talk to you about a simple, yet fun project I did last year : an animal detection device that could control my DSLR and take pictures.

I thought that it would be a fairly simple thing to do with Arduino and a motion sensor. I chose to use an IR sensor because they are very cheap and efficient, and bought the PIR sensor from parallax. It just has a single bit output, so it's super simple to use with an Arduino. It is very sensitive and fits well this application. The only bad thing about it is that it has an incorporated LED that turns red every time a motion is detected, which is probably useful for most use cases, but not in my situation 😀 I just cut the circuit track leading to the LED so it wouldn't turn red anymore.

Motion detection on Arduino
The motion sensor and its 3 pins : The one bit output, VCC, and GND.

Once we have the information about whether  a living thing is in front of the sensor or not, we need to control the camera to trigger it. This part really depends on what kind of camera you own, if it can accept a remote control or not. If it doesn't, one way to trigger it is to use a servo motor to press the shutter button (with the Arduino Servo library), but the problem might be the noise it generates when moving, which could scare the animals. My DSLR ( a  Canon 550D) has a jack input for remote control which makes it really easy to command. What you will need is a standard 2.5mm stereo male jack, some wires and that's it!

Canon Remote Controller Wiring (2.5mm mini-plug and N3 plug)

You just need to solder the 3 wires to the jack connector. One for the ground, one for the focus command, and one for the trigger command. To focus, just put the focus contact to the ground; and it works the same way to take a picture.

So how to control the camera with an Arduino?

We will use two digital ports of the Arduino to control trigger and focus of the camera. When these outputs will be set LOW, they will fire the action they are supposed to create (focus or trigger). When set HIGH, nothing will happen. To protect the camera, you should put a resistor between the outputs and the camera (I used 2.2K resistor) just to make sure no current goes into the DSLR.

The final schematics look like this:

The very simple schematics of the breadboard circuit. The LED is simply there to control if everything is working (on when something is detected). You can click for the full size image.
The very simple schematics of the breadboard circuit. The LED is simply there to control if everything is working (on when something is detected). You can click for the full size image.
Motion detection on Arduino
The real life schematics 🙂

The program will be pretty simple too : if something is detected, take a picture and turn on the control LED 🙂

Here it is:


#include <Camera.h> // The Camera library makes it easier to control a DSLR

/********PINS*********/

int PIR_Pin = 3; //the digital pin connected to the PIR sensor's output
int LED_Pin = 2;
int focusPin=6;
int shutterPin=7;

/********VARIABLES****/

int idletime =0; // The time since last picture
int lastshot=0; // The millis() when the last picture was taken
int burstInterval=5000; //The time between pictures when motion is on
int calibrationTime = 30; // The sensor calibration time (so we don't get false positives when we start the Arduino up)
long unsigned int lowIn;//the time when the sensor outputs a low impulse
long unsigned int pause = 2000;// The time necessary for the motion to be gone after the sensor has gone to a LOW state
boolean lockLow = true; // goes to false when a motion is detected
boolean takeLowTime;
boolean burst=false;// burst mode indicator
Camera* eos; // a pointer to our DSLR

void setup()
{
 eos =new Camera(focusPin,shutterPin);
 Serial.begin(9600);
 pinMode(PIR_Pin, INPUT);
 pinMode(LED_Pin, OUTPUT);
 digitalWrite(PIR_Pin, LOW);

 //Sensor calibration
 Serial.print("Calibrating sensor ");
 for(int i = 0; i < calibrationTime; i++){
 Serial.print(".");
 delay(1000);
 }
 Serial.println("SENSOR READY");
 delay(50);
}

void loop()
{

 if(digitalRead(PIR_Pin) == HIGH){ //If a motion is detected
 if(idletime>30000){ // If the camera is in sleep mode
 (*eos).TriggerFocus(); // wake up the camera
 idletime=0;
 }

 digitalWrite(LED_Pin, HIGH); //signal that a motion is detected
 if (burst){ //Once the motion has been detected and a picture taken, we go into this mode to keep taking pictures every 5s until the motion ends
 delay (burstInterval);
 (*eos).TriggerShutter();
 lastshot=millis();
 idletime=0;
 }
 if(lockLow){
 lockLow = false;// We enter in "motion" mode
 (*eos).TriggerShutter();// We take a picture right away
 delay(1000);
 (*eos).TriggerShutter();// We take a second picture 1s later
 delay(2000);
 lastshot=millis();
 idletime=0;
 burst=true; //Now we go in burst mode,ie picture will be taken every 5S
 }
 takeLowTime = true;
 }
 if(digitalRead(PIR_Pin) == LOW){ //If mothing is detected
 digitalWrite(LED_Pin, LOW); //Turn off the LED
 if(takeLowTime){
 lowIn = millis(); //save the time of the transition from high to LOW
 takeLowTime = false; //make sure this is only done at the start of a LOW phase
 }
 idletime=millis()-lastshot;
 burst=false;

 if(!lockLow && millis() - lowIn > pause){ // If there has been more than 2000ms inactivity, we exit the motion mode
 lockLow = true;
 }
 }

}

The Camera library is included in the project. It is a very simple library that avoids you to code the boring stuff (like setting LOW the trigger output, then HIGH again etc 🙂 )

To host the electronics and the camera, I built a wooden box big enough to put everything in easily, with a lid so It could be weather resistant. Here are the pictures

Motion detection on Arduino
You can see the PIR sensor, and a layer of tape around it. The goal is to make its FOV a bit narrower, so it only fires when the animal is in the camera frame.
Motion detection on Arduino
I used an old remote control from a broken RC helicopter (RIP 🙁 ) to power the Arduino. You can obviously put anything you want in here ( staying in the 7-12V range is recommended )
Motion detection on Arduino
Top view of this masterpiece of engineering.
Motion detection on Arduino
The camera is held here with its tripod mounting hole. You can also see the stereo jack.
Motion detection on Arduino
The lid. The foam layer is there to protect from the rain.
Motion detection on Arduino
The whole thing, with the 550D and the Sigma 10-20mm. The bungee cords can be used to set the device in a tree.

This is obviously far from being perfect, the DSLR shutter noise scaring most of the animals away after the first picture, and the size and weight of this thing making it hard to place anywhere you'd want 😀

On the other hand, it does work pretty well and can take some fun pictures.

Cat eating a pizza

Hungry birds.

Hope this can give little help to those of you looking for ways to photograph animals 🙂

New videos/ photos. When a drone goes 250m high

Hi everyone!

I created a new album on my flick'r account : Drones and stuff. I will try to update it frequently with pictures of everything we do 🙂

Our quadcopter
Our quadcopter

We also posted 3 new videos on Youtube:

A FPV flight where we reach 250m of altitude with our quadcopter

[youtube]http://www.youtube.com/watch?v=GxX-b6REVtg[/youtube]

A peaceful flight near Saint-Benin, France.

[youtube]http://www.youtube.com/watch?v=_EMD8Hvcxsg[/youtube]

A little "ad" for multicopters 🙂

[youtube]http://www.youtube.com/watch?v=muKquqGi12Y[/youtube]

More to come soon 🙂

The octocopter

One of the first flights
One of the first flights

We recently built a brushless gimball for our Gopro but our quadcopter became too heavy to fligh safely, so it was time to get something bigger. We first thought about a nice hexa, but we couldn't resist to the appeal the octocopter. We wanted to get enough power to carry a lightweight DSLR such as my 550D, or simply all the FPV equipment we have, plus our Gopro on its brushless gimbal; all of this with a 10 minutes autonomy.

It all went so fast. Add to cart. Pay. Bam, it's delivered. We chose this time not to build the frame ourselves, just to put everything together, and have fun.

The Hobbyking X930 895mm glass fiber frame.

We bought this big and cheap octocopter frame from Hobbyking, the X930. The arms are in aluminum and the rest of the frame is made with pretty thick glass fiber.

[notice]THE MOTOR MOUNTS ARE VERY WEAK.[/notice]

If you look at the comments on Hobbyking's website for this frame, you will see that many people (including us) broke several of them while flying. So don't even try to fly with them, they will eventually break. We reproduced these motor mounts in aluminum with our CNC and mounted them under the original ones to get  rock solid motor mounts.

Turnigy 3536 910kV
The Turnigy 3536 910kV motors mounted with 12x4.5 props. You can see the CNC milled aluminum motor mount under the original one.

The Turnigy 910kV motors provide plenty of power to lift anything you'll throw at the octocopter. They are controlled by 40A controllers (Turnigy Plush 40A), which are fed by an octocopter power board.We use two 3S 5000mAh batteries in parallel to reach our desired autonomy.

Our octocopter power stage
The power board and the 8 ESCs.

Be careful with this board, it is only certified to deliver 8x10A, which is really low (our motors can take up to 35A). We chose to add a lot of solder on the PCB in order to increase the amount of current it could deliver and it seems to be working fine so far.

We flashed our Ardupilot with the latest octocopter firmware and tried to find the best PID values for the octocopter. It does fly pretty well now but there is definitely room for improvement.

Our octocopter
The "command" part of the system.
Our octocopter
Ready to fly. (Yes, we broke one prop so we replaced it with a 9x4.7 :D)

We'll try to fly FPV with it as soon as we can with our new new brushless gimbal (article to come 🙂 ) and we will obviously post videos of it here and on YouTube on our channel. 

We'll be back soon 🙂

The Ardupilot Mega 2.5 : why it's awesome.

After a good run, we decided it was time for our homemade quadcopter controller board to go. Actually, it had to. It started to wobble in the air pretty violently for no reason while flying. We made no change to the program, nor touched the hardware, and since it was working fine before, we figured that it probably came from an electronic problem somewhere in the tons of wires and soldering we made. Pretty hard to "debug"...

So here we were, on 3D Robotics website, ready to click the famous "Add to cart" button. And we finally did click, after a long time of hesitation. It was not that long, in fact. It was a no-brainer. For 180$, you get a tiny assembled PCB with an accelerometer, gyroscope, magnetic sensor, pressure sensor, GPS, current sensor, with completely open-source software that will let you do basically anything you could want to do with any kind of RC model. Not only this works with quadcopters in + or X configurations, it's also made for RC cars, planes,hexacopters, Y6 copters, octocopters, tricopters, and even helicopters! 180$ seems pretty cheap now, doesn't it? 😉

All the firmwares you can upload to the onboard Arduino mega
All the firmwares you can upload to the onboard Arduino mega
We don't regret having spent so much time on our controller board at all. It was a great experience, it worked pretty well and got us to understand pretty much everything about how these drones fly. We just couldn't make something so small and so well designed ourselves in our garage. Plus, the huge community working on the Ardupilot's software came to something close to perfection, with a dedicated windows program (APM mission planner) that can control every single parameter of the drone, communicate with it in flight via a telemetry module, prepare mission scripts with GPS waypoints and actions to take, read flights logs and export them into Google earth-friendly KML files (and more)!

What comes with the Ardupilot
What comes with the Ardupilot
We ordered the fully assembled APM 2.5 with a Mediatek GPS, and a current sensor. It also delivers with a USB to micro USB cable so you have everything you need to start playing 🙂

The Mediatek GPS,  current sensor and APM2.5
The Mediatek GPS, current sensor and APM2.5
It turned out very easy to setup on our existing quadcopter frame. We followed the instructions given on the arducopter google code project and everything went smooth and fast! The steps are the following:

  1. Download mission planner and install it (it will also install the Arduino mega drivers on your computer)
  2. Plug-in your APM
  3. Start mission planner
  4. Choose from the drop-down list the COM port you APM has (check Windows Device manager to find which one)
  5. Go on the firmware tab, select the one you want to use, upload it!
  6. Press connect and you're ready to configure everything!

The default parameters should be fine for an average quadcopter frame (50cm wide, ~1200kv motors, 1kg). At least they are okay for flying. We lowered a bit the PIDs on ours because it was a bit too nervous but the first flight was still pretty good and the stability in the air was quite amazing, even with high winds!

A log from the the Ardupilot
A log from the the Ardupilot
You can assign any action you want on your radio extra switches and knobs. The most impressive one obviously being the "Auto" mode, where the quadcopter will follow a script of actions the user can write with the mission planer software. Just flick a switch, sit down and let the drone take off, fly to the waypoints you told him at the altitude you told him, and then land where you told him.

Casual flight around the Eiffel tower...
Flying has never been so easy! 😀 Also, it is really, really nice to have the return to launch (RTL) feature, which will bring back the drone where your armed the motors. It is a life saving feature, for those of us who put expensive cameras on their drones and don't want to crash them in case they lose the orientation or the video signal when doing FPV. It actually happened to us in one of our first flights. We were about to test the RTL feature when the drone was so far that we couldn't see its orientation anymore. We were already thinking about the "walk of shame" we would have to take with the broken pieces of our beloved quadcopter. But none of that happened. We flicked the RTL switch, and the drone came back home 😀 This feature really is a must-have! It's awesome and works great. We've only played with it last weekend, and even though it was a pretty windy weekend here, we managed to fly up to 80 meters with no problem whatsoever for the drone!

OMG, we see that the earth is round! No. It's the Gopro fisheye that does that. But everything seems pretty tiny at 80 meters of altitude.
"OMG, we see that the earth is round!" No. It's the Gopro fisheye that does that. But everything seems pretty tiny at 80 meters of altitude.
If there should be a conclusion to this article, it would be : buy the Ardupilot. It's great, works with everything, has a big developer community around it, and is actually not that expensive when you think about all the electronics it contains.
We just ordered the telemetry and OSD module so we can go all FPV on it 😉 We are definitely going to play our quadcopter in the weeks to come, and will try to add a nice video to this article (or to a new one) to show you what you can do which such a powerful tool 🙂