Ryan Dancy; Firmware (Riishi)
Purpose of dashboard:
Can easily get information on what’s happening to the system
Dashboard makes it easier to read data as it is organized/sorted (sorts through CAN)
Card Sorting:
Most critical/important cards selected were:
Any fault in general (Charger Fault <Boolean>, Rear Power Distribution Faults, etc.)
Rarely/never viewed:
Firmware won’t typically look at anything electrical related (ex. voltage, battery, motor velocity)
Babydriver is irrelevant (does not know what it is in the first place)
Solar 5 and 6 are basically the same thing (# refers to num of mppts, can measure values from solar panels)
Mech brake engaged (used to be e-brake engaged)
State changes are useful to know
State transition is also important (reverse, park, neutral, drive)
State of battery fan
Status codes 0-10 (not a boolean value), 0=success, !=0 means failure
More on how they use dashboard during the race:
Being able to locate data based on time in case an issue occurs
People who would use the dashboard:
Anyone who has knowledge of the system (hardware, firmware, and strategy at times)
Firmware people who have the knowledge to debug whatever comes up in the system
Sort logs by message + time (being able to filter it)
Current projects w telemetry?
CAN explorer project
GUI that allows messages to be sent
Scenario of using telemetry?
A user who is in the chase car who is monitoring the feed
Ensures that all state changes are occurring when they are supposed to