Open-sourced, big data knowhow meets auto racing

A few months ago, Ars took a look at how cars are getting smarter, mainly in the aid of fuelefficiency and safety. All that technology stuffed under the hood creates data, and where there’s data, there are nerds eager to analyze it.

It used to be that, unless you were a professional racing team, you had to be satisfied with the dials and gauges on your dash if you wanted to know what was going with your vehicle. But the steady drumbeat of Moore’s law has a way of democratizing technology. Data acquisition is now coming to the masses, thanks to Autosport Labs. Based in Seattle, the company is at the final stage of raising funds to develop Race Capture Pro, an open-source alternative to more expensive data gathering setups like those from TraqMate or RaceLogic.

As almost anyone who’s driven on track can tell you, if you want to go fast, the best place to start isn’t the tires or engine. It's the driver. Some drivers might be faster than others thanks to quicker reflexes or better eyesight, but as with any skill there’s more to it than natural talent. This is where data acquisition comes in. A good data acquisition system will do a number of things. GPS pinpoints exactly where the car is with sufficient resolution to see whether or not you’re using the right line. Accelerometers will record your g-forces, while other data is collected from the engine, brakes, and so on, building up a detailed portrait of exactly what the car is doing. It’s easy to talk a big game when you're sitting around in the paddock with a beer. But when your data tells you everyone else was taking a particular turn with pedal flat to the floor and you weren’t, there’s nowhere to hide.

Enlarge/ Even amateurs can do some sophisticated things with data capture these days. This graph shows that I am much kinder to the brakes than my teammates!

Paul Kruse

Race Capture Pro will do all of the above, but the most exciting feature is the possibility of real-time telemetry. With most current systems, you have to wait until a pitstop, or even the end of the race, before you can pull the flash card and get your data. For solo drivers, this isn’t much of a problem. Data analysis, like texting, is best left until you’re not behind the wheel. But for team activities, like the ever more popular Chumpcar and Lemons grassroots racing series, this will be a huge boon. Race Capture Pro uses bluetooth to feed data to an Android phone, and from there, to the Internet. The Android app will also function as a dash display, providing useful info like lap time deltas (how much faster or slower the current lap is compared to a reference). Brent Picasso, Autosport Labs’ founder, also tells me Google Glass integration should also be possible (that's something I very much want to see).

If you’ve ever spent time at a track day or grassroots event, you can’t help but notice IT-types are heavily represented in the paddock. Autosport Labs is aiming Race Capture Pro directly at them by including a scripting language, called Lua, that can control the inputs and outputs on the unit. This might be for something as simple as turning on a fan based on temperature readings, or it could involve collecting data at higher resolution at a particular corner based on GPS coordinates, through to controlling the position of a wing (DRS for the masses!). If the ingenuity seen in your average Chumpcar or Lemons paddock is anything to go by, the sky is probably the limit.

If you want F1-level data gathering (like high speed linear pots on your suspension), then yeah... BIG bucks. But most of the sensors you'll care about are already there, and gyros and accelerometers are fairly inexpensive.

A lot of sensors are cheap, or already available for you to log. For brake temps I used thermocouples, which you can actually create yourself or buy cheaply. You can also use your OEM sensors if you have knowledge of the output characteristics. Other sensors can be bought at auto parts stores, for example many people use GM coolant temp or air temp sensors and the characteristics are well known.

Capturing from the ECU means knowing what codes correspond with what values, much like SNMP. If this project can aggregate the codes so you can just plug and go, I'm interested. I've been looking for a good tool to gather more data than you get from the OBD/OBD II requirements, but most of the options are expensive and involve proprietary software. The manufacturers don't publish all the codes, at least not anywhere I've been able to find.

Even though it is not a straight data collection system, this article should have mentioned all of the great work that is happening on MegaSquirt/microsquirt by Bowling and Grippo. It is an engine/vehicle management/control system that can be used to fuel inject just about anything. It has open software and is wide open for tinkering and adding new stuff. They have even gone so far as to add things like transmission control, and GPIO. Of course you can use it for data logging, but what other affordable DIY system allows you to tweak engine parameters while driving? Super cool stuff, check it out!

Do you know if it is taking measurements straight from the sensors or does it require an ECU? I would be really surprised if it did as any sandrail or purpose-built vehicle won't have one. And there are a decent amount of enthusiasts with pre-OBDII computers which really limits aftermarket data collectors. A basic one for my car costs upwards of $600, and that doesn't even cover the cost of installation or sensors like the wide-band O2.

Edit:

It looks like by default it takes regular sensor input, with an additional capability to take ECU input:

Straight from sensors. But this unit has the ability to log digital data as well, such as serial data from an ECU. But code to process that will vary from car to car, and isn't something they'll release with it. They do have plans to also log CAN data from a vehicle's OBD2 CAN bus.

Capturing from the ECU means knowing what codes correspond with what values, much like SNMP. If this project can aggregate the codes so you can just plug and go, I'm interested. I've been looking for a good tool to gather more data than you get from the OBD/OBD II requirements, but most of the options are expensive and involve proprietary software. The manufacturers don't publish all the codes, at least not anywhere I've been able to find.

The place to start with this is here : http://www.can-cia.org/. Most modern cars use some form of CAN(Controller Area Network) to communicate between various modules in the system.

There are however some issues. The first as you mentioned is that the manufactures do not necessarily publish anything about what standard they are using. You could use some kind of CAN BUS capture tool to acquire and analyze the frame to determine the standard. This could be a lot of work.

The second issue is that the broadcast rate of the signal you are after might be much slower than you want, and even if the broadcast rate is high enough, the main controller might not be updating the values that quickly. Many sensor values are only updated when the controller is not otherwise busy.

Without having in depth knowledge of the controller you are trying to capture data from it is probably not worth, less expensive and more reliable to install secondary sensors you can rely on.

I agree with Corey. However there are some sights/groups dedicated to reverse engineering the stock ECUs of various platforms. PGMFI.org for Hondas comes to mind. I think Subaru has one, maybe a few other makes.

the (additional) sensors, loggers and transmitters don't necessarily cost big bucks - there are good systems available in the rc model and hobby/educational robot scenes, with some good arduino-based options. i'm guessing the biggest obstacle to using this hardware in a full-size car without modification is the transmitter range or line of sight.

"Even amateurs can do some sophisticated things with data capture these days. This graph shows that I am much kinder to the brakes than my teammates!"

i think this reveals a pitfall of data acquisition - correctly interpreting the data. a low brake temp could mean several negatives, like not manually keeping the brakes in their operational window, over-cooling, or less kinetic energy to dissipate ( a.k.a. going slowly).

"Even amateurs can do some sophisticated things with data capture these days. This graph shows that I am much kinder to the brakes than my teammates!"

i think this reveals a pitfall of data acquisition - correctly interpreting the data. a low brake temp could mean several negatives, like not manually keeping the brakes in their operational window, over-cooling, or less kinetic energy to dissipate ( a.k.a. going slowly).

That's why you need a dataset, not just one or two points. If brake temp sensor information is being acquired, so should wheel speed, RPM, throttle position. Throw in an ambient temp sensor to adjust for a hot or cold day...

Had a college classmate who demonstrated for our industrial technology class his ability to hook his laptop into his vehicle and the ability to make adjustments to the computer. Pretty neat stuff. Forget what kind of car he had (Honda I think). His examples of adjustments was to try to decrease nock at different power levels.

Capturing from the ECU means knowing what codes correspond with what values, much like SNMP. If this project can aggregate the codes so you can just plug and go, I'm interested. I've been looking for a good tool to gather more data than you get from the OBD/OBD II requirements, but most of the options are expensive and involve proprietary software. The manufacturers don't publish all the codes, at least not anywhere I've been able to find.

others have said it, but i'll rephrase it: you tie into the wiring going to your ECU from the stock sensors. so it's not getting data from the ecu. rather, it's sharing the sensor with the ecu, and is reading directly from the sensor. of course, some sensors work differently or have different ranges than others, so it won't be a plug n play hookup, but if you're a tinkerer, you probably already have a shop manual for your car that gives you some range/test info for your sensors to go by. if you have a purpose-built car (that you built yourself), then you probably already know those ranges/etc since you had to know them to buy/setup your gauges if they didn't come with their own sending units.

my question would be - is this box smart enough to interpret data coming from hall-effect sensors (ie: many wheel-speed sensors) or just simple resistance-based sensors (temp/pressure sensors).

to the author - i'm curious where you put your thermocouple to measure brake temps? was it small enough to stick under (or JB weld to) a brake shim? obviously you can't have it on the rotor without some spiffy wireless tricks...

i've thought about taking a potentiometer from an old set of racing pedals (steering wheel got broken when i moved but pedals are fine) and attaching it to my brake pedal, feeding a little IC to control how many LEDs light up on a little bar on the dash. then do the same with the stock throttle position sensor. that way my in-car video would have throttle and brake position info on-screen, without any fancy datalogging stuff like this. this would be more useful to me than the digital brake light switch, because i left-foot brake. my miata will often lift a rear wheel in a sweeper, and then the LSD stops working since both wheels need SOME load to work. just a tiny bit of brake actually shoots me out of the corner much quicker.

to the author - i'm curious where you put your thermocouple to measure brake temps? was it small enough to stick under (or JB weld to) a brake shim? obviously you can't have it on the rotor without some spiffy wireless tricks...

The thermocouples were positioned in the caliper directly behind the piston in this case. It wasn't ideal, in theory you want to get them as close to the rotor/pad interface as possible. But it worked.

Android:WifiLapper is open-source (GPL), and does data dumps once per lap either by consumer routers or via your cell data connection. Also comes with a simple analysis app that runs a webserver so you can view your data online as it comes. It can also read from bluetooth OBD2 readers or an IOIO breakout for additional sensors.

RaceChrono is free, very feature-ful and does data over cell iirc.

Trackaroo's TrackMaster is paid, has a ton of add-ons, and so I imagine it can do data dumps as well.

RaceChrono and TrackMaster are more polished, though WifiLapper is aimed more at the ChumpCar/Enduro/LeMons user, and so is all about the telemetry sending.

Full disclaimer: I wrote WifiLapper initially, though the community does most work on it nowadays.

so it looks like you're measuring brake fluid temp at the caliper/piston. i wonder what sort of time it takes to transmit any appreciable heat through the brake pad, its backing, then thru the shims and piston to the fluid... i've taken a car around the block to bed in some new pads and then was immediately able to remove the caliper wearing only thin nitrile gloves... the pads and rotor on the other hand, not so much - they were way too hot. and no, there are no heat sink fins on that car's caliper.

so it looks like you're measuring brake fluid temp at the piston. i wonder what sort of time it takes to transmit any appreciable heat through the piston pad backing, thru the shims and piston to the fluid... i've taken a car around the block to bed in some new pads and then was immediately able to remove the caliper wearing only thin nitrile gloves... the pads and rotor on the other hand, not so much - they were way too hot.

Not sure if this is how the pros do it, but you can get I2C infrared temp sensors that go up to 350C for $20 at sparkfun: https://www.sparkfun.com/products/9570. That said, I'm not sure if that's high enough for brake temps, but you could certainly do tire temps.

The IOIO can do I2C, connects to android phones, and it's like $60.Edit: Though both wifilapper users who have tried the IOIO have said it is _extremely_ fragile. One of them managed a 14-hour enduro with one, but only after frying 5 while trying to get it wired properly. A robust pre-made box like in the article would be very nice.

so it looks like you're measuring brake fluid temp at the caliper/piston. i wonder what sort of time it takes to transmit any appreciable heat through the brake pad, its backing, then thru the shims and piston to the fluid... i've taken a car around the block to bed in some new pads and then was immediately able to remove the caliper wearing only thin nitrile gloves... the pads and rotor on the other hand, not so much - they were way too hot. and no, there are no heat sink fins on that car's caliper.

In my experience, about 3-5 seconds. Like I said, wasn't ideal, but it did give us an idea of how braking strategies of different drivers affected brake temperatures by comparison.

Also, racing is nothing like street driving, especially a short period. Eventually all the components become heat soaked and the temperature differential is reduced substantially.

so it looks like you're measuring brake fluid temp at the caliper/piston. i wonder what sort of time it takes to transmit any appreciable heat through the brake pad, its backing, then thru the shims and piston to the fluid... i've taken a car around the block to bed in some new pads and then was immediately able to remove the caliper wearing only thin nitrile gloves... the pads and rotor on the other hand, not so much - they were way too hot. and no, there are no heat sink fins on that car's caliper.

In my experience, about 3-5 seconds. Like I said, wasn't ideal, but it did give us an idea of how braking strategies of different drivers affected brake temperatures by comparison.

Also, racing is nothing like street driving, especially a short period. Eventually all the components become heat soaked and the temperature differential is reduced substantially.

i'm quite aware of the difference between street and track. i've done a few DE days, and have been autocrossing for over a decade. i don't have the spare time or income to do lemons/chumpcar. if i did, i'd be all over it. in the houston region, we've got quite a few drivers who autox their lemons/chump cars. i just wish they'd sort them out first instead of occasionally oiling the track.

i only mentioned the delay in heating different parts of the brake system because you're probably missing peaks/spikes - such as the end of long straights. however, it looks like (as long as you're also collecting other useful data) that what you have is already proving useful.

"Even amateurs can do some sophisticated things with data capture these days. This graph shows that I am much kinder to the brakes than my teammates!"

i think this reveals a pitfall of data acquisition - correctly interpreting the data. a low brake temp could mean several negatives, like not manually keeping the brakes in their operational window, over-cooling, or less kinetic energy to dissipate ( a.k.a. going slowly).

That's why you need a dataset, not just one or two points. If brake temp sensor information is being acquired, so should wheel speed, RPM, throttle position. Throw in an ambient temp sensor to adjust for a hot or cold day...

This thing would have to be stupid cheap for lemons or chump car, they frown on expensive parts that give an advantage. So if they are aiming for those series they might want to rethink it. This is not something that fits with the "junkyard racing" mantra.

All sounds cool but just something else to go wrong! I realize the reviewed hardware is primarily for racing but this stuff is happening in production vehicles more and more.

It seems like half the repairs on my vehicle nowadays are to replace some bad sensor versus having a problem with underlying item the sensor was monitoring. Some of those sensors are expensive to replace. Seems like the one in the SUV transmission cost about $400 bucks to be swapped out by Mr. Goodscrew.

All sounds cool but just something else to go wrong! I realize the reviewed hardware is primarily for racing but this stuff is happening in production vehicles more and more.

It seems like half the repairs on my vehicle nowadays are to replace some bad sensor versus having a problem with underlying item the sensor was monitoring. Some of those sensors are expensive to replace. Seems like the one in the SUV transmission cost about $400 bucks to be swapped out by Mr. Goodscrew.

difference here is that if part/all of this system fails, you can still drive. your car won't go into limp mode, and it'll handle exactly the same as it did before the failure.

unless of course you go whole-hog and use it to control dynamically adjustable aero or suspension...

also, this thing has a MUCH higher sampling rate than OBD-II stuff does, because it needs to. consider yourself lucky if your car's factory OBD-II/CAN has a sampling rate higher than 2-3hz.

also - a good part of the reason you have fewer actual mechanical failures is BECAUSE of those sensors, and sensible programming complete with failsafe (aka limp) modes. they keep the moving parts operating within design parameters so they're less likely to fail. for example - if your car loses a knock sensor, the computer can't keep timing or mixture at the optimal setting based on the fuel running through your system (especially important for performance engines which may also be flex fuel - there's a huge difference in ideal fuel/air/ignition/valve timing based on fuel octane ratings!). so if a knock sensor fails, the computer falls back to default settings (extra rich, retarded timing, etc) that should be safe for any octane fuel, so you don't run too lean and damage things like bearings, conrods, pistons, valves, etc. sure, it may foul the spark plugs a little sooner, but plugs are expendable anyway.

same for your transmission - i'd much rather change the fluid and a sensor or two for a few 100 bucks than to rebuild/replace the tranny for several K.