[URGENT] IME Problems

Hey guys :slight_smile: We are having a few problems with our IME’s.

We have 4 separate IME’s on on our drive.

I2C_1, I2C_2, I2C_3, I2C_4

We are getting accurate readouts from IME 1, 3, 4, but the second encoder is nearly 200 ticks off from the other encoders…every time.

What we have tried.

  1. Swapping out the second 4-Wire that goes from I2C_1 to I2C_2.
  2. Swapping out the entire IME setup on the I2C_2 (new IME disk / casing).
  3. Swapping out the cortex.
    *Would an IME disk go bad? If so how?

What doesn’t make sense to me is the I2C_3 and I2C_4 are getting good readouts. I would think that if the second IME in the daisy is faulty, the results on the rest of the chain would also be bad. That’s not the case. IME’s 1,3,4 are within a few ticks of each other.

Would this be a hardware issue? Do we need to order 4 new IME’s and a new Cortex?

Would this be a software issue? If needed I can provide our code.

Please let me know ASAP! Thanks!

200 counts in general or over a specified distance of X? 200 ticks is about 3 inches on a 4 inch wheel directly driven I think.

I wonder if that one black & white encoder wheel inside is dirty so you see black and white more often? If always a +200 no matter the distance I don’t know what could cause that but proportionally off could be more “false” black sections causing the encoder to do a count +1 throwing you off.

We had grease on the IME sensor before too and it looked all messy. Wipe it off and see if that helps. That helped us once.

Next thing to check is to see if that wheel has any slippage. If it’s slipping, then your IME is correct. That wheel went a bit longer and you have a weight distribution issue to fix.

Otherwise quickly buy a replacement and swap it out to see if that helps. It’s Friday so get ordering!

Another thing is to check are the packets coming back from the IME to see if you have data loss. Being 200 over would not seem to be packet loss. But it’s something else you could check.

See code sample in this thread. The i2c stats tell you if something went awry in communication.

Another thing you could try is to download a new competition template and see if you have the same problems. This way you can know whether or not it’s your code that is giving you the problem.
Hope you guys can fix this fast; especially with The U.S. Open just around the corner. Look forward to seeing you there!

We also tried swapping out the IME discs. A disc that looked good wouldn’t give any sort of a readout whatsoever, and a disc that had been scraped so it had a white circle going around it gave us readouts. But so far, we get readings of 350 on I2C_2 while the other 3 encoders have readouts of all almost exactly 550. So to clarify, it is 200 less, not more.

We will try downloading a competition template in about an hour and see what happends.

Any other ideas?

What about a firmware update on the cortex, joystick and vexnet keys?
It doesn’t seem to be a hardware issue to me seeing as you swapped out everything.

I checked the keys yesterday, the updater said they were up to date. I updated firmware on the cortex and tried directly downloading, and that didn’t seem to fix it either. I will recheck all of that today though. However, we haven’t installed RobotC 4.30 yet. We are still running 4.27. Any chance that could be it?

How about ignoring I2C number 2? You are generally averaging two encoders depending upon your drive. You may just want to ignore this one in the calculation until you can figure it out. That is probably your path of least impact given you compete in a few days at Nationals.

What we saw with flaky I2C’s in the past is that once corrected all your numbers you used in auton are off. So depending upon how much you have just been dealing with this one encoder will depend upon the cascading influence has down stream.

If a holonomic drive that gets a little tricky but if you think of X and Y as two sets of numbers to manage it is not that bad.

PM me or post your code and let’s see what can be done.

I’m not entirely sure if RobotC is the problem; maybe James can answer that. You could give it a try though. I would suggest you leave your primary programming computer alone and do this test using another computer if possible. Just a safety precaution.

No chance.

It’s likely to have a simple solution.

My first thought was hardware, but if you have swapped that IME with another then you have (mostly) eliminated that.

Perhaps the 200 count difference is an accurate indication of how far the encoder has moved, you need to do some simple tests and verify what is happening. Rotate each wheel by hand without the competition code running and see how many counts you get for one rotation, it should be 627 if geared for torque or 392 if geared for speed (why, that’s about 200 counts, any chance the motor is geared wrong? ).

If the above shows the same number of counts then it’s probably your code.

You swapped out the IME for a new one and the cortex and changed the order.

I think it’s telling you that there is a slip in that wheel.

One solution is to not use the IMEs. I got burned by them at States last year. I dont want to use them ever again.

I had static drop out issues when I had them. This year I used the Quad encoders and the drop outs due to static discharge have stopped

To avoid all IME problems I have found the best solution is to use Quads instead of IMES

haha, thanks Miranda :slight_smile: We would also like to use the quad. encoders, but it didn’t work with our design.


We have given up on using the second encoder. We will just be using 3 of our 4. Thanks for all the troubleshooting help!