Heads up from Archytas 6933. If you haven’t started working on the color manipulator yet under the assumption that it’s pretty easy and can be done at the last minute, you’re right, but that doesn’t mean it’s not tricky. We just finished the coding on our color wheel spinner for 2020 Infinite Recharge after resolving a number of “gotchas” in the process. Here are the gotchas we noticed:
– The fact that the glare of the built-in light off the glossy surfaces (and especially reading through the polycarb under the trench) actually makes the color detection worse, as documented in some of the Ri3D videos. Worth noting is that the RGB readings normalize for total brightness (the three values always add up to 1.0) so it may not actually be necessary to use a light even under the table. We’re reading from above anyway, but beware the glare.
– Spinning the wheel from the side (rather than the top) works great, but can easily push the robot away, and rather than relying on the driver to exert pressure, a temporary PID position control on the drive wheels to “lock” the robot pushing forward at a constant force works nicely.
– Attempting to read colors and count revolutions has to be able to deal with quite a bit of error, and in particular, keep a close eye on boundaries. We tested the principle that holding the sensor EXACTLY between the green and red slices caused the sensor to read YELLOW! Because of course it would. So if you get a little bit unlucky, and depending on how far away the sensor is, spinning the wheel could give you a flash of a complete wrong color in between slices. There are a number of ways around this, of course, including requiring multiple readings, ignoring unexpected color results that are not in sequence, etc.
– Technically, you don’t need the color sensor, but trying to rely on drive team eyeballs to count rotations could be problematic due to visibility and frame rate issues, and it could be pretty tricky to eyeball it. But drive teams also don’t like control taken away, so we ended up having not only color indicators, but also a rotation count progress bar that fills up from 0 to 5 to inspire trust. It’s nice for them to be able to see the auto code working.
– Overshooting the target color at the end is very much a thing. The 20ms latency, combined with momentum, is not your friend. PID velocity control when spinning to a color and using a slower speed than the 3-5 rotations is wise, as is switching to PID position to lock at 0 when the desired color is found will stop the wheel dead, and will even back it up slightly if momentum carries it too far.
Have I missed anything? Any other comments about issues you had getting the color task working?