VEX Optical Shaft encoders in FRC

[sanddrag]

If it were allowed, would VEX Optical shaft encoders be a suitable piece of hardware to use in FRC? I ask because they are very cheap, at $20 for two.

[BrianBSL]

Originally Posted by sanddrag

If it were allowed, would VEX Optical shaft encoders be a suitable piece of hardware to use in FRC? I ask because they are very cheap, at $20 for two.

I guess you could, but I'm pretty sure they are not quadature output, and I bet their max speed is pretty low, so if you geared them down enough you could use them, but don't expect the precision that you would get out of one of the grayhill, honeywell, or us digital encoders that go for $40-$60 each.

You get what you pay for with encoders.

[artdutra04]

You could use the Vex Shaft Encoders in FRC. According to the Vex Shaft Encoder Manual, the Vex encoders can handle up to 1,020 rpm with 100 pulses per revolution. They cannot be geared directly off the CIM motors, but this is a decent speed. The sensor itself is a digital sensor, releasing a string of 0s and 1s. For every 01 pulse, that is 1/100 of a revolution.

[Gdeaver]

They only give counts with no direction info. However this simplifies the programming. When I saw that VEX was going to offer encoders, I couldn't see how they were going to implement the interrupts and state machine in easy c. They aren't - just a simple counter. They should be considered off the shelf. There should be an easy c add in. If there was a take off on the cop trans then every team could have some sort of autonomous action with out to much effort. This could improve the 2006 game action. To many teams in 2006 had a autonomous strategy of do nothing.

[foobert]

the guys at vexlabs.com discourage the use of interrupts because pwm generation for the motors is done in timing loops, so interrupt processing would cause glitches in the pwm. also, the high priority interrupt is used by timer0 to sync the pwm generation so that it does not happen while r/c data is being sent from the master processor, so that spi interrupts, (also high priority), do not cause glitches in the pwm.

so although they frown on use of the low priority interrupt, they really, really discourage use of the high priority interrupts.

[BrianBSL]

Originally Posted by foobert

the guys at vexlabs.com discourage the use of interrupts because pwm generation for the motors is done in timing loops, so interrupt processing would cause glitches in the pwm. also, the high priority interrupt is used by timer0 to sync the pwm generation so that it does not happen while r/c data is being sent from the master processor, so that spi interrupts, (also high priority), do not cause glitches in the pwm.

so although they frown on use of the low priority interrupt, they really, really discourage use of the high priority interrupts.

I'm confused by this - on the FRC controller, the PWM outputs are sent by the master uP. Is this not true on the Vex controller? Seems like a waste of a chip then to just do the radio stuff.

[artdutra04]

Originally Posted by foobert

the guys at vexlabs.com discourage the use of interrupts because pwm generation for the motors is done in timing loops, so interrupt processing would cause glitches in the pwm...

I'm confused . According to the Vex Shaft Encoder Manual, the Vex encoders do not plug into the Interrupts. They plug into any port on the Analog/Digital inputs. The Vex Ultrasonic Sensor plugs into the Interrupt ports, and from experience I've had working with the Ultrasonic Sensor, it only pings out when you tell it to in the code.

[BradAMiller]

Originally Posted by artdutra04

I'm confused . According to the Vex Shaft Encoder Manual, the Vex encoders do not plug into the Interrupts. They plug into any port on the Analog/Digital inputs. The Vex Ultrasonic Sensor plugs into the Interrupt ports, and from experience I've had working with the Ultrasonic Sensor, it only pings out when you tell it to in the code.

When programming with EasyC the encoders plug into the interrupt port. The way you use it is to create a program block that starts the sensor (begins counting interrupts in the background) and later in the program another block that stops counting. Anywhere in between those you can read the current count or reset it to another value.

So to compute how far your robot has traveled you just read the count number which is in units of 1/90 of a rotation, take into account your wheel diameter, and you have distance.

To compute the speed the robot is moving use a timer block to get the time that has passed since the last shaft encoder reading. Now you have the distance and the time so you can compute the average speed the robot was going.

Brad

[foobert]

Originally Posted by BrianBSL

I'm confused by this - on the FRC controller, the PWM outputs are sent by the master uP. Is this not true on the Vex controller? Seems like a waste of a chip then to just do the radio stuff.

the motor outputs on the vex controller are re7, rg0, rg3, rg4, re0, re1, re2 and re3 on the user controller. the first four of these are pins that may be used for hardware pwm. just for laughs i used pins 1 and 2 to control the brightness of a couple of leds according to stick positions.

the master controller does indeed appear to do little but decode the signal from the radio. out of every 18.5 ms it spends 6 to 12 ms decoding ppm input from the radio and then has 6 ms in which to push the data over the spi bus to the user controller. and it will do this for two radios.

i think the master also controls the reset on the user controller.