After designing an initial GUI, I moved to the CAN implementation as the next logical step. I specified all information that would need to me transmitted to the dashboard over CAN, chose addresses at which the various information would be sent, and documented the various units and data types that information would be sent as. I also created a spreadsheet that could keep track of the car's CAN bus as it changed (arbitration ID, byte ordering, units, special formulas, etc...), including action items to mark unimplemented or redundant information on the bus. After implementing this in the dashboard code, it was ready to be loaded onto a microprocessor to get the physical CAN bus set up.

Setting it up on the Raspberry Pi was a mostly straightforward albeit time consuming process. Essentially it just involves installing the OS, setting up auto-login, installing packages and libraries, and then setting up an auto-start script for the graphics environment, CAN bus, and the program itself. It took me about half a day to get through. Once the program was ready and the GUI was verified working, the last step was to connect it to CAN and see if the system works, at which point I could set up a boot partition to protect the SD card from corrupting during an unexpected power-off (which it will see frequently in the car).

Creating the CAN protocol and testing the connection went quite smoothly. The only two issues were a small issue in the protocol on the data unit side (a small typo in the lua script which prevented it from running properly) and a mismatch in the byte-ordering between the DAQ transmission and what the python program was expecting. Once those two issues were addressed, the system worked flawlessly and was ready to be partitioned and tested on the moving car.

The changed display program met very positive feedback from the team, with positive comments on the layout, feature set, or just general appearance. In particular, other drivers on the team applauded the new program's responsiveness compared to the old system, as it updates more smoothly due to much lower overhead from the operating system and a much simpler program. One change that was made later to further improve the smoothness was implementing threading for the CAN bus, so that a large volume of CAN messages would not stall the GUI (we had issues with this when adding a few high rate sensors to the bus for end-of-life testing). The powertrain team was also quite appreciative of the function-based oil pressure warning, as our previous system was generally unable to warn the driver save for a complete loss of oil flow throughout the system.

All of these additional features to the dashboard and its software also warranted an overhaul to the controls and interface aspects of the dashboard as well.

Firstly, the upgraded on-screen ambient warning alerts were a fantastic addition, but there was concern about their visibility in bright daylight. Most of our fall testing for the new display program had been at night where the screen was very bright and there was no glare to worry about, and although we knew that the screen was daylight visible, we worried that the ambient alert system would not be as eye-catching as it needed to be in a daytime testing or competition environment.

Therefore, I decided to implement an array of addressable LEDs as a part of the new dashboard construction. These LEDs would replace the old LED implementation and would allow for much more versatility in terms of the LED color and behavior. The whole philosophy of this new LED array was for it to catch the driver's attention and alert them if they needed to check for issues. With such a complicated car and potentially inexperienced (certainly non-professional) drivers, it would be a bit unreasonable to expect them to memorize every alert or warning light behavior, so the goal was to catch their attention using color and brightness to indicate that they needed to check the screen for warnings. 

Similarly to the philosophy for the LEDs, with the increasing number of controls on the car, adding more knobs, switches, and buttons becomes un-sustainable as a control scheme. It leads to extra wiring and a confusing layout for the driver (TR25 had big issues with this, as most drivers were unfamiliar with most of its non-essential controls). To combat this, I decided to move every single adjustable setting in the car onto a pair of rotary encoders. One encoder would select the setting, the other would adjust it. Settings would be kept track of on the dashboard and would be broadcast to their necessary destinations via CAN bus.

This came with numerous advantages as well as a few drawbacks: 

After careful planning and consideration with the team (including multiple meetings to discuss fail-safes, controls requirements, etc...), we decided to go forward with this new modular dashboard design. The LED array would be easily modifiable and we could test alert behaviors before committing to them, and the new controls scheme offered enough convenience and modularity that we were willing to work with the drawbacks.

Since the LEDs are digitally controlled, I was also able to implement brightness control so that the array would always be visible. This is important as our competition takes place in the morning/afternoon as do some of our testing sessions, but we also frequently test at night time where the default brightness would be far too distracting (we had this issue with the singular neutral LED from TR25's dashboard which would annoy drivers while they sat waiting in the car between runs).

Info-Alert Array

The alert array was designed to use a familiar layout to our previous year's iteration, but with an additional column to the left of the screen to add symmetry for the column on the right (6 LEDs in total). Behaviors are divided into rows, and the color choice is chosen specifically to reflect what the behaviors mean: the neutral indicator is white as white is a neutral color. The warnings follow the increasing severity convention of yellow, orange, red. Other informational alerts use colors that are distinct and recognizable while not overlapping.

In software, alerts have their own data type which stores the color, whether the alert should blink and how fast, and then a priority level which allows the unit to decide which alert to display if multiple share the same physical position. High priority alerts like oil pressure override everything to make sure the driver won't miss them, even despite the fact that having multiple warnings at once is fairly unlikely. This system makes sure that behaviors are easy to add and change, providing a framework for future development.

LED Tachometer

In addition to the info-alert LED array, I also included a 10-LED tachometer, as this would help build audio-visual muscle memory for the driver to help time their gear changes, and would generally add accessibility to the car for new drivers. For this, I decided to use a sides-to-center style tachometer where lights illuminate on the sides of the bar first, progressing towards the center as the engine approaches the shift RPM. The choice to do this versus the more common left-to-right style is a little complicated, but the main considerations were how far the driver turns their head for tight corners (symmetry is desirable) and the fact that this style centralizes the shift point which can help improve reaction time. For the color selection, I used a typical green (outer 4) to yellow (middle 4) to red (center 2) color schema as it provides decent contrast at different points in the RPM range. I also set all LEDs on the tachometer to begin blinking a cyan-blue color at the shift RPM, as the large contrast change also helps with the driver reaction. Other designs use different color patterns, such as Formula 1 which often uses green, red and blue, or LMP2 (specifically the Oreca 07) which uses a variety of different color schemes even on the same model of car including green, yellow, red or green, yellow and then all LEDs blue. All of that is to say that the exact tachometer setup is largely down to driver preference, but I tried to choose a setup that would work well for inexperienced drivers to help make it clear when the best time to shift is.

One other small detail to go with this is the inclusion of thresholds based on the engine gear. This will allow the driver to shift at the best RPM for each gear to keep the engine in the power band. It's a small detail as the best RPM does not change by much, but it is technically better than not including it as long as the system isn't disruptive to the driver.

The Transition to a 'VMU'

As mentioned before, the dashboard control unit does not simply display information, and the controls on the physical panel are no longer distinct from each other and from the screen. The multi-position settings on the car have all been consolidated to a single processing unit, which broadcasts them to the necessary destination (engine calculations back to the ECU, active aero and front anti-roll settings to the active aero/servo control unit, extra calculations and settings data to the data unit). Due to this, the dashboard controller was renamed to "VMU" (Vehicle Management Unit) for its TR26 iteration. 

As an additional bonus, with the implementation of digital to analog converters talking from the dashboard unit to the ECU, the traction control and fuel mix settings could be set more consistently. This also presented the opportunity to send other, more complex signals to the ECU, which was difficult before as the ECU is only able to transmit CAN signals and not receive them. Now that a real-time controller has the ability to send these signals, we have a few new easy opportunities for performance gains.

The first and easiest of these to implement is shift cut by gear. One of the major goals for TR26 was to improve the build quality and reliability of performance components compared to TR25 (which sounds like an obvious goal but we really wanted to prioritize it this year rather than seeking raw performance gains). Shift by gear is a big help to our reliability as it helps with the compromise between shift time and shifting reliability. We have difficulty shifting from first to second gear in particular, which is not helped by the fact that a failed shift between those gears puts the car into neutral. With shift by gear, we can increase the shift cut time for the first to second gear shift to make it more reliable, while at the same time decreasing the cut time for all other gears to gain some performance. I discuss cut-by-gear more on the pneumatic shifting page.

For TR26 we decided to only add cut by gear as an additional input back to the ECU, but we at least considered a few other datapoints to send including steering angle to improve traction control, and shifting commands to automate the shifting process entirely.

Gear Calculator

This is where I will take a brief aside to discuss the process of developing the gear calculator. The original classifier I used simply divided RPM by the vehicle output speed, then checked if it was close enough to a known transmission ratio (non-parametric buckets). This system worked okay, but there were two main issues: signal noise (from transmission shock loads during gear changes, throttle changes, or braking), and an anomaly in the output shaft speed sensor.

I took the data from our first few testing sessions into MATLAB to analyze what was going on, and the first thing I found was that the data anomaly was actually a sort of overflow. After around 2500 RPM of output shaft speed, the signal would wrap back around do 1250 RPM. I solved this by simply checking if the car's wheel speeds were above a certain threshold, and adding back 1375 RPM if it was less than 2000 RPM at or above that speed (I will explain why 1375 instead of 1250 shortly). Doing this resulted in a nice continuous graph for the output shaft that fixed this overflow issue from a software side, which was really the only solution due to the lack of documentation on the data types on the data unit.

For the signal noise, I tried a few different things to counteract this. First, I tried a moving window average, but this didn't end up working very well since it couldn't debounce the signal when the transmission and engine were settling after a shift quickly enough and would fluctuate. From intuition, I came up with another type of filter I would try, which uses the formula 

EWMA = EWMA(1 - (1/K)) + new_sample(1/K)

From my usage of the variable name EWMA (and the formula), you may be able to tell that this actually an Exponentially Weighted Moving Average, which I learned after I looked up the name for the formula I had derived. Even before doing any research, there were two things I liked about this filter.

1. It technically considers ALL of the previous data samples, but gives more weight to the newest one (I initially named this a "pull filter" because the new samples pull the filter to converge at a new value).

2. It always runs in O(1) time, even with a very small weight (large K). This is better than the moving window average which runs in O(K) for a K sample window.

I build a System-In-Loop simulator in MATLAB where I tested these different filter ideas using real car data we gathered from our first test with shifting. I quickly realized that K was a tradeoff between response time and accuracy, and after tweaking the bucket thresholds and trying different values of K, I was eventually able to end up with a highly accurate classifier that generalized pretty well to any data file I tried while still responding pretty fast (200-300ms or about 4-6 ticks of the dashboard). It makes a few mistakes here and there, but in all of the actually important areas (mainly during acceleration but also during downshifting) it is spot on. The mistakes it makes are largely due to shock loads in the transmission after a failed shift. Below you can see the graphs of how the classifier does with real car data. (Note that the graphs include my corrected output shaft values!)