Let's Make Robots!

ATROPOS: Fonera Quadrocopter. An insanely home-made UAV

Flies scaring everybody that is too near...

Aimed by fritsl last post :)   ...

Atropos is a wifi operated quadrocopter system. It uses a Fonera 2201 with a custom compiled version of GNU/Linux OpenWRT.

A set of wii sensors gives the information to the router throughout custom CPU GPIO pins. To achieve I2C communication a especial linux kernel module is used to make an emulated i2c port with every 2 GPIO pins available.


[UPDATE 2/10/2014]

There is a talk at congress "NavajaNegra" in Spain that I show the Atropos with it's last flight control. Much more stable, but I still need a pilot class :P. The small flight is without any correction from my part but the gas.


[UPDATE 07/01/2013]


Here it comes a major upgrade of Atropos, as you can see in the front image. I have redesigned all mass distribution, putting all ESC together, and making a case for the whole system. To the cosmetic changes comes software changes, like scaled realtime graphs, and the most important thing, Pitch and Roll PID controller values has much more fine tunning.

Now I have to tune YAW PID and then Atropos will be on 1.0 version!.


New tests and flights in the new videos.

Atropos is remotely operated by a wifi link, powered by a Fonera router. The user can pilot the aircraft with a HTML5 and canvas web interface, making AJAX request on every key stroke or mouse movement. Telemetry is received with COMET (SERVER Push) HTTP information and Javascript is used to manage the entire page.

Fonera sends rotor commands to a 16F876 PIC, which generates PPM signals to manage ESC ( Electronic Speed Controllers). Those ESC are the power stage to trifasic motors.

To achieve very fast and less time consuming requests, http router web server has been modified on it's source code, to process all the AJAX requests in a RAM shared memory portion on the router.

Software control is completely home-made, and suited to be run into Fonera. It reads nunchuck and motion+ wii sensors, applies a low-pass filter, and a 2ndcomplementary filter on every loop which has been previously readed. Finally three PID controls manage rotor speed to guarantee stability.

Managing the aircraft with keyboard control is almost impossible. Due to this I developed a C program to translate USB Gamepads events into fixed-timed HTTP requests. This can be ported to any other control, making very easy to adapt to mobile devices, like phones, tablets, etc.

Will post more pics, videos & data ASAP!

[UPDATE 6/9/12]

I have posted a new video showing a test flight to observe compensated yaw lock implementation with HMC5883. There is a lot of pid tuning work left...

I recoded a huge part of HTML5 telemetry interface as you can see in the video, also software control has been updated with DCM  algorithm.

IP camera is kinda messed up with colors since a early crash during another test flight. :(

[UPDATE 19/10/12]

This is the whole architecture of Atropos system. I hope it will help to make you a better idea of how this mess of wires works :)

Also I have attached a new video, (see at the top of the page) showing the last version of HTML5 interface, with attitude real time graphics   (Where I live, windy season is starting and a new test flight is kind of uncomfortable, so this is a PID tuning session, by the see-saw method).

Video has several parts:

-First, I show how I will control the quad moving the mouse along a squared shape. The web part is functional but since it has to be completed with GPS+IMU filters in the flight control, that part is for the moment under construction. Also on the center of that shape, there are two arrows, green tell you real yaw degrees, and orange target yaw degrees. That works entirely

-Then, I enable three on-fly attitude graphics, on the right. That graphics are also canvas objects. Red line is target position on each plane, pitch, roll and yaw, and there is also a blue line. Thats the current position. The closer they are both lines, the better PID is tuned.

-Last, I disable graph attitude, to enable a HUD version of attitude indicator. That was the first component I made for this copter, but
for my first tests 1 year ago, that was not much helpfull in the debugging process, so I decided to make it optional, and enable it when fligths become more stable.

-Extra: you can see a terminal window running at bottom. That is the USB R/C trainer to UDP packet translator, to achieve faster and more efficient control of the copter, that HTTP requests. My intention is to make it unnecessary almost all the time, when I implement entire GPS Hold. It will make keytrokes+mouse a more user friendly control.

[UPDATE 07/01/2013]-> See top of the page









Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Don't worry about that costyn, I'm finding your comments very constructive. Indeed, I'm studying the UDP solution. A direct R/C receiver will be implemented too (to avoid the whole computer in casual flights)

My first approximation was aimed by the success of my other project: Texas Ranger ROV. But a ROV doesn't need too much process speed to be controlled. Yeah, triying to make things simple (no native apps), they turn crazy xD.

For the moment, I will keep the html5 telemetry and improve the input method. UDP first, then, the R/C receiver.

Please, keep commenting wathever you want !



Ok, I understand now. Looking at your other project (also very cool), I see the web interface makes sense. And of course it makes sense to re-use an already built control interface for your next project (the copter).

Cool that you included a camera on your ROV, with so much bandwidth between robot and control station it makes sense. :)

Anyways, I'm a network engineer by day, and I guess the networking aspects make me wanna comment and help out. :)


that is very cool!! i like it!