Does anyone know of any systems that would be efficient in spinning the wheel however many times assigned and also aligning the color?
1 Like
A wheel on a motor, optional encoder, and the REV color sensor in the kit of parts.
17 Likes
And don’t forget to mount the whole thing on a deployable mechanism.
Yeah. This isn’t exactly going to be difficult to do, in theory. The problem is that at least our lazy susan is a little stiff to turn, and I’m not sure how much the vinyl will wear over the season. But, in concept, it’s a really simple problem. Note color, spin motor, count color 6 or maybe 7 more times, stop, run away.
A couple of teammates and I were originally thinking borrowing a Steamworks gear (not sure about the legality/whether or not it counts as COTS for that, but I think Andymark still has them in stock) and spinning that using a motor, catching the teeth on the standoffs in the control panel.
Alas, I checked and the dimensions aren’t quite right - the control panel/wheel of fortune/lazy susan/repurposed hatch panel with a new paint job just too short to fit the teeth of a Steamworks gear between the polycarb (both are 2" thick, but the control panel has two 1/4" sheets of polycarb, making the available space only 1-1/2").
For a slightly more realistic solution, replace the gear with a wheel and don’t bother trying to catch the standoffs with teeth.
3 Likes
I havn’t checked to see if the spokes line up / workout, but the gear does come in 2 unassembled halves. You could just not assemble them, then it’s about 1" thick…
We also do have quite a few left…
3 Likes
Thanks! I was not aware this sensor comes with the KoP.
I would say that the encoder isn’t optional if you want to get the rotation correct consistently. With a good encoder setup, you should be able to automate the spin of the Wheel of Fortune with enough precision to get four rotations every time. It’s just a matter of calculating the correct numbers. For the color positioning, it’s the color sensor that may be the optional part. I think we’re likely to be using the Wheel arm as a drive camera boom as well, so in our case we’ll probably set it up to be spun by driver control and manually aligned using the camera image. Should work just as fast (or faster) than the sensor and probably as accurately.
A camera is overkill for this. All you care about is the color. For rotation control, the pseudocode is basically “spin the wheel with some voltage until the color changes the requisite number of times, then stop”. For position control, the pseudocode is “get color from the FMS, spin the wheel with some voltage until the robot’s color sensor shows the FMS color (or whatever the color offset is around the wheel from your robot’s color sensor location), then stop”.
I don’t think there’ll be that much inertia to deal with, and the color sensor readings come pretty fast, so I don’t see why you’d need a human in the loop. There’s nothing for the human to compensate for here unless your robot doesn’t get positioned properly in the first place.
1 Like
Why use an encoder? Why not just count rotation off the color sensor that you need anyway?
2 Likes
Can someone explain this (page 33 blue box 3-4)
The CONTROL PANEL has read the required color
for POSITION CONTROL for at least three (3)
seconds and less than five (5) seconds
It sounds like they want you to change it off the selected color after 3 and before 5 sec??
that can not be right?..
1 Like
I’ve interpreted that blue box to be indicative of what each state of the light means. In the case you mentioned, it would be that during Stage 3, a flashing light means the CONTROL PANEL has detected the correct color for at least 3 seconds, but less then 5. Since you need at least 5 seconds to obtain POSITION CONTROL, a flashing light means that it has not been 5 seconds yet, not that you would need to change off the color.
But the camera is a double use instrument. It’s other purpose is as the drive camera on that end of the bot, made more effective by it’s position on the top of the mast holding the rotation wheel/motor. It makes lining up the rotation wheel for proper contact with the control panel a lot easier in the first place and then is also positioned to see the colors very conveniently. That’s also why the human is good in the loop. I think we’re going to find that positioning is going to be less accurate than we’d like and thus there will be some slop in these systems that might be more problematic.
Because I was proposing doing this without the color sensor. It’s my take that this may well be the less-ideal solution and that direct observation by camera is better. Then the encoder makes it possible to achieve precise rotation with the control panel without relying on another sensor.
Is there a specific encoder you would use?
We like the CTRE mag encoders, because we use Talon SRX controllers almost exclusively and they provide pretty much perfectly into the SRX itself. No need to go through the roboRIO. We’ll likely situate the controller on the boom near the motor for this reason (to avoid a long encoder cable.)
1 Like
If you’re already going to commit to spinning the Wheel 
, I wouldn’t think the color sensor is much more of an addition-- especially since the encoder reading doesn’t always indicate control panel rotations(spins freely). Color sensor would eliminate human latency / control, which might be a problem considering stream quality.
In that case, you’re using the control panel AS an encoder.
5 Likes
If you have proper contact with the Control Panel, then rotations of the drive wheel to Control Panel rotations should be a fixed relationship. An encoder should be able to reproduce a four-spin rotation of the Control Panel every time. No latency issue at all, since the feedback is handled entirely on the controller (we use Talon SRXs and CTRE mag encoders for this kind of thing). The relatively small movement to align for color would also be programmed this way, with preset movements depending on initial position of the Control Panel. Again, no latency or feedback issues since the actual movement is handled on the spot by the controller/encoder combo. It actually should be less prone to latency than the feedback loop through the roboRIO needed if you’re using the color sensor.
One thing you should pay attention to is the field tour videos. The field actually indicates to you when you have spun the disc the correct number of times, and when you have identified the right color.
The rules also heavily suggest you cannot spin the disc more than 60 RPM (1 RPS).
So, while automation is obviously better, if that fails or you can’t figure out your encoder + light sensor setup, you can just go slowly and use the field to tell you when you’re done for the rotation bit - provided your mechanism does a decent job stopping the wheel at that time. And for the position bit, you will take at most 3 attempts, for a total of like 10 seconds of effort. So it’s not as automation dependent as it first seems.
2 Likes
By latency I meant human control, aka having to visually recognize the wheel is contacting or that the color is correct since you are streaming a camera to the dashboard. As @CIM said, it’s not a make-or-break scenario having this type of control, and it is still possible to spin the wheel manually. I’m saying if you’re going to go for automation, I would assume the color sensor is more reliable than the encoder for similar effort to design.
1 Like