It should say Arduino UNO because the name is set in the makefile as Arduino UNO, so no problems there... Will you for the sake of it download Arduino 1.0.5 and try those drivers.. Because the drivers in arduino 1.0.5 are signed drivers.. Maybe that will skip some of the windows errors that come up..
i changed pins because i use arduino uno and i think problem caused bcuz of that .....
Hmm, then what pins did you change to?? You can find the pins definition in the Config.h file.. The throttle is on pin 7.. And it's a interrupt pin on the leonardo.. Did you come around the receiver code, and in that case did you implement it in the firmware???
If you need further help then please provide me with everything you have, so I know how to formulate my answers..
Well, you need some kind of linux environment in-order to make that particular project.. I used cygwin, which is some kind of linux shell for windows (http://www.cygwin.com/).. From there all I had to do is go into the directory for the makefile using "cd" and then type make!
However, the board (atmega8u2) worked fine initially with 16 MHz crystal I changed it to 8 MHz crystal, and then it failed.
It's not as simple as just changing the crystal and expect it to work.. The clock has to be changed in the firmware also.. I changed the clock to 8Mhz and recompiled the firmware for you.. This firmware is only for the USB serial, without the DFU.. Try it out and report back..
I had some free time this weekend, so I just made something I wanted for a long time!!......... Some background action for my PC monitor!
I know this idea isn't new, but I believe my approach/results is somewhat different than the standard Ambilight clones out there..
This is a simple ambilight clone that anyone can make.. What you need is a LED RGB strip with WS2801 or WS2811 (though the code is written for the WS2801) , a arduino and a PC with processing 2.0+..
The strip I used has 32 LEDs and the sketch is written for 32 LEDs.. This can easliy be changed by changing the "number of LEDs" constants on the arduino and processing side..
The code expects the leds to be divided on three sides of the screen.. I have 16 LEDs on the top of the screen and 8 on the left and 8 on the right side.. Led number 1 is on the right-bottom side of the screen and led number 32 is on the left bottom side of the screen..
The strip is connected as follows to the arduino:
MOSI (Arduino) <-----> DI (Data input LED Strip) SCK (Arduino) <-------> CLK (Clock input LED Strip) 5V (USB, ARDUINO) <-------> 5V input on LED Strip GND (Arduino) <--------> GND input on LED Strip
Now before I continue, words of caution! The Strip is powered by USB in my case, and is working fine because I turned down the brightness of the LEDs.. This can be set in the the processing sketch by changing the variable Brightness.. if you're using 32 LEDs like me, then a value of <110 is okay! Still, if you're unsure then set the value to 64, or power the strip externally...
Open the sketch MakeMeLight.ino in the arduino folder and hit compile followed by upload..
Now start the processing sketch with MakeMeLight.pde (in the processing folder) and hit the "Run" button..
You'll get a simple GUI with four button.. Two buttons for the Sound Mode and two for the display mode.. (See screenshot in the attachments)..
The Sound mode is a VU-meter for the PC speaker output.. So it'll react to the music/sound you're playing.. The left side of the screen will represent the left speaker volume, and the right side of the screen will represent the right speaker volume..
The Display mode is a dynamic ambilight mode.. The meaning with dynamic here is that it reacts "better" to color change compared to other ambilights out there.. If you look at other software ambilight projects, you'll see that they average a chunk of the screen in order to get a high FPS (frames per seconds, or in this case updates per second).. The negative outcome from this is that the ambilight will somewhat feel very static/very still/very boring..
In my case I chose to only average 5 pixels per LED and came out with a average FPS of 20.. The next question you'll ask yourself, why so slow??? Considering that this is a software ambilight (the pixel data is read by getting screenshots of the screen and processing that image) this is a very okay frame rate.. And believe me, you won't notice any flickering.. I made sure of that!
In sound mode, the FPS is around 700-1000 FPS.. The reason is that reading sound data is a fast process, very fast compared to taking screenshots...
Another plus here is that the PC software is written in processing, meaning it's auto cross-platform! =)
I've added some pictures of the LEDs on my screen and the final setup..
Here is some clips demonstrating the two modes:
Display mode: Sound mode:
If you've got any question please feel free to ask!
Ya, no bootloader, you got it wired wrong or in worst case scenario it's a small brick/fake.. Sparkfun had a similar problem when they ordered from china I believe, read this: https://www.sparkfun.com/news/350
You can program your UNO with the Arduino ISP sketch (http://arduino.cc/en/Tutorial/ArduinoISP), and try putting the bootloader on these chips.. If it doesn't work, well, you got yourself some fake IC's that you can use to practice soldering..
Great work mate! Looking good with the red'ish design ! I had a similar idea once upon a time (not the game, but the actual method of using the PC to code/debug a whole game and then just simply port over the code by copy, pasting and filling in the gaps of course)! You didn't post your code, so I'm going have to bother you with a couple of questions =P! How will this run on an UNO? Will it fit and how will the performance be?
About your old method of rate-PID tuning: What is your speed setpoint/reference ? I guess 0 deg/s and before your have manually put your quad at 0 deg for roll and pitch angle?
I have trouble understanding what you mean.. But I'll give it a shot.. When the quadcopter is in rate-mode, the set-point is determined by the RC-reciever.. Meaning you change the setpoint directly with the transmitter/Remote control.. For example, if you roll left then the setpoint will be something <0deg/s (negative angular rate), and the opposite if you roll right, >0deg/s (positive angular rate)..
If you're in angle mode, the reciever controls the setpoint of the angle-PID, and the angle-PID will in turn decide the setpoint for the rate-PID...
I know well Matlab and I have got it on my laptop. (My dream would have been to use Simulink ). Anyway what do you do with your Matlab script? Transfer function?
Simulink is slow and not optimal for something you run and optimize in real time.. Sure, you got the Real-Time toolbox, but if you ask me it sucks!
No it's not transfer functions, that would be optimal in-case i modeled the system.. But instead I did the following:
Arduino side: Wrote a whole new sketch that only handles inputs, outputs and gyro, acc calculations.. Meaning all the PID calculations are done in matlab..
Matlab side: I implemented some known PID tuning methods, like Ziegler-Nichols, SIMC, IMC etc.. They are easy to calculate.. It was just a matter of iterating and testing the results I got from the different methods.. The method that gave the best result for my quad. was the SIMC.. Still the results were not perfect, but it got me pretty close to something acceptable.. I know your going to ask why it didn't give me the optimal magical numbers =P! The reason is lag/delay in the system.. Matlab runs fast, a little too fast for the Serial-communication on the arduino.. So by the time arduino sends the data, the quadcopter would have changed its state drastically (not for the human eye maybe, but you can see it if you look at the data).. This kind of lag/delay can lead to early oscillations in the PID-tuning..
The optimal way to run this type of tuning is on the arduino itself.. So maybe write a PID optimizer for the arduino??
You have to tune the rate-PID before the angle-PID
I agree with this but how do you practically tune it? I mean with the angle-PID, it's easy to tune, you can look at the angles values or even look at your quad to see if it's stable but with the rate-PID, I have no idea how to tune it.
ya, I get what you're saying.. The method I'm using today is pretty advanced and requires some expensive software.. I basically made a Matlab script that sends data back and forth to the quadcopter and optimize the PID values.. Before that I did it by hand, this is my old method:
1 ) Put the quadcopter in rate mode 2 ) Increase the throttle until the quadcopter starts to hover on its own.. 3 ) Increase the P-term until you observe oscillations.. Now subtract 10% of the value and set it as your P-term .. 4 ) Increase the D-term until you observe oscillations.. Now subtract 10-20% of the value (this is your D-term now).. 5 ) Now go back and increase the P-term with small steps until you observe oscillations.. Then subtract a couple of steps.. 6 ) Increase the I-term until you observe oscillations.. These oscillations will have a lower frequency, so step up the I-term slowly.. And be careful when it starts to oscillate.. Because the P- and D-term will kick in, and increase the frequency of the oscillations.. So be careful! After that, substract approx. 10-15% of the value... 7 ) If you are satisfied with the results, then go out and take it for a spin, and observe how it flies and reacts to the wind etc.. Then go back and fine tune your copter if you observed any types of oscillations/control problems.. 8 ) Buy me a beer!!!!!
Which mode is the easiest to tune for a first time?
Now this question made me sad.. Because it means that you didn't read through my code correctly.. Let me explain how my closed-loop works.. I got 2 loops, yes, one is as you called it position loop (angle loop) and the other one is the rate loop.. But I like to also call them the slow/outer loop (angle) and the fast/inner loop (rate).. I just drew a "map" in paint (MsPaint > PhotoShop =P) to make the process clear.. As you can see in the map, PID-rate is part of the inner loop which in turn controls the motors directly.. The reason for this is because of the update rate (400Hz) which is close to the motors PWM refresh rate (~480 to 500Hz).. The PID-angle is part of the outer loop (because it's slow approx. 50Hz), which corresponds to the receiver refresh rate which in fact is 50Hz also! So PID-angle is like an auto-pilot for the position of the copter.. So to answer your question: You have to tune the rate-PID before the angle-PID!.. If the rate-PID isn't stable you won't get a stable copter with the angle-PID!
Note: I didn't read or see your code (something wrong with github, keep getting errors when I try to open your files).. My answer above assumes that you have one inner loop and one outer loop! Two separate inner loops will only lead to a slow response from the quadcopter which in turn will lead to bad PID values, which in turn will make the quadcopter uncontrollable in harsh environments!
How did you actually do your tuning? Did you put your quad on some sort of ball joint ? Or did you hold it in your hand ?
A ball joint would be the safest way.. But because I don't have a ball joint, I used a FAN-stand, like the one on this: http://www.tradeindeed.com/images/Stand-Fan_482-700.gif And tied the copter to the stand top.. When I got the copter pretty stable, I took it out of the stand and held it in my hand during fine tuning (DON'T RECOMMEND THIS, I still got a bunch of scars all over my arms!)