Quote:
Originally Posted by Kevin Sevcik
Have you checked the outputs of the encoders with an analog oscilloscope, AT the pins on the Digital Sidecar? That is, leave everything hooked up, and probe the pins while they're still connected. I've had issues with crosstalk between encoder signals before. It was extremely confusing until I probed my inputs with an O-scope and discovered the noise. You'd be looking for spikes in the A channel when the B channel is transitioning, and vice-versa. It's not necessarily something you'd see if the encoders were disconnected, as the O-Scope inputs are much higher impedance than the digital inputs on the cRIO. Nor would I trust that the USB NI device would necessarily be fast enough to pick them up.
This would explain the differing behavior at different resolutions, as the counter would be looking at different transitions on different lines in each of the modes.
Admittedly, when I saw this behavior, it would also throw the encoder counts off. That is, spinning the encoder X revolutions forwards, and X revolutions backwards would leave a significant remainder, as opposed to zero. Have you checked to make sure your encoder numbers are corresponding to reality, and that they're agreeing in each direction?)
|
I would have tried what you are suggesting had NI tech support not been able to reproduce the problem. They have reproduced the results including the speed changes by mode and the alternating speeds. The problem is not unique to our robot.
Quote:
|
(Note: This is all speculation sight unseen of the FPGA code. It's entirely possible there's something in that code that's wonky instead.)
|
I believe the the FPGA is the most likely bad actor. In all cases the distance was correct to within 1-4 inches after 160-170 inches while the speed varied during the entire 15 second run. I found it hard to believe that noise would have a zero sum on all encoders over the 15 second period on dozens of runs that we made.