12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

I am using a PIC18F458 to try to get a motor to lift a weight a
specified distance. I am using a quadrature encoder to close the
feedback loop and the encoder has 1600 counts per revolution.

I have written a working algorithm that given a final destination,
will produce a nice accelerate, cruise, and decelerate trajectory. I
then want to feed this trajectory into a PID function which will set
the appropriate duty cycle.

My problem is PID algorithm... i know how to write it and how it
works, but given the error between where the motor is currently and
the desired position, i need some sort of conversion between error and
duty cycle, because if i set the duty cycle to be exactly what my
error is, the motor spins too fast and out of control... but if i try
to make it smaller, the motor wont move fast enough...

does anyone have any idea or any suggestions on what i can do to fix this?

any help will be greatly appreciated

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Yes first you must apply a P-factor, like this:
PWM = (Position Error) x (P-factor).
Initially the position error is likely to be in counts (difference between set and actual positions), and you can probably work with that as this
value is likely to be in the range 0 to a few hundred.
Then simply multiply with an adjustable integer number (P-factor), typically anywhere from 1 to several thousand, and feed to PWM.
If this is a 2or 4-quadrant drive you must obviously handle the polarity issues both regarding the position error and the PWM drive.
Also the PWM will most likely want the data with a certain offset, and you may have to impose hard limits before moving data to the
PWM register.

Further down the road you'll most likely have to add both Integral and Derivative, in addition to the Proportional to get a good working system.
But start with Proportional alone to get the hang of things.

Good luck!
poopinurmouf wrote:

> I am using a PIC18F458 to try to get a motor to lift a weight a
> specified distance. I am using a quadrature encoder to close the
> feedback loop and the encoder has 1600 counts per revolution.
>
> I have written a working algorithm that given a final destination,
> will produce a nice accelerate, cruise, and decelerate trajectory. I
> then want to feed this trajectory into a PID function which will set
> the appropriate duty cycle.
>
> My problem is PID algorithm... i know how to write it and how it
> works, but given the error between where the motor is currently and
> the desired position, i need some sort of conversion between error and
> duty cycle, because if i set the duty cycle to be exactly what my
> error is, the motor spins too fast and out of control... but if i try
> to make it smaller, the motor wont move fast enough...
>
> does anyone have any idea or any suggestions on what i can do to fix this?
>
> any help will be greatly appreciated
>

--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Thanks, that actually does help. But the issue is, since the PIC does
not use floating point, i cant get a accurate enough P-Factor to
multiply the error with. I have run some tests and it looks like the
P-Factor should be a number between 1 and 2...

any suggestions on how to get around this?
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Don't be confused ... floating point by definition is inaccurate. If you
like inaccurate, there are floating point libraries for the PIC but they
tend to be slow.

Values in the PIC (or any processor) represent whatever you want them to.
There is no need for a "1" in the PIC to represent a 1 in real life.
Sometimes, though, it is easier if you have some representation that means
something to you. The math usually isn't easier, but getting your head
around it is.

Depending on your calculation and need for accuracy, you might allow a
two-byte value of 20,000 to represent a P-Factor of 2. This should give you
a decent amount of precision, and enough headroom that overflow isn't a huge
issue. Of course, you will need to scale your inputs, too. If you need
more precision, use more bytes.

In the more general case, you would use scaled fraction arithmetic. Allow
the highest possible value for the number of bytes you choose to use to
represent "full scale" or the highest value of the result. This takes some
thought, but it is a worthwhile exercise to get familiar with reasonable
ranges of values in the problem space. This is a common enough practice
that the 16 bit PICs do scaled fraction arithmetic natively.

72/73 de WB8RCR http://www.qsl.net/wb8rcr
didileydadidah QRP-L #1446 Code Warriors #35
----- Original Message -----
From: "poopinurmouf"
To:
Sent: Thursday, June 26, 2008 10:04 AM
Subject: [piclist] Re: Position Control with PIC
> Thanks, that actually does help. But the issue is, since the PIC does
> not use floating point, i cant get a accurate enough P-Factor to
> multiply the error with. I have run some tests and it looks like the
> P-Factor should be a number between 1 and 2...
>
> any suggestions on how to get around this?
> ------------------------------------
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Ok, that makes sense, i think i can handle that.

I am still a little confused with something... should i be sending my
PID controller the position error in counts or should i try to send it
a velocity in counts/sample? what are advantages/disadvantages for
each method?

thanks for all your help
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

If you want to control position, then the controller needs the position.
The derivative part of the controller is essentially velocity.

Keep in mind that the derivative component is very hard to tune, and
generally isn't particularly useful except in unresponsive loops like
temperature. You probably want to start out with the derivative gain set to
zero. Integral deals with offset and proportional helps you respond more
quickly. If you can't get the loop to respond quickly enough with just PI,
then start edging up the derivative. Personally, for a position controller,
I wouldn't bother with implementing the derivative portion.

72/73 de WB8RCR http://www.qsl.net/wb8rcr
didileydadidah QRP-L #1446 Code Warriors #35

----- Original Message -----
From: "poopinurmouf"
To:
Sent: Thursday, June 26, 2008 10:43 AM
Subject: [piclist] Re: Position Control with PIC
> Ok, that makes sense, i think i can handle that.
>
> I am still a little confused with something... should i be sending my
> PID controller the position error in counts or should i try to send it
> a velocity in counts/sample? what are advantages/disadvantages for
> each method?
>
> thanks for all your help
> ------------------------------------
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I understand how a PID works and what all the terms are for, im still
stuck on what to feed my PID. I am driving my motor with PWM duty
cycle %. If i send the PID a position error, how do i translate that
to a duty cycle %?
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Hi
I have only just looked at the messages relating to this topic. I
would have thought to do what you want that you need to use the servo
in two different modes. When the position error is above some
specified value then have the servo working as a speed controller to
make it follow the ramp profile. When the position error is below this
threshold change to position servo mode to get to the set position.
Regarding the calculation accuracy have a look at "Microchip's"
application node AN937. This contains general information on "PID"
design and the source code contains some useful 16/24 bit maths
routines. The division routine is fast as it uses hardware multiply
and a table of reciprocals. I used these routines for a PID speed
controller for the table on my X3 milling machine and the worked well.
There are also other position servo designs in other application
notes. I hope this reply appears in the messages in a sensible time.
The last reply I posted took several weeks to appear. (This reply
16:15 26/06/08)
Les.

--- In p...@yahoogroups.com, "poopinurmouf" wrote:
>
> Ok, that makes sense, i think i can handle that.
>
> I am still a little confused with something... should i be sending my
> PID controller the position error in counts or should i try to send it
> a velocity in counts/sample? what are advantages/disadvantages for
> each method?
>
> thanks for all your help
>

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

thats a good idea, i hadnt thought of that. In another forum, i asked
the same question and someone responded telling me that the I term in
my PID is pointless because i am using position as my feedback by
driving the motor to a velocity, and that conversion alone would
account for the integral term in my PID... is this true, i had never
heard of this before... any opinions?
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> Thanks, that actually does help. But the issue is, since the PIC does
> not use floating point, i cant get a accurate enough P-Factor to
> multiply the error with. I have run some tests and it looks like the
> P-Factor should be a number between 1 and 2...
>
> any suggestions on how to get around this?

Change your scale and use fixed point math. Anything that can be
represented as a 1 can be represented as a 10 or 100 as long as your
scale is the same throughout the calculation. What you need is more
resolution, not floating point.

DLC

>
> ------------------------------------
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> Ok, that makes sense, i think i can handle that.
>
> I am still a little confused with something... should i be sending my
> PID controller the position error in counts or should i try to send it
> a velocity in counts/sample? what are advantages/disadvantages for
> each method?

In order for your PID function to make sense of anything your feedback
and output need to be in the same units so that your error value makes
sense. Of course this isn't always possible, it is just the ideal.
Otherwise you need to scale your feedback to match the math used for
your output. Don't get hung up on unit names; it doesn't matter if the
units are inches fathoms or furlongs, as long as they are consistent.

DLC

> thanks for all your help
> ------------------------------------
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> If you want to control position, then the controller needs the position.
> The derivative part of the controller is essentially velocity.
>
> Keep in mind that the derivative component is very hard to tune, and
> generally isn't particularly useful except in unresponsive loops like
> temperature. You probably want to start out with the derivative gain set
> to
> zero. Integral deals with offset and proportional helps you respond more
> quickly. If you can't get the loop to respond quickly enough with just
> PI,
> then start edging up the derivative. Personally, for a position
> controller,
> I wouldn't bother with implementing the derivative portion.

You really think so? I would disagree. I find that P and D are the
most useful, especially for servo mechanisms. Without the D portion
you lose the ability to ramp up and down rationally at the ends of your
control curve. I've found the I factor to be MOST difficult to tune
because of its tendency to "unwind" to make up for lost time accumulated
over a "noisy" cycle. Most folks tend to "short circuit" the I
accumulation when they reach target or the blasted loop tends to zip
ahead.

DLC

> 72/73 de WB8RCR http://www.qsl.net/wb8rcr
> didileydadidah QRP-L #1446 Code Warriors #35
>
> ----- Original Message -----
> From: "poopinurmouf"
> To:
> Sent: Thursday, June 26, 2008 10:43 AM
> Subject: [piclist] Re: Position Control with PIC
>> Ok, that makes sense, i think i can handle that.
>>
>> I am still a little confused with something... should i be sending my
>> PID controller the position error in counts or should i try to send it
>> a velocity in counts/sample? what are advantages/disadvantages for
>> each method?
>>
>> thanks for all your help
>> ------------------------------------
>>
>> to unsubscribe, go to http://www.yahoogroups.com and follow the
>> instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> I understand how a PID works and what all the terms are for, im still
> stuck on what to feed my PID. I am driving my motor with PWM duty
> cycle %. If i send the PID a position error, how do i translate that
> to a duty cycle %?

This is where "fuzzy logic" comes in handy. You don't _care_ what the
PWM duty cycle is. You only care what your desired velocity or position
is and what your error is from that. So, you know that you have a
distance of 2 feet to traverse, you measure your error and find that you
are 1.5 feet off of your destination. Now you increase your PWM until
you match your destination. You don't care what that value is, but you
do know, and code for, that as you get closer to your goal you need to
slow down to avoid over-shooting it. This is called the "PID tuning
loop" where you set the weights on your P,I,D to get you the
acceleration/deceleration curves that you want. There will be NO direct
correlation between your error value and PWM, they are related by an
unknown value out there in the real world that is causing the
difference.

Divorce your mind from the "error to PWM translation", there isn't one.
You only care about the destination and the error value.

DLC
--
Dennis Clark
TTT Enterprises
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> thats a good idea, i hadnt thought of that. In another forum, i asked
> the same question and someone responded telling me that the I term in
> my PID is pointless because i am using position as my feedback by
> driving the motor to a velocity, and that conversion alone would
> account for the integral term in my PID... is this true, i had never
> heard of this before... any opinions?

I think that he is simplifying it a bit. The I term does come in handy
with positioning PID loops for smoothing out some variations. But it is
deucedly difficult to tune, and needs to be an order of magnitude or
more lower than the weights given to the P and D terms. Which may be
why he said that.

DLC
--
Dennis Clark
TTT Enterprises
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

When i had a purely PID position control application, this is exactly
what i did... i did not care what units or value i was giving the PWM,
i just had it so the larger the error, the more power to the motor...
and it worked fine, a slight overshoot, but not an issue for my app.

I only started to have problems when i tried to incorporate a
trajectory generator so that my motor would have a smooth accelerate,
cruise, decelerate path... this involves a maximum velocity that i
should cruise at, and also a maximum acceleration for my acceleration
and deceleration phase of the trajectory. Also, timing plays a big
role in my trajectory computations... It was only when i added this
trajectory generator that i started to have problems with setting
appropriate duty values.

right now, i have the traj. generator working, i know this cause i
have debugged and i know its giving correct positions to the PID
controller. But i have yet to find a way to control this, i have tried
to use "fuzzy logic" with this one, but either i got almost no motor
rotation, or i get too much... i have yet to find a happy medium.

any suggestions? i have coded this in C, so if you think looking at
the code would help at all, let me know
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> When i had a purely PID position control application, this is exactly
> what i did... i did not care what units or value i was giving the PWM,
> i just had it so the larger the error, the more power to the motor...
> and it worked fine, a slight overshoot, but not an issue for my app.
>
> I only started to have problems when i tried to incorporate a
> trajectory generator so that my motor would have a smooth accelerate,
> cruise, decelerate path... this involves a maximum velocity that i
> should cruise at, and also a maximum acceleration for my acceleration
> and deceleration phase of the trajectory. Also, timing plays a big
> role in my trajectory computations... It was only when i added this
> trajectory generator that i started to have problems with setting
> appropriate duty values.

So your problems started when you implemented a trapezoidal accel/decel
curve? I feel your pain. I've done this by implementing the ramps
outside of the PID loop and feeding the PID loop the values that I
wanted for that stage of the traverse. This set the maximum or minimum
values that the loop could move to, not the endpoints at the
destination. Try that dodge.

BTW - If you keep the message history in your response we can tell who you
are responding to.

DLC

> right now, i have the traj. generator working, i know this cause i
> have debugged and i know its giving correct positions to the PID
> controller. But i have yet to find a way to control this, i have tried
> to use "fuzzy logic" with this one, but either i got almost no motor
> rotation, or i get too much... i have yet to find a happy medium.
>
> any suggestions? i have coded this in C, so if you think looking at
> the code would help at all, let me know
> ------------------------------------
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

John,
I think you're mistaken... at least when it comes to motor control.
The derivative is VERY important, it acts as a damper (a bit like dunking the motor in a jar of honey) and
it is what keeps the position from overshooting when using high P factors... which in turn is necessary
for getting a 'stiff' and accurate response.

"John J. McDonough, WB8RCR" wrote:

> If you want to control position, then the controller needs the position.
> The derivative part of the controller is essentially velocity.
>
> Keep in mind that the derivative component is very hard to tune, and
> generally isn't particularly useful except in unresponsive loops like
> temperature. You probably want to start out with the derivative gain set to
> zero. Integral deals with offset and proportional helps you respond more
> quickly. If you can't get the loop to respond quickly enough with just PI,
> then start edging up the derivative. Personally, for a position controller,
> I wouldn't bother with implementing the derivative portion.
>
> 72/73 de WB8RCR http://www.qsl.net/wb8rcr
> didileydadidah QRP-L #1446 Code Warriors #35
>
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Hi,
Floating Point is not really more accurate, but can represent larger numbers.
Fixed point is absolute in accuracy, and based on the wordlength in use you
know exactly how accurate it is... e.g 32bit (4byte) give you an accuracy of
1 / 429,496,7296... which is some 0,00000002%... adequate for just about anything!

Anyhow forget floating point for your project, fixed point is what you need.
Servo systems can be made to work with 8bit math but you may be disappointed with
the results. I recommend using 32 bit math because some products may need it, although
other parts of the PID code (like error calcs) needs only 16bit... That's AFTER limit!
If you're careless with limiting data you can get rollover and the system goes haywire!

At your stage of development you should remove the trajectory planner from the system
and concentrate on getting the loop locked and stable... This is the foundation that the
trajectory planner and all else is based on.

You say a P-factor between 1 and 2... Well in theory that may be correct,
but I would think you've got to the core of the problem right here. You still won't need floating point math here.

A good working PID algorithm may look something like this (this is the exact calculations done in one of my PID controllers):
Y=(Kp*U) + (Ki*(KiA+U)) + (64*(Kd*(U-(k-1))))
Y is the summing node, and this is the data that essentially is fed to the PWM.
However Y will need some post processing before you can pass the data to the PWM register.

A)
Obviously because Y is the sum of 'everything' it is likely the largest variable in the calculations, I needed 32 bits here,
and it needs to be truncated to 16bits. Remember to preserve the sign as this is all signed math!
Don't operate on the original Y variable, copy it to a temporary before proceeding!

B)
In the early stages I recommend using only the P term from the equation as this greatly simplifies things until you get the loop locked.
Your "PID" then becomes: Y = ( Kp * U ).
-Kp is adjustable P-factor (32bit),
-U is position error (16 - 32bit),
-Y is the sum (or product in this case...).

C)
Then to avoid overloading the PWM register you MUST hard limit the 16bit data, still preserving the sign.
The limits must be within (or well within) the PWM range for the selected resolution, 10bits recommended.

D)
You now have a Y value that lays in the range: (-1023) - (0) - (1023). Or use 1020 to be safe...
This is almost something the PWM can eat but we need just a little more processing...
The sign needs to be removed (since the PWM operates only on positive values), so if Y < 0 then complement
to bring it positive, store the sign in a flag.

E)
Now you can move the Y data to the PWM register, and output the sign bit to the H-bridge to control direction.
You should now have a somewhat 'stiff' motor, be able to test out various Kp values, and set new positions by
writing to the Set Position variable.
HTH
poopinurmouf wrote:

> Thanks, that actually does help. But the issue is, since the PIC does
> not use floating point, i cant get a accurate enough P-Factor to
> multiply the error with. I have run some tests and it looks like the
> P-Factor should be a number between 1 and 2...
>
> any suggestions on how to get around this?
>
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Sorry there was a typo in my last post, corrected here:

B)
In the early stages I recommend using only the P term from the equation as this greatly simplifies things until you get the loop locked.
Your "PID" then becomes: Y = ( Kp * U ).
-Kp is adjustable P-factor (16bit),
-U is position error (16bit),
-Y is the sum (32bit). (or product in this case...).

Eirik Karlsen wrote:

> Hi,
> Floating Point is not really more accurate, but can represent larger numbers.
> Fixed point is absolute in accuracy, and based on the wordlength in use you
> know exa--
>
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

poopinurmouf wrote:
> Thanks, that actually does help. But the issue is, since the PIC does
> not use floating point, i cant get a accurate enough P-Factor to
> multiply the error with. I have run some tests and it looks like the
> P-Factor should be a number between 1 and 2...
>
> any suggestions on how to get around this?

Use some kind of fixed point arithmetic.

Suppose you wanted to multiply your error by 1.625. This is 26/16 so you
could write code like this:

correction = ( 26 * error ) / 16;

Remember to check for overflows when you do this. Using 16 as a divisor
is good because the division is a simple bit shift. Your accuracy is now
in the order of 1/16th

You should be able to find more about fixed point maths on the web
somewhere but good stuff seems hard to find.

Your could try these:

http://www.embedded.com/98/9804fe2.htm
http://ww1.microchip.com/downloads/en/AppNotes/00617.pdf

Pete Harrison
www.micromouseonline.com

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )