quad copter coding

Honorwalk: I am controlling the device, currently tethered, by an extra long USB cable. I start with the [throttle] variable at 1, and slowly make my way up to 30ish where it looks like it's almost ready to take off, and then at around 35 or 40, the quad flips over.

Not sure what you should try next. Sounds like you have a coding error somewhere or your control system is inherently unstable. Have you calibrated the accelerometer? Do you calculate Pitch and Roll angles or use the accelerometer values raw?

I believe I am using the calculated variables. I’m using the .wire library. I copied All of the setup for the mpu from the arduino page on mpu 6050, and it returns nicely. Whenever i open the serial window, it calibrates the accelorometer. Should I perhaps use a different method than adding all the outputs together?

You mean the MPU600? You are adding them up and uses it as an input for your PIDs? So yes, you should use a different method since what you’re doing is almost a non-sense.

This sensor does NOT output attitude angles (pitch, roll and yaw) but accelerator and rate of turn with respect to the 3 space axis. But you have to compute the attitude angle from these 6 values in order to use them as input for your controllers.

Have a look at this page, it explains well what’s going on and explains how to use these values in a complementary filter:
http://www.chrobotics.com/library/attitude-estimation

No, I think you are misunderstanding me. I diddnt do a very good job at explaining my proccess. So The device I am using is called The MPU 6050. I receive the X (the pitch), Y(the roll), Z (the yaw), and G (the upwards acceleration) raw data from it. I retrofitted the code from the Arduino reference page on Said MPU to calculate the actual angles for each. For now, I am only using the X, Y, and Z data from the MPU. I have three different PID loops for each variable. They each take their corresponding angle from the MPU as an input, and ,with the P=1.5, I=0, and D=0, the loops calculate an output. Now each motor has a different combination of these three outputs all added together. For example,

top left prop= (-xOut)+(yOut)+(zOut) top right prop= (xOut)+(yOut)+(-zOut) bottom left prop= (-xOut)+(-yOut)+(-zOut) bottom right prop= (xOut)+(-yOut)+(zOut)

alright, that is the stabilization part, but, as it is still tethered to my computer via a USB chord, I control it (just for now) via the serial window by adding a set variable to each propeller above.

So essentially, each propeller is outputting an equal manually set chunk plus the data from the output of the three PID loops. Does that make more logical sence? Again, Thankyou guys for all your input.

OK I understand better. But you receive from the MPU 6050 the raw gyros (X, Y and Z) data and accelerometers (X, Y, Z) data, not the angles directly, these are calculated... I prefer this formulation to avoid confusion ^^

I don't really know how your frame is oriented but for a standard frame, both front propellers shoud go the same way for the pitch (X) stabilization (both rear props should go the same way, opposite to the front's), and both right should go the same way for the roll (Y) stabilization. I don't know if it's only because of the way you wrote it here or if there's a real problem on your quad, but if so, that could explain the flipovers... If the PID receives values for the pitch but is outputing on the roll, for example.

Bonus question: do you use two pairs of propellers rotating in different directions?

I believe the code I used does produce the angles. The page has a code that gives the raw variables, but below that is a code that returns the angles. At least, in my tests, it returns 90 for the corresponding angle a when on its side.

The way I've built it is the diagonal propellers are spinning the same way, while the adjacent props are spinning the opposite. I don't see how having the front props spinning opposite from the back would work... manipulating the yaw would also effect the pitch, wouldn't it?

Bonus answer: yes, the props spinning the same way have the same props, while the opposite are opposite. So the props are always pulling up.

Ok, good thing for the direction of rotation.

Let me clarify for what I said, I didn't use the right terms. I meant that the output of the PID should be applied with the same sign on both front propellers for the pitch control ; and with the same sign on both rear props. While on what you wrote, this is the case but for the roll control. Once again, it depends on how you defined your coordinate frame, but I'd check that again if I were you.

Yes, I have checked and double checked this. So yesterday I was testing it, and messing with the pid variables, specifically the p variable. it seemed to help a lot. Still some fine tuning, but I tied the quad down so I could view the changed I made. And it seems to me working.

What settings does work better? Also, try to increase a little the D setting, it helps against instability.

Having a verbal description of how you think the code is working is no substitute for reading the code.

It seems to work better at the 0.1 range. And Ill try changing the d