View Single Post
  #4   Spotlight this post!  
Unread 13-01-2009, 14:48
Kevin Sevcik's Avatar
Kevin Sevcik Kevin Sevcik is offline
(Insert witty comment here)
FRC #0057 (The Leopards)
Team Role: Mentor
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Houston, Texas
Posts: 3,622
Kevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond repute
Send a message via AIM to Kevin Sevcik Send a message via Yahoo to Kevin Sevcik
Re: Inconsistent reading from encoder get rate

Quote:
Originally Posted by rwood359 View Post
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.
Why wouldn't you believe that crosstalk between the channels would be a common occurrence that could hit NI as well as you? If it's inherent in the system design for some reason, or if the kit encoders are particularly likely to do so, then there's every reason to assume it would be duplicated on NI's end as well. I agree that it's unlikely, but I think it'd bear looking at if you don't have anything better to do but wait for NI to come up with something.
Quote:
Originally Posted by rwood359 View Post
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.
It's possible the FPGA is the culprit here, but I'm sort of doubting it. A period measuring interface like this isn't going to be terribly complicated. All you're doing is capturing the ticks elapsed between edges. All the mode does is change which edges you're looking at. If they're being extra tricky about it and adaptively shifting the number of edges they're looking at depending on how fast the wheel is turning, then I could see it there being a problem. But it just doesn't seem as likely to me.

Meanwhile, it's pretty possible for the encoder to trick you into thinking it's working when it's not. Depending on the timing of the spikes, the rising and falling edge of it could simply be nulling each other out as far as the distance is concerned. But it would play heck with your period measurements. Thus my concern. If you're not willing to attempt it, I'll grab an O-Scope and check the functionality on our robot in a few days if NI is still bug-hunting.
__________________
The difficult we do today; the impossible we do tomorrow. Miracles by appointment only.

Lone Star Regional Troubleshooter
Reply With Quote