Encoder on SRX Returning wildly differing values

[Tparbotmail]

Just hooked up our E4P encoders, and we are getting wildly differing values. I confirmed that my java code matched the the rio browser selftest output. All firmware is up to date. I am pretty sure it is not a coding problem.

If you push the joystick forward for 2 seconds 1 encoder will read several thousand revolutions the will read a couple hundred. The wheels are spinning just fine. The robot move in perfectly straight line.

How do you confirm that an encoder is damaged or wired incorrectly?

[Poseidon5817]

Originally Posted by Tparbotmail

Just hooked up our E4P encoders, and we are getting wildly differing values. I confirmed that my java code matched the the rio browser selftest output. All firmware is up to date. I am pretty sure it is not a coding problem.

If you push the joystick forward for 2 seconds 1 encoder will read several thousand revolutions the will read a couple hundred. The wheels are spinning just fine. The robot move in perfectly straight line.

How do you confirm that an encoder is damaged or wired incorrectly?

Do you have the encoder counts per revolution configured correctly? This was an issue for us for a little while.

[Tparbotmail]

We've done no configuring yet. Just out of the box, working with get methods just to get a feel for them. The browser and my code match. I think the one is damaged. They are off by thousands. We are dependent on our electrical team to swap, and I was wondering if there is a way to prove it is physically damaged without just swapping it out.

[sraque]

You can be 100% sure of you code not being the issue if you use the web interface to the RIO and do a self-test on each Talon SRX. There you will see raw encoder counts measured by the SRX.

[Tparbotmail]

Originally Posted by sraque

You can be 100% sure of you code not being the issue if you use the web interface to the RIO and do a self-test on each Talon SRX. There you will see raw encoder counts measured by the SRX.

Thank you, I did do that and that is how I was sure it was not a Java error.

[gpetilli]

Originally Posted by Tparbotmail

Just hooked up our E4P encoders, and we are getting wildly differing values. I confirmed that my java code matched the the rio browser selftest output. All firmware is up to date. I am pretty sure it is not a coding problem.

If you push the joystick forward for 2 seconds 1 encoder will read several thousand revolutions the will read a couple hundred. The wheels are spinning just fine. The robot move in perfectly straight line.

How do you confirm that an encoder is damaged or wired incorrectly?

I would start by swapping the wires from the encoders to the SRXs to see if the speed follows the encoder or the SRX.

If the encoder, reseat the optical disk using the spacing tool that came with the encoder. A long shot, but check the lines per rev on the optical disks, there are several options available from 100 per rev to 360 per rev. You can try to count them or the count should be engraved on the inner hub of the disk.

If it follows the SRX it is most likely an error in the code or that one SRX had it's defaults changed (perhaps last year) and the other did not.

[Tparbotmail]

Originally Posted by gpetilli

I would start by swapping the wires from the encoders to the SRXs to see if the speed follows the encoder or the SRX.

If the encoder, reseat the optical disk using the spacing tool that came with the encoder. A long shot, but check the lines per rev on the optical disks, there are several options available from 100 per rev to 360 per rev. You can try to count them or the count should be engraved on the inner hub of the disk.

If it follows the SRX it is most likely an error in the code or that one SRX had it's defaults changed (perhaps last year) and the other did not.

The long shot was most likely the problem. Electric engineer was available tonight to come over and break it down. Turns out that the optical disk on one side is 250 and 360 on the other. The person doing the work to mount them must not have seen it.

[Tparbotmail]

Thank you all for replying. I suspected it was a config problem but I thought it would be a good topic to have on the boards for others to learn from

[Ether]

Originally Posted by Tparbotmail

Turns out that the optical disk on one side is 250 and 360 on the other. The person doing the work to mount them must not have seen it.

Just curious: how do you guys store and label E4P encoders and their disks when you are not using them on a bot?

[Tparbotmail]

Let's put it this way, The mechanical team will not be handling delicate equipment any more.

We will put a system in place to properly store and catelogue electronics. If u have any suggestions please share them. Love to hear it.

[Ether]

Originally Posted by Tparbotmail

If u have any suggestions please share them. Love to hear it.

The E4P optical disks are fragile and easily damaged. They must be handled and stored with great care. When they are damaged (scratched or smudged) or improperly installed they can cause frustrating problems that may be difficult to diagnose.

Store optical disks individually in clean lint-free labeled soft plastic bag, inside a small labeled box. Store that small box inside a larger labeled box containing the rest of the encoder parts.

Team policy: no one handles or installs until they have been properly trained.

[Tparbotmail]

Amen! Thanks and grateful for your input. Our competition encoders E4Ts and mag encoders and boards from our great CTR vendor are in transit right now. and they will be kept in the china cabinet until our electronics mentor is ready for them. We might be getting a new fridge this summer I am thinking about turning the old fridge into a robot part storage cabinet.

What was great about the problem was the kids got to see how to diagnose the issue and confirm it was broken. We took the optical reader off and cleaned it with an alcohol wipe. Did some manual turns of the wheels. It was a good night.

The other thing that came out of the effort was some of the tasks our pit crew will be doing to check the bot after we compete. Learned a lot from the mistake.

[ozrien]

Another useful sanity check is oscilloscope-ing the A/B outputs of the optical encoder while it's spinning. Just in case this helps anyone, here's a video demonstrating this...
http://www.ctr-electronics.com/downl...odEncoders.mp4