Vex encoders/Interrupts


Has anyone used the encoders with the Vex bot? We’re using a Vex platform for prototyping so that the programmers can work on the drive code while everyone else builds the real thing.

If I use Kevin’s encoder code with the Vex encoders, or if I use EasyC with the Vex provided encoder code, I don’t quite get what I expect!

Interrupt 1 comes up as Encoder 2 (Kevin) or Interrupt 2 (Easy C)
Interrupt input 2 comes up as Encoder 4 (Kevin) or Interrupt 4 (Easy C)
3 comes up as 6, and I can’t find the rest of them.

This happens on at least 2 Vex controllers, so I’m sure it’s not a bad controller.

Does anyone know for sure what ports the Interrupt pins map top, or do I need to disassemble my controller and map it out with a meter? :slight_smile:

Has anyone successfully used 4 encoders on a Vex bot, all connected as interrupts?



I remember the Vex encoders not being quad-output, so you can’t have the “phase A plugged into dig-01 and phase B plugged into dig-02” problem. Hm.

Just out of curiosity, especially if you’re using tank drive, what is the purpose of putting an encoder on the front and rear wheels of the same side of the robot? Shouldn’t those wheels turn the same amount anyway?

I guess it wouldn’t be a bad idea to say exactly what you have plugged in exactly where. That seems to be the starting point for a lot of these questions:)

We had the same problem last year. Interrupt pin 3 registered as encoder 6, interrupt pin 6 registered as encoder 4, and interrupt pin 4 either registered as a random thing each time, or stayed at -13. I know the answer, but my brain doesn’t want to remember it right now. I will try to think about it and get back to you tomorrow.

He probably is using one motor per wheel rather than having them chained together like the typical 4wd FRC robot. The bigger question what good encoders are on a tank drive robot other than to control wheel speed.

This is no ordinary Vex bot! It’s…It’s…It’s…frankenVex!

It’s a prototype with mecanum wheels, so that our programmers can work on the mecanum drive code while the actual robot is being built. FrankenVex consists of a Vex controller, 4 Victor 884s (Motor 1-4), some power wheel motors (I think…very beefy), and the mecanum wheels.

There’s a photo attached below. We need the encoders in order to make the thing drive straight!

What’s plugged in where: Motors go to ports 1-4, encoders, I’ve tried plugging an encoder in each of the interrupt ports, and got the weird mapping I described before. I’d like to plug the encoders into ports 1-4…but I’m willing to plug them into any 4 ports such that they’ll work :slight_smile:

I think I’ll probably just stick an old FRC controller onto FrankenVex, making it into FrankenFirst, since the encoders seem to work correctly on the FRC.

Here’s a poor picture of it. Once I get it put back together I’ll post a better one.





Switching to an FRC controller shouldn’t affect anything unless you change the code because the FRC controller and the VEX controller have the exact same microchips and are just packaged differently. Also, I was wondering how you are powering the Victors and motors because you don’t appear to have a 12v FRC battery on the robot and running them off a 7.2v VEX battery could be causing your uneven drive problems if they are made to run off 12v.

It seems that the interrupts and encoders work on the First controller, but not the Vex. I’m not sure why.

I checked the datasheet of the Victor 884s and they’re okay with 7.2V. I do have a second Vex battery just for the 884/motors.


The Vex controller may have a different mapping of processor I/O pins to digital inputs. So even though the processor inside is the same, “what goes to where” is different.

Just a personal comment, I’ve been through the recent FVC and I experienced much unpleasantness when using the VEX encoder. Not sure due to its poor build quality or otherwise, there is often much plastic dust (due to friction between plastic parts when spinning) accumulating INSIDE the encoder unit, which affects the encoder’s output and hence would affect you during tuning/testing and soon you will find yourself changing program values unneccessarily. The abrasive dust would get clogged not only in the optical wheel but also in the IR sensing area which results ultimately in the failure of the device to sense any rotation at all (after long runs) and you will need to open it up and blow air into it in an attempt to clear out whatever crap is inside…
One solution could be to position the optical wheel properly and suspend the optical wheel on bearings… :stuck_out_tongue: not sure if that helps…
In a nutshell, don’t rely too much on the vex encoder :o

If you are using easyC Pro you can use quad encoders on the VEX bot. Plug your encoder A channel into interrupt ports 1-4 and plug your B channel into I/O ports 5-8 or hit F5 and reasign I/O ports 1-4 to Digital Inputs.

It looks like you are using the VEX encoders though so you probably need to upgrade to a set of quad encoders.

Good Luck