Forum Update - Announcement about May 10th, 2018 update and your password.

How can I rotate a servo accurately & repeatably ?

I’m trying to make a continuous rotation servo turn in it’s smallest possible increment and consistently do a full rotation in a set number of increments.

I’ve been experimenting with this on and off for the last 2 weeks with 2 different servos: a Parallax High Speed Continuous and the cheapest FiTech servo I could find at RobotShop.

For now, I’m using an Arduino with the servo library but I plan on moving that to the P1 and eventually the P2.
So far, I have a simple test program that perfectly stops the servos, then turns them for 20ms both clockwise and counter clockwise.


The problem I’m having is that I can’t seem to get a consistent full rotation.
I was hoping the community would have some pointers on how to achieve this.

Thanks!

Jason

Comments

  • 24 Comments sorted by Date Added Votes
  • Have you seen the new servo with feedback https://www.parallax.com/product/900-00360
    Infernal Machine
  • These hobby/RC servos are inherently sloppy, so you're simply not going to be able to get reproducible rotations without feedback. The new high speed feedback servos can do this or you can add some kind of external feedback.
  • How far (degrees) are you having the servo move. Realize that it takes time for the movement to complete. If you send a new command while the servo is trying to get to a certain position it will not complete the first command.

    Tom
  • Travel distance over time depends on factors like battery voltage and weight on the wheels. Add a few ounces to your robot and it'll weigh more, and won't likely travel as far.

    The only way you can achieve what you want is by using a closed loop system. This can be done with encoders of some type. You can make your own, purchase them ready made (Parallax has some), or get servos with Hall effect sensors in them. Parallax also has these.
  • thejthej Posts: 87
    edited June 27 Vote Up0Vote Down
    OK. I thought this might be to way to go (feedback loop).
    I'm trying to keep the costs of my project as low as possible.
    I just ordered a few Servo 360's from Parallax so I can try them out.

    The intention is to use the servo in the same fashion as a stepper. Feedback does appear to be essential.
    I will sift through the forum to see what others have done with the 360.

    If anyone has any links (forum or otherwise) to example code (Tachyon/arduino/etc) or usage info for the 360, I would be very happy :-)

    Jason
  • If you are a spin type, I did a driver when the feedback 360 first came out. obex.parallax.com/object/869
    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
    Cool, CA, USA 95614
  • Thanks Tom!
    I will dig into this tonight!
    I have not used SPIN but I'm sure I can get the gist of it quickly :-)

    Jason
  • Here is a pointer to a forum discussion that may be useful. https://google.com/url?q=https://forums.parallax.com/discussion/167298/new-parallax-360-feedback-servo&sa=U&ved=0ahUKEwi-1425-PTbAhWZCTQIHdL4CAUQFggEMAA&client=internal-uds-cse&cx=002870150170079142498:hq1zjyfbawy&usg=AOvVaw3NtgE7AD4OwdEDd1ya_2pz

    It kind of goes on and on.

    PWIW, Parallax never did any spin driver for the 360 feedback. They are supporting C
    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
    Cool, CA, USA 95614
  • The 360 servos aren't as easy to use with an Arduino as they are with a Propeller. The Arduino Uno is a single-core device, and the output of the servos is not a signal that you can use with an interrupt. So your code will need to constantly check the value of the feedback to determine position, and whether the motor has gone past it's 12 o'clock position. Being single-core this leaves less opportunity to do other robotic things.

    A simple optical encoder is easier to use. You may not need much resolution to get the job done. A 12- to 24-stripe codewheel is usually more than enough. Condition the signal from an IR reflective pair though something like a Schmitt trigger, and feed that to pins 2 and 3 on the Arduino. These are the external hardware interrupt pins, which allow your sketch to count wheel revolutions without having to resort to constant polling.
  • jmgjmg Posts: 11,507
    thej wrote: »
    For now, I’m using an Arduino with the servo library but I plan on moving that to the P1 and eventually the P2.
    So far, I have a simple test program that perfectly stops the servos, then turns them for 20ms both clockwise and counter clockwise.
    How many servos do you intend to finally use ?


    The 360 servos aren't as easy to use with an Arduino as they are with a Propeller. The Arduino Uno is a single-core device, and the output of the servos is not a signal that you can use with an interrupt. So your code will need to constantly check the value of the feedback to determine position, and whether the motor has gone past it's 12 o'clock position. Being single-core this leaves less opportunity to do other robotic things.
    Yes, Arduino is less ideal, the older AVRs need SW help to capture & flip edges for pulse-width, and lack interrupt priority control.
    Life is a little better on the newer Mega4809 series, as you can snapshot capture Pulse Width, and Pulse Period, then read later - see the manual Figure 20-7. Input Capture Frequency and Pulse-Width Measurement (TCB)
    The 4809 has 4 TCB channels, so you will be able to read more servos on a P1.


  • ercoerco Posts: 19,148
    Those Feedback 360 servos will ruin all other servos for a fellow!
    "When you make a thing, a thing that is new, it is so complicated making it that it is bound to be ugly. But those that make it after you, they don’t have to worry about making it. And they can make it pretty, and so everybody can like it when others make it after you."

    - Pablo Picasso
  • GenetixGenetix Posts: 1,247
    edited June 28 Vote Up0Vote Down
    thej,

    Are you by chance using a Shield Bot and what are you doing that requires such precision?


    jmg,

    A stock BS2 makes the Arduino look like a race car and yet the humble BOE-Bot with encoders performs reasonably well.
    Also on the Arduino everything is library dependent so if the library doesn't support that function then it's useless.


    Gordon,

    I see Parallax still carries the Boe-Bot digital encoder kit but I don't see any code or references for using it on a Shield Bot.
    I would assume it would work.



  • Genetix wrote: »
    I see Parallax still carries the Boe-Bot digital encoder kit but I don't see any code or references for using it on a Shield Bot. I would assume it would work.

    I recall that kit uses modulated IR with a digital input, so they should connect straight in to the external hardware interrupt pins on an Uno (pines 2 and 3) without any conditioning. There's code everywhere for incrementing a counter in an interrupt service routine, so no problem there. I'm pretty sure you wouldn't even need to debounce using sensors like these.

  • The 360 servos aren't as easy to use with an Arduino as they are with a Propeller. The Arduino Uno is a single-core device, and the output of the servos is not a signal that you can use with an interrupt. So your code will need to constantly check the value of the feedback to determine position, and whether the motor has gone past it's 12 o'clock position. Being single-core this leaves less opportunity to do other robotic things.

    A simple optical encoder is easier to use. You may not need much resolution to get the job done. A 12- to 24-stripe codewheel is usually more than enough. Condition the signal from an IR reflective pair though something like a Schmitt trigger, and feed that to pins 2 and 3 on the Arduino. These are the external hardware interrupt pins, which allow your sketch to count wheel revolutions without having to resort to constant polling.

    Not a problem for my application. I will have seconds to minutes between each servo movement.
    The servo is directly driving a threaded rod which will have a light load on it.
    That load needs to be moved 0.02mm each movement. The rod I'm using produces a 0.7272mm movement for a FULL rotation. So I need the servo to do 36.36 "steps" per rotation to meet this requirement (9.90099 degs per "step").

    I've been testing to find the smallest increment I can get from my el cheep servos.
    Currently I'm getting about 128 "steps" clockwise and 150 counter clockwise.
    Which is better than my needs !
    Clockwise is the only direction I need to use with accuracy.

    My idea (before I posted) was to calibrate my "steps" to be 3x my required 36.36 (109.08) and add tiny compensations for the 0.08, every 10 movements.
    My problem of course is that I don't get a consistent number of "step" per rotation.

    Using an encoder or Feedback 360 I could know how much I'm out and calculate compensations on the fly.
    :-)

    Encoder wheels are easy enough to find/make but where would I get a proper sensor? I don't see any on the Parallax site with a quick search.

    Jason
  • This is the encoder used for the ActivityBot.
    https://parallax.com/product/32501
  • thej,

    If you want to precisely drive a lead-screw (threaded rod) then you want to use to a stepper motor.
    If you don't drive a stepper too fast or give it too high of a load then it will repeatedly advance the same number of steps in either direction.

    If you are using an ordinary threaded rod then there will be considerable backlash which will affect a quick direction change.
    If you are going a considerable amount in the other direction though then the backlash will get canceled out.
    Just don't expect to move 2 forward and then 2 steps back and be at the same starting point.

    https://learn.adafruit.com/adafruit-arduino-lesson-16-stepper-motors
    https://www.arduino.cc/en/Tutorial/MotorKnob
  • jmgjmg Posts: 11,507
    thej wrote: »
    That load needs to be moved 0.02mm each movement. The rod I'm using produces a 0.7272mm movement for a FULL rotation. So I need the servo to do 36.36 "steps" per rotation to meet this requirement (9.90099 degs per "step").

    I've been testing to find the smallest increment I can get from my el cheep servos.
    Currently I'm getting about 128 "steps" clockwise and 150 counter clockwise.
    Which is better than my needs !
    Clockwise is the only direction I need to use with accuracy.

    My idea (before I posted) was to calibrate my "steps" to be 3x my required 36.36 (109.08) and add tiny compensations for the 0.08, every 10 movements.
    My problem of course is that I don't get a consistent number of "step" per rotation.

    Using an encoder or Feedback 360 I could know how much I'm out and calculate compensations on the fly.
    You should plot a number of passes on a graph/table, as I'd expect the averages to be correct over many rotations.
    - ie you will have a quantize error, more than a count-creep error.
    Linearity may also be an issue with analog-track designs.

    Anyone know what the quantize error is on the Parallax Feedback 360 ? - that's strangely missing.
    They will have some PWM capture resolution limit, and then some DAC limit, and the frequency tolerance specs suggest no crystal, just a RC Osc MCU.

    Is there a reason you do not use stepper motors - even with micro-stepping ?
    thej wrote: »
    Encoder wheels are easy enough to find/make but where would I get a proper sensor? I don't see any on the Parallax site with a quick search.
    Digikey shows Broadcom Quadrature Optical pickups, for 256 and 500 steps, at $9.60/100, and Pot-like Bourns 128 step mechanical encoders at $5.18/100 (gray code variant)

  • Yes. Steppers are the ideal solution but I want to see if I can get away with using a servo.
    So far, with even some feedback, it looks totally doable (more testing needed...and I have some Feedback 360's in the mail :-)

    I don't need to worry as much about backlash as I will only need to turn clockwise for all but the last of the movements. That's where the "accuracy" is needed. Once that collection of movements are done, it will turn CCW to return to the original position. So only one reverse in direction. If I had to turn both directions over and over, I wouldn't even consider a servo.

    what it comes down to for me is:
    How accurately can I move a servo?
    How repeatable can I make those movements?
    What kind of Feedback will work?
    ...and how much of each is "good enough"?


    From the conversation, I could probable get away with one of my el cheapo servos and an encoder wheel with maybe 4 holes. Tune the servo for about 110 "steps" per rotation.Then use 3 of those "steps" at to achieve the 36.36 steps needed per rotation and add or reduce steps every quarter turn as needed (counting steps along the way of course).

    Of course, I will need to test this...

    Jason
  • jmg wrote: »
    You should plot a number of passes on a graph/table, as I'd expect the averages to be correct over many rotations.
    - ie you will have a quantize error, more than a count-creep error.
    Linearity may also be an issue with analog-track designs.

    Anyone know what the quantize error is on the Parallax Feedback 360 ? - that's strangely missing.
    They will have some PWM capture resolution limit, and then some DAC limit, and the frequency tolerance specs suggest no crystal, just a RC Osc MCU.

    Is there a reason you do not use stepper motors - even with micro-stepping ?

    Digikey shows Broadcom Quadrature Optical pickups, for 256 and 500 steps, at $9.60/100, and Pot-like Bourns 128 step mechanical encoders at $5.18/100 (gray code variant)

    By counting "steps" and calculating how many to add/reduce at least every quarter turn, shouldn't this be able to clean up that error?

    j
  • jmg wrote: »

    Anyone know what the quantize error is on the Parallax Feedback 360 ? - that's strangely missing.

    One part in 4096.

    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
    Cool, CA, USA 95614
  • jmgjmg Posts: 11,507
    jmg wrote: »

    Anyone know what the quantize error is on the Parallax Feedback 360 ? - that's strangely missing.

    One part in 4096.

    Thanks.
    Is that on the PWM capture side (420ns capture resolution?) , or both PWM capture and DAC side ? Do you know what MCU is used inside that ?
  • I don't know anything about how the feedback pulse is generated. In the thread I cited previously, there is a bunch of stuff about the details of the servo.
    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
    Cool, CA, USA 95614
  • jmgjmg Posts: 11,507
    I don't know anything about how the feedback pulse is generated. In the thread I cited previously, there is a bunch of stuff about the details of the servo.

    Ah, thanks, yes find more here - for the angle-to-pwm side phipi says

    " This was captured while slowly rotating the shaft between two closely-spaced angles :
    = a discrete increment between adjacent pulse widths, of ~250 ns
    = consistent with the sensor chip's stated resolution of 4096 discrete pulse widths over a full rotation, which works out to a resolution of 0.088 degrees.

    thej wrote: »
    By counting "steps" and calculating how many to add/reduce at least every quarter turn, shouldn't this be able to clean up that error?
    Depends which error you mean ?
    From the above, the Parallax unit has a 4096 step sensor. You could couple two directly, and log the two CW/CCW sensor outputs, to get an idea of linearity & consistency across units.
    Capture that to better than the 250ns quanta, to ensure you have sensor-limit readings. (P1 can do that easily)
    You can also use that sensor to check other feedback servos, but a digital output, with 4096 steps is looking appealing.
  • jmgjmg Posts: 11,507
    edited June 30 Vote Up0Vote Down
    thej wrote: »
    From the conversation, I could probable get away with one of my el cheapo servos and an encoder wheel with maybe 4 holes. Tune the servo for about 110 "steps" per rotation.Then use 3 of those "steps" at to achieve the 36.36 steps needed per rotation and add or reduce steps every quarter turn as needed (counting steps along the way of course).

    Of course, I will need to test this...

    If you are going to build your own encoder/sensor, you might want to look into Single Track Gray Codes. Those will give an absolute angle.
    Looking into my notes, I find mention of these : (there are many solutions)
    STGC_m30_s5p6
    STGC_m31_s5p6
    STGC_m60_s6p5
    STGC_m126_s7p18
    STGC_m240_s8p15
    STGC_m360_s10p36

    m = Steps Encoded (usually per rev), s = sensors required, and p (IIRC) is the pitch/spacing of the sensors.
    Where s * p = m, those sensors are evenly spaced around the (usually circular) single track.
    Where s*p < m, (the m60 one) that looks to have a 180' track - there are some mechanical / assembly benefits to having less than 360' for the sensor PCB.

    and here are claims from the web, of the maximal STGC
    The maximums are something like this (always 'something under' 2^N)
    Length(m) STGC(s)
    2 4
    3 6
    4 8
    5 30
    6 60
    7 126
    8 240
    9 504
    10 960
    11 2046
    12 3960
    13 8190
    14 16128
    15 32730
    16 65504
    17 131070
Sign In or Register to comment.