PhotonVision
Status LED support
I know this is just a placeholder but some thoughts on status LEDs.
I'm working on a Gloworm "alternative" using various COTS modules and parts together with a RPi3 to help teams build more complete vision modules using PhotonVision. The Gloworm is great (I have one) but this is something to tide folks over or satisfy the "I built this myself" itch. Details and designs to be shared on Chief Delphi when it's ready (it's pretty close).
On to the status LEDs: most RGB single package LEDs are common cathode so active high on a GPIO will work great; putting that out there unless there is a strong plan to do something else.
For over the top functionality, the ability to control the active sense of the GPIO pin would be "powerful" (note I didn't really use the word "useful"; it could easily be a case of "when engineers attack").
In that case, configuration could be:
"statusRGBstates" : [ 1, 0, 1 ]
Indicating high, low, and high to activate R, G, and B respectively.
I'm incorporating the status LEDs into a small custom PCB which also handles constant current for the LEDs using a common cathode approach since I'm assuming this is fairly low risk. Let me know if you feel this isn't the case...
The status LED is visible via the red-shaded light pipe in line with the LEDs on the left side.
Quick shot of the internals without the top of the case being rendered:
An assembled prototype is running on my bench as we speak - status LED wiring tested driven by the RPi but not being driven by the code of course.
For the sake of conversation... what sorts of status should be indicated? Which ones are hardware-dependent, or apply to all types of hardware?
secondarily... how can/should these be mapped when each of R, G, or B are available?
FWIW, on limelight:
We discussed this on the Discord a while back with relation to Gloworm, which has only 2 LEDs, a Red and Green. This was what I came up with for the status->LED mapping.
(SHTF = Stuff Has Totally Failed. :-) )
As for how this functionally needs to be implemented, it becomes tricky to do flashing. The way flashing works with the "Camera" LEDs is with a wave generator built in to PiGPIO. This can only be used with one "wave" at a time, and therefore only one set of LEDs at a time. Flashing of status LEDs will have to be implemented differently.
I have thought about a small daemon that runs on the Pi to handle this, with unix socket calls to change state, but that removes the true control of it from PhotonVision itself. It comes with the upside that it can do its own life-sign checks on the Photon service and system status (networking, NT, etc). Something to be considered.
My thoughts are that any status LEDs are PhotonVision status and not hardware status. That said, there is a question as to whether all 3 LEDs are equally utilized (and important) or there is hierarchy of LEDs ("something like PhotonVision supports up to 3 LEDs; if you support less than this, we consider the priority to be R & G with B as optional").
SHTF is a tough one, you need a lot going right to know that SHTF. Years ago I was working with a computer OEM new to the UNIX space, we created a bunch of configuration validation tools to help detect misconfigurations in the various system databases. Someone got the idea that having a CPU and memory test would be useful. I pointed out that by the time we've reached multi-user operation, or even a shell prompt in single user mode, we can be pretty sure the CPU is working even without running such a tool. You can do things like set an indicator very early in the startup of the process and then clear it when the various key subsystems have started up correctly.
There is a question of who are the LEDs for - developers or users. As developers, we love developer-oriented states but for users, that all too much "inside baseball" in most cases.
Maybe only the R and G LEDs mean anything to users and the B status is a developer debug (you don't need to include it in the hardware but if you do, it'll be off unless the code explicitly turns it on and it will never be a user oriented indication).
I don't think the table is bad but we could eliminate the flashing for the 4th state (it's a little clunky to have the solid green be a "good" state and then augment it with an even "better" state that makes it harder to see if there is a target or not (the flashing rate limits the rate at which "target acquired" can be relayed to the user. If G indicates a target, that can be a somewhat fast moving status - you might be aligning the camera or in the case of my design, doing a manual brightness set (the LED driver has a settable "max" brightness so if someone complains about intensity, anyone on the team can make a quick tune up with a small screw driver without any software knowledge, or connection, or whatever).
In the case of that table does "no NT" mean no connection to the robot's NT server? What if PV is running the NT Server?
Could R indicate either NT connection to robot made or local NT Server started with G indicating just target status (no flashing - all solid)?
The daemon idea isn't bad. It can either be a simple one way PV to LED driver like "set the LEDs to 01F" or if you want to do health checks, it could go in the opposite direction where the daemon initiates the connection to PV and gets a "state" record and decides what to display from that. The second becomes an issue of what the state record contains and then considering you've got probably only 2, maybe 3 indicators but you could add flashing more easily. From the human interaction perspective, flashing is typically considered sub-optimal because you can't do a glance, you need to keep looking for the duration of the flash duty cycle + some more to tell what's happening to a reasonable level of confidence. Flashing for problematic, essentially terminal states is a different matter, if you're broken down and not going to be able to proceed, that's a definitive state for sure. In that case, you can do flashing in software since you've determined that things are too broken to do much else so I might as well spin and blink...
I lead a team that builds the fastest commercial messaging software in this quadrant of the galaxy - we can and do collect a ton of metrics, that's easy. Boiling it down to "news you can use" is a much harder egg to crack. We're always weighing internal metrics against what a user would care about or could even do something about. Same sort of considerations here but with just a couple of indicator lights, it's even more stringent.
This discussion also makes me think about whether an RGB LED is a appropriate or not - the above suggestion has the effect of giving you a yellow-ish light for NT and target active on an RGB LED. I don't think this a deal killer - it's a clear state change from "NT active + no target" and "NT active + target" states. if you were messing with the camera, you'd know when you have a target or not.
Manual, no computer, no web page, target confirmation is a big deal IMO.
This discussion has moved me off of using a single RGB LED and to having 3 distinct LEDs, each with the own light pipe through the top cover. Having them separate will eliminate the question of color blending impacting the meaning of the LEDs. Each will be distinct and easy to differentiate.
I'm including all 3 - just in case.
I don't have a solution for the Gloworm only having two LEDs - I suspect it will be a decent volume platform once it becomes available so having something that works clearly with only 2 LEDs makes a lot of sense. Maybe there could be a 3rd LED for the next Gloworm revision.