Voltage Counts Range 0-970

[Jefferson]

Now that we have slip rings on our swerve modules, we spend some time at the roll-over point of our analog encoders (the point where it rolls from 5V to 0V). We were surprised that there was significant "chatter" around this point and chalked it up to a bug in the PIDContoller to be found latter.
In trying to debug some different weirdness observed in crab, I started looking more closely at the values reported for GetAverageValue from the modules. I was surprised to find that the encoders never report anything greater than 970, but roll over all the way to 0.
A few things we checked:
Encoders are providing a full 0-5V output range.
GetValue provides the same range.
All four wheel modules on two robots exhibit the same "chatter" in the modules.

Of course we can rescale all of our calculations to 970, but I'd like to know why we aren't getting to 1024.

Has anybody seen anything like this before? We've not used the full range of our encoders before now.

Thanks

[Al Skierkiewicz]

Jeff,
What are you using for encoders? If you are using continuous pots then they are behaving as expected. It is possible with this device to momentarily short the 5 volt and 0 volt together at the transition. While this give a lot of noise output it also arcs the rotating contact in the pot. Eventually, this device will fail.

[Jefferson]

Al,
Thanks for the reply. Hardware was our first thought as well. We checked the voltage output from them and they are send as much as 4.96V to the analog module (couldn't ever get exactly 5, but I expect we weren't hitting the exact roll-over point).

We are using these guys:
http://www.usdigital.com/products/en...tary/shaft/ma3

They are magnetic encoders with 10-bit resolution, so I don't think shorting around the end is the issue.

[Al Skierkiewicz]

Jeff,
Those should be fine but be aware that the rapid move from +V to 0V might occur at too high a slew rate to be used by the analog module without some filtering. That might be what is giving you the noise. You might also want to add a cap right at the power input of the encoder, say a .47 or 1ufd just to keep the power supply clean. Are you using the ball bearing version?

[jhersh]

Originally Posted by Jefferson

Now that we have slip rings on our swerve modules, we spend some time at the roll-over point of our analog encoders (the point where it rolls from 5V to 0V). We were surprised that there was significant "chatter" around this point and chalked it up to a bug in the PIDContoller to be found latter.
In trying to debug some different weirdness observed in crab, I started looking more closely at the values reported for GetAverageValue from the modules. I was surprised to find that the encoders never report anything greater than 970, but roll over all the way to 0.
A few things we checked:
Encoders are providing a full 0-5V output range.
GetValue provides the same range.

Is there any reason you are not using the GetVoltage entry-point? That will take into account factory-calibrated scaling coefficients unique to every module. You will get far more accurate results using that method. At the very least, try that and see how closely it matches your DMM at that max value.

Also keep in mind that the range of the module is -10V to 10V.

Joe

[RufflesRidge]

Originally Posted by jhersh

Is there any reason you are not using the GetVoltage entry-point?

The PIDGet currently uses GetAverageValue.

[Jefferson]

Originally Posted by Al Skierkiewicz

Jeff,
Those should be fine but be aware that the rapid move from +V to 0V might occur at too high a slew rate to be used by the analog module without some filtering.

Al,
I really think my issue is in the control system hardware (see Joe's post above and my response below). But to confirm this I am going to short the 5V supply to the signal wire to see what reading we get. If it is in the 970 range, that takes the encoder out of the equation. I'll post results here.

Originally Posted by jhersh

Is there any reason you are not using the GetVoltage entry-point?

Joe,
Like RufflesRidge said, the PIDController uses values instead of volts for the source. I had considered changing it to volts (we have used volts for years prior), but decided that the counts should be the more "raw" reading. One less calculation between me and the raw reading must be a good thing... or so I thought.

Originally Posted by jhersh

That will take into account factory-calibrated scaling coefficients unique to every module. You will get far more accurate results using that method. At the very least, try that and see how closely it matches your DMM at that max value.

This is very interesting. I saw your post a little late in the night to try anything last night, but I'll give it a try tonight if we're not too busy getting ready to go to Razorback.
Are you saying that it is not unexpected to get something other than 1023 when we supply 5V to the module, and the error is corrected when converting back to the voltage? If so, that's a really good reason to go back to voltage, and the PIDController should probably be changed for future seasons.

[jhersh]

Originally Posted by Jefferson

Joe,
Like RufflesRidge said, the PIDController uses values instead of volts for the source. I had considered changing it to volts (we have used volts for years prior), but decided that the counts should be the more "raw" reading. One less calculation between me and the raw reading must be a good thing... or so I thought.

That's in Java? C++? Both?

Originally Posted by Jefferson

This is very interesting. I saw your post a little late in the night to try anything last night, but I'll give it a try tonight if we're not too busy getting ready to go to Razorback.
Are you saying that it is not unexpected to get something other than 1023 when we supply 5V to the module, and the error is corrected when converting back to the voltage? If so, that's a really good reason to go back to voltage, and the PIDController should probably be changed for future seasons.

You are certainly not guaranteed a certain raw value for a specific voltage. That's an uncalibrated raw value. It will be consistent for a given module, though, so if you only need it to work on one module, you can figure out what raw values are mapped to what voltages, and you can use the raw codes reliably. If you switch modules, you need to figure out new raw codes again.

-Joe

[Joe Ross]

Originally Posted by jhersh

That's in Java? C++? Both?

C++ only. It was reported on FIRST Forge in January http://firstforge.wpi.edu/sf/go/artf...3648572967 51

[Jefferson]

Originally Posted by jhersh

You are certainly not guaranteed a certain raw value for a specific voltage. That's an uncalibrated raw value. It will be consistent for a given module, though, so if you only need it to work on one module, you can figure out what raw values are mapped to what voltages, and you can use the raw codes reliably. If you switch modules, you need to figure out new raw codes again.

-Joe

Great info. Thanks.