Exact match. Not showing close matches.
PICList
Thread
'[PIC]: Need help with PID for motor control on a F'
2001\07\16@131738
by
Duane Brantley
OOPS! Sorry for the resend. I didn't get the topic line correct.
Hello everyone,
I found out this weekend that I a PID loop for the motor control on my bot.
I'm using the F877's PWM output to control my drive motors thru an Hbridge
setup. The motor has a shaft protruding from both sides. The wheel will go
on one side and I'll put a shaft encoder of some type of the other side.
With the shaft encoder, I'll be able to determine speed, direction, stall,
and whatever else I need.
I have NO clue about a PID loop, so if someone could give me some code to
look at and get an understanding, I'd greatly appreciate it!
Thanks,
Duane Brantley

http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: >uP ONLY! [EE]:,[OT]: >Other [BUY]:,[AD]: >Ads
2001\07\16@135734
by
Eisermann, Phil [Ridg/CO]
2001\07\16@142211
by
Dan Michaels
Duane Brantley wrote:
.......
>I have NO clue about a PID loop, so if someone could give me some code to
>look at and get an understanding, I'd greatly appreciate it!
>
Duane, if you have access to "Mobile Robots" by Jones & Flynn,
they have some simple examples in C code.
oy,
 dan michaels
http://www.oricomtech.com
=========================

http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: >uP ONLY! [EE]:,[OT]: >Other [BUY]:,[AD]: >Ads
2001\07\16@144222
by
Duane Brantley
If I can get away with it in C, that would be great!! If not, assembly will
work. I'll look for the book when I get off from work.
{Original Message removed}
2001\07\16@152201
by
Dan Michaels
Duane, it is an excellent book, but probably not worth
buying just to get the PID stuff, which is not covered
thouroughly. It does have a really good description of
how to implement subsumption architecture, however.
Try Barnes&Noble.
 dan
================
At 01:26 PM 7/16/01 0500, you wrote:
>If I can get away with it in C, that would be great!! If not, assembly will
>work. I'll look for the book when I get off from work.
>
>{Original Message removed}
2001\07\19@140551
by
Mike Mansheim

> I have NO clue about a PID loop, so if someone could give me some code to
> look at and get an understanding, I'd greatly appreciate it!
[WARNING]: this ended up being a long post
Actually, the pseudocode for a PID loop is pretty basic. Say you want
to control motor rpm:
pid_calc:
last_error = error
error = target_rpm  measured_rpm
sum_error = sum_error + error
delta_error = error  last_error
proportional_term = error * proportional_gain
integral_term = sum_error * integral_gain
derivative_term = delta_error * derivative_gain
control_signal = proportional_term + integral_term + derivative_term
and the pwm for the motor is derived from control_signal. The real trick
is
tuning the gains to get your system to respond the way you want. The
integral
term gets you to a steady state operating condition; the proportional term
reacts
to sudden changes in speed (therefore, load), and the derivative term helps
react to a rapidly changing error. The derivative term is often not needed

I would certainly start without it. Using just the integral will work, but
the system will react relatively slowly to changes. You can also use just
the proportional term, but the speed will always be at some offset from the
target speed (some error would always be required to have the control
signal
nonzero). In a PI system, if the proportional gain is too large, the
system
will oscillate around the target (hunting).
Some other considerations/thoughts for turning this into actual code:
 pid_calc should be called at a consistent time interval, which should be
based on how fast the systems responds to a change in the control signal.
Do NOT adjust faster than the system can respond, or the feedback is
meaningless!
 be aware of the effect that filtering the feedback signal can have on the
response of the system. For example, if the rpm is being measured via
a frequency to voltage converter fed into an a/d input on the pic  that
is likely being done more frequently than pid_calc, with the result
filtered before being used in the pid calculations.
 error has a sign  this has to be dealt with in all the math. You want
the integral sum (sum_error) to be able to move up & down  so you want
a signed error  but that can be accomplished without actually using
signed variables, if that is your preference. On the other hand, a
negative control signal doesn't make sense in many systems. For
example, controlling the speed of a motor that can turn in both
directions: the motor direction is probably set elsewhere and is not
tied to this control signal. So you would trap a negative error and
set it to zero for the proportional term calculation.
 bounds checking in general: you don't want the integral term to roll
over
(I've heard this called "winding up"); you'll probably want to clamp it
at
some value that represents the maximum control signal allowable.
Typically,
the integral gain is 1, and the proportional gain is large  which means
you
need to make sure that the proportional gain calculation is "legal",
etc...
 one approach is to have control_signal 16 bits, error 8 bits, and the pwm
output the high byte of control_signal. With the integral gain = 1, this
is
a good place to start for a controlled ramping up to a target value.
 you'll have to decide when to reset the integral sum (sum_error) to
zero.
Also, you might have a condition where you save the integral sum, then
restore
it later. For example, to stop quickly, you set the pwm output to zero;
then
to get going again, if you know you want to be back at the same speed,
you just
restore the old integral sum, rather than waiting for the loop to build
it
back up again. Another example of integral sum manipulation: if the
target
rpm changes by a large amount, you could add or subtract some chunk from
the
integral sum to give the pid loop a head start on getting to the new
speed.
 if you need to really get fancy, obviously the gains don't have to be
constant.
They can be proportional to the error, or different for different ranges
of
error, or different for positive and negative errors, etc. The limit on
the
integral sum also doesn't need to be constant. Just start simple, as
things
can get really complex  especially when your system is "crossing
boundaries".
 and on and on...

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2001\07\19@141015
by
James R. Cunningham
2001\07\19@173524
by
Olin Lathrop
> pid_calc:
> last_error = error
This first step should go at the end, otherwise the DELTA_ERROR below will
always be 0.
{Quote hidden}> error = target_rpm  measured_rpm
> sum_error = sum_error + error
> delta_error = error  last_error
>
> proportional_term = error * proportional_gain
> integral_term = sum_error * integral_gain
> derivative_term = delta_error * derivative_gain
>
> control_signal = proportional_term + integral_term + derivative_term
>
> ...
> and the derivative term helps
> react to a rapidly changing error. The derivative term is often not
needed
> 
> I would certainly start without it.
The derivative term is often used with negative gain to dampen the system
and prevent it from ringing. Unfortunately it is also the most susceptible
to input noise. High integral term gain can lead to instability, which can
be partially offset by the damping effect of a negative derivative term.
Personally, I would start out with just the P and D terms. Start
experimenting with the system with just the P term and get a feeling for how
it reacts, then slowly crank up the D term and see how the damping works.
I would leave the I term to last and only use it if you need low long term
error or the steady state error without it is too large.
********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 7429014, olinKILLspamembedinc.com, http://www.embedinc.com

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body
2001\07\19@183638
by
Mike Mansheim
>> pid_calc:
>> last_error = error
> This first step should go at the end, otherwise the DELTA_ERROR below
> will always be 0.
>> error = target_rpm  measured_rpm
>> sum_error = sum_error + error
>> delta_error = error  last_error
>>
>> proportional_term = error * proportional_gain
>> integral_term = sum_error * integral_gain
>> derivative_term = delta_error * derivative_gain
>>
>> control_signal = proportional_term + integral_term + derivative_term
I should have been clear on scope: either last_error or error will have
to be global or static; I assumed error would be global. In that case,
I think the way I wrote it would work. If that statement is at the end,
it requires that last_error survive until the next call.

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2001\07\19@184117
by
Mike Mansheim
More... (looser matching)
 Last day of these posts
 In 2001
, 2002 only
 Today
 New search...