A newb’s attempt at flight

Well, the title says it all! I finally hooked up everything and decided to see what would happen if I set uniform speeds on all four rotors without a control algorithm behind it all… Not a very good idea. I was fairly lucky in that nothing severe happened to me, the other “innocent” bystanders, nor the quadrotor. The only damage was to one of the propellers. For those who haven’t experienced it before… No matter how hard you try, there will always be some imbalance so the quadrotor will just fly off to the side. I left it on for just about a second or two (indoors) and the times when I set the speed high enough to lift off, it crashed. For those who have already achieved flight, forgive my noobishness!

Okay, so let’s go back a bit to the attaching of the various components. The motors attached using screws. Make sure you firmly fix the propellers. Usually, there is some sort of tightening mechanism. In the case of my motors, it works like so:

Fixing the Propellers

Fixing the Propellers

So what next? The motor drivers of course. You may need to take off the motor to solder the wires to the motor driver. Three (thick) wires connect the two. If you connect the first first of the ESC to the BLDC, the second to second and the third to third, the motor will rotate in one direction. If you flip any two (Or invert the order itself which is what I did by placing the ESC upside down), the motor will rotate in the opposite direction. Make sure two are in one sense of rotation and the other two are in the opposite sense. You can only determine the exact direction by running the motor. Put the two on one sense on opposite ends. Run them and adjust the blades accordingly such that all four motors push the air down. MIT’s Aerospace Controls Lab has made and implemented a variable pitch propeller. Check it out here: http://www.youtube.com/watch?v=Vy5Ky50eGJs

I attached the ESCs to the chassis using these connectors (Cable Ties):

Cable Ties for ESCs

Cable Ties for ESCs

I actually had to couple a pair of them to get the required size but it is very firm provided you tighten it well enough. You can also see in the image above the wire connections. I soldered the wires (A little painful due to the thickness) and then used heat shrink to make the joint more stable. Don’t forget to put the heat shrink before you solder!

The next thing I thought I would need was a custom cape for the sensors and a transistor for the microcontroller to transistor interface. I used 2 male to male connectors (40×2) and placed them on a PCB and soldered it. It fits snugly on the Beaglebone. I also soldered some female connectors on to the PCB for use with other components. I then added female connectors for the two sensors to sit on and simple transistor inverter to convert the 3.3V output to 5V output for the ESCs. Granted, the polarity gets inverted but there is a polarity option in the BB’s  PWM module which you can just invert. The finished product looks something like:

Cape Top 1

Cape Top 1

Cape Bottom 1

Cape Bottom 1

I took these pictures before the test flight and before I finished soldering the connections for the sensor. I’ve done that now but these pictures are higher resolution and the difference isn’t too major. It’s a bit sloppy here but it works really well.

Here is a picture of the cape with the Bone (Bone below).

Cape with All Connections

Cape with All Connections

The transistors. Why did I need them? I test the motors with a 5V PWM from a arduino and it worked. Then I test with the transistor logic converter from 3.3V to 5V from the BB and it worked. I used the transistor but with a 3.3V logic and it still worked. I connected the BB directly and for some strange reason, the BB switched off! Maybe it was drawing too much current (I had checked the average current with the transistor and it was nearly 0) or maybe it was just a coincidence. That pin still works but I wasn’t willing to take risks and so the transistors. The ESC wires are the four that are sticking up on the cape. Make sure you fix them properly such that they don’t move and can’t be pulled and don’t hit the blades. This is VERY IMPORTANT.

One mistake I had made in one of the earlier posts was that the PWM control was based on the frequency. It’s not. You set the frequency constant. You then vary the duty cycle. In my case, I set the frequency to 50Hz (Specified: 50-60Hz). Varying the duty cycle (In terms of ON time) from 1ms to 2ms varies the speed from 0 to maximum. You may have to calibrate the ESCs initially. Some ESCs are even programmable. Mine is but I haven’t played around with those options yet.

BB Attached

BB Attached

I attached to the BB to the chassis on the location they provided with four screws. I used some foam padding as you can see in the image above.

The last thing is to attach the battery. I did in the mount below. You can see the blue thing in the image above. That’s the battery. I attached it using the same cable ties. All the wires may not fit in the battery so you may need to combine them. Some people, I’ve heard use two batteries but I’m not sure about how they distribute them.

So put it all together and what do you get!?

Fully Hardware Ready

Fully Hardware Ready

I’m currently working with the sensors. While I had them working well, I did not have the angles exactly. It’s fairly easy to get the angles from the accelerometer but you need to correct them with the gyroscope because the accelerometer doesn’t respond well to noise. I’ll post an update when I get it working problem. I’ll probably  have to implement Kalman filtering in the end.

Explanation of the PWM Modules on the Beaglebone

PWM – Every robotics enthusiast has heard of this term. Some fear it with a vengeance. Just kidding. But it is incredibly useful though! PWM is the short form for Pulse Width Modulation. I won’t go into detail on what PWM is exactly but I will briefly deal with it. Most of this post will be about how to use the in-built PWM modules on the Beaglebone.

PWM probably comes from communications but what it essentially is is a square wave (No, the double is was not a typo!). Well, not exactly a square wave… But imagine this. Take a square wave like this one:

Now, keep the rising edge at the same position each time and only move around the falling edge between the previous and the next rising edge. That is PWM for you! Basically, you’re modifying the width of the pulses but you keep the time period constant. That means a PWM signal has a characteristic frequency which is kept constant because if it were to be modified, it wouldn’t be called PWM but rather Pulse Position modulation (PPM – The digital analog of frequency modulation) but we don’t need to get into that! A PWM signal looks like this:

There are different ways in which PWM can be produced. In the image above, you can see that he takes the point at which the triangular wave cuts through the input signal for both sides of the pulse. In other cases, only the rising edge is used for syncing and the pulse starts agains after the signal is over. In this kind, a sawtooth signal as opposed to a triangular wave. The duty cycle of a PWM signal is the ratio of the ON portion of the wave to the whole time period. In our case, we will use a constant duty cycle in the short scale and vary it when we need to.

So that’s the basics of PWM. Now what is it used for? With digital controllers, it is difficult to produce an analog voltage. You need to work with DACs (Digital to analog converters) and it is generally a pain to use. Another problem with DAC is that sometimes, like when you’re controlling an LED, it is current controlled and has a threshold voltage. Since it is current controlled, you lose some power on the resistor you put in series to carry the extra voltage drop. What you do instead is use a PWM signal. If you take a high enough frequency (Even 50 Hz would do) and you use the PWM signal to control a transistor switch (Which in turn controls your load, in this case the LED), an averaging effect occurs and the LED brightness can be varied easily by changing the duty cycle. With this, you can have very low duty cycle which can achieve very low brightness which cannot be done with a voltage controller. Awesome, right?!

With respect to quadrotors, how is it used, you say. Well, I may get into the working of the BLDC (Brushless DC Motors) in a later post but basically it takes three sinusoidal inputs which are 120 degrees out of phase with one another. This is fairly difficult to generate, especially because the currents are insanely high. So what we do is use an ESC (No, not escape, Electronic Speed Controller). These are high power devices which take a 12V input and provide three output wires to connect to the motor. Easy enough. Just match them up. Be careful about the polarities (Two will be opposite – Again, I’ll post about this in a later post). So how do you control the speed? You cannot directly vary the voltage, especially because the power is so much.

Generally, ESCs are programmable and require a PWM input to control the speed. For example, in my ESC, by varying the frequency from 50Hz – 60Hz you fix the frequency at some value between 50-60Hz and vary the duty cycle from 1ms-2ms to set the speed. At 1ms, the motors will be off and 2ms, it will be maximum. For initial tests, I was using something like 1.2ms. Apparently, this is the perfect format for radio controllers but using a microcontroller has the same effect. I would suggest using a circuit in between, just to be safe. I haven’t done that with this microcontroller yet because I was working on using the PWM modules on the Beaglebone itself. Here’s how it works:

There are three enhanced high resolution PWM modules (ehrpwm). Each has two outputs. The duty cycle of the two outputs can be different but they both have to be at the same frequency and the same run state. This posed a problem because I only had access to three outputs of which I could control the frequency! Well, let’s trying using them anyway (Hmmm… What is that itching sensation up my sleeve?) That means each PWM module can control two motors each giving control over a total of 6 motors.

First, the mux settings have to be adjusted to allow the PWM output to be provided at the particular pins as shown below. The first module is called the ehrpwn.0
The two pins are denoted as ehrpwm.0:0 (Pin P9-31) and ehrpwm.0:1 (Pin P9-29) respectively. Those are the pin numbers where the output will appear. Here is what you have to do.

root:~# echo 1 > /sys/kernel/debug/omap_mux/mcasp0_aclkx
root:~# echo 1 > /sys/kernel/debug/omap_mux/mcasp0_fsx

If you want to use the second module: ehrpwm.1:0 (Pin P9-14) and ehrpwm.1:1 (Pin P9-16) respectively:

root:~# echo 6 > /sys/kernel/debug/omap_mux/gpmc_a2
root:~# echo 6 > /sys/kernel/debug/omap_mux/gpmc_a3

For the third module: ehrpwm.2:0 (Pin P8-19) and ehrpwm.2:1 (Pin P8-13) respectively:

root:~# echo 4 > /sys/kernel/debug/omap_mux/gpmc_ad8
root:~# echo 4 > /sys/kernel/debug/omap_mux/gpmc_ad9

I got all this information from the datasheet. You can go through it in detail. Note that the first module can be obtained at a second set of pins if you want.

After doing all this, the PWM settings are directly exposed in the file system. The main ones we will be dealing with are: period_freq (Frequency in Hz) and duty_percent (Duty cycle)

We covered both of these features in the intro section. Make sure the duty_percent is set to 0 before changing the period. Otherwise, it is said that the duty_percent may be randomly changed to a different value. If i and j define the PWM module and the output:

root:~# cd /sys/class/pwm/ehrpwm.i:j
root:/sys/class/pwm/ehrpwm.i:j# echo 1 > request
root:/sys/class/pwm/ehrpwm.i:j# echo 0 > duty_percent
root:/sys/class/pwm/ehrpwm.i:j# echo 1 > period_freq
// Sets the duty cycle in percent
root:/sys/class/pwm/ehrpwm.i:j# echo 50 > duty_percent
// Sets the duty cycle in nano seconds. Use either
root:/sys/class/pwm/ehrpwm.i:j# echo 1000000 > duty_ns
root:/sys/class/pwm/ehrpwm.i:j# echo 1 > run

For example: root:~# cd /sys/class/pwm/ehrpwm.0:0

It is good to check the availability of the PWM pins first through the following command.

root~:/sys/class/pwm/ehrpwm.i:j# cat request
ehrpwm.i:j is free

period_freq is directly in hertz while the duty_percent is in percent. The polarity is also useful to invert the logic.

Easy enough, right? Beats embedded C any day of the week and twice on Sunday! (Stole that from some movie :D)

So what about that fourth motor!! So what about that extreme case you want to control 8 motors? Do we just pair up two motors, sacrificing mobility?

NO!! There is another module which can be used as a PWM called the ecap module, short for enhanced capture. The procedure to use it is very similar to that of the ehrpwm. The AM3358 has three ecap modules but the Bone implements only two of these. These are the mux pins for the two different ecap modules:

For ecap1 on P9-42

root:~# echo 0 > /sys/kernel/debug/omap_mux/ecap0_in_pwm0_out

For ecap2 on P9-28

root:~# echo 4 > /sys/kernel/debug/omap_mux/mcasp0_ahclkr

And then, almost the same set of commands as for ehrpwm (With the addition of one extra command)

root:~# cd /sys/class/pwm/ecap.i
root:/sys/class/pwm/ecap.i# echo 1 > request
root:/sys/class/pwm/ecap.i# echo 0 > duty_percent
root:/sys/class/pwm/ecap.i# echo 1 > period_freq
// Sets the duty cycle in percent
root:/sys/class/pwm/ecap.i# echo 50 > duty_percent
// Sets the duty cycle in nano seconds. This is for 1ms on time Use either
root:/sys/class/pwm/ecap.i# echo 1000000 > duty_ns
root:/sys/class/pwm/ecap.i# echo 1 > run

Where i is either 0 or 2 (Those are the ones that Beaglebone implements).

So to summarize what the Beaglebone can do in terms of PWM: There are 3 independent ehrpwm modules, each of which has two outputs. The outputs of one module must have the same frequency but can have different duty cycles. This gives you 6 output pins. There are two ecap modules which can be used for PWM. These modules are independent. That gives you a total of 8 PWM pins to play with…
Enjoy! Just don’t connect your loads directly! LEDs may be okay with a resistor in series but if you’re not sure, follow a tutorial or use a transistor switch to protect the board.

So that’s it for today. As always, if you need some help with this, feel free to post in the comments.

The New Chassis

Hopefully, if I manage to sit down long enough today, I’ll be making two posts. This one (The easier one) is about the chassis and the next one will be on the PWM modules on the Beaglebone. Something for everyone, eh?

So far, I’ve gone through three different chassis. The first was a wooden one and didn’t work so well due to the weight (This was more than a year back). The second, I got it fabricated by a good friend of mine named Manish. Here is a picture of it in all it’s galore!

Aluminium Chassis

Aluminium Chassis

This was made of aluminium with separate mounts for each for the four motors. The mounts for the battery and board still needed to be done. It was really light and felt well made. The problem was that it got slightly damaged during transport along with the motors too (The wires coming out of two of the motors broke off). It never got to see the light of day…

The lesson. Carry your BLDC motors on flights very very carefully! So when I placed an order for 4 new motors (Cause the old one was out of stock), I saw a really nice chassis with proper mounts for just 1,000 INR so I decided to purchase it. It looks really good. We’ll just have to see how it flies. Here’s a nice picture of it:

Nex Chassis

Nex Chassis

I bought all these from Nex robotics. Here is their link: http://www.nex-robotics.com/
I guess it would mainly be useful for Indian customers.

Now, the next thing to do is test out the BLDC motors after hooking it up to the ESC’s which need a PWM input from the microcontroller. The only thing I’m nervous about is if a 3.3V input would do (because that is what the Beaglebone provides and if the load pulls too much current, it might be a problem). I would mostly probably use a transistor interface just to be safe.


I2C on the Beaglebone

I got I2C working well a couple of weeks back and got both the modules I am using working well with the beaglebone. I later modified the code to allow API calls to read the values from the two modules. Now I have a proper working directory for the complete project and I’ve decided to test out other things separately and then import them into this single working directory.

This post is to describe how to get the I2C working on the Beaglebone. I got some help from https://github.com/quick2wire/beaglebone. The only problem was that I planned on using C/C++, not python, for better support with OpenCV. I’ll explain the protocol along with the code together. This post assumes you know a bit of electronics. Make sure you don’t connect any 5V supply to any of the beaglebone pins and don’t draw too much power. This means you should only use modules which are working on 3.3V logic and not on 5V logic! If they are 5V logic, you’ll need to some some sort of voltage divider or so. I will not delve into this on this post. If you’re doubtful about something, please feel free to ask me because a wrong connection could be the death of your board (As I’ve read on some other posts).

What needs to be is this:

Include these header files:

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <linux/i2c-dev.h>

or the corresponding cpp header files. The i2c-dev.h gives you access to the i2c protocols.

What you need to understand about I2C is that it is a bus. You can connect multiple devices to the same two wires on the Beaglebone. There are three such buses on the Beaglebone and the third is the most accessible. I2C has just two pins required, the serial data and the serial clock. Bus 3, from the datasheet, is located on P9 at pins 19 and 20.

Pin 19 – I2C – 3, SCL (Serial Clock)
Pin 20 – I2C – 3, SDA (Serial Data)

Since we are working with Linux, we don’t need to deal with the low level protocol. We directly connect these two pins with the corresponding pins on the module. Of course, you’ll need to power up the module. In my case, it need a five volt power supply and 3.3 logic voltage. DO NOT POWER THE MODULE USING THE BEAGLEBONE! Some ports may be able to do so but I’m not sure exactly which ones and even then, the power limits are fairly low so I suggest using a separate power supply. (I used an arduino’s 5V supply). The logic supply can be obtained from pins 3 and 4 on P9 on the beaglebone. Make sure you common the ground with the beaglebone’s GND pins at pins 1 and 2 on P9.

After connecting your module and powering it on, try this command in the bash terminal:

i2cdetect -y -r 3

i2cdetect is a part of the package i2ctools. This command will read all the devices on your I2C bus 3 and show you the addresses. My output looks like this:

I’ll post my output the next time I hook it up

Note the addresses of you devices and check with the datasheet to see if they match. Each I2C bus has a maximum of 128 address (And thus 128 devices can be connected to it). Most devices have a unique unchangeable address. Some have a register which can change one or two bits in the address so that you can connect two or more of the same modules. You can directly set the registers with i2cset and read the registers using i2cget from the command line. The syntax is follows:

i2cset <i2cbus> <chip address> <register address> <value>
e.g. i2cset 3 0x19 0x07 0x97

In my example, I write to i2cbus 3. The device/chip hardware address is 0x19. I choose to write the value 0x97 to the register at 0x07 on the chip.

i2cget <i2cbus> <chip address> <register address>
e.g. i2cget 3 0x19 0x07

I now read the value I just store on the device at 0x19 in the register 0x07. Simple enough. So now you’re asking how to do this from a C code, right? Well, I hope so😉

Basically, to write, you need to specify four things, the bus, the chip address, the register address and the value. To read, you specify the same things except the value.

To do the first, you open the file “/dev/i2c-3” as O_RDWR with the following command:

int g_i2cFile;
g_i2cFile = open(“dev/i2c-3”, O_RDWR);

This opens the i2cbus 3. To handle possible errors, do something like this:

int g_i2cFile;
if((g_i2cFile = open(“dev/i2c-3”, O_RDWR)) < 0){
perror(“Failed to open the i2c bus”);
return -1;

g_i2cFile is the i2c file handle.
You then need to set the device address on the bus. You can do that like so:

int address = 0x19;
if (ioctl(g_i2cFile, I2C_SLAVE, address) < 0) {

I2C_SLAVE is a I2C variable defined in the i2c-dev.h header. address is the address of the device which you found in i2cdetect or from your datasheet. You need to do this each time you want to change the device. I made this into a function with an argument for the address.

Now you just need to read or write the data. I made functions for each. Let’s analyze the commands. This is for write:

unsigned char I2C_WR_Buf[MAX_BUFFER_SIZE];
I2C_WR_Buf[0] = Reg_ADDR;
I2C_WR_Buf[1] = Data;
if(write(g_i2cFile, I2C_WR_Buf,2) != 2) {
perror(“Write Error”);

n is the number of bytes you want to send. The first byte should be the register address and in this case, the second byte is the data to be written. Multiple bytes can be sent if the register is to hold multiple bytes but I haven’t yet seen such a case so I am not too sure about that. To read is just slightly more complex. You first write out the register address you want to read from and then accept incoming data.

unsigned char I2C_WR_Buf[MAX_BUFFER_SIZE];
unsigned char I2C_RD_Buf[MAX_BUFFER_SIZE];
I2C_WR_Buf[0] = Reg_ADDR;
if(write(g_i2cFile, I2C_WR_Buf, 1) != 1) {
perror(“Write Error”);
i2cSetAddress(DEVICE_ADDR);                              // This address might not need to be set again but this works for me
if(read(g_i2cFile, I2C_RD_Buf, n) !=n){
perror(“Read Error”);

Change n to the number of bytes you expect to read. Generally it is one but some devices allow you to send back multiple bytes by oring the register address with 0x80 (In my case, at least… Check your datasheet for this). The output will be at I2C_RD_Buf. And you’re done. Except one thing. Make sure you close the i2c handle like so:


I’ve uploaded the class file and the header file for the i2c protocol on the beaglebone at https://github.com/ajaykumarkannan/Beaglebone-I2C

You can use it. You need to compile i2c.cpp with -c flag, include the i2c.h file in you main and then compile. A makefile would be the simplest to do this. I’ve included an example. It is just arbitrary so do modify it for your purposes.

Angstrom and Linux

This post is regarding some things I picked up while playing around with the Beaglebone but is not documented so clearly or easily in the Beaglebone setup. And I suggest using linux as you don’t need any drivers at all. And as I haven’t even tried playing with it in Windows, I won’t be covering it here but I believe you can use telnet or a basic serial terminal like putty.

As soon as you plug the brand-new beaglebone into the USB, it powers on and it will mount a partition on your computer as a mass storage device. This contains some pdf documentation including the datasheet and other files. It also has the documentation for the cloud9 IDE. It is a built-in IDE for the Beaglebone based on Javascript which aims to provide an interface to the Beaglebone similar to arduino. This is not yet complete. It is easy to do simple GPIO and LED blinking but in my opinion, I would much rather use the more powerful Linux backend since it’s already there and Cloud9 is merely running on the Linux backend. In any case, if you want to use Cloud9, copy the documentation to your computer and eject the mass storage device. It will then automatically configure a network interface between your PC and your board through USB and you can access cloud9 through any web browser. Just follow the documentation. The network that is automatically setup maps my computer to and the Bone to

Note that this connection is in addition to your WiFi/Ethernet connection. I believe that it may be possible to use this interface to connect the bone to the internet through USB by using NAT but I have not yet accomplished this.

Since you now have a network interface to the Bone, that means you can ssh into it or use a serial terminal… Or both. The serial terminal is more fundamental as it shows all the boot up and shutdown process while the ssh of course doesn’t.

Before starting, I recommend that you add your user account to the linux group dialout by doing:

sudo adduser <username> dialout


su -c ‘adduser <username> dialout’

where <username> is replaced with your username

Log out and log back in. This allows you to run the serial terminal without having root access.

Now make sure you have screen installed by doing:

sudo apt-get install screen


sudo yum install screen

You can use minicom or putty but I started using screen first so it has been a force of habit. Generally, the beaglebone maps to /dev/ttyUSB0 and /dev/ttyUSB1. Just check ls /dev/ttyUSB* before and after plugging in the device.

You need to connect to the second one. Usually, it is /dev/ttyUSB1 and you need to specify the baud rate which is 115200. Connect by executing:

screen /dev/ttyUSB1 115200

If it is still booting, you will see the boot sequence. Otherwise, it will ask for the login. Login as root. There is no password so just hit enter when it asks for it. And ta da! You’re in!

Just remember that the network is only setup after you eject the USB storage device. You need to do this each time. SSH is installed and started on the beaglebone by default and you can access it either through a terminal or through nautilus, the GNOME file browser. For shell access, just ssh://root@ If you want to access the folder structure, go to the location bar in the file browser (Ctrl-L for short) and type in: sftp:// Enter root as username and leave the password blank.

If you want to set a root password, type is passwd after login though I don’t really see a point. If someone wanted access, they can just mount the sdcard and copy the data or put a new version of Angstrom on it.

And speaking of new versions, you can get the latest version of Angstrom from http://downloads.angstrom-distribution.org/demo/beaglebone/

They’ve given the directions to load up the new image. WARNING: It will format all existing data so take backups. You can back up the entire sdcard including the original distro by executing the following command (Assuming the sdcard is at /dev/sdb):

mkdir beaglebone

cd beaglebone

sudo dd if=/dev/sdb of=unmarked_sd

tar zcvf unmarked_sd.tar.gz

sudo rm unmarked_sd

Make sure you’re using an sdcard reader for all this backup and restore. To restore, use an SD card of the same size or larger and execute:

sudo su

tar Ozxf unmarked_sd.tar.gz | dd of=/dev/sdb

The backup and restore portion has been adapted (Which is a subtle way of saying copying😉 from http://taylanayken.wordpress.com/2012/03/27/getting-started-with-beaglebone/

Do take a look there. He shows how to compile a new kernel for the beaglebone. Pretty cool stuff.

That’s it for now. I’ll be adding more about this as I learn more about it. Don’t forget adding yourself to the dialout group! That’s what made me write this post in the first place because of its usefulness.

Ozxf unmarked_sd.tar.gz | dd of=/dev/sdb

Android on the Bone

I’ve loaded up Gingerbread on the Beaglebone before and a blog entry can be found in my other blog. While the Androd shell is just as fast as other distributions for the Beaglebone, the GUI which can be accessed seemed too slow for it to be usable for me. I tried Ice Cream Sandwich today and the same lagginess prevailed. The DEMO images can be obtained from this site:


A very good wiki/how-to can be found at:


The lag could be attributed to one of two things. The first being the fact that I’m running Android off of a class 2 SD card which limits the card speed. The second is the fact that I was accessing the GUI through a VNC server. I think it’s mostly the second which is causing the lag because there are plenty of videos demonstrating the Beaglebone with LCD touchscreens and they seem perfectly stable while other demo videos using VNC are just as laggy as what I observed.

The DVI cape can be purchased separately for the Beaglebone and used to connect the Bone to a monitor. I believe that this should be fairly fast as well. For now, I will be sticking with Angstrom and try to interface using the I2C protocol. I have found some similar articles for the BeagleBoard xM. The problem that I believe that I may face would be different voltage levels. I need to look into this.

One thing to note about the Android demo images are that TI claims that the builds have “pre-integrated SGX (3D graphics accelerator) drivers”. This definitely is something to look into when developing graphics solutions.

An Intro

The main aim of this blog is to document to making of a quadrotor and to get feedback from other people.

The first quadrotor that I made along with a friend was on the heavy side (Having made it out of wood). It was controlled by an atmega32 with BLDC motors and drivers and wings purchased from Nex Robotics. The accelerometer and the gyroscope were also purchased from Nex Robotics. The main issue that we ran into was that the body was too heavy.

This time, with the help of another friend, the chassis has been made much lighter using an aluminium frame. I will be using the same motors and drivers but the gyroscope and accelerometer have been changed. In fact, on two modules, we have a gyroscope, an accelerometer and an magnetometer, each having 3 axes. This should provide much better control and give us better stability.

I plan on using the Beaglebone as the controller with some sort of wireless module, most likely a Xbee Pro. The Beaglebone runs embedded Linux and is much more powerful than atmega processors (I include arduino boards in this) as it runs at 700Mhz when powered by a power source or at 500Mhz when powered by USB. The Beaglebone is a Beagleboard aimed at hardware projects. It has ARM Cortex A8.

The sensor modules work or I2C or SPI and the Beaglebone includes natural support for these two protocols and also provides PWM pins. The next thing that I will be doing is to interface the sensor boards with the Beaglebone.