Skygauge
Using .csv files in Plotjuggler
Essentially a primitive telemetry dashboard/clever workflow to create one
I talked with one of my friends who does telemetry stuff for work (for a drone, pretty cool)
“we use plotjuggler with csv telemetry files”
essentially: Throw csv files (spreadsheet with raw values) at graphing program (plotjuggler). program go whirr. program displays graphs/data visualizations
csv file = “comma separated values” file
How their drone telemetry works on a technical level:
Data comes in in byte arrays that a multi-process program parses and hands off to a different program.
That program converts the byte arrays of cbor format into csv or spreadsheets.
Then a third program takes all the telemetry related csv files and makes a big csv with all the data.
Then that big file is loaded in the plotting application
This may not exactly be how our telemetry works. The technical details don’t really matter though tbh
Basically raw data gets processed a few times into a massive spreadsheet (millions of cells), each cell with a single data entry
All the user can really see is the .csv file
This file is enormous, and functionally useless to the user. They can’t get any useful insights out of that
However, firmware has mentioned that they would like an option to see that raw data as a tab on the telemetry dashboard
Plotjuggler
The .csv spreadsheets are then imported into Plotjuggler
Open-source, so we can poke around if we wanted to
You can create plot setups, so they have a bunch of setups that load once the data itself is imported/loaded in
“we have setups for position, velocity, and accel that have targets and actual
Then ones for each of the 4 propeller block with the values for the servos and rotor rpms
then a page with PID tunings”
along with many many other plot setups
Each graph below is a “plot setup” that you can just feed data into
the data loaded in goes in that left panel and you can drag it in, make new plots on the right, and make different tabs of plots (see top for tabs)
friend seemed pretty happy with plotjuggler: didn’t have any complaints/pain points with it
does require lots of upfront configuration
Our telemetry dashboard should just be ready to go, no configuration required (verify this assumption in user interviews)
We will also require other visualizations like battery pack architecture
Features he liked
can drag to resize plots
can make timestamps line up
change colour of each line
apply filters
turn data/lines visible/invisible
automatically populates data files into the appropriate plot set ups (just keep file names the same)
otherwise, you drag and drop data into the plot setup
intuitive
dragging is bad for trackpad use – this team is in an office and have a computer mouse. Firmware will likely not have this luxury when debugging the car in the middle of some desert
dragging bad for mobility/accessibility
good to offer an alternative to drag and drop (ie right click → list of plots displayed in dropdown → select from list)
can split up an individual plot into two plots, and lay them out either horizontally or vertically
Customer/Operator Dashboard
These are some photos of the telemetry dashboard used by the customers/operators (as opposed to the development team) – this is for a totally different user and application
https://www.youtube.com/watch?v=gt8sCxkrzjg timestamps are 0:45 to 1:00 if you want to see it in action
Bottom image is the screen for the “Inspect” tab. The top image I have no idea which tab it’s on.
The lack of indication as to which tab/display mode you’re on is confusing (and bad UX)
Also note the white on yellow on the (buttons? indicators?) at the very top – contrast is too low
Good to use figma plugin contrast checkers like Stark
Yes they’re aimed at accessibility, but good contrast benefits everyone, especially if you’re a firmware member looking at the display in bright sunlight
If the top things are indicators (red = error, green = good, yellow = double check), that could be a cool way to show system status at a glance, and allow firmware to check systems status quickly
...
Getting Started - Inspo From Other Solar Car Teams
Before we start to look at boards from external sources, we wanted to focus on other team’s telemetry dashboards to get a better understanding on the dashboards as a whole. Using the Telemetry Server documentation as references for some so make sure to check that out too!
Near East University
They have cleaner lines documenting trends in their data - make sure the data can be filtered to decrease the bumps. This filtered data can also be seen down below in Stanford’s dashboards
Near East’s interpretation of their data is likely doesn’t show enough key data points but comparing these to our previous telemetry dash, it’s easier to follow at a glance (especially if we are showing many lines on one graph)
Stanford
Older Dashboard
Newer Dashboard
If you take a look at Stanford’s old board (left) in comparison to their new board (right), you can see that they didn’t utilize the space that they had available on their new board.
Instead they decided to focus more on the aesthetics. It is crucial that all the relevant data is shown first before figuring out how you want to present this on the board.
The old board may seem outdated by design, but it was easy to read already and provided everything that was required
Delft University of Technology
Currently the top ranked solar car team in the world, so let’s see what separates their telemetry dashboard from the rest of the competition
To start, unlike the other dashboards that we looked at so far, this one is split across two screens! It allows them to fit all the relevant data with several tabs at the top of the dashboard, while having enough white space and big enough text displays to be readable
They also have a tab that opens up a page for their battery and a power flow visualization that allows you to see where losses occur
MIT (Not on the Telemetry Server page) - https://fsae.mit.edu/blog/2020/11/18/my20-telemetry-system
This telemetry dash is a sample from MIT Motorsports (MY20 so pretty recent) which is engineering their Formula SAE car. Although they aren’t creating a solar car and are displaying different information from what we would want, their electric vehicle has a telemetry dash which can be used for references on in-vehicle data visualization.
For both of the displays, the text is fairly small and I think they could have gone a bit more intense in the colour contrast between background and generic text (dark grey - light grey).
MY20
Good colour contrast in their battery temperature and lap detail graphs although the data seems very condensed for the brief time period displayed on the graphs (about 3 minutes worth of data). Some data points could be aggregated for a more fluid visualization.
I like how the stats are displayed at the bottom right of the dashboard (the icons paired with the labels) although there is way too much whitespace. Could have better used their space by either including more stats or increasing the size.
MY18 - https://youtu.be/mi-mz7vBkRM
Could have used more contrast in the colours to boost usability (as seen in their MY20 dash). The legend for cell temperatures is useful but they should have added a legend as well for the cell voltage (considering there’s more than one line)?
Perhaps they could have condensed the cell temperatures graph towards the bottom to save space for other useful information
Looking at Tesla Owner APIs
This is an API scraper for pulling vehicle information from the Tesla Owner API
https://reposhub.com/python/miscellaneous/lephisto-tesla-apiscraper.html
The colour shading under the graph lines, which is a feature used in our previous dashboard, helps to track the trends in the data I believe.
The colour could have a bit more contrast on the dashboard but I think there is a really good usage of whitespace.
Colour blocking on the vehicle speed/power paired with the number provides users with 2 features to look at. If we are to have an indicator such as this, perhaps we could do some colour pairing like below:
Here is another example of a Tesla Owner API
This is another example of a Tesla dashboard sample (these aren’t professional samples and appear to be more personal projects but we can maybe use them for reference?)
Based on prior research, we know that circle/pie charts aren’t great for depicting values so we can either avoid them altogether, leave them as estimations for users, or include a little legend below with the label and value as shown above.
Since graphs with lots of data are hard to read, I kind of like the feature where you can select specific x-points on the graph which creates a little box with the timestamp and values at that time.