The data sources for the telemetry system are:
The system CAN bus of the car
A GPS module attached to the raspberry pi running the telemetry system
At a minimum, the things that should be logged via telemetry are:
Battery stats (voltage, temps, state of charge, estimate of distance remaining)
Relay states (MCI, BMS HV, BMS ground, solar, charger) → need to ask what these are
kind of like a light switch: when you switch it on, the module turns on
safeties
BMS - battery management system
thing that monitors the battery packs
Solar stats (voltages, temperatures, other)
Power consumption (unsure on this, potentially able to pull data from power distribution)
Charging (current, voltage, time-to-full, etc.) → what else is in the etc lol
GPS data (initial condition + offset) → starting position, then how much you’ve travelled from there
Velocity/Speed (unsure on this)
Warnings in case something goes terribly wrong
DBC file – gives list of all the available messages that could be sent
All the data that telemetry will read
Go through this to get full list of technical requirements
pay special attention to the CAN messages
Glossary of Terms
GUI: Graphical User Interface
ETL: Extract, Transform, Load – data processing, loading it into something where you can read it
RAW: appears to be an image file format. Not sure if this refers to a data file format
AFE: Active Front End – some electrical thing. Likely not relevant
SOC: State Of Charge – the level of charge of an electric battery relative to its capacity
Basically, 0% (drained battery) to 100% (fully charged)
Discharge/bleeder resistor: discharges the electric charge stored in the capacitors when the equipment is turned off, for safety reasons
Bus (electrical): a big connector (often a bar – “busbar”) where any number of loads are connected in parallel
...
List of Technical Questions for Avery
Explain what battery modules are, and their architecture
What prevented Solar Sense from working? Was there any warning?
Go through table and explain stuff
List of Recruitment Questions for Avery
Is it one person who’s devoted to using the telemetry dashboard, or multiple?
What roles on firmware use the telemetry dashboard?
Will they be doing different things with telemetry? If so, what?
Who do you recommend we talk to?
Do you know anyone who used the MSXII dashboard?
Leads to speak to for MSXIV
Hardware – James Lin
Firmware – Ryan Dancy, Mitchell Osler
Strategy – Emma Wai
MSXII
Aaron Tan
Taiping
List of User Questions
When something goes wrong with the car, what’s the first thing you look at?
What data would be most catastrophic to miss?
Are there any indicators that tell you something is going wrong?
What data do you look at the most often?
What data is looked at the least often?
Do you have a process or checklist that you do when checking telemetry data? Tell me each step.
When you manually calculate data, can you tell me how you do it?
Use excel? By hand?
Do you throw out outliers?
What information do you need to find in order to calculate data?
How large of a dataset do you need to view?
All the data from the last x months?
X number of data points?
How do you separate datasets?
What datasets do you view at the same time? Is it important to be able to view them at the same time?
...
Title | User Story | Importance | Notes |
|---|---|---|---|
Readable Summary | The overview GUI should be legible in full screen, with all the data above the fold. | Must Have | This is critical, since all the important information should be distilled into a form where they are available at a quick glance.
|
Data Logging | All data should be logged to a database | Must Have | This is probably going to take some careful thought into table design in order to partition the tables correctly.
Most of this will be for strategy purposes during the race, which will probably operate on a week's worth of data at most (realistically probably just the previous day). I can see the data being used for ad-hoc queries after the race, in order to explore various characteristics of our design. I think this has lower priority than getting the GUI complete, as we can always log to a file and then perform ETL afterwards. |
RAW data mode | There should be a way for someone to view the raw messages if the visualization is not working (or doesn't provide that information). | Should Have | There must be a way to view the raw data (aka "Console Mode")
In CAN system, each device will send messages in binary DynamoDB converts the 1s and 0s into actual readable data
|
Speedometer reading | The GUI should display the speed | Must Have | We should have the option to switch between km/h and miles/h |
Cruise control setting | The GUI should display the currently set cruise control target | Must Have | |
Average speed over interval | The GUI should have the option of displaying the average speed over an interval (say 15 minutes) | Should Have | I found this extremely useful during ASC 2018, when choosing our cruising speed during the hilly parts. It's not critical for telemetry, but it is pretty important for strategy. I found that typically, we would end up averaging slower than our target speed by 10-15 kmph, due to the variation in road grades. |
Battery pack module stats visualization | The GUI should display the battery pack module stats (voltage, temperature) in a visualization of the pack. If there is room on the main tab to display this, that would be ideal, otherwise it can go in a separate tab. | Should Have | Personally, I would like to see something like what Kentucky or Delft has implemented. Especially with our pack layout being split into a master/slave box, I think having the telemetry GUI representation reflect that layout would be really nice. I propose that we colour code the cells (like Kentucky), and then make the individual battery modules smaller (like Delft). This physical layout visualization isn't critical for telemetry/strategy, but it helped me understand hardware faults (on the AFE) as well as which areas of the pack required additional attention. I got around this during ASC 2018 with a separate spreadsheet that I marked out the pack layout in, which I would cross-reference against my data readings. It can also help visualize the temperature distribution inside the pack. |
Total Pack Voltage | The GUI should display the total pack voltage | Must Have | This allows us to spot check SOC calculations and perform power calculations
|
Battery pack module voltage | Assumption: module is a set of cells, battery pack is the collection of modules | ||
Battery pack module temperature |
| ||
Maximum module voltage | The minimum/maximum module voltages are used to determine how unmatched modules affect our capacity when charging/discharging (the minimum module affects our capacity when discharging, and the maximum module affects our capacity when charging).
| ||
Minimum module voltage | The GUI should display the minimum module voltage. | Must Have | |
Average module voltage | During ASC 2018, I manually calculated this as the average discounting any outliers (ie. module inputs exhibiting hardware faults, unbalanced modules).
| ||
Battery pack current | Must Have | If the current is too high, something’s off
| |
Discharge resistors enabled | At FSGP/ASC 2018, there were some concerns as to whether or not the AFE could handle enabling more than 1 bleed resistor per AFE, given we had observed that the board would heat up a significant amount. A new board revision is supposed to fix this, but we should follow up with this requirement when that is completed. This would also allow provide us with an interface to remotely enable bleed resistors. This can probably go underneath a separate tab that isn't the Main Dashboard. | ||
Motor Controller Temperature | The GUI should display the motor controller temperature | Must Have |
|
Motor Controller Status Flags | The motor controller gives us the following error flags:
And the following limit flags (which determine what control loop is limiting output):
Having this would have been critical for ASC 2018, where we dealt with a lot of issues with our motor controllers. | ||
Motor Controller Bus Measurement | The GUI should display the motor controller bus current and bus voltage. |
| |
Motor Controller Velocity Measurement | |||
Motor Controller Phase Current Measurement | Motor phase current used for the 3 phase BLDC motors
| ||
Motor Voltage Vector Measurement | |||
Motor Current Vector Measurement | |||
Motor BackEMF Measurement / Prediction |
| ||
15 V & 1.65 V Voltage Rail Measurement | |||
2.5V & 1.2V Voltage Rail Measurement | |||
Fan Speed Measurement | |||
Sink & Motor Temperature Measurement | |||
Air In & CPU Temperature Measurement | |||
Air Out & Cap Temperature Measurement | |||
Odometer & Bus AmpHours Measurement | This is really useful in order to correlate telemetry data with road data. | ||
Solar Sense (MPPT) input | Since we didn't have solar sense working at ASC 2018, we resorted to measuring the current entering the pack from the BMS (by coasting). This would be useful because:
|