beagleboard / beagleboard/librobotcontrol

low speed encoder readings

Open
#186 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
212
Forks
167
PR merge metrics
No merged PRs in 30d

Description

**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.

Contributor guide

No contributing guide indexed for this repository

Research direction

The issue names the EQEP driver, Blue configuration, and a software encoder counter but no files or tests. Start by locating the EQEP position-counting path and how channel A/B GPIO access is exposed. Done means low-speed pulse-duration measurements provide signed speed without disrupting position counting, with a smooth transition between modes.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
embedded-iot, robotics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.