pid controlled quadcopter steadies then oscillates again

[shayelk]

Hi all!

I'm still working on a VI to controll a quad copter, and I got this wierd PID response while adjusting the gains for the pitch channel: the quad will get steady and after a second or two of staying steady it will start oscillating again.

any Ideas how to solve this problem?

snips of the relevant parts of the block diagram and control panel are attached, and a video of the quad's behaviour is available here


I'd also love to hear your ideas about the next step- position controll. As far as I can tell, in order to controll the quad's location (i.e on the x axis) I'll need to add another PID block which will get the quad's x distance from the desired spot as input, and will give a pitch angle as output. Then I'll need to connect this PID's output as setpoint for the PID I now use to controll the quad's pitch. is this the right approach for the problem? any suggestions?

Thanks a lot for your help!

[GerdW]

Hi shayelk,

why are there terminals in the BD without a label?

Which timing does your PID loop use?

Why do you multiply PID output with -1? This is usually handled by the PID parameters!

How did you determine the PID parameters? Just by guessing or did you proceed as recommended by Wikipedia (heard of Ziegler-Nichols?)?

A quick guess with no underlying data: start your next try using Kc=0.02, Ti=0.5 and Td=0… (Making the PID act "slower"/more "damped".)

[billko]

A picture is worth a thousand words, but a VI is worth a thousand pictures.  Let's see the actual code.  Or is that it and you are using the "run continuously" button?

[shayelk]

thank you for yor comments! I'm new to labview so I'm really happy for all your remarks.

GerdW:
unlabled terminal- fixed

pid timing- the loop only start another iteration when new data arrives from the cameras, so it should work at about 100Hz which is the frequency at which the cameras work

multiplying by -1 - I actually didn't know how to do it elegantly- the program I'm using for input sends positive pitch when the quad is tilted backwards, while the remote controll I'm sending the output to uses positive pitch to tilt the quad forward. so I need to reverse either the PID's output or input. I'd love to know if there is a more elegant way of doing it.

The PID parameters were determined by trial and error as recommended by Wikipedia. I actually do need to try and use Ziegler-Nichols.

The parameters you suggested made the quad oscilate really slowly from side to side but it never converges to anything.

bill:

the VI is big and clumsy so I wanted it to be easy to find the problematic section. the entire VI is now attached:

thanks again for your comments!

[billko]

I just wanted to make sure that the code itself was respnsive enough to actually control it.  I still have to look at the code.

[johnsold]

One thing which may be a problem is the race conditions produced by the use of the Value property nodes connected to the unlabeled 2D array.  The for loop with Rotate writes to it and all the case structures with PID code read it, one of them twice.  You have no way of knowing the order in which the reads and write occur. It could even be different on different iterations of the while loop, particulary if the Controll booleans change. Similary, local variables are also prone to race conditions, create extra copies of the data, and are slow, although faster than the Value property node.  Use wires.

Also, Value property nodes are the slowest way to move data. They force a switch to the UI thread.

Sequence structures are rarely needed in good LV code. Your program could be well managed by a state machine.

I do not have the Tracking Tools VIs. I have no idea how long those VIs may take to execute. But delays in a control system can make it very difficult to stabilize.

The Mathscript node in rotate.vi is probably orders of magnitude slower than the same transformation implemented in LV code.

Counts should use integer datatypes.

Lynn

[shayelk]

The race conditions does seem to be the problem.When I used wires instead and re-used Ziegler-Nichols to determine the new PID gains it worked just perfect.

About sequence structures- I don't really understand why you wouldn't want to use sequence structures in a case when you want the VI to run at a certain way (i.e initialize the cameras->read the calibration file->run the control loops->terminate the cameras) - isn't it a more elegant and visual way of writing it instead of a case within a case? (well, I guess the answer is "no" but I'd love to understand why).

About the Mathscript- do you mean using math nodes such as multiply and add? that seems to be really clumsy and not readable. isn't Mathscript the way to go when I want to perform calculations of that sort? am I missing a third option?

The count issue is fixed.

Thanks a lot for your comment. I'm really learning more then I thought I would out of this thread.

[GerdW]

Hi shayelk,

isn't it a more elegant and visual way of writing it instead of a case within a case? (well, I guess the answer is "no" but I'd love to understand why).

Sequence frames limit parallel execution to their frames. Bad with modern CPUs…

- Use DATAFLOW to sequence steps of your algorithm. The error wire is recommended to enforce dataflow…

- You named some steps of your algorithm: use a state machine to execute your states…

do you mean using math nodes such as multiply and add? that seems to be really clumsy and not readable. isn't Mathscript the way to go when I want to perform calculations of that sort? am I missing a third option?

MathScript is only readable to people using C a lot. When using LabVIEW a lot you get used to read G…

Pure G usually is much faster than MathScript. And there are a lot of "advanced" math functions in the palettes!

[johnsold]

Thanks, GerdW, for reading my  mind (again) and posting before I did.

Lynn

[paul_cardinale]

Improperly tuned PIDs can have very strange behaviors, include what you describe.

You may just need to adjust your gains.