I’m using the v5 and want to run 4 Optical Shaft Encoders and a gyro. But the v5 only has 8 ports. Does anyone know how to combine the ports?
Didn’t Vex offer a 1 port encoder in the past?
Is there a way to run one of the encoders with one port on the Optical Shaft Encoder and only get a one way value?
There was in RobotC. As for using this with V5 and pros, I have no idea. Have you tried doing this, with just one port? https://pros.cs.purdue.edu/v5/api/c/adi.html#adi-encoder-get
Yes in every config possible. I was wondering if I can use either the digital in or the analog in functions in pros.
According to a PROS man on discord, 1 wire encoders aren’t supported on V5. IIRC, it is just counting ticks as an input, so technically you could make code that manually does that, but I’m not sure as to what accuracy you would get. There is probably a reason it isn’t supported with V5.
Ok I was thinking that pros looked at each port as a separate encoder and would add or subtract depending on the interval and witch one fired.
Judging by the vexrobotics.com page I think that they are digital. Am I right?
I’m using mecanum drive this year and was wanting to use the shaft encoders on the wheels. Do I need 4 encoders or can I get away with 2?
The 3-wire ports on the V5 are connected like a smart device (like motors or vision sensors). There’s a chip that runs those 3-wire ports that enables the capabilities like gyro, encoders, ultrasonic, etc. that ultimately communicates its status to your program. This chip hasn’t been programmed (by VEX) with the capability to do single-wire encoders.
You could possibly set up a single wire encoder, but you only get new values up to every so often (on the order of a 2-10 milliseconds - not sure the actual latency now that we’ve gone through a few firmware releases). You’ll have to do the math to see if that kind of latency is acceptable or if you’ll start missing rising/falling edges.
I guess it’s possible that they could come out with an adapter for 3 wire to smart port then.
If you are using V5 they have built-in encoders. I don’t think there is any benefit to using a shaft encoder on a shaft driven directly (or by gear or chain) by a V5 motor. There may occasionally be an argument for a potentiometer (on an arm or the like).
While the v5 motors have great build-in encoders they only measure where the motor’s output shaft is not where the wheel’s shaft is. I experienced a lot of snaking on my autons last year unless I pulled back all of the drive wheels then it was fine.
This is correct, we didn’t add code for 1-wire encoders. The primary reason is that we want all data in a single packet sent back to the main cpu and there isn’t room for 8 ports worth of encoder data (we send 6 bytes for each encoder, 4 bytes for position and a 2 byte velocity).
Velocity? Does pros have access to this data? How accurate is it?
What was the interface between the motor shaft and the wheel shaft? Direct drive would have the least slop, gears would be next and chain would have the most play.
Best of luck with the drivetrain!
V5 comes with built-in encoders.
Direct drive but the play in the motor was enough.
Which are incapable of measuring the rotation of anything but a motor’s drive shaft. Sometimes you want to measure the rotation of other things.