Legal mid-match feedback

I have, for some time, been tossing around ideas for giving feedback to the driver mid-match for things such as battery voltage, motor failure (PTCs, Cortex breakers, etc.), and sensor data (the robot is often facing away from the driver, so determining whether Mobile Goals and cones are fully grabbed is difficult; limit switches and sonar sensors could help). The obvious answer is LEDs, but those are limited by the finite port count (especially since sensors have to go in there too) and the fact that they can only be one color. An LCD could work as well, but they have limited area for information to be displayed and are difficult to read from a distance. I even considered a servo, with different angles denoting different states, but that is limited to 1 “bit” of information at once (and would use up a motor port). Does anybody know of other solutions to this issue? Is there a (legal) way to chain LEDs to the I2C port, or some other vex parts that could provide data to the driver about the state of the robot during a match?

There are not many options. In addition to the LEDs, the flashlight could send out a series of on and offs for different lengths of time. There are no really good solutions. You would need one drive team member dedicated just to reading the feedback.

Probably the best for mid match:
VEX Speaker

Yeah, I thought as much. I gue… ALL HAIL THE PROS TOAD

Seriously though, a flashlight blinking in morse code would be amazing and I really want to try it now.

That’s an interesting thought. I’ve never used a Vex speaker before; how is the sound quality? I know it’s only 8-bit, but is that enough to make out a voice or at least recognizably different tones?

It’s pretty decent. The only problem is that sound files take up a lot of room on the cortex.

That may be an issue, but my files aren’t that big, so I’ll probably be fine. I’d be more concerned on RAM usage when loading/playing files.

There is no way to sense the state of the PTCs. You can indirectly deduce it from the robot behavior, but it is not possible to sense it.

The Cortex does not have breakers, it has PTCs. Same issue.

There is not a VEX competition legal way to chain LEDs off of the I2C bus.

A servo can give you much more than one bit at a time, since one bit means the device can only be in one of two states. As you note, a pointer on a servo can point to many different directions that would be easily discernible from a distance. You’d still be limited to, say 8 total states. Each state could encode the information for 3 separate binary devices/settings. It would still be inefficient, and I doubt it would be helpful.

As to displaying the value of limit switches and sensors, instead of taking the time to relay the information to the driver, you can just make the code operate the device differently based on whether or not the sensor indicates the cone is lined up, for instance.

Yeah, less of PTC and more general motor stall (if full power is given but an encoder says it isn’t moving, the PTC probably tripped). I didn’t know about the PTC in the Cortex, thought; thanks for the info. About the sensor output, obviously some things (like limit switches in the claw) would be better if done autonomously, but for less reliable sensors (e.g. sonar) which may experience noise or other things getting in the way, it would be better to give the final decision to the driver. About the servo giving 1 bit thing, I meant more of it can tell you one thing at a time; it can’t be in two positions at once so it can only get linked to a single input (as opposed to LEDs, which we can have multiple of). My phrasing was stupid, sorry about that.