Professional racing telemetry can get very expensive. The costs go as high as $100k per year, which is an enormous amount for small race teams and hobby drivers. I found entry-level race drivers needing a way to monitor & improve their racing skills at a reasonable price.

I explored whether it is possible to use affordable Android devices to do the job for very little money.

Race Telemetry is a tool for race teams to remotely monitor the performance of a driver. Such monitoring can lead to an improvement of the driver’s skills as well as the car set up and performance. Having access to such technology makes a big difference, but you pay the price for it. Professional Formula 1 telemetry systems cost as much as $100k a year, which is an unbelievable cost for entry-level race drivers. Then there are cheaper solutions, but they don’t provide any real-time data.

A photo of the Homola Motorsport racing team in FIA ETCC
Homola Motorsport at FIA European Touring Car Cup 2015


Honours Class Medal Winner at Edinburgh Napier University


PROJECT TIMELINE
Fall 2014 - Spring 2015

PROJECT TYPE
Dissertation at Edinburgh Napier University

SPONSOR USER
Homola Motorsport

PERSONAS
Race Driver, Race Team Director

SKILLS & TOOLS
User Centred Design, Adobe Illustrator, Omnigraffle, Balsamiq, Adobe Photoshop, HTML, PHP, CSS, JavaScript

"Could I run the telemetry on Android?"

    - Ondrej Homola

Due to my interest and work experience in motorsport, I decided to address this need. I got an idea: Can Android smartphones and tables facilitate real-time telemetry? Android devices are not so expensive and they carry the necessary technology. While at home you might use a tablet for watching Netflix, you should be able to use the same device for race events, right? A tablet has all the necessary sensors and technology - camera, GPS, motion sensors, and an Internet connection. With this in mind, I set myself a goal to research and prototype whether such telemetry system could be built and run on Android devices.

The project involved research into user needs, racing telemetry systems, data visualization, technical exploration, and most importantly the design and development of real-time communication between a race car and the pit crew. All of this by using Android devices.

Research

The project was created in cooperation with Homola Motorsport, which was in 2015 was a leading race team in the FIA European Touring Car Cup. A close relationship with this team ensured a better understanding of the needs and it provided me with the ability to test out what was later designed. By the book I could have chosen to have hobby race drivers as sponsored users, however, I realized by working closely with a semi-professional race team, I might get a lot of insights into what actual race drivers need and translate it for the smaller teams. A photo of the Homola Motorsport racing team in FIA ETCC

Insights from the Race Team Director

The price

The price is a key factor in determining which telemetry system a user will go with. Some teams can’t even afford to have a direct walkie-talkie connection with their race driver. So it has to be affordable.


Real-time delivery

If a car is equipped with a telemetry system, it traditionally does not work in real time. Instead, it would collect the data and after the race sessions, the data could be dumped into a computer program, which is used for further analysis. That is an important step for improving the car set-up, but real-time data would make things way more responsive and faster. The pit crew would be able to spot problems quickly and would be able to come up with better solutions while the driver is at a track. The team would then have the ability able to provide the driver with recommendations for a better driving line or brake balance set up. The options are endless.


The key features of real-time telemetry
If a real-time race car telemetry is being built it needs a couple of key features to make sense for the race team. A real-time onboard video is a key to observing the race driver, the behavior of the car, steering wheel inputs and the environment around the car. All of this needs to be paired with data which should be displayed close to the video. Both of these parameters help the race team to see what is going on and if something wrong goes with the car.

The insights from the Race Car Driver

While interviewing the race car driver, it became apparent that it is necessary to show also relevant data to a race driver. If there is such a display, it can’t be distracting and it needs to show as little data as possible.

"... if the engine is overheating, then I need to know!"

    - Mato Homola, the Race Driver

Professional race interior in Seat Leon TCR
Professional race interior in Seat Leon TCR

Besides the interviews, competitive research had been conducted and the following products were reviewed: Race Navigator, Torque app, Harrys Lap Timer, Dash.

Sketches

The first sketch of the Live Telemetry

According to an interview with the race team director, a real-time video is key. Therefore, it should take most of the screen, so it is immediately visible when something goes wrong with the car.

The rest of the screen would have:

  • Primary data
  • Secondary data
  • Track/Map with real-time position


Wireframes

In this stage, I have taken the early sketches and created wireframes, so I can better communicate the design and test it out. I added one step of annotating the wireframes to explicitly map the whole experience, which would be useful in further design and development stages.

Home

Wireframe of Home

Home is the first screen when the app opens up. It should have buttons for the LiveRacing features: Live Telemetry, Car Setup and Racing Screen. To add additional value to this screen, an informational board with statics should be used.

  1. Icon and name of the app
  2. Information Board with general statistics
  3. Section of Pit Crew
  4. Live Telemetry Button - on tap -> Live Telemetry
  5. Car Setup - on tap -> opens a submenu with “New entry (x1)” and “View Previous entry (x2)”
  6. Section of the Racing Car features
  7. Racing Screen Button - on tap -> Racing Screen

Live Telemetry

Wireframe of Live Telemetry

Live Telemetry - is the key feature of the app. It should display real-time data, which will be streamed from the race car.

  1. Back icon, app icon and a title of the screen - on tap -> Home
  2. Rotate icon (to landscape). Initially, it should be used only during the development stage, but it might stay if there is a space
  3. LIVE icon - should indicate if the app is connected to ‘the car’ and is receiving real time
  4. Video stream
  5. RPM
  6. Gear Indicator
  7. Speed
  8. Laptime
  9. A temperature of 'now not specified part of the car’
  10. Weather
  11. Track layout with GPS
  • x1. Live Telemetry in Landscape orientation
  • x2. Back icon, app icon and a title of the screen - on tap -> Home
  • x3. Dev icon, to rotate back to portrait

Car Setup

Wireframe of Setup

From competitive research, it became obvious that there should be a way of storing setup sheet data. What is usually written on a paper could be digitalized. This can help the team to see what the conditions looked like during previous sessions.

  1. Back icon, app icon and a title of the screen - on tap -> Home
  2. Selection section. At first select a circuit, data and then a session to get setup
  3. Car setup 
Due to the cope of this project and focus on the real-time data, Car Setup stayed in the backlog for the future updates

Racing Display

Wireframe of Racing Display

As mentioned in research, the race driver said he would need some sort of a racing display - if there is none in the race car.

  1. Back icon, app icon and a title of the screen - on tap -> Home // this button could be removed, when the app is full screen
  2. RPM diodes. The first 2 diodes should be green, then the next 2 should be orange and the last one should be red (which indicates a perfect moment to change gear)
  3. Gear Indicator
  4. Icon to shift up (might be removed)

Lo-Fi Prototype

Overview of the wireframes

After I finished wireframes for both the race driver and the pit crew, I used Balsamiq to create a sketch-like prototype for further testing. I combined both experiences into one app, so depending on what the users need, they might just switch it around.

User testing

I met with users and showed them the Balsamiq prototype. There were generally happy with the app and they have suggested a couple of minor changes.


"I need to see oil temperature"

    - Mato Homola, the Race Driver

Insights

  • The diodes should present only RPM close to the MAX RPM, race drivers don’t need to see low RPM. For instance: the 1st diode could be for instance 4800, 2nd 5000, 3rd 5100, 4th 5300, 5th 5500
  • The second orange diode should indicate a perfect time to change gear while red should mean – max RPM
  • The arrow icon, which should have indicated time to shift, is not necessary and should be removed
  • Use a Warning icon instead of the arrow icon. The Warning icon should flash is something is wrong with the car, for instance, the cooling fluid temperature is too high or too low
  • Add a bar to the bottom of the screen with a temperature of cooling fluid and oil. If the numbers are too high or low, they should have a red color.

Changes in UI

After the user meeting, I amended what the users asked for. The changes are marked red. Image of Changes UI

Mockups

I found mockups to be a great way of presenting an idea of the concept, as it gave users a feeling of a finished product. Therefore, I did some early mockups with Adobe Illustrator CC. The design process of mockups also involved user testing and a number of updates have been done.

Mockup of the Racing Display
Mockup of the Racing Display


Testing the mockup on Samsung Galaxy Tab 4
Testing the mockup on Samsung Galaxy Tab 4


Mockup in a race car
Mockup in a race car


Mockup of Home and Live Telemetry
Mockup of Home and Live Telemetry


Prototyping in code / IoT Architecture

IoT Concept of Live Racing

The image above is an initial idea of how the IoT system should look like. It might be a bit adjusted in implementation to demonstrate a working prototype. For the development purposes a street car, Citroen C4 VTR Coupe, was used.

The ECU (onboard car computer) is connected to ‘Android Device 1’ via OBDII Bluetooth Adaptor. 'Android Device 1’ uses an app called Torque to gather data from OBDII and to send the data to the cloud server.

A cloud server is based on Open Torque Viewer created by Matt Nicklay. Matt has developed a web app, which can receive data from Torque, store them in a MySQL database and display them on a website. I wanted to take his work and hack it, so it works as I needed.

Then 'Android Device 2’ in pits and 'Android Device 3’ in a race car will have an app 'Live Racing’ to access and display the data. The pit crew will use the app for Live Telemetry, to see and analyze the progress of a race/practice session. On the other hand, 'Android Device 3’ will be used as a Racing Display mounted in a dashboard, with necessary data for a race driver.

Prototyping - backend

IoT Concept of Live Racing

Creating the backend turned out to be a huge challenge. After spending a couple of days hacking Open Torque Viewer system, I managed to ‘convince’ the web app to start showing real-time data from my car! In the middle of the night, after a long coding session, I would run down to my car and test out the new features. The web app was finally able to display speed, RPM and temperatures in almost real time.

One of the requirements was to show a gear number. However, the car doesn’t send that data to OBDII. Therefore I had to talk with the race team director and he showed me a way how the gear number could be calculated. It involved a fairly complicated conversion, but after plugging it into javascript, it magically started to show the gear.

Prototyping - front end

Having done a big chunk of the back-end functionality, I started coding the front-end for both the Racing Display and Live Telemetry. The Racing Display was easier to develop because it only used data from ECU. On the other hand, the Live Telemetry needed to have a live video stream and a track layout with GPS to indicate where the race car is. Moreover, the video, with real-time data and GPS needed to be synchronized.

Racing Display Prototyping

I have started with the Racing Display. Based on my knowledge at that time, I made a decision to build the prototype using PHP, MySQL, jQuery & CSS3 and convert the final project into a hybrid app using Phone Gap.

Racing Display Prototyping

I used the Bootstrap framework in order to get the built-in responsive behavior and then I custom coded in what was necessary. The image above shows the code running on all of my testing devices: Nexus 4, Samsung Galaxy Tab 4 7", Samsung Galaxy Tab 4 10.1“.

Live Telemetry Prototyping

As mentioned above, the part of building live telemetry is extremely challenging. Not only you need to receive real-time data, but you also need to see real-time video and GPS of the race car. That is a lot of data that needs to be sent from the car to the cloud and to the Pit Crew.

Live Telemetry Prototyping

I started developing the ‘Live Telemetry’ screen. Again I used Bootstrap and for the initial stage, I used a placeholder for videos. The real-time data was sort of easy to implement as well as the map, which however needed a very frequent refresh rate.

Live Telemetry - Video Stream

After extensive research about the live streaming from Android, I made a decision to use the ‘CCTV’ apps, because they work in the same way as I need for Live Racing!

Live Telemetry - Video Stream

The app IP Webcam did the work the best and fastest. The video was only 1 second delayed on WiFi, and the sound is 3 seconds delayed. These delays were acceptable for the working prototype.

In the photo above, I have for the first time tried implementing the IP Webcam app in this project.
* 7" Samsung Tab is using this app to stream the video
* 10" Samsung Tab is displaying the video

PhoneGap

After the code was tested, the app was wrapped into a hybrid cloud using Phone Gap.

Final testing

A couple of days before the final delivery I went ahead and tested the whole experience. Below you can see what it looked like.

OBDII Bluetooth Adaptor - plugged in OBD connector / ECU, to send data to other devices
OBDII Bluetooth Adaptor - plugged in OBD connector / ECU, to send data to other devices


Live Racing App running on Samsung Tab 7
LiveRacing App running on Samsung Tab 7


IP Webcam streaming real-time video from Nexus 4
IP Webcam streaming real-time video from Nexus 4


Live Racing App - Live Telemetry - on Samsung Galaxy Tab 10 - with real-time video from Nexus 4 and Real Time Data from the car
Live Racing App - Live Telemetry - on Samsung Galaxy Tab 10 - with real-time video from Nexus 4 and Real Time Data from the car


Live Racing App - Racing Display - on Samsung Galaxy Tab 7
Live Racing App - Racing Display - on Samsung Galaxy Tab 7

Conclusion

When the project was about to finish, I took a break and reflected on the whole experience. The users liked the experience and they would use it immediately if one major problem got fixed (this especially bugged the race car driver). It was the delay. For the driver, the race display needed to be uncompromisingly in real time, no lag whatsoever, which was challenging to ensure due to the architecture and speed of the Internet connection. WiFi made the experience much faster, but let’s be honest there are not many tracks that have wifi built in around the track. For those reasons this prototype, when combating with the professional telemetry has difficulties to catch up. Those systems use long-distance radio waves, with long antennas and a bunch of sensors to transmit the data.

This prototype used only the sensors available in the Android devices which naturally wouldn’t match the real F1 implementation.

To conclude, the project started with heavy research and with the end goal to address user needs. Then a solution was designed and prototyped as a proof of concept. This project proved that, aside from the Internet connection being improved, the solution proposed would work out. I imagine if the back end was reworked with a different technology, this project could be successful in the future.

The Award

This project was awarded the Class Honors Award, for the best honors dissertation project within my school’s Interactive Media Design Faculty. The reasoning as to why the committee chose this as a winning project were: a good match of human-centered design, user experience, prototyping and implementing the project on time + delivering. Honours Class Medal Winner at Edinburgh Napier University

 

© Copyright Ondrej Homola, 2018