jadonk
commented
4 years ago As of now, the encoders are only storing 32-bits in the driver:
It looks like the userspace also doesn't do anything to handle overflows and just returns a 32-bit count:
- https://github.com/beagleboard/librobotcontrol/blob/master/library/src/io/encoder_eqep.c#L127
- https://github.com/beagleboard/librobotcontrol/blob/master/library/src/encoder.c#L33
Looking at the TRM section 15.4, it seems there is a way to estimate speed without looking at positions, but not a clear way to do position counts past 32-bits without adding an interrupt routine:
So, do you think the need to add a 64-bit read operation in the library and an interrupt routine in either the userspace library or the kernel? I think we can take that on as an enhancement by the August release.
Is 64-bit enough?
clarkbriggs
dlech
Is your feature request related to a problem? Please describe. Not an error, but clarification of precision. I am trying get a common implementation of BBs vs say RPi. Comparison of current sysFS result size vs prior mmap direct register access which was long int. Back then I thought the hardware was 64 bits. Today the library returns int via atoi( ).
Describe the solution you'd like Of course, a return value that captures the hardware size is best. Is it 64 bits or 32 bits? OBTW, refs such as https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi gripe about deficiencies in atoi, like not thread safe. Preferred implementation seems to be atol( ). There is also the issue of mixed long int vs unsigned long int. I'm pretty weak on coding for this difference. I take the BB hardware to be unsigned in nature, but with correct underflow and correct max value, it may look like a signed int. The rc_test_encoder_eqep function clearly returns singed ints and backwards motion shows as negative numbers. Even refs like https://www.tutorialspoint.com/c_standard_library/c_function_strtol.htm don't seem to be careful with signed vs unsigned.
Describe alternatives you've considered As I try for a common user level implementation between BBs and RPis, I have chased the Raspbian encoder kernel driver, which seems to be a standard Linux available driver. It is clearly software based and take two definable GPIOs for inputs. Multiple instances are allowed. There is a dtoverlay to declare them at boot time. The community doesn't seem to use these for robotics but for rotary encoders that are used for volume knobs. The typical max value is small. The size is not well specified. At least, I couldn't find it. I ended up using the relative response that simply returns +1 or -1 and doing by own accumulation. This leaves the max value more in my control. Of course, you can tell me to use extra hardware such as the long-promised Raspberry Beret. But we still need some thought on the software interface design.
Additional context While I'm at it and considering RPis, I started thinking about long duration operations for our bots. To date, driving around the lab floor doesn't challenge the 32 bit size, I suppose. I did start driving an R/C car with a BBB around the parking lot. We need to start implementing features that account for roll over. The TI hardware has interrupts for that. It hurts my head trying to think about how to do that correctly. If we don't do it well ahead of time (and well), it will be very difficult to identify as a problem in the field when the bot is on mile 10 of 50, or whatever.