Design

The dashboard component of the project has 2 main uses.

The first is to record and transmit data about the car. The data will show areas of the car’s design that can be improved to squeeze every drop of performance out of the car. The project’s subteams will improve the design of the car based on the data recorded by the onboard computer. The data is retrieved from sensors on the vehicle and logged while simultaneously being displayed to the dashboard.

The second use is data while driving. Being able to easily discern information about the car in real time is indispensable while racing. With the information displayed, the driver will be able to use more of the car’s potential performance by having a much better idea of how far they can push it safely. The information also frees the driver to concentrate on driving instead of trying to guess the information themselves.

There are 4 main features of the dashboard.

The first is recording data from the onboard sensors mounted to various points on the vehicle. For example, sensors will be attached to the suspension to detect how much the suspension is compressing or decompressing. When the amount of compression of all of the wheel’s suspensions are combined, the computer can calculate a center of gravity for the vehicle. Other sensors will be used, such as those that can accurately record velocity. For some focuses of data, there will be redundant sensors in case one fails or produces inaccurate data.

The second is the processing and logging of the data. Information from the sensors isn’t useful on its own; it must be processed. There will be various sub-functions that the computer will run in real time to interpret the sensor’s recordings and create useful, accurate performance data from them.

The third is displaying the information on a screen on the dashboard. The driver will be able to easily see the most important information without being distracted from driving. As a stretch goal, the dashboard will have a sub feature to allow various configurations of the dashboard’s GUI to be used, so the driver can customize it to their liking.

The final feature is the exporting of the data to an external device. The on board computer cannot run certain analyses on the processed information by itself, and it will not be accessible to the engineers at all times. Therefore, it is important to be able to export the data, preferably wirelessly, to a device that can either run the analyses itself, or pass it on to a device that can without needing to access the computer on the vehicle.

The UI is done in Unity, because the dashboard creator wasn’t useful enough, but the Motec software that handles the connection between the SoC and the ECU is still being used. This software is called a T2 server. It can handle connections over a serial port, which will be plugged into the ECU, and output them via an API, which can be accessed by the language that Unity uses, C#. C# also has the ability to log the data and will be able to launch the python code that sends the data elsewhere over bluetooth, or possibly send it with more C#.

The hardware needs to be ordered but after a windows install on it, it should be very easy to set up the software on the device, likely nothing more than just putting the server on it via a flash drive and running it. Some additional fiddling might be required to ensure the device can be turned on without needing to get at the insides but that should not be difficult.

The UI, as said above, is developed as a 2D Unity project. Pygame wasn’t being friendly to me; whenever a sprite rotated, it would look like it was melting and then crumple up and fly off to the bottom right before crashing. Information and/or fixes on the internet were scarce and, needless to say, I ditched the program after spending several frustrating hours on just making a thing spin. Unity has worked quite well in 2D, unlike the 3D version that was already tried. The only minor issue seems to be scaling on changing resolutions due to one of the elements being anchored while the others are not. There’s only one size screen this system will be used on, though, so the problem shouldn’t cause much time to fix. Internally, each dynamic element, such as the gear text, the CoG dot and the RPM dial, is driven by a small script that reads the data from another script attached to an invisible object. That script is the script that retrieves data from the T2 server, using the server’s API.