Opinions about motors with integrated encoders

During Toss Up, I heard a lot of different comments about the use of motors with integrated encoders. Some people told me there were glitches in the software, others told me they appeared to be more susceptible to static electricity, etc. Yet, I noticed a lot of teams in the high school divisions were using them, so I’m wondering how people feel about them. Were there software glitches that later got fixed? Were there workaround plans for electronic noise, static, etc.?

I’d like to hear about your experiences, both good and bad, about using these things on your robots.


They should all burn in the fiery pits from whence they came. That’s my team’s experience.

But truthfully it’s a mixed bag for different people. Some people use them to resounding success, others have a slew of profanities they want to say about them. I definitely form the latter.

The best I can say is be wary of static and be wary of how you build your robot.

For Skyrise we made the decision to go back to the Red Optical Encoders.

A few teams came up to our pit as well asking for help on the IMEs.

We had lots of troubles at our regular Indiana tournaments, but at Worlds we experienced NO troubles whatsoever. I am going to try to fit in the big red encoders next year just to stay safe.

I love them, but the static kills.

We have never used them before but we have heard lots of bad things about them. Some say it helps for perfect autonomous and others it allows them to lose matches :confused:. We are going to use the red encoders this year because we have haven’t heard anything bad about those. Personally I’ve also heard they overheat faster which is a definitely is a big NO NO.

Our experience with them this year was not a good one…
They somehow managed to not work during the finals making our robot commit suicide by raising his lift during auton and driving into the barrier, breaking all the lift’s axles

The IMEs worked great for us, but we only used them on our drivetrain; I vastly prefer pots for the lift over encoders.

We used them on our Rice robots and only one had issues with them. It was more of a programming issue as for some reason, they weren’t being read correctly. Our 15" robot had them and never had a problem with them. The autonomous always worked correctly and we were able to read them with no issues. We also never had any issues with static and the encoders.

I haven’t personally heard a lot of people having issues with the integrated ones but I did see a lot of teams using the optical encoders at worlds and our programmers plan on testing those out and making comparisons to see which ones they prefer.

I am not sure if static discharge is only with IME’s, greater with IME’s or completely independent of the IME’s. We’ve seen issues with robots with IME’s over time. More sporadic these days but still present.

It would be helpful if the firmware release notes would actually list if any changes were done to I2C communication.

Many of our teams are considering going back to quad encoders. But the space needed for them is pretty large.

Something I never got with the IMEs was a consistent and accurate revolution - count in all the debugs I did. I literally had this experience where one encoder started at 0, went to 500 and then jumped a fraction of a second later to 12000. We had sprayed things down with anti-static before hand.

We ended up eventually using timers in our code to account for this.

I’ll save Mr. Pearman the trouble :slight_smile: Link here and here.

I’m glad to say that I had no issues this last year, although we definitely have had issues before. I used brand new IMEs for this year, although I don’t know if that actually had any effect. I think that you should go ahead and try to use IMEs for their obvious benefits and have a contingency plan if something goes wrong at a competition, whether that be fix it there or change it out for the next competition.

I’ve never heard this one before. It shouldn’t really have a super negative effect on the motor itself, since it’s sort of an external part of the motor. The only thing you’re changing inside the motor itself is a gear that is colored black and white. I don’t see it making the motor significantly hotter or more stalled.

Personally, I’ve only ever had trouble with static once. It was a worlds qualification match in 2013, sack attack year. My robot just stopped running and the wheels kept going. I couldn’t control it at all, and then after restarting the robot, it worked perfectly. At this point, I never knew the IMEs ever had a static problem.

Be careful at worlds, because those red carpets can build up lots of static.

I like them a lot and have never had static problems, but every so often the motor will start making bad clicking sounds because of something with the encoder.

Thanks very much to everyone who has answered so far. Very interesting.

I have a couple of quick questions: did the static problems happen with motors that were mounted only on the chassis, near the ground (where I presume static charge build-up would be greatest)? or did you also see static problems higher up, off the ground, for example near the arms or whatever?

Also, do the integrated encoders have the same resolution per revolution as the red plastic encoders? I think the red ones give 360 pulses per revolution. EDIT: I just read that the Cortex reads the encoders as 360 pulses/revolution.

We had a ton of trouble with IMEs and I was getting really annoyed with them by the end of the season.

For the first few months or so, our motors would die out every single match after only 5-10 seconds of play. Afterwards, when we disconnected from the game, we worked fine. We could go easily for 20-30 minutes without ever burning up our motors.

Little did we know that our IMEs were getting too much static and causing our motors to die out… once we changed the IMEs, we did a lot better, although we did lose a game at World’s most likely because of them. However, they worked alright - but I think I prefer shaft encoders.

Edit: Our motors were on our drivetrain, very close to the ground, and I believe that one of the wires would occasionally touch the floor.

I had very similar experience to your sack attack experience. After we got knocked out in toss up, I was able to calm down and learn more programming and I tried to use three IMEs on an H drive. I made an active brake code. One button on the joystick zeros the encoders and the other button programs the three groups of motors to spin in correct directon to make the base resist pushing. It worked out perfectly — until I put it on the ground. When I press the brake button the motors kept spinning and spinning and I had no idea why. Now it seems to be a static issue.

I took serious consideration of IMEs after reading team 359A’s sack attack notebook, in which they highly commented on IMEs. Now I am rather confused— is it easier to just use IMEs, or spare more space and unnecessary structure change for opticals, or, rather, continue to develop a function between our robot speed and battery voltage to get rid of encoders? A decision to make.

Now im not the programmer on our team but i can say for sure they are a pain. Its hard to say how many times i took apart the motor to find the encoder gear has a nice silver line etched into it from rubbing against the sensor. And yes static is a killer. In the event our team holds in our gym, our robot every year has had an issue and it is the worse!! Im not 100% sure if its true main function is to discharge static but a button was placed to technically discharge the robot. Also the big bulky wires are a mess to and annoying. But the static charge was the main issue because the robot would lose connection and not reconnect the whole match. I myself will attempt to convince the programmers to let me install the big red encoders just for a more reliable way of sensing.

I used IME’s this year. They were reliable about 95% of the time.

They can be reliable even more than that also if you have a fail safe in your program. Our fail safe was to use time as a backup from the IME’s (so have a max-time per step).

The problem with the IME’s for my team was that every once in awhile the reading from them would constantly be zero, then the robot would keep running until the max-time was reached.

If programmed right, I think they get the job done. But for 100% reliability of the Optical Quad Encoders it’s hard to beat that. But then again the size of the IME’s is so good! Ahh the pros and cons list goes on and on…

It seems gaining that 5% (or arguably more) is worth the space needed for the Optical Quad Encoders. You can design around needing that extra space. You can’t design around pure sensor performance.


I had the clicking noise too!! For me what it was that the two screws under the cap of the encoder came loose and were hitting the gears.

Our experience with IME was awful. At our school some times the encoders would not stop the robot by never increasing the encoder count I assume or they would cause the robot to completely skip a step by reading an invalid encoder count. This happened at school 5% of the time. At worlds it seemed like 50% of the time. Loosing a match because of a senor malfunction is frustrating. We replaced our encoders 3 times at worlds before giving up on them. Our IME where on the drive. I’m not sure why vex even sells these. I don’t care about the size of the optical shaft encoders but its the fact they use two digital sensor ports each which could be used for other sensors.