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