N/A • 12 Mar 2009 • EDITORIAL
Seasoned track racers know what it means to be able to see all their lap times, acceleration and braking points, position on track, speed, etc. While there are relatively inexpensive data loggers that can do this in varying degrees, none have what I want and none can show the data live in the pits. Live data during a race can make a big difference to a driver’s performance, and to a hopefully attentive pit crew especially if you're monitoring the health of your motor.
I am not a seasoned track racer but I have run in six 24 Hours of LeMons races, logged a bunch of track days, plus a few days of rallying. With just that little experience, I already want real-time telemetry. A quick search reveals that anything close to what I am looking for would be well beyond my meager budget. I realize the exorbitant four digit prices of these units is solely to do with the niche aspect of their use. If everyone had or wanted one, they would cost little more than an iPod or a mobile phone.
So, seeing a potential hole in the market place and having a personal desire for nothing less than real-time telemetry, I find myself investigating how one might build such a solution. It would require a couple of key components:
• A means of acquiring data from various inputs on the vehicle
• A means of transmitting that data from a moving car to another location
• A means of storing and processing the data
• A means of displaying the data in a meaningful way either live or replayed
The first step is to look at what data I want to capture and what can capture it. Here is what I would like to have available to me and my pits in real-time:
• Lap times
• Vehicle speed
• Wing position (should you make your own dynamic wing like I did)
• Throttle position
• Lateral and longitudinal forces
• Vehicle position on the track
• Air fuel ratio
• Coolant temperature
Measuring Data From The Real World
While a transponder can provide access to lap times, it can’t tell you how fast you were going and whether or not you hit the apex on turn 5. However, a good GPS system can. With resolution down to 2 meters using a 20 channel SiRFstarIII chipset with WAAS enhancements and multiple measurements, you can plot a car’s position on the track with reasonably good accuracy. There are times when GPS drifts but most of the time it is spot on. If there is unobstructed access to the sky above and a reasonably consistent ionosphere, your plots will be very precise. So I need GPS.
Next is the throttle position. In a more up to date car, OBD-II and CAN bus systems will have this data but we’re talking about LeMons racing which means cars 20 years old or more. So that’s not in the cards for the initial solution. More on CAN bus later. Instead, a slide potentiometer can be used in conjunction with throttle position to convert it into a variable voltage signal.
Acceleration forces being placed on the vehicle can help tremendously to determine the friction circle on the tires. It’s the abrupt changes in the friction circle that send you flying off the track and into the weeds. Looking for bad habits in how you move the car around the track can make a big difference. So a 3 axis accelerometer is what’s called for. It outputs 3 variable voltage signals indicating the G forces left and right, front and back and up and down.
Capturing the vehicle’s vital statistics to look for trouble before it brings the car to a grinding halt can make a big difference especially in an endurance race. I am only doing basic monitoring so far: coolant temperature and air fuel ratio.
Finally, and purely for LeMons foolishness I want to capture the distance between the rear of the car and any potential tailgaters. LeMons is hair raising wheel-to-wheel racing and quite a few get just a little too aggressive for their skill level (myself included) when trying to overtake so a vain attempt to thwart tailgaters can be a bit of fun and might confuse a driver or two. The idea is to have something on the back of the car that will suddenly move to distract the following driver when they get too close. I have put two small sharks with LEDs on top of servos that rotate 180 degrees. I am in the process of upgrading this to two large sharks that thrust backwards about 18" via linear actuators.
To pull all this data into one place, I need a microcontroller that I can program to read in the data at preset intervals. I chose a microcontroller from MakingThings. I have programmed it to take samples from the various inputs 5 times per second and average them. The microcontroller will also serve a series of other functions. It outputs key data to an LCD screen for the driver. It manages the servos that react to a tailgating driver. And it actuates a set of relays that drive the wing motor based on lateral and longitudinal g forces. Most importantly it passes the gathered data to a communications module that will allow it to be transmitted to a fixed location. Timing is important so the microcontroller needs a means of fixed timing control. This is why I have chosen one that runs with a real-time operating system built around tasks that repeat at preset intervals. The microcontroller is programmed in C and is based on the ARM7 microprocessor.
From Where It Happens To Where It Needs To Be
So we have all this useful data but we need it in the pits to analyze the driver’s performance while he’s on the track. There are numerous wireless possibilities including point to point and shared public networks. I chose GSM, more specifically GPRS because it doesn’t have limitations on distance between vehicle and viewing location and the data rates are adequate for 1 second sample intervals. GPRS coverage is very good at most tracks.
GPRS does mean that I need to bundle data samples into groups and send them in small bursts. This I am doing every 10 seconds. The GPRS module maintains a persistent network and data connection but only transmits data every 10 seconds. While it is processing the next batch of data it waits for remote acknowledgement to assure the sent data has been transmitted successfully.
The unit I have chosen from Telit Communications actually combines GPRS and GPS into one unit. So it is this module that actually recieves GPS data including vehicle position and speed. It communicates with the microcontroller serially requesting all its data and then packaging it up with the GPS information and sending it over GPRS. The unit is programmed in Python and uses GPS timing registers to make it reasonably easy to maintain time integrity.
Packaging It Up
There are numerous components that now make up the telemtry unit: a data acquisition module, a communications module, an accelerometer, a serial interface, an ultrasonic range finder, a dual slide potentiometer, an LCD planel, and two servos. Putting all this together requires a lot of wiring. Also, I want it to be at least water resistant as we will race in all conditions. The orientation of the unit is important to make sure the accelerometer provides accurate readings. I also want all this gear to be viewable almost as a work of art in and of itself.
I settled on mounting the two main module boards back to back on a small piece of wood and adding the smaller components wherever they fit. I enclosed the two modules into an enclosure not much different from a tupperware container. It has a removable top for working on the unit and clasps that seal it shut. This way it will be able to withstand weather without any critical components getting wet. Despite being weather resistant, I am putting it in trunk of our track car right over the rear axle to keep it somewhere near the center of gravity of the car and most importantly to protect it in case we should ever have a rollover. It's not likely but in our last race 3 out of 100 cars flipped over so I don't want to risk it.
Back End Muscle
On the receiving end of the car's data is a co-located web server. The GPRS unit sends the data via HTTP to the web server which does the more sophisticated processing of the raw data. The web server is coupled with a database server to store the data it recieves. In addition to receiving the data from the GPRS unit, the server also validates the remote unit with a secret key and sends it configuration information everytime a new session is started.
The web server computes the lap times based on a defined window or geofence for the start/stop line. Once the car passes through the start/stop window, a new lap is created and the old one is updated with the final times and statistics. Since the GPS plot may not land directly on the start/stop line each time, the server computes the speed and distance to the start/stop line and adjusts the lap time accordingly to guarantee accuracy. Data from the other sensors is converted into the appropriate units to be presented. Timing data is analyzed and the delay from real-time is computed. So far, the average delay is about 20 seconds. I am hoping to get it down to 10.
Raw data and the processed data are stored in the database so that it can be retrieved at any time. The database is set up to distinguish between different tracks and different events and can even support multiple remote units at the same time.
Serving It Up
Now that the data is accessible to the internet, we can view it from just about anywhere. Any computer with a browser and an internet connection can access the data given the right permissions. A map of the track is shown along with the car’s path for its current lap. This will show if the driver is taking the right racing line on the track.
Complementing the map is a series of graphs that show the computed data from all the data inputs showing speed, acceleration forces, and pedal positions. An additional chart shows the times for all the completed laps. A menu allows the pit user to identify the current driver, change the current track and to pop up a window with all the laps from the current event. Clicking on a completed lap replays it on the screen as if it were live. The pit user can also send a message to the LCD display in the car with messages like “pit now” or “pit next yellow”. The messages are not meant to replace a two way radio but they make for a simple basic secondary communications.
Bells and Whistles
Again specifically for my LeMons racing, I am adding a new feature to the microcontroller. I have connected it via a series of relays to drive an old electric window motor. The window motor is set up to raise and lower a rear wing on the back of the car. The controller computes lateral g forces and braking forces and determines the best wing position and commands the window motor to that position. As g forces and braking forces increase, the wing raises up. As they decrease, it goes down. The braking forces must exceed a defined threshold to put the wing up to prevent it from moving when braking only slightly.
The idea behind a dynamically controlled wing is it can act as an air brake when slowing for the exit in the straights and add down force in the turns. The wing will not likely be fast enough on quick transition turns but in longer sweeping turns especially ones with tight exits, I expect it will add noticeable down force approaching the apex all the way through to the exit. Most importantly it will have minimal drag in the straights but will kick in under braking and then continue through the turn in, apex and follow through.
There are several features I want to add on as time goes by. The first being the ability to interface to CAN bus in modern cars. I want to be able to use it in my Audi S4 when I take it to track days. CAN bus provides a wealth of data that can be very helpful to drivers and pit crew. Engine temperatures, engine timing, lamda sensors all indicate overall engine health and can be vital to avoiding a broken car. Individual wheel speed sensors from the ABS system can indicate changes in grip. There are hundreds more to choose from. CAN bus is complicated and will take me some time to develop the interface fully. Also, different makes of cars use different higher level protocols so I might only ever get it working on a few specific platforms.
I also want to take advantage of the voice functions in the GPRS unit to allow for a two way open voice commuincations between the driver and the pit. Setting this up is complicated as it requires special circuitry between the microphone, earpiece and the communications module which I would probably have to build myself.
I plan to make it so the unit doubles as a vehicle tracking system to use off the track. Since it is GPS and GPRS enabled, it would allow you to know where your car is at all times and even potentially open a voice connection to it, disable the ignition or check on various conditions.
Finally, after a couple battle hardening race sessions with what I am now calling the "Track Shark", I will evaluate what it would take commercialize this as an inexpensive yet fully functional real-time track telemetry solution. It will take a bit of re-working but even after the cost of materials and a reasonable profit margin, the solution would still be an order of magnitude cheaper than comparable products already on the market.