Chief Delphi - Fighting PID

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Fighting PID (http://www.chiefdelphi.com/forums/showthread.php?t=92514)

Geek 2.0

20-02-2011 21:52

Fighting PID

I have yet to try this, but I'm curious...

I want to control the facing direction of the robot with a gyro and PID AND I want to control the travel direction of the robot with an accelerometer and PID.

Will these two PIDs fight each other? If so, how would I program around that? Also, what's a good way to program it, considering I can only use one pidWrite() function per class?

davidthefat

20-02-2011 22:01

Re: Fighting PID

One solution:
Write a PID loop from scratch; it is a win win situation. You solve that problem, and you learn how to make a PID Loop and how it functions.

Geek 2.0

20-02-2011 22:04

Re: Fighting PID

I'm actually in the process of doing that, and just found a strange problem...

I found this in the PIDController class in WPILibJ:

Code:

if (((m_totalError + m_error) * m_I < m_maximumOutput)

                        && ((m_totalError + m_error) * m_I > m_minimumOutput))

{

       m_totalError += m_error;

}



m_result = (m_P * m_error + m_I * m_totalError + m_D * (m_error - m_prevError));

m_prevError = m_error;

By the looks of it, it's saying that it won't add the error to the total error if the result would be outside the maximum and minimum output. Does that seem wrong to anyone else? Shouldn't it add the error no matter what, and then clip off the result to fit in the max and min output?

Patrickwhite

20-02-2011 22:17

Re: Fighting PID

Quote:

Originally Posted by Geek 2.0 (Post 1027942)

I'm actually in the process of doing that, and just found a strange problem...

I found this in the PIDController class in WPILibJ:

Code:

if (((m_totalError + m_error) * m_I < m_maximumOutput)

                        && ((m_totalError + m_error) * m_I > m_minimumOutput))

{

       m_totalError += m_error;

}



m_result = (m_P * m_error + m_I * m_totalError + m_D * (m_error - m_prevError));

m_prevError = m_error;

That is usually how it's done. There are a few things in WPI's implementation that don't make sense, but overall it's fairly useful.

In terms of your original question, even if you used WPI's implementation, your output doesn't have to feed straight into a motor. If you have them as separate outputs, then decide yourself how to feed them into the speed controllers, there shouldn't be any problem.

kgzak

20-02-2011 22:31

Re: Fighting PID

We've always written our own PID loops. I have never used the PIDs given to us, I find that if you make you're own you can customize it to what you need. It's not that difficult, I use Labview though.

Deetman

20-02-2011 22:42

Re: Fighting PID

Quote:

Originally Posted by Geek 2.0 (Post 1027925)

I guess I'm a bit confused as to what you are using your sensors for. Using a PID with a gyroscope as feedback to control what direction your robot is definitely possible. As far as the accelerometer as a feedback sensor into a PID control loop, what exactly are you trying to control, direction of travel? Accelerometers pose an interesting control problem due to their sensitivity to noise including noise from vibrations in which a first robot has many. This can of course be overcome but I guess I'm confused as to what the accel will be helping control... Not saying you are wrong or that it won't work but to help you more I could use a bit more info.

Geek 2.0

20-02-2011 22:47

Re: Fighting PID

I must say, I'm having a bit of trouble understanding what WPILibJ is doing. I'm trying to use it as a reference, but it's contradicting itself. Another example of something that doesn't make much sense:

Code:

if (m_continuous)

{

      if (Math.abs(m_error) > (m_maximumInput - m_minimumInput) / 2)

      {

             if (m_error > 0)

             {

                    m_error = m_error - m_maximumInput + m_minimumInput;

             }

             else

             {

                    m_error = m_error         + m_maximumInput - m_minimumInput;

              }

       }

}

Continuous means that we don't use maximum and minimum input values. but apparently if we're continuous, we're referencing maximum and minimum inputs values!!! What's going on now??

Maybe I shouldn't use this as a reference...

Alexander Meyer

20-02-2011 23:28

Re: Fighting PID

Continuous mode still uses the min and max values, but not as limits--instead, it assumes that the shortest route to the setpoint can be achieved by going past the max back to the min and vice/versa. At least, if the comment on the SetContinuous method is to be believed..

Geek 2.0

20-02-2011 23:42

Re: Fighting PID

Wow, just wrote a lot of code (with no testing in between... this'll end poorly).

Thanks, that makes sense. Since I don't have that, I'm not supporting that feature. It all works out now.

Ether

20-02-2011 23:49

Re: Fighting PID

Quote:

Originally Posted by Geek 2.0 (Post 1027942)

By the looks of it, it's saying that it won't add the error to the total error if the result would be outside the maximum and minimum output. Does that seem wrong to anyone else?

Seems right to me.

Quote:

Shouldn't it add the error no matter what, and then clip off the result to fit in the max and min output?

No. You don't want the integrator error to continue winding up once it's large enough to produce the maximum output.

All times are GMT -5. The time now is 03:44.