"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 with using Android devices.
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.
Insights from the Race Team Director
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.
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 on the 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 obvious 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
Besides the interviews, competitive research had been conducted and the following products were reviewed: Race Navigator, Torque app, Harrys Lap Timer, Dash.
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
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 clearly map the whole experience, which would be useful in further design and development stages.
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.
- Icon and name of the app
- Information Board with general statistics
- Section of Pit Crew
- Live Telemetry Button - on tap -> Live Telemetry
- Car Setup - on tap -> opens a submenu with “New entry (x1)” and “View Previous entry (x2)”
- Section of the Racing Car features
- Racing Screen Button - on tap -> Racing Screen
Live Telemetry - is the key feature of the app. It should display real-time data, which will be streamed from the race car.
- Back icon, app icon and a title of the screen - on tap -> Home
- Rotate icon (to landscape). Initially, it should be used only during the development stage, but it might stay if there is a space
- LIVE icon - should indicate if the app is connected to ‘the car’ and is receiving real time
- Video stream
- Gear Indicator
- A temperature of 'now not specified part of the car’
- 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
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.
- Back icon, app icon and a title of the screen - on tap -> Home
- Selection section. At first select a circuit, data and then a session to get setup
- 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
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.
- Back icon, app icon and a title of the screen - on tap -> Home // this button could be removed, when the app is full screen
- 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 a gear)
- Gear Indicator
- Icon to shift up (might be removed)
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.
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
- 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 a 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.
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
Testing the mockup on Samsung Galaxy Tab 4
Mockup in a race car
Mockup of Home and Live Telemetry
Prototyping in code / IoT Architecture
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
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.
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.
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 a live telemetry is extremely challenging. Not only you need to receive real-time data, 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.
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 an 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!
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
After the code was tested, the app was wrapped into a hybrid cloud using Phone Gap.
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
LiveRacing App running on Samsung Tab 7
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 - Racing Display - on Samsung Galaxy Tab 7
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 delay whatsoever, which was difficult to ensure due to the architecture and a 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.
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.