I’m planning to buy a USDigital encoder. On the lynxmotion page, it’s written “Frequency = 15khz”. On the US Digital page, it’s written “Tracks from 0 to 60,000 cycles/sec”.
So which one is the right one? If I put a motor with a 50:1 redution such as this one, I expect 120 cycles per revolution (and 480 pulses). Will I be able to handle 60 000/120=500 RPS=30000 RPM for the external shaft or 600RPM after the 50:1 reduction, or 15 000Hz/120(cycles/s) = 125RPS = 7500RPM, or 150RPM after reduction? (or something else?)
If the answer is 600RPM, I’m thinking to maybe buy the one that does 360 cycles per revolution and allow me to read precisely a motor that goes at 200RPM (still more than what the gear head motor can do). Why did lynxmotion decide to sells the 120cycles/s version rather than the 360cycles/s one? Am I missing something?
The 15khz came from US digital not me. With the 120cpr you get 3428 quadrature counts in one inch with our GHM-04 motor and a 2.5" tire, or 0.3 thousanths of an inch resolution… Even if you used a 5" tire the resolution would still be under 0.001", why would you need more resolution that that? What am I missing? These values are for a motor running at 7500rpm. You really want to install the encoder onto a motor with 60krpm? I’m lost…
GHM-04 motor RPM under load = 7500 rpm
Encoder = 120 cycles per revolution
Encoder = 480 quadrature counts per revolution
Frequency = 15khz
3428 quadrature counts per inch with a 2.5" tire
US Digital claims 60kHz on their website. I suppose there could be confusion and that it’s actually 60 k pulses/s = 15 k cycles/s (which would be consistent with your 15kHz), but on their webpage, they claim “Tracks from 0 to 60,000 cycles/sec”, not 60,000 pulses. I’m just wondering which data is the right one.
I won’t have a 60kRPM motor. I’ll more than probably use the GHM-04. We’ll use 72mm wheels, and we’ll be able to read only half of the counts (we use a counter that increments on raising edge, not on falling edge). It means we’ll have a 19µm resolution, which is great.
If we were to use the 360cpr version of the encoder, and if it still supports 150/200 RPM from the motor, we are down to a 6µm resolution. I think it might significantly improve the precision of our positionning system…
In theorie I don’t need more precision (gosh, we are already speaking about a resolution of a few thousand pico meters, it’s a few thousand molecules, it’s amazing), but 3 times more precise is 3 times more precise, regardless of how precise it is to start with
eventually you’ll get down to needing the pitch tolerance of the gears in the gear head and have to calculate at what angle they stopped the last time you changed direction so you can factor in the backlash… and then there is the coefficient of friction between your wheels and the surface to consider, and the irregular profile of the wheels surface which you will have to calculate a wear factor in for…
For something that’s free rolling on the floor, I don’t understand why such precision is needed. The terrain would cause the thing to bounce around and add more precision robbing factors to the other factors Eddie mentioned.
Such precision would be beneficial for pick -n- place machines that place fine pitch FPGA’s on a circuit board, but for a rover, I just don’t see the need to beat your self up over a few molecules of precession.
Well, I guess my point was more why have a lower resolution when you can have a better one for the same cost… I also wanted to make sense of the difference between the lynxmotion data and the US Digital data
The resolution of the unit we sell is more than adequate for the purpose. More resolution would require faster response from the host processor, possibly resulting in more difficulty in programming. (metaphor to follow) You could frame a house by measuring the 2 x 4’s with a micrometer, but the house will not be “better” than one framed using a tape measure. But it will be more troublesome to build.
Inflation maybe… lol
