encoder max speed resolution

helo every one
I wanted to know what is the max speed in which the vex servo motor could turn and that the encoder could still keep track of him
I know that the encoder resolutiion is 1700 [Hz] about 600[us]
and that means about 19 wheel turns in a second so
2pirN=D=vt => dosen’t make much sense here (too big)
pir19=D= 83 [m] (smallest vex wheel radius 7[cm])
thanks in advance

If you read this it says:


Jordan’s reply is useful.

However, my hunch is that you need to worry more about whether the device connected to the encoder can keep up with the flood of interrupts that an encoder approaching max speed will create (The Vex microcontrollers do well in amateur robotics contexts, but they are not supercomputers).

Also, I doubt the Vex Encoders will hold up for very long if they are spun at top speed for very long. In bursts, “Yes”, for a long time, “Probably not”.


i have tried(and was successful) at gearing the encoders up, it was a increase by 7, so for every wheel rotation it rotated 7 times. however, i ran into a problem, in robot C the sensor values are stored in a 16 bit variable, so it has a max of ~ 65000. (-32500 - 32500 ) i ran into a problem, which you can probably see. At least for some of the things i was doing, i was causing it to reset after it reached its max or min, which means it will go back to the bottom (from 32500 all the way to -32500) this caused some headaches, however it can be solved by gearing it differently.

my suggestion is to gear them up, but not more then by 4, otherwise the numbers get really big and confusing. especially if your code looked anything like mine.

so the encoder can stand up to 1134 rpm no matter the wheel radius => distance doesn’t play a part in the calculations I need to do only the motor torque needs to be limited to the encoder rpm which he his according to the site to 100 rpm in free speed… so I don’t have any problem perform that side of the equation.
the other side is exactly what gblake said but the only thing is that I am not using vex pic, my controller is working on 50Mhz internal clock thats 20ns and in the entrance I have put 3 FF and a rising edge detection in order to keep track of the encoder data so I think that’s spouse to cover it.
thanks for the replies

In that case, you could program it so that when the variable for the encoder, say, x, reaches >30,000, it would add one to a different variable, say, y. Then when x resets, y still has a record of how far you’ve travelled.

As for the max speed, I was wondering about that… a while ago, I tried to print to screen the encoder values as my robot moved. It wasn’t too fast of a robot or anything, but the printtoscreen values skipped by fours. Is print to screen just slow and unnresponsive? It is going through a serial to USB converter and then RS232…

Yes, Print to Screen is slow.
IO in general is slow, compared to internal CPU operations, so the encoder can’t count nearly as fast as the CPU can do A=A+1.
The Print to Screen calls a library API.
The library routine has to convert your number from binary to the ascii character representation, which usually requires doing divide by 10 (divide is amoung the slowest maths for CPU), and then send it to a serial output port.
All the serial output transformations after that add latency, but may not limit the throughput unless they have throttling flow-control back to the cpu.

Some theoretical math for encoders, YMMV:
100rev/Minute * 60sec/min = 1.666 r/s
1.666 r/s * 90 encoder ticks/rev = 150 tics/sec
motor updates happen every ~20ms, so about 50updates/sec
With encoders at 1:1 on motor shaft, and motor running at max nominal freewheel speed of 100rpm, the encoder counts 3 times faster than the ability of the cpu to talk to the motor to tell it to stop rotating the encoder.
At max power output, the motor will be running at half max speed, so the encoder is counting up only 1.5 times faster, so you’ll need a PID or other routine to slow down as you approach the count limit if you want to hit it exactly. Ramp up/down of speed is a good idea anyway, to avoid wheel scrub which throws off your location.
For typical autonomous driving patterns 4" diameter wheels, each encoder tick is about 1/8th of an inch (4*pi/90).

On the other hand, there is this comment from the winning team coach presentation for the MAGIC2010 competition: “odometry is lousy, just really really terrible”.

In easyC you can gear up the encoder, as we treat the encoder as a Long 32bit

what do you mean by “Gear up” (mechanical or programming??)
i geared it up mechanically with chain but it would be convenient to do it in the code…

It would be impossible really, to “gear up” the encoder in the code, unless originally they were not giving you complete accuracy with the encoder, and allowed you to gain some if you wanted by changing something.