Shop OBEX P1 Docs P2 Docs Learn Events
Motor Positioning, Inertia, & SX — Parallax Forums

Motor Positioning, Inertia, & SX

nick bernardnick bernard Posts: 329
edited 2005-02-18 15:06 in General Discussion
it's like you know,

i have a position encoder (8bit) attached to a DC motor. this feedback encoder is wired to RB. the motor is controlled by 2 relays that determine the direction of rotation. the sx controls both relays via FETs.
There is an identical position encoder (let's call it the command encoder) with a knob wired to RC. the program will turn the motor until the position of the feedback encoder matches the position of the command encoder.

simple right?

eh no - occasionally the motor will overshoot the command position because the motor needs time to stop & inertia keeps things moving for a bit. i did some crude measurements and determined that at full speed the position encoder changes LSB at 24 times a second. The SX is sampling the feedback position every .5us or 2000000 times a second so i should have plenty of time to emplement some type of control scheme to resolve this problem.

i was simply wondering if anyone has had any experience with transient control with the SX or any other advice that could help with this situation.

see the encoder at
http://www.encoderdevices.com/download/ed_21/ED-21.pdf

and also a crude one-wire schematic

and some code

thx
nickB

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life

Post Edited (nick bernard) : 2/16/2005 10:59:43 PM GMT

Comments

  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2005-02-16 23:13
    "Electrical braking" or "regenerative braking" should help reduce overshoot which may or may not work for your application.
    In most DC motors this is a simple matter of creating a "shunt" across the motor terminals after power has been removed or
    redirecting the generated power into a storage supply. In most AC induction motors, applying a small DC voltage has a
    similar braking effect.

    ....Also, if you know you are going to "stop" the motor, then ramping the speed down will also work.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe - Mask Designer III

    National Semiconductor Corporation
    (Communication Interface Division)
    500 Pinnacle Court, Suite 525
    Mail Stop GA1
    Norcross,GA 30071

    Post Edited (Beau Schwabe) : 2/16/2005 11:16:57 PM GMT
  • Paul BakerPaul Baker Posts: 6,351
    edited 2005-02-16 23:22
    Though I don't have experience with this, this sounds like a good application for PID, which will act like an overdamped circuit. The motor will slow as it approaches its target position amortizing the reduction in momentum over a larger period.

    heres the first link i came across: http://www.ecircuitcenter.com/Circuits/pid1/pid1.htm

    Post Edited (Paul Baker) : 2/16/2005 11:25:23 PM GMT
  • nick bernardnick bernard Posts: 329
    edited 2005-02-17 01:02
    I spent a year in college studying analog & digital control and DSP but i cant apply it to a simple circuit. they left the practical application part out.
    in any case i think i have a solution:

    1. predict where the motor will stop so we can stop it early.
    2. how early depends on how fast its moving

    so all we have to do is subtract the previous position from the current position and multiply it by a constant, add that to the current position and voila

    i may have a problem with timing since the sx is operating sooo fast but when i start twiddling with the assembly i think something will come up...

    off to the think tank
    nickB

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    League Bowling.... it's not a sport, it's a way of life
  • BeanBean Posts: 8,129
    edited 2005-02-17 02:54
    How about just ramping down the motor speed as you approach the set point.
    But a PID controller would be the best.
    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out· the "SX-Video Display Module"

    www.TerryHittConsulting.com
    ·
  • nick bernardnick bernard Posts: 329
    edited 2005-02-17 13:09
    the only control i have over the motor is on/off via relays so i cannot control speed.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    League Bowling.... it's not a sport, it's a way of life
  • BeanBean Posts: 8,129
    edited 2005-02-17 13:12
    I don't see how you could possibly hope to "hit the mark" using something as slow as a relay to control the motor ?
    If you used a mosfet or something you could slow the motor using PWM.
    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out· the "SX-Video Display Module"

    www.TerryHittConsulting.com
    ·
  • nick bernardnick bernard Posts: 329
    edited 2005-02-17 14:04
    the speed of the motor is less than 8 rpm. further more the motor is only a prototype. the actual system i want to try to control is a hydraulic motor. relays control solenoids that control pumps that turn the hydraulic motor that turn the feedback encoder.

    here's a pic i found on google

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    League Bowling.... it's not a sport, it's a way of life

    Post Edited (nick bernard) : 2/17/2005 2:15:23 PM GMT
    800 x 600 - 55K
  • Paul BakerPaul Baker Posts: 6,351
    edited 2005-02-17 16:29
    Again I don't have experience controlling hydraulic motors either, but I would imagine that inertia in a hydraulic motor will be even more of an issue. If precise control of such a system is nessesary, you may need a more complex control system. Also using a standard DC motor may not be an accurate model for control of a hydraulic motor (much like a pharmacuetical company wont choose a paramecium to test a glaucoma drug on). But the fact that your motor is 8rpm probably means its a gear reduction which will add to the inertia, so perhaps it is an acceptable model of your target system. Anyways since you said you took courses on control theory you probably already know many of these things.

    With all that said, if you will only have on/off control of your target motor, my best suggestion is to derive inertial equations to calculate what the total rate of travel will be once the motor is switched off for a given speed, and when the position reaches the point where the inertia will take it to its intended position, switch off the motor.
  • nick bernardnick bernard Posts: 329
    edited 2005-02-17 18:05
    Paul Baker said...
    ... Anyways since you said you took courses on control theory you probably already know many of these things...
    ...derive inertial equations to calculate what the total rate of travel will be once the motor is switched off for a given speed...

    my courses were all mathy. when we had to develop controllers for missles and broomsticks the plant was modeled by mathmatical models (laplace or z transform).

    and yeah thats what i was saying. something just like this, (Z^-1 is the previous sample) where you add an "expected position bonus" to your feedback before pushing it into the comparitor.
    the trick is finding out how often to sample the feedback

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    League Bowling.... it's not a sport, it's a way of life
    828 x 534 - 47K
  • Jim G.Jim G. Posts: 27
    edited 2005-02-17 19:11
    This sounds like a very fun project, and there have been some great responses to your original questions...

    Not knowing much about your current set-up, I will throw some things out that you have probably considered, so please don't be offended... stuff like using the upper 8 bits of the 9-bit encoder, and using 1:1 ratio for the pulleys, etc.

    One of the challenges for this project is getting the time domains straight.· At 24 LSB steps/second that is 42 milliseconds/step;·so you have things happening in the millisecond range.· The knob is probably getting turned faster than that, when it is actually being turned, so you may need to deal with that;·and of course, the CPU is screaming.· Setting up a 100uS interrupt, for instance, and using a couple prescaling counters to perform different tasks every 100uS, 1mS, 100mS, etc. will help.· If you want to get real fancy, you can have the program calculate the motor speed, in mS/count, instead of using the estimated value...

    One thing that will help is to think in terms of "how many milliseconds until the thing is in the correct position given how long it has been running", instead of "how many counts on the encoder is it from the desired position".· In order to calculate this you need to know the (difference in encoder counts) X 42 mS/count - (how many mS to stop).· The (how many mS to stop) value can probably be loaded from a small, 16 byte(?) table, and the index into the table is how many mS (or ten's of mS)·the motor has been running (relay energized).· You will have to build the table by experimenting with different on times.· You could proabably write a test program to turn the motor on for different durations of time, and measure how much it moves when turned off.· So you need to keep a counter that is·reset upon energizing a relay and counts up to some limited value (15 for instance) every n mS while the relay is energized.· The rate at which this counter is incremented is one of those time domain things mentioned above; it will be handled by some prescaler in some timed interrupt...

    So, as the thing is moving you calculate the above formula every 1mS, let's say, and when the answer is somewhere near zero, you de-energize the relay.· Remember that the uncertainty is 42mS·(per LSB count).·

    I am curious about a couple things.· If the demand encoder is turned to a point where it would be "shorter" for the motor to turn the other direction, does it continue in the original direction, or does it reverse direction?· When it reverses direction, for any reason, is there a time delay between deenergizing one relay and energizing the other?· Is is feasible to give the motor a little "bump" in the reverse direction to make it stop quicker?

    I guess I got a little carried away, but it is an interesting project... ;-)

    Jim.
    ·
  • nick bernardnick bernard Posts: 329
    edited 2005-02-17 19:52
    Jim G. said...

    I am curious about a couple things. If the demand encoder is turned to a point where it would be "shorter" for the motor to turn the other direction, does it continue in the original direction, or does it reverse direction? When it reverses direction, for any reason, is there a time delay between deenergizing one relay and energizing the other? Is is feasible to give the motor a little "bump" in the reverse direction to make it stop quicker?

    thx for the reply jim.
    to answer your questions the comparitor algoritm does find the shortest path from Command to Feedback and i did not add a delay for a change in direction. also i dont think that i can "bump" the hydraulics like that because thats almost what i'm doing now with 1 lsb of overshoot and i'm sure it will be too "violent" for the drive.

    this project initially was running on a BS2SX. but when i got the sx chips in a few days ago i realized they would provide much better control over the unit and a bs2sx could still handle the position displays.

    in short i've been working with the sx for 3 days and i really dont know to much about interrupts (because i just got to that unit in the al williams book). but i used to program intel 8086's in college so the assembly is comming quite natural. i figured there would be a method to time sample rates i just know know much about it.

    whoa is me.
    any help?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    League Bowling.... it's not a sport, it's a way of life
  • Paul BakerPaul Baker Posts: 6,351
    edited 2005-02-17 19:56
    Nick yeah your hitting home, but I think you may need another z^-1 to model the system correctly. I'm about to go into a little bit of mathmatical hand waving so don't hold me to this being correct. Your trying to determine final position if you were to turn the motor off at this moment, then compare that with the desired final position (once the difference is 0 you shut off the motor). The system has a momentum = 1/2mv^2 acted upon a frictional force F=ma, Now I'm not quite sure how to solve for final position, but you have 2nd derivative momentum acted upon by a 2nd derivative force (wrt position), it would seem you would need a 2nd order system to model this.

    Post Edited (Paul Baker) : 2/17/2005 8:00:43 PM GMT
  • nick bernardnick bernard Posts: 329
    edited 2005-02-17 21:33
    i havent tried to model the system yet. and you're right . if you derive the model from a purely mathematical stand point you could develop a 2nd order system(just like i did with that broomstick in school). However, there are other ways of describing system performance and utimately developing a model. one method we used early on is to graph the step response of the system. from it you find the rise time, settling time, and overshoot. from these parameters you could easily develop a simple model to describe the system. it's to bad i forgot how to do that....

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    League Bowling.... it's not a sport, it's a way of life

    Post Edited (nick bernard) : 2/17/2005 10:35:48 PM GMT
  • frdchangfrdchang Posts: 14
    edited 2005-02-18 04:05
    is there a reason why you won't use a PID controller?

    if the gain is high enough, you basically squash away any need to model the system.

    what is the bandwidth needed?

    i use PID all the time without the need to model a system. the only time i ever modeled a system is when i had to play with a robotic arm.
  • Paul BakerPaul Baker Posts: 6,351
    edited 2005-02-18 07:33
    My understanding is that the end system will be controlling a hydraulic motor which is either on or off, therefore PID wouldn't work.
  • nick bernardnick bernard Posts: 329
    edited 2005-02-18 15:06
    righto-PID is great but it doesnt work well with relay controlled hydaulic motors that CANNOT be jerked to and fro to settle on a position... also i dont think that i'll have much trouble handling this with the SX. the encoders already return byte size data and the system is slow enough to implement a dsp-esque control algorithm.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    League Bowling.... it's not a sport, it's a way of life
Sign In or Register to comment.