clarkbriggs
commented
4 years ago Subsequent discussions elsewhere lead to some clarifications. The need is really for a speed counter, an encoder click rate measurement. This is especially needed at low slow wheel speeds, such as at start up, when time differentiation and left-right differentiation is too noisy due to low click rates. Encoder position counting is just what is needed at speed. It provides long term position knowledge and has usable differences over small dts. At speed the hardware encoder can shield the CPU from the high interrupt rate. We size the drive mechanism for a variety of requirements. We pick a motor, its size, its RPM limits, its torque value. We pick a gear box ratio. We pick an encoder which we can place on the axle side or the motor side and can have multiple pick ups per revolution. We all know how our cars work: some are great at the low end, others are great at the high end, but are very many great at both ends? The current proposal is to provide a speed reading based on timing the duration between encoder clicks. This will provide a good working measurement at low speeds. At some high speed it could be onerous. Both its utility at low speeds and its cost at high speeds depend on the motor, gearing and senors counts.
dlech
Is your feature request related to a problem? Please describe. For smallish ground vehicles, encoder counts at slow speeds are inaccurate. This makes forward speed control and steering rotational speed control very poor.
Describe the solution you'd like Several years ago, Nick Morozovsky at UCSD identified a dual mode approach where low speeds were measured by the time duration between encoder pulses. The Blue's EQEP encoder does a good job with position. It seems to have a mode for counting the period between pulses. It would probably be difficult to switch between the two modes and keep a hardware measure of distance or position. I suppose all that mode switching would need to be in the EQEP driver and would need TI support for figuring it out. The sign of the duration needs to be determined somehow, probably with an approach like the position counting uses. It might be enough to give the user access to the channel A and B GPIO edge changes, while not disrupting the EQEP position counting, so the user could time the duration between pulses. The OOTB Blue configuration doesn't seem to expose user access to the EQEP input GPIOs.
Describe alternatives you've considered This is readily implemented in a software encoder counter. At high enough speeds, the position is read or accumulated like usual. It is smooth enough to differentiate in time for speed and to difference left-right for rotation. At low speeds, the time between pulses is measured. The consumer can use the inverse of the duration for a speed measurement. I built this for the RaspberryPi which has a kernel driver for a software rotary encoder. I used the relative mode which delivers +1 or -1 counts which I then accumulate. I can measure the time between these readings and produce a duration. The sign of the event provides the sign of the duration.
Additional context Some consideration is needed to get a smooth transition between the two modes and perhaps hysteresis is needed to smooth bouncing back and forth across the boundary.