ATROPOS: Fonera Quadrocopter. An insanely home-made UAV

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 2nd complementary 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

 

 

 

http://www.youtube.com/watch?v=0Sef9T8KogU

http://www.youtube.com/watch?v=Iph7TKhkL9I

http://www.youtube.com/watch?v=DaPQhUp1SVw

http://www.youtube.com/watch?v=kZBanslXxRA

 


Flies scaring everybody that is too near...

  • Actuators / output devices: 1100KV Brushless motors
  • Control method: Web interfaced, sending HTTP requests
  • CPU: Fonera 2201 Atheros CPU, 1x16F876A
  • Operating system: OpenWRT LINUX
  • Power source: 11.1V 4500mAh LiPo
  • Programming language: C, CCS C, javascript
  • Sensors / input devices: Wii Nunchuck, wii-motion, Wifi
  • Target environment: outdoor

This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/atropos-fonera-quadrocopter-an-insanely-home-made-uav

that is very cool!! i like

that is very cool!! i like it!

Nice, but using a webserver and html5?

Cool flying machine, but I was wondering why you use a web interface to control it? Surely there are easier ways of getting input commands over a wifi link? Just straight UDP packets sent from your controlling host to the linux kernel on the copter? 

In any case, impressive flying machine made out of a router/ap using openwrt! :slight_smile:

You’re right

I would like to implement faster methods. UDP sounds great! (Thanks!).

However, this solution implies difficulties on the fonera side, but it’s very easy to make request from a wide range of gadgets using http requests.

 

 

AY! Wicked! Thanks for

AY! Wicked! Thanks for posting :smiley:

(and good job!!!) Gives me something to think about :slight_smile:

Nice job, I look forward to

Nice job, I look forward to more details on how it came to be!

UDP more difficult?

I can’t imagine that writing your own program for OpenWRT which listens for UDP packets and translates them to commands for your copter could be more difficult than having to rewrite the webserver to make it faster (and also has to translate them to commands) and writing a whole AJAX/html5 interface?

 

Besides, would a phone browser be fast enough to be able to control it? If you write a native program for your phone you could try using the accelerometers of the phone to control your copter.

Please understand I’m not criticising your project, I think it’s really cool, it’s just my opinion that your control method is a bit complicated and could be simpler. :slight_smile:

**Don’t worry about that **

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 !

 

 

Ah!

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. :slight_smile:

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

Cheers

ESC

Nice project. What ESC are you using, and what frequency are you updating them at?  I’m working on one using wii motion plus gyro and ADXL335 accelerometer, but I can’t get the damned thing to stop oscillating wildly, not matter how much I tweak the PID values.

Short answer: 125Hz.Long

Short answer: 125Hz.

Long answer: 50Hz is the “standard” freq for hobby servos but it is too slow response for quadrocopters. Some projects claim to be 50hz refreshed, but I believe that it is too slow. Other projects make oversampling on the sensors (about 1kHz) and then averaged to 200 or 100 Hz.

However, I have been for 2 months tuning the PID control. It is a very frustrating stage. If you have a decent loop speed (+100Hz), the problem should still be the PID.

You can tune PID by see-saw method: let the quad to balance in one of it’s axis, and test PID:

Simply put 0 values to I and D, start with P:0,5 and continue increasing until violent oscillation starts. Then increase D in very little steps (0.01), until the response start to improve.

Thanks

Thanks. My main loop is running at about 200hz, and sampling every time.  I’m controlling the ESCs with the Arduino PWM, which runs at 490hz. I know this is good with my ESC, because it works with the multi wii copter (http://multiwii.com).  I’m pretty sure I’ve got a combination of bad hardware (one of the motors seems very underpowered) and some iffy code. I’ll get there someday :slight_smile:

I’ve seen videos of tuning where they get vigorous oscillations, but only of an inch or see either way; I’m getting way more than that. I’ve had it stable, but VERY slow to level.  It’s frustrating, there are so many quadcopter projects coming up at the moment and I’m getting nowhere.  Worse, because I’m not using an RC receiver, like you, I can’t just use some existing software to confirm that my hardware is good.  shrugs

Keep fighting!

I have posted 3 new videos. Those videos are about fixed PID tests. That was a very hard stage because you don’t view the light at the end of the tunnel until you are almost near of the end.

Make sure you have the ESC timing in the Medium or Fast config (assuming that your motors are outrunner). And the same on all of them. Check your IMU filter and make sure that is fast enough. (Not too agressive low pass filters.). Then tune your PID. If your PID is auto level, but slow, try to increase P. Use D to correct overshoot.

Do you have some videos in order to help you to tune your PID?.

 

 

 

I’ll try and get some

I’ll try and get some video.  Each cycle of my program takes between 3000 & 5000us, depending on if it’s outputting flight data over serial or not; it does this on request.  On each cycle it reads the accelerometer and gyro, and estimates the angle.  The accelerometer data is held as a moving average across 10 reads to try and smooth out the noise.  The current gyro and previous accelerometer values are combined in a 19:1 in favour of the gyro readings. This was based on ideas from http://www.starlino.com/imu_guide.html.

By low pass filters, do you mean the gyro to acc weighting, or the smoothing factor on the accelerometer, or something else?

Hmm, just been reviewing the Sparkfun page for the ADXL335 breakout, and it says it’s set to 50hz bandwidth. I suppose that could be causing some issues if I’m reading it significantly more frequently than that?

Thanks.

imu

By low pass filter I mean a smooth factor. I haven’t tested he ADXL335 breakout, but if it probes at only 50hz and you request faster it could be a problem, as you suspect.

If you don’t have gyro drift with 19:1 factor, It looks pretty good :slight_smile:

I have posted some more videos explaining my PID tuning process. I hope they give you some ideas!

Wow, this is getting really,

Wow, this is getting really, really nice! I’m close to saying that it’s one of the coolest Quads I have “seen” - if it was more stable in air, it would be!

The user can pilot the aircraft with a HTML5 and canvas web interface, making AJAX request on every key stroke or mouse movement.” - Let me know when you want that interface up on front page of LMR, just let me know :slight_smile:

Really nice setup - and so unfair you have mountains to fly in ;/ Next tep must be something like an Easy Star II with FPV and head tracking, 2 DOF - fly on air preassure from mountains for hours :slight_smile:

HTML control panel

Very nice flying machine, I’m interested in your html / ajax script used to control the machine and send back live video to the control page. I also use a basic html / ajax script for my bot, but I am kinda new to html and if you could share your sript, or at least how you embeded the live video that would be great.

 

Nice Work !!

**Glad to see you like it **

Glad to see you like it  fritsl! Wow, putting my interface on front page, would be great for me!. Let me take another video, with the HUD enabled (yes, it has an Actitude Indicator stacked on the ip camera image, but, it is hidden in the test). If the flight is good enough, I will post it and will tell you.

Now, I’m testing other PID values, that are the lacking part of the robot. It is being very hard to me finding better values…

Other stuff that I haven’t wrote on this update, but it is very important, is that I took costyn advice, and I coded an UDP implementation of my USB trainer. Quad is accepting UDP requests making it much faster tan accepting AJAX requests (Thanks costyn ).  Yes, you could control the quad by web, but it will be more affordable when I implement GPS Hold ^^

The html video is very

The html video is very camera-dependent. You have to see how your camera is showing the video on it’s interface. Some cameras work with an ActiveX component, it is not good, cause you have to see that on IE … Some others, you simply call a web page like

http://ipcamera/video.cgi

if the camera asks you for the login, you can launch as:

http://login:pass@ipcamera/video.cgi

Or, like my case ( with this camera) you have  static jpgs. Every call to the target page, returns to you a frame. On the camera web interface, there is a javascript function that retrieves seamlessly every frame.

Once you have this functionality (whatever your case is) on a fresh page, you put all together, calling this page from your control page with an iframe.

for direct retrieving example

<iframe style=“blahblah” src=“http://login:pass@ipcamera/video.cgi”></iframe>

or if you need a fresh page to retrieve in background every frame

<iframe style=“blahblah” src=“http://ipcamera/page_that_I_made_to_retrieve_frames.html”></iframe>

On the other side, my intention is to put the code and html5 interface on GPL license, but I know that it is a little mess of spaggheti for the moment ;).

If you had some trouble with this, tell me you ip camera model, and I will see what we can do :slight_smile:

UDP

Hey costyn, I’ve implemented UDP reception. It gives me more delta-Time process, and works like a charm!.