Shop OBEX P1 Docs P2 Docs Learn Events
PID position control of a motor — Parallax Forums

PID position control of a motor

Graham StablerGraham Stabler Posts: 2,510
edited 2011-02-18 10:06 in Propeller 1
I was wondering if anyone has implemented PID position control of a DC motor. I've seen a nice speed control object of Kye's but am struggling to find something that will do position control. I have something that is working to a fashion and will complete it if necessary but thought I would just ask.

Searching for PID on the forum gives no results! I assume that is too few characters?

Cheers,

Graham

Comments

  • Miner_with_a_PICMiner_with_a_PIC Posts: 123
    edited 2011-02-10 05:08
    Graham,

    Try searching proportional integral and you will get hits. The titles are littered with the keyword PID, so I think you are right about the search engine limitation.
  • JasonDorieJasonDorie Posts: 1,930
    edited 2011-02-10 11:19
    If you're referring to Kye's object that reads a quadrature encoder to give you position & speed readings, it should be relatively easy to alter it to target a specific position instead of a speed. The code appears to do a good chunk of work to compute the speed from the encoder positions (which are directly measured).

    If you look at the file "PWM1C_PIDEngine.spin", the code from lines 135 to 156 compute the position from the encoder inputs, storing the result to "encoderPosition" and then writing it out to hub ram. Lines 156 to 195 all seem to be computing an average speed over time, and storing the result in "averageBuffer". The code immediately following that is the PID loop, which uses the "averageBuffer" result as the measured parameter.

    You could just change the code at line 199 to use encoderPosition instead of averageBuffer, and see what happens (right below the //////Feedback///////// comment). Since a PID loop is just trying to get a value to hit a target, it shouldn't matter which value it is.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2011-02-10 12:07
    Jason,

    First I'm using an absolute encoder. Kye's speed control algorithm I suspect only reduces the speed by removing the power to the motor, I need to drive it in both directions to maintain a position.

    I've implemented a controller in spin and it works OK, I suspect it is just a little slow for the response I'd like (no surprise) and it has a few bad habits. To get really good performance which is what I need I will have to consider various other devilish details the simple formula for PID do not mention. Saturation, integral wind up and derivative kick. You can even choose between alternative implementations, each are still PID but have unique properties.

    I'm learning all of this stuff now, they didn't teach us any of it in my control modules, that was all pole placement and root locus drawing :)

    Graham
  • aetomatoaetomato Posts: 1
    edited 2011-02-16 19:24
    I tried to use HB-25 motor controller to control parallax motor mount and wheel kit (#27971). I use microcontroller to send 1-2 ms pulse to HB-25. However, the motors work improperly or shut off after a few seconds. Does anyone know the reason for this?

    Thx,
    May
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2011-02-17 10:31
    You should start a new thread
  • Paul MPaul M Posts: 95
    edited 2011-02-18 06:28
    .......
    I'm learning all of this stuff now, they didn't teach us any of it in my control modules, that was all pole placement and root locus drawing :)

    Graham

    Me too. The theory is fine when you can actually characterise the system you are controlling, which in my experience is seldom the case in the real world.

    I did a control system over a year ago for a vehicle chassis dynamometer (rolling road) capable of absorbing over 300HP. When I searched for PID routines they were all very simple and most assumed a contant timebase. In my case the PID update was triggred by a pulse train that was also the speed signal.

    The great advantage of doing it in code is that you can easily deal with integral wind up, limit unexpected, excessive changes in the control value etc., and using simple comms you can change the gains "on the fly" for tuning. For me the added advantage of the prop was that I could dedicate one cog for the control knowing that the control would not be compromised by other 'stuff' going on elsewhere.

    Sorry, just some comments and not much help but Good Luck!

    Paul
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2011-02-18 10:06
    Thanks Paul, I'm making some progress, changing my means of generating PWM speeded up the loop so much that even in spin it is too fast for my encoder (the derivative error is either one or zero) so I need a higher resolution encoder. I've gone mad and ordered a 20000 count one, which after decoding is 80000 count, a lot better than my current 256 :) I know my code can handle the pulse rates too because a cog is devoted to it :)

    Graham
Sign In or Register to comment.