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
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
Tom
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.
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
I will dig into this tonight!
I have not used SPIN but I'm sure I can get the gist of it quickly :-)
Jason
It kind of goes on and on.
PWIW, Parallax never did any spin driver for the 360 feedback. They are supporting C
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.
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.
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.
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.
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
https://parallax.com/product/32501
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
- 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)
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
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
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 ?
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.
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.
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