My previous post described how VEX Integrated Motor Encoders (IMEs) work in general, and how they physically get connected together on your robot, aimed at someone who has never used them before. I intended this post to be more a in-depth discussion about the different uses of IMEs and things to look out for. However, the research I did on the VEX Forum for this post, combined with our team’s experiences this year (written in blue), have brought me to the firm conclusion that our team will never use them again. (Perhaps someday I will eat these words, but I doubt it unless the technology is upgraded.)

Grain of salt: We use easyC, which appears to behave particularly poorly with IMEs compared to RobotC; there are many RobotC (and easyC) users that have made great use of IMEs on their robot without incident. We are not one of them. But even RobotC users include failsafe/backup code so that if the IMEs do fail, the robot will have a chance to recover and keep going. In my book, that’s still not a great sensor.

In lieu of my original intention, this post is now intended to be a resource for other VEX users that pulls together information from many disparate VEX Forum posts, all in one place, so you don’t have to go searching for the information in 20 different threads, a little bit here, a little bit there. If you’re having problems with your robot, and think it might be because of your integrated motor encoders (or cannot figure out what could possibly be the cause), please read on and see what you think based on the information that knowledgeable people such as the awesome jpearman have provided. This post is long, so here’s a table of contents:

The Processor

Things start out badly in my book when you learn how the technology works. There are 2 processors inside the cortex, one that handles user code, and another that handles system functionality. You’d think that the IMEs would fall into the “user code” category, but that’s not how it works inside. The IME daisy-chain is actually plugged directly into the other processor inside the cortex, the one running the system code. So right off the bat, this data is not being processed in the same way or in the same place as all of your other robot sensor data (not a fatal flaw, but curious).

The Communication Protocol

That port that the daisy chain gets plugged into is labeled “I2C”, which stands for Inter Integrated Circuit; it’s a communication protocol that was intended to be used for processors to talk to each other inside the same device (on the same printed circuit board, even). It was never intended to be used over many feet of wire, the way VEX uses them.

The encoders are chained together with special 4-wire connectors used only for IMEs:

  • red and black wires work just like they do for everything else;
  • yellow (SCL) is for a CLock signal, generated by the master (the cortex); and
  • white (SDA) carries the DAta to and from the master and slaves (the IMEs).

The communication protocol between the cortex and IMEs is incredibly complex, and off-this-planet different from the way standard VEX sensors work. Here’s the description from the VEX Forum(from rockstar jpearman) of a typical sequence to send one byte of data from the master to a slave (edited slightly from his original, since I have not included all of his technical background; see original post for full details).

  • The master sends a START bit (special pulse on the data wire).
  • The master sends the address of the slave it wishes to communicate with.
  • The master sends 1 bit indicating if data will be transferred to or from the slave.
  • The slave acknowledges it is ready by pulsing the data wire for one clock cycle.
  • The master sends the data 1 bit at a time.
  • The slave acknowledges it has received the data by pulsing the data wire for one clock cycle.
  • The master sends a STOP bit (special pulse on the data wire).

That’s it, for one byte of data to one IME. jpearman goes on to say the following, which explains why robots experience problems with IMEs, even when their programs are not making use of them. Just having them plugged in makes the cortex act like you’re using them, regardless of your user code.

The I2C communication is constantly running in the background even when you are not asking for encoder data. Each IME is asked for the current count in turn every 2mS, … When you ask for encoder data you are simply given the last count that was received from the particular IME.

If you are interested in learning the technical details of how IMEs work, please do read jpearman’s post; it’s highly educational.

This is your robot. This is your robot on IMEs.

In the same post from jpearman, he describes what happens to the encoders, the cortex, and your program (and hence your robot) when the cortex and IMEs lose connection. I’ve converted it into a table here, for each programming language. In the table, “ENC” is used to denote a variable containing the value of an encoder.

What Happens EasyC RobotC
Encoder cable unplugged from cortex ENC stuck at last known encoder count
Cable unplugged & replugged Cortex can no longer communicate with IMEs; ENC stuck at 0 Re-initializes IMEs; ENC reset to 0*
Cable unplugged from middle of daisy chain IMEs in disconnected section behave as in #1 or #2 above; IMEs before the break will function normally
I2C disturbed in some other way May or may not be able to recover; it’s “up to the cortex communications software to decide what to do” May re-initialize IMEs if it can’t re-establish connection; ENC would be reset to 0*

* The awesome jpearman, in his testing of IMEs (albeit several years ago), found that “the most common problem is that IME counts first freeze and then reset back to zero.” His post contains RobotC code you can use to remember an array of the last encoder values retrieved so that if they do reset to 0, (a) you can tell that they did, and (b) you can add the last-known value to all of your new values. (Of course your motor probably moved some while the cortex was regaining communications with the IMEs, but it’s certainly better than nothing.)

How this affected us this year: We were using our IME to raise our forklift arm to a certain height and hold it there, while we carried stars to the fence. On a number of occasions, in the lab, at scrimmages, and in competition (unfortunately), our robot must have gotten reset to 0 or stuck at 0 (we use easyC), because instead of stopping about 18″ off the floor, it just kept going up. This action resulted in (a) lots of grinding gears while the arm was still trying to go up, past its maximum height, and (b) us tipping over backward during auton and putting us out of the match completely.

We established a strict protocol of turning off the robot and joysticks in between matches, and turning them on and connecting to the field in a specific order to make sure that the encoders really did get reset to 0 and that nothing was “left over” from a previous run, etc. It helped some, I think (see below on randomness).

Other Things that Affect IME Functionality (Badly)

Attachment to the motor. This is the easiest one to test and fix; for some users, a change here could make all the difference. VEX Forum commenters widely report that screwing the black IME cap onto the motor too tightly prevents the black-and-white gear from spinning freely (and hence, counting properly). Other users reported poor results when the gear was dirty or greasy. (And, like any gear, if it has any damaged teeth, it’s obviously not going to function.)

If the IME seems to be stuck at 0 for a short while, and then starts counting, (a) look at the black-and-white gear to make sure it’s not scratched, dirty, or has damaged teeth; and (b) try loosening the screws that hold the IME to the motor and see if it changes the counting behavior. Who knows – the IME fairy could smile on you, and this could be the sum total of your problems.

Total length of daisy chain (in feet). As described at the top of my post, the I2C communication protocol was never meant to run over the distances required in robots. To reiterate, jpearman responds in this thread to a user who has a total of about 8′ of cabling in their daisy chain:

I’ve never tested that far … but I2C signals were never intended** to be run that sort of distance. As everyone else has suggested, the most likely problem is a connection between two of those cables.

** Why? Well, I2C stands for “inter integrated circuit”. It’s a communications bus (quite an old one) designed to be used between two integrated circuits and is most often used for connection within a single PCB (printed circuit board) or perhaps between two PCBs.

Small variations in quality among 4-wire extension cables. In this Forum thread, the enquirer has encoders on a really long string of extensions, with the total length of over 15′ (Skyrise, I think. jpearman responds below concerning variations in the internal resistance of the 4-wire cables. Perhaps this is only an issue when you have a very long chain of wires?

I think you are near the limit (or perhaps beyond) on cable length and small differences in the quality (ie. the resistance) of the connections may be the difference.

Several other commenters on the forum have warned to inspect your cables for small nicks or crimps, such as when the wire has been bent around a corner sharply; in these cases throw that cable section away and replace it. Apparently a small nick is enough to destroy the communication in that segment.

Electromagnetic interference/noise. The complex signal running through the 4-wire cables can apparently be affected (badly) by external forces that are commonly present on VEX robots, like current running through neighboring wires that the 4-wire is bundled with, or if the 4-wire is running past a motor that is turned on (less certain about this last claim). From this VEX Forum thread, technik3k says [with my emphasis added in bold]:

When I was debugging this problem I saw that IMEs were giving good readings if robot was just sitting there or driving around. Manually moving lift both slow, fast, and many times—would still give me correct readings. The problem wouldn’t start until you power lift motors that had IMEs. … This indicates that … power spikes in the adjacent motor wires likely are [the cause of the IME resets]. .…

So, if the above guess is correct, what could you do?

  1. Try to increase power to the motors gradually. For example, apply only 40% of intended power first, then 75% after 20ms interval, and 100% after another 20ms interval. (18ms is PWM duty cycle, so the wait interval has to be at least that). This will reduce both motor EMI and cold start amps reducing chances of voltage drop that could lead to brown-out.
  2. Make sure motor wires do not run close to 4-wire I2C connectors. Put them on the opposite sides of any metal parts for increased shielding.

jpearman sums things up rather nicely in this comment on a post from pretty early on in the IME’s existence, and I’m not sure why I only learned about it today, 5 years later. (If you don’t know what pulse width modulation is, please see my earlier post on VEX motors, or my post on motor controllers.)

Try to avoid running the encoder wires in a big harness along with all the motor control wires. Crosstalk may be a factor here, remember that the way speed is controlled on the motors is by using pulse width modulation so there are a lot of high speed digital transitions on the motor wires.

Skipping gears (or wheel slippage). No one on the VEX Forum mentioned skipping gears, but this happened to us this year. Because the IME is on the drive shaft (as opposed to optical encoders, which are placed on the movement shaft, at the end of the gearbox), if the gearbox experiences slippage, the motor will be turning (and the IME counting), but the movement arm will not, resulting in a disconnect between where the IME (and your program) thinks the arm is, and where it actually is. For us, we had a systematic problem where the drive shaft motor with the IME (one of many moving the forklift) was coming away from its idler gear when our forklift was at the bottom of its motion, so every time the arm took a lap going up and then down, the IME would get off from its correct count by X clicks; after the forklift went up & down 10 times, our count would be off by 10X.

An analogous problem occurs for IMEs on a chassis. The IME, again, is counting rotations of the motor, but the wheel can experience slippage against the mat. So the cortex thinks the robot has moved X feet, when in reality the robot has moved X-minus-unknown feet. Slippage of wheels against the mat is exactly the same as gear slippage (the wheel is a gear). NOTE: This problem is not unique to IMEs; it is exactly the same for quad encoders, since no shaft-based sensor can detect slippage of wheels against mat. I’d relegate this IME deficiency to a lower-priority category, since robot position on the field is probably an annoyance and a lost scoring opportunity at worst, whereas a cumulatively-misread arm position, as described in the previous paragraph, can cause your robot to grind gears, break teeth, and commit suicide by tipping over.

Static discharge (ESD – electrostatic discharge). There are many people talking about this on the VEX Forum. People in dry climates do say that they have clearly had their IMEs go offline due to static (mecanum wheels appear to be a big culprit). Robot drives around on rubber wheels and foam mats for a while, then robot touches field perimeter and the static that has built up finds a way to ground, and then the cortex/IMEs just can’t handle it (that’s my technical description). It’s real enough that at Worlds they treat the mats with anti-static spray. Here’s jpearman’s full-length discussion on ESD. The highlights:

The static discharge can interfere with the operation of the cortex, specifically the micro-controller inside the cortex. Robots using the

IMEs are particularly susceptible to the effects of static discharge for a couple of reasons.

  • The IMEs are powered from the same source as the micro-controller, older sensors are all powered from a separate regulator.
  • The IMEs contain their own micro-controllers and use a complex (relatively) method of communicating with the cortex.
  • The standard digital ports have a series 1K resistor making them less susceptible to ESD.

Note that item #2 above says that the complex communication protocol used by the IMEs makes them more susceptible to disruption by ESD. Yep; see above (“Communication Protocol“). He goes on to explain what happens when a robot experiences static discharge (my emphasis in bold):

We have seen two main problems caused by static discharge.

  1. The user processor inside the cortex (the micro-controller running EasyC or RobotC code) can crash (the definition of crash being that it stops running the code correctly for whatever reason, bad memory access, un-handled exception etc.). Once this happens control of the robot is lost with motors running at their last commanded speed due to a bug in the master firmware.
  2. IMEs either lose communication causing the encoder count to freeze or are they re-initialized so they return unexpected encoder counts.

Condition #2 above is described in the easyC/RobotC table above. jpearman says in his post that “Condition 1 is very rare, I have never experienced it.” However, we have, and so have a lot of other teams, and The Vex Raptors have given it the name “ghosting.” Read on.

Small variations in manufacturing of the motor itself can affect whether the it will work with an IME attached. Luckily this particular problem has a solution (thanks here to Tony Piechota, a teacher from Ontario, Canada for this insight!):

The small pinion gear at the end of the motor armature shaft is not always factory installed at the same height and can contact the protruding pins on the IME’s circuit board. (verified with vernier caliper measurements). The symptoms are very similar to many of the ones [mentioned above]: intermittent operation, motor not being able to turn (not caused the B/W encoder wheel), and even outright short circuits. I have removed the motor from the IME and pressed the gear down until the top of the gear is flush with the motor shaft. So far in limited testing over 2 days all problem symptoms in the 2 robots I fixed are gone.

My Personal Favorite: “Ghosting”

[Note: many of the VEX Forum quotes included below are from RobotC users in the early days of the IME; RobotC did release an upgrade that cleared up these problems for many RobotC users (though the fact that very few top teams use IMEs should still say something). I have included their quotes here because they are exactly the types of behaviour that our robot experienced with easyC this season (2016-17). I can tell you with 100% certainty that we experienced ghosting as recently as January 2017 with easyC, and I have seen some RobotC Forum posts during the Starstruck season report behavior that still sounds a lot like ghoting to me.]

This is the real reason I’m never using IMEs again. Only after doing research for this post did I come to finally understand the (probable) cause of the bizarre problems that our robot has been having this season. The Vex Raptors on the VEX Forum are referring to this problem as “ghosting,” or the CPU getting, essentially, stuck running the last command that it received. In our lab, disabling field control or removing the VEXnet key did not even make the robot stop; the only remedy was turning the robot off. This is actually kind of difficult/dangerous if it’s stuck in a mode where the chassis is on—usually an adult has to jump onto the field and lift it off the ground while someone else reaches in and turns it off.

  • This happened to us in the middle of several matches in operator control; in the instances I can remember, it happened for several seconds, and then the robot recovered. But during that time, our drivers had no joystick control, and the robot was just strafing across the field by itself.
  • In the lab, it usually happened during autonomous, right after we used the IME to start a PID to hold up our forklift arm. It would move to the next step in the program, and get stuck there permanently until power was disconnected. Field control switches did nothing.
  • On one occasion, it actually got stuck on the LCD screen in the pre-autonomous section. We were on the practice field at States, and nothing would get it to reset, including turning the robot on and off, or changing the batteries. However, since we were at a competition, we had the 9-volt battery plugged into the cortex, which was keeping it “alive” through the battery change, and keeping it from resetting. For the rest of the day, we unplugged the 9-volt in between matches when we changed batteries, just to make sure that the cortex was really power-cycling.

So while jpearman in his ESD post (which was from a while back, albeit) said that the cortex crashing from ESD was extremely rare, here are some threads from the VEX Forum, that might make you feel better if this has been happening to you. It made me feel a lot better to know that all of these random, un-reproducible, unpredictable problems we have had since the beginning of our season were not because of something the girls were doing to the robot, or not doing to the robot, or something related to their programming (all of which seemed fine; also, we’re a big checklist-to-reduce-human-error kind of team).

Static Electricity Ruining Brains
We have had issues with static electricity and the IMEs. With the IMEs in, after about 30 seconds or more into driving the robot, the robot would just start being out of control. Disconnecting from Vexnet would not stop the robot. Disconnecting the IMEs did resolve the problem so the team is now using shaft encoders. –blatwell
We also had that problem. We almost lost the tournament champion title due to dropouts from using IMEs. –NattyMan0007

Another long thread:

Robot Disconnecting

Last competition I had a problem with our robot; I could turn both the controller and the cortex on and they would connect perfectly. After about 20 seconds of driving the robot would stop taking commands and repeat the last command given to it, ex. driving forward. Once this happens you lose control the robot. However, all three lights on the controller are still green. The only way to stop the robot is to shut the controller off. I use easyC, if that helps. –6717

From my experience, EasyC and IME’s don’t mix well. … I have had the exact symptoms you have described when using IME’s, even when their are just plugged into the brain. I just let the IME’s sit in a box and use other sensors. –Max-D

I have encountered these symptoms countless times—motors not responding until the brain restarts while all lights remain green—with multiple codes, multiple robots and I have also seen teams encounter the same issue and reach the same conclusion. the two common factors have been easyC and IME’s. whatever the problem is, it magically disappears when the IME’s get unplugged. this even worked on a robot that had it’s encoders plugged in but they weren’t used in the code so that no code change took place in the process of decommissioning them. –Max-D

I just confirmed that this is why the problem was happening. When i unplugged the encoders everything worked… –6717

Last year, several teams I know, including mine, encountered a similar issue (robot “ghosting” the last commands it received from the controller forever until it is turned off, but only while IMEs are plugged in). Most of us theorized that the problem is static electricity being collected by the IMEs sent to the cortex. We refer to this as ESD (Electro-Static Discharge). –The VEX Raptors

The team below ended up re-downloading the firmware onto their cortex frequently to keep their robot functioning with their IMEs.

Weird IME Problem

We were having some of the same issues. … I can definitely see static being an issue, though. We force-redownloaded firmware and code and after one test, everything was working fine. … It may end up being that we have to redownload firmware/code every couple of robot usage hours :confused:

Just to add on specific details:

One time we got the first part of the autonomous to work (one movement to get the [Sack Attack] sacks), then one of the encoders made all of the motors reverse. That was probably related to the sacks. We redownloaded the code (not firmware) and then the robot would go completely different directions than what was assigned. We ended up taking off the autonomous entirely due to the IME failure… it cost us at least one match.

I plan on dealing with redownloading firmware/code every once in a while for the rest of the year, but until the issue gets directly addressed, I’ll be sticking to the optical encoders. –edjubuh

Team 24C and our team have both had problems with IMEs collecting static electricity and sending it to the brain. This can cause several different problems, most notably the robot doing whatever it was doing when it bugged out, infinitely until you turn it off. –The VEX Raptors

And one last thread. This thread is also from early on in the IME’s lifetime, but I have to say that, at least with easyC, these problems remain:

Opinions about motors with integrated encoders

[IMEs] 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. –OscarNVCC

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 Botfather

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. –MGOD

Randomness

Ask anyone on my team, and they will not hesitate in telling you that I have a pet peeve: I hate random errors. Give me a systematic error any day. Systematic is good. Yes, systematic errors may tell you that you have a catastrophic design flaw, but now, at least you know you have a catastrophic design flaw. Random errors suck. You have no idea if your robot has one problem or 15 problems. You have no idea if your robot has an ongoing problem or a problem that is somehow resolved. You don’t know if it’s a programming problem, a mechanical problem, a connectivity problem, or if it’s something the kids are somehow doing in their setup and operation of the robot.

IMEs produce 100% random errors (and a few systematic ones, but I think they’re few and far between). tecknik sums things up pretty completely in this forum comment:

My experience with IMEs this year was that they failed on 50% of the runs after [our] lift moved up and down several times. After reading up on vexforum the only thing that became clear was that nobody really knows for sure what is going on. So, since we had plenty of other issues to deal with – we just moved to quad encoders and it worked flawlessly.…

Read through the various VEX Forum posts linked here, and you will see a lot of people report things like: their 5 IMEs were working fine for several months, and now nothing they can do will get the last 2 in the chain working and they’ve tried everything, and please help! … and here’s another update from the next day … now they turned the robot on, and all the IMEs are working fine. Over the course of the season for our robot:

  • had a kick-ass autonomous 95% of the time, and committed suicide the other 5%
  • would “ghost” in the middle of matches, where our drivers would lose control of the robot for several seconds with the robot driving across the field by itself
  • would clearly lose connection between the cortex and IME, resetting the encoder to 0 and causing our forklift to keep going up
  • had gear slippage in the IME gearbox, resulting in a mismatch between the forklift’s actual position and where the IME thought it was
  • had times in auton skills where the IME clearly stopped working after 1 or 2 instances of being used in the program
  • had one instance in the lab where it drove the autonomous pattern in the opposite direction from where the program was directing it (we turned it off after it started doing this, as it crashed into the perimeter; don’t know what it would have done in the next instruction step)
  • had multiple instances in the lab of ghosting after the first 2 steps in our auton program (this conveniently occurred 2 days before States)

And of course you can never intentionally reproduce ANY of these problems. We could drive around in the lab for weeks with no problems, and then BAM, it’s the all-ghosting-show. In the moment, many of these problems do not seem related to the IME (ghosting during operator control, for example), and so the nature of the problems further stymie any efforts to remedy them. Most people won’t connect “The robot is ghosting during driver control” with “It must be the IME’s fault” or even “I wonder if it’s related to the IME?” Because to any sane person, it’s not related.

We had other odd problems this year, but based on my research, I feel that I can definitively tie these occurrences to the presence of a single IME, connected via one single 4-wire cable section to the cortex. We are refurbishing our robot in preparation for Worlds right now, and have of course removed the IME. We are using a potentiometer to measure the height of the arm instead of an IME.

Switching to Other Sensors: Potentiometer & Optical Shaft Encoders

One of the selling points to the IME is that it’s compact, and for the most part doesn’t require special accommodation in your robot design to add. In addition, since it is plugged into the infamous I2C port, it frees up the digital ports in the cortex for other sensors. That’s the allure, and hopefully I have convinced you that the allure may just be something shiny-looking.

Next time you’re at a competition, walk around and look closely at the robots from top teams, and especially from teams that score high on programming skills. You’ll probably notice that lots of them have those big (clunky, not-shiny-looking) red boxes on their chassis—optical shaft encoders—and that there is not an IME around. I started noticing that a lot this year. If you read the full versions of the threads linked above, most people recommend switching to shaft encoders, and those that did switch reported flawless execution after they ditched IMEs. The main drawbacks to shaft encoders:

  • they’re big, so you have to plan for room to install them in your robot design, kinda from the beginning; hard to switch from IMEs to shaft encoders (easy the other way, but you don’t have many takers)
  • each one takes up 2 digital ports on the cortex

For a movement arm, consider replacing an IME with a potentiometer. We’re basically using a potentiometer now in exactly the same way as we were using the IME: turn the motors on while POT < someValue, etc. We were using the IME because of easyC’s very-convenient (read: shiny-looking) PID function block that we could use to hold up the forklift while we were carrying stars to the fence, in lieu of writing our own PID code. We have found the POT to be reliable and consistent, but the center-core of the device itself is a little fragile, and we’ve already broken two of them; luckily they’re still usable, given the way we need to install and use them.

If You’re Stuck with IMEs

You may be stuck with IMEs; you may have them on your robot now, and may not have any way to incorporate a different sensor on your robot without a significant design change. So what can you do to make life better? There are a few programming-related changes that can mitigate problems if the I2C loses communications and the ENC gets reset to 0 or stuck at 0, etc.

  1. Unplug the daisy-chain from the cortex every time you turn off/on the robot to make sure they are really really reset. I so wish I had known this when my team was using them. VEX Forum user Gold Rush says in this post:

    Every time we turn our robot off and on again, we have to unplug the encoder wire from the I2C port and replug it again in order for our IMEs to work. Asides from that, our IMEs have been working fine.

  2. Add what we call “kill timers.”
    • At the start of every programming block that invokes the IME for whatever measuring need you have (“move this motor until you get to 1000 clicks”), start a timer (killTimer).
    • Figure out how long the given movement would take if it was working correctly (e.g., 1000 mS), and add a buffer to account for life’s little variations (e.g., 250 mS).
    • In your loop that’s checking the IME count, add the statement: “if killTimer > 1250, then break.”
    • Make sure you put killTimers everywhere that your IME could spaz out.

    Without a killTimer, if the I2C communication is lost (ENC stuck at last recorded value), or lost and regained (ENC reset to 0 / RobotC; ENC stuck at 0 / easyC), or any other wacky thing that might happen, the block of code that is checking the IME count will either never progress to the next instruction, or take an unusually long time to progress to the next step, both of which indicate that there is basically a fatal problem. The killTimer will at least break that loop, and hopefully save your robot from damaging itself or tipping over, etc. Your robot will probably not do the rest of its autonomous pattern effectively, but your robot will not be dead.

  3. Check to see if ENC is suddenly 0.
    • Include instructions in your IME coding that monitors the value of ENC, and if ENC = 0 for more than x cycles through the loop, then break, or take some other action based on what programming language you are using.
    • See above for a link to jpearman’s RobotC code for keeping track of the last-known encoder values so that if ENC is reset to 0, you can take all of your last “real” values and add those constants onto all of your new readings. As I mentioned above, it’s not a perfect solution, since your motor probably moved during the time the I2C was regaining communication with the IMEs, but it’s better than having ENC starting at 0, which can obviously cause damage to your robot if it results in a movement arm trying to extend past its maximum point.
  4. Re-download your firmware onto the cortex. Per edjubuh on the VEX Forum (as mentioned above under Ghosting), try force-re-downloading the RobotC or easyC firmware onto the cortex (possibly on a regular basis, if it appears to have any temporary positive effects).
  5. Troubleshooting process. The awesome jpearman on the VEX Forum offers a useful, systematic process of troubleshooting your IME system when you have (a) a system that used to work that now doesn’t, or (b) an IME daisy chain that stops working half-way through. In the second comment/response in this thread, he walks through the process of, essentially, rebuilding your chain from one motor on up, in a way that ensures that each IME and connecting cable is functional.

⋄  ⋄  ⋄

There you have it, another dissertation from the Coach’s Corner at Renegade Robotics. I hope that this information all pulled together here in one place proves useful and time-saving to other people, and maybe saves other teams some frustration along the way. If I’ve included anything in error here, or have omitted something important, please email us.

Share this post: