Motion control and RELATIVE position problem

louis_reginaldjean@hotmail.com wrote:

Find an absolute position command and use it.  If you can only find an
absolute position command in an entirely different set of software then
chuck what you have now and go with the new stuff.

This isn't a motion control problem per se: the problem is that you want
absolute positions, your start position is moving and you can only issue
relative commands.  Since you cannot issue the command at the same
moment that the position is sampled you cannot guarantee that the
controller's final position will be what you want.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm afraid I'm missing something-- assuming a good reference point,
there's no difference between controlling a system with an absolute vs a
relative encoder, so long as no counts are missed.  

You don't send a servo system the number of counts it needs to travel--
you send it the desired position, and let the controller keep track of
the error, and move it in the right direction until the error is zero
(or near it).  

The start position of the relative encoder, unless somehow set
otherwise, is the position when the thing was turned on (at least if
properly initialized).  The real problem here is the large delay between
when the position is sampled and when the motion command is
modified--and its probably responsible for the oscillation. If you can't
deal with this delay, you won't be able to control even an absolute
system.



This seems to be the real problem!  A PID controller that can only
recieve relative commands isn't worth the silicon its laid out on.

I'm having trouble believing that the Microchip software behaves in this
way.  A PID system receives the command as its input, not the error.  If
you're at 1000, and want to go to 2500, you send the command 2500, not
the difference of 1500.  You do it this way regardless of whether you're
using an absolute or relative encoder.  With the absolute encoder, you
have the luxury of being able to miss counts, but that shouldn't be a
problem anyway.  You can use the PIC 18F2331, or 18F4331, which has
quadrature inputs, and never miss a count.  Or you can use any PIC you
feel like, and use an HCTL2020 to keep your count.  Either way, you'll
never miss any counts. The OP will need to write the PIC program, but
you must be programming the PIC in any case.  If the program can't be
modified, the same delay would kill you with an absolute encoder as
well.

FWIW, Microchip doesn't make PID controllers, but they might have
published code or an application note the OP might be using.  Most of
the code I've seen from Microchip (which all use absolute commands, BTW)
seems to make use of the counters to count quadrature.  I've had
problems using this approach (because of a 1024 count encoder and a
196:1  gear down to boot), and seem to have missed counts.  I've never
figured out why (and spent some time trying), but I suspect it was
noise, or too much overhead when polling the counts.  The encoder inputs
on the 18Fx331 have noise rejection that's software programmable, and no
overhead when polling the register for the count, and the HCTL2020 has
noise rejection built in, and maintains the correct count even when its
output is latched for reading.  The controllers I've built this way have
been fairly bullet proof.

The key is to give the PIC your command asynchronously, use a timer
interrupt to poll the current position, calculate your error, and modify
the output to the motor accordingly.  You should be able to do this at
more than 500 Hz with a 20MHz clock.

If the OP is willing to spend about $150, there are a slew of pretty
good controllers out there, even pic-based.  I haven't used them, but
www.jrkerr.com seems to have a good presence.




--
Scott
Reverse name to reply

Scott Seidman wrote:


That's why I was suggesting that if he had something that did not work
that way he should chuck the software.

-snip-


-snip-

 > FWIW, Microchip doesn't make PID controllers, but they might have
 > published code or an application note the OP might be using.  Most of
 > the code I've seen from Microchip (which all use absolute commands,
 > BTW)...

I haven't looked at any of the Microchip app notes that closely.  I'm
generally suspicious about code from app notes unless the company is
_really_ trustworthy -- IOW if they're Motorola.  I don't even know if
that still holds now that they've spun off FreeScale.  I suspect the OP
is missing something in the available commands.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I guess I am asking more than answering ... I'm not very familiar with
the how this whole setup works, but if the incoming signal is
"oscillating" at the same frequency of the sampling, shouldn't he just
increase his sampling rate according to Nyquist's sampling theory and
he should be ok?

abahei wrote:


He didn't say that it was oscillating at the sampling rate, he just said
it was oscillating -- and yes, that's a problem but it's a separate
problem and may not even be with his controller (his application could
have a large disturbance input, for example, which would cause the motor
to "oscillate" in some folks' terminology).

If the oscillation were from tuning, then obviously that should be
addressed.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

@g43g2000cwa.googlegroups.com:


Many things cause oscillation in control systems, and a delay of the sort
the OP is describing could certainly be one of them.



--
Scott
Reverse name to reply

I use the code in Microchip applicatio note AN718 title "Brush-DC
Servomotor Implementation using PIC17C756A". Look at page 9, the last
paragraphe it's said "In Position Mode, a 16-bit relative movement
distance is entered as encoder counts divided by 256.".  Look again at
page 12, to time you will see "relative position". Just do a search
with the word "relative". So tell me where did you see code from
microchip that use absolute position? Application note AN696 and AN 532
use relative position too (again make a "seach" on the pdf file). So I
CAN'T send a command of 2500 if I'm in position 1000 to go at 2500.

I use the code in Microchip application note AN718 title "Brush-DC
Servomotor Implementation using PIC17C756A". Look at page 9, the last
paragraph it's said "In Position Mode, a 16-bit relative movement
distance is entered as encoder counts divided by 256.".  Look again at
page 12, two time you will see "relative position". Just do a search
with the word "relative". So tell me where did you see code from
microchip that use absolute position? Application note AN696 and AN 532
use relative position too (again make a "seach" on the pdf file). So I
CAN'T send a command of 2500 if I'm in position 1000 to go at 2500.

louis_reginaldjean@hotmail.com wrote:


Why don't you modify the program to take absolute position commands?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott wrote:

A job for a consultant?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins wrote:


Or for pre-packaged software.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

louis_reginaldjean@hotmail.com wrote in news:1123516102.898386.265330
@g49g2000cwa.googlegroups.com:


Try AN937, for an example-- its listed under PID in the mechatronics
category.  The whole routine takes under 100 us, so your lags should be
non existent in a real time scale.

Frankly, relative control the way this note describes it is a silly thing
for a dynamic system-- you need to get the current position via RS232,
caculate a relative command based on your absolute needs, and send it
over RS232.  This will cause huge delays.  Think about sending the
absolute endpoint via RS232-- when received, the embedded controller can
then go calculate the error based on where your motor is NOW.  Simply by
sending an absolute endpoint, you can replace two relatively long UART
delays (plus whatever delay is added by your calculation and typing) with
one subtraction to calculate your absolute error (about 4 clock ticks!!),
and this should end your problem.

Take the applications notes for what they are-- thumbnail sketches on how
to get a job done--not necessarily the best way to do it, and not even
guaranteed to work.  Read ALL the relevant notes, and take the best bits
and pieces from each.  You should be able to wade through the software
and figure out how to provide the algorithm with an absolute command
instead of a relative command.  I think Tim Wescott has published a PID
algorithm in the past that is relatively easy to port to PICs, as well.

I know it seems frustrating, but once you start playing with something as
deeply embedded as this, you should jump in with both feet.  It's tough
to make things work unless you understand the task at a fairly
fundamental and algorithmic level, and can make the system do exactly
what you need it to do.  If you're not willing to get comfortable at this
level, then each task you take on has a real possibility of turning into
a can of worms.  You invest enough time in it to realize its a hair over
your head and then pick another tack, so it can be a huge resource waster
if you're not careful.  Even if you have the skills, if you can find a
reasonable off-the-shelf solution, its often cheaper in the long run than
rolling your own embedded system.

Otherwise, you might as well go with the $150 controller from jrkerr--it
really seems to be quite a deal.  If you're a student, or not under any
time pressure, keep hammering away at your own custom-tailored embedded
solution--it's good for your soul, and will make you MUCH MORE VALUABLE.

FWIW, I ended up building a PID controller because I needed to drive it
with an analog signal, and get the position output with a D/A and the
reasonable commercial systems I could find used a 10-bit A/D, which
wasn't high enough resolution for my needs, and didn't provide D/A
outputs.

As a last note, I recommend avoiding the 17C line of PIC entirely.  It's
userbase is extremely limited.  Stick with "F" chips--you have a lot more
flexibility while debugging code.  Move to the 18F line (if you can
afford the compiler), or stick to the 16F line, and you're more likely to
get support from a big userbase.  This doesn't seem important, until you
get a note from a user that points out a mistake in the documentation for
the PIC you're trying to use, or a small hardware bug with a workaround.  
Input like that can keep you from tearing out your hair, and a large user
base is the only way to get it.



--
Scott
Reverse name to reply

Scott Seidman wrote:

-snip-


Easy to port if you know how to make a PIC do the math.  If you just
take the code as written it will be a couple of orders of magnitude
slower than if you use fixed-point arithmetic with hand-optimized
multiplies in assembly.

Ask for a sample snippet of code before you proceed, though.  I'm
working with one of those off-the-shelf solutions for a PIC and it could
be used as an example of unmaintainable code.  Partially this is because
it's heavily optimized, and the PIC is not amenable to fast,
well-structured C code, but partially it's because (in my humble
opinion) the guy writing the code didn't really pay attention to
maintainability.

Yes it will.  When I interview people I ask questions and listen to
answers to find out what they've actually done, and at what level.  To
earn top points from me folks need to demonstrate that they can
understand all levels of a development effort, and that they know the
level that they're being hired for intimately.


As a last note _I_ recommend avoiding PICs entirely.  Atmel makes the
AVR line of microprocessors that has all the same features of the PIC,
plus an instruction set that was designed from the get-go with input
from a compiler group.  As a result you have much less temptation to
write terribly structured code "because it'll be more efficient".

I would apply the same advice to the 8051 but (alas) it is just too damn
popular.

And lest I start a flame war:  These are just my opinions, and I may
design a PIC (or an 8051) into a product tomorrow (particularly if the
client pays by the hour :).  There are huge numbers of good products
that are based around PICs and 8051s, so even though _I_ think they
should all be used as doorstops shouldn't keep _you_ from making good
stuff with them.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

@corp.supernews.com:

I've always wondered why you used floats in that PID code, and I've
chalked it up to illustrative purposes.  It might not run fast as
written, but its easy to follow.  Is there a link to that, BTW?



Understood.  If I was doing more embedded work for a living, I'd cast a
much larger net with much finer holes before I settled on a family.  That
said, I haven't had much trouble with the PIC.  I think the CCS compiler
takes much of the pain away, handling paging and so forth, so long as you
don't need to concern yourself with how fast the program runs and what
the assembler looks like.  Certainly, the c-code is easier to follow than
what I see from my friends using Hi-Tech.  

The 18F series has a better instruction set than you might be used to, if
you've stuck with the 16f so far.  It also has nifty features like
hardware 8x8 multiplies, and good support for motor control (e.g., direct
quadrature input--huge deal for when your count is tearing along real
fast--3 PWMs and their complements with a deadband for brushless
control).  I'm anxious to see how ccs supports the dsPIC (which they've
been promising for 6 months or more).  Now THAT looks appealing-- dsp for
a few dollars!

I learned how to code a uP on a 68030, using a firmware board with a
keyboard tied directly into it--no assembler, looking up the hex code for
each and every command and argument.  If you needed to edit a line on the
firmware, you'd hope to hell that the replacement command took up the
same or less bytes than what it was replacing, so you wouldn't have to
reenter your entire code from that point on (You'd learn pretty fast to
throw in liberal NOPs between statements!).  By that standard, there
isn't a development environment around that isn't tons better than that,
so I guess I'm easy to please.

Sounds like the AVR line is worth a look-see, so long as the compiler
doesn't cost an arm and a leg.  Which of the more reasonably priced
compilers do you recommend for the AVR?

Have you tried Cypress PSoC?  I've been thinking about picking up a dev
kit just to see what's up.  I try to go with products with a large base
of development tools, for obvious reasons, but when you look at all the
beautiful analog conditioning tools right on the chip, it has some appeal
("My board will be smaller!!").  Then you think about how lovely the
analog stuff you just place on your PCB now actually works, and how
little design time goes into it, that you wonder if the PSoC path is
worth it.

--
Scott
Reverse name to reply

Scott Seidman wrote:


I used floats purely for illustrative purposes (in fact as originally
published I hadn't even compiled the code -- I learned a lesson there).
  In practice I wouldn't hesitate to use floats _if_ I had plenty of
excess processor power, but on most processors floating point is way
slower than fixed-point arithmetic.  Since others have covered embedded
fixed-point math I haven't tried to address it.

A link to the article, or to just the code?  The article's on the
Embedded.com website (they own the rights), but I've got a pointer to it
on my website (http://www.wescottdesign.com/articles/pidwophd.html ).
They used to have the code available as a stand-alone download, I don't
know if they still do.

I've heard that, and will check it the next time I'm involved in
selecting a processor.  Usually my clients come to me after the
processor choice is fixed in stone, so it's been a while since I've had
the opportunity.


In fact I've got a DSPic sitting on a board design that I work on when
things are slow.  It'll probably never actually get built 'cause I'm
pretty busy these days, but it's sure intriguing.  I actually selected
it more for the 2.7-5.5V VCC range than price -- going straight from
batteries to the chip was _very_ appealing in this case.

By the time the PIC became popular I had moved to a company that built
small-volume high-performance equipment, and the philosophy was to save
software engineering hours by way over specifying the hardware.  We did
have one project where we actually selected the AVR (over the PIC) and
got as far as doing some sample code with it before the project was
canceled, but that's the closest I've come.

When we selected the AVR it was on the bleeding edge and the only
compiler available was the IAR.  Since then a bunch of them have popped
up, none of which I have experience with.  http://www.avrfreaks.net  used
to list a bunch of tools for the AVR, but the site has gotten _much_
slicker since the last time that I looked so I don't know how to get
around it easily any more.

I've seen it.  I've had the dubious privilege of being dragged through
the first few attempts at analog programmable hardware -- they were
always so bad that we found the flaws before we even got samples.  It's
made me very cynical, but if the application comes up that might use it...

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 8 Aug 2005 08:48:22 -0700, the renowned
louis_reginaldjean@hotmail.com wrote:


Why don't you just keep track of the previous *setpoint* and
add/subtract from that?

Add/subtract from the process variable is a mug's game, assuming it's
the encoder that's supplying all your feedback data.  

You'll need to zero it at some point (maybe with a 'home' switch).


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

louis_reginaldjean@hotmail.com wrote:


It would help if you described the nature of the oscillation in readings
(presumably from a quadrature encoder).

* Is it a maximum of +/- 100 counts or does it always get that wild.

* What is happening to the shaft of the motor while these counts are
  oscillating.

* Is the absolute position with reference to anything at all or is it
  just arbitrary.

With the answers to the above three questions we would all have a bit more
leverage on your problem and might be able to provide a more specific and
concrete solution.

--
********************************************************************
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************