OK, now I have yet another question.

Does RobotC plan to support the Vex motor shaft encoders using the RobotC motor PID routines?

That is, if I connect a Vex optical shaft encoder to the output of a Vex motor, is there a way for me to have RobotC handle the motor speed control via it's PID routines?

I have my doubts here as the Vex optical shaft encoders are not quadrature based and I am at a loss how to setup a good PID routine for them. Without quadrature encoding you cannot tell which direction a motor is turning. While you do know which way you programmed it to go, you don't really know if it has changed directions yet nor if it is being forced backward by external forces.

Any input here would be appreciated. I bought a bunch of optical shaft encoders a while ago and am finding them pretty useless in any situation where the axle reverses direction at this point.

Take care,
KJohn

RobotC runs on a variety of different platforms with varying degrees of internal PID support depending on the capabilities of the encoders supported by the platform.

Currently there is no "native" RobotC PID support for the VEX version. And you have accurately identified the issue with the VEX encoders -- you can't tell which direction the motor is actually moving.

Of course, all is not lost. The servo motors used by VEX do have a closed loop speed feedback algorithm. I'm not sure of the specifics of the VEX servos, but the algorithms used by many servos are PID based.

There is nothing to prevent you from writing your own PID algorithms for VEX directly in RobotC code. Motor speeds are only updated every 16 milliseconds or so -- an inherent characteristic of servos and the non-modifiable low level firmware in the master processor -- so there is ample time to implement such an alogirthm.

One way to overcome the non-directional encoders is to only use forward direction and always assume the counts are in a forward direction.

Thanks for the info. I think when I get a chance I am going to play with putting two optical shaft encoders on one motor to see if I can fake a quadrature type setup. It will probably not work too well as the Vex encoders produce 90 ticks a revolution which means I would need to place one encoder off phase fro the other by 1 or 3 degrees. I might be able to pull this off by twisting a shaft in a vise.

The reason for all this was not as much speed control, as you mentioned the Vex motor is basically a servo so it has some degree of speed control built in, but rather determining shaft placement for dead reckoning.

My other option here is to, as you so kindly put it, "only use forward direction and always assume the counts are in a forward direction" which would make the problem moot.

Take care,
KJohn