Automated Pit Checks

[Awesomeplayer165]

Features:

• maintainable, year-agnostic API
• possibly use command factory
• data structure (in code, with this year as an example for the future) representing general values to match after a specific amount of time.
• dashboard button starts the testing
• should hook into
• shouldn't regard the current value is at, but takes in the system's current value after waiting that system's specified amount of time as well as the data structure's expected value with a specific tolerance.

potential data structure:

[
   {id: Obj(expected value, time offset, tolerance)}
   ...
]

[kevinclark]

I love this idea. When I think of what you're describing I think of Nagios. It's not an amazing piece of software, but it effectively has a trivial and generic api for reporting how something is doing with a variety of levels: CRITICAL, UNKNOWN, WARNING, OK. Effectively to write a check, you can just make a program that does something and then prints a level with a message. Nagios handles aggregation and then alerting based on simple rules.

If you could make your api sufficiently generic (register a 0-arg method handler that returns an enum and details, for example) it'd be easy for pit checks and mid-match alerts (which you could then use to dump extra info into the log) to share code.

I could imagine this being adapted as easily to hardware specific constraints (driving the swerve motor should consume < N amps) as other things that need investigation (odometrey as drifted from vision more than some margin of error).