Aashmika Mali; Hardware + MSXII (Riishi)

• Telemetry Dashboard is critical for the Hardware team

  • Need it to acquire information (ex. state of the car, range) about everything in the race

  • The process that goes into building the actual telemetry dashboard isn’t as important to the team as long as all the necessary information is there for the race

First part of Card sorting:

• Faults are important and should be identified in some form on the dashboard

  • Example: A notification or an alert badge pops up

  • Faults will completely stop the car in some cases, so even if the team can’t fix the fault on the spot, it can help them identify the issue as fast as possible based on certain factors

• Voltage, drive states, and speed are also important

• Other states are sometimes viewed, but it isn’t the main priority

• They want to get rid of the jumpstart cell (on power select)

• Current measurement readings on the rear battery are unclear

• Crucial to monitor the DCDC main battery supply and the aux

Second part of Card sorting:

• Data can be grouped based on:

  • Faults

  • Driving information

  • Power data (measurements that are taken that aren’t through the battery)

  • Main battery

  • Important statuses + Driver control statuses

  • Nice to know (less essential, misc)

MSXII related:

• The dashboard was limited, but it did enough for the race

• Constant radio communication was needed

• Telemetry was used more for debugging than for an alarm system for faults, etc.

• Having data available was good to have

  • Since we have strategy models (via strategy team), the data isn’t necessarily important to act on

  • Was easy to follow (ex. battery voltage graph, battery temperature)

• To have the longest range, constant velocity was required

• Would be nice if you can hover over graphs to see the exact values and labelling axis with units

• The last dashboard did not indicate/show faults so having an alert system in place would be nice