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
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
...
Vector Measurement:
The magnitude (length) of the vector is proportionate to the amplitude of the AC wave
The direction (angle) of the vector is the phase shift of the wave (ie 2/3 pi rad)
https://www.allaboutcircuits.com/textbook/alternating-current/chpt-2/vectors-and-ac-waveforms/ ← good diagrams here
EMF: voltage
BackEMF: the fast a motor spins, the more backEMF it generates. The backEMF opposes the input EMF.
Voltage Rail: one PSU (power support unit) can produce several different voltages – each voltage is a “voltage rail”
Each rail has its own circuitry within the PSU
MPPT: maximum power point tracker – an electronic DC to DC converter that maximizes power extraction/transfer between the solar array (PV panels), and the battery bank
Overcurrent
Overvoltage
PWM
Bad Motor Position Hall Sequence
Odometer
Solar Sense
Coasting
List of Technical Questions
Explain what battery modules are, and their architecture
What prevented Solar Sense from working? Was there any warning?
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")
|
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 | |||
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 | ||
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:
|