Looking to give himself a competitive edge, racer [Douglas Hedges] wanted to come up with a system that could give him real-time feedback on how his current performance compared to his previous fastest lap time. Armed with a Raspberry Pi and some Python libraries, he set out to add a simple telemetry system to his car. But as is often the case with these kind of projects, things just started snowballing from there.
At the most basic level, his system uses GPS position and speed information to light up a strip of RGB LEDs on the dashboard: green means he’s going faster than the previous best lap, and red means he isn’t. Any interface more complex than that would just be a distraction while he focuses on the track. But that doesn’t mean the Raspberry Pi can’t collect data for future review after the race is over.
With the basic functionality in place, [Douglas] turned his attention to collecting engine performance data. It turned out the car already had some pre-existing equipment for collecting metrics such as the air-fuel ratio and RPM, which he was able to connect to the Raspberry Pi thanks to its use of a well documented protocol. On top of that he added a Labjack U3 data acquisition system which let him pull in additional information like throttle position and coolant temperature. Grafana is used to visualize all of this data after the race, though it sounds like he’s also considering adding a cellular data connection vehicle data can be streamed out in real-time.
In the past we’ve seen onboard data collection systems make real-world races look more like their virtual counterparts, but it seems like the solution [Douglas] has come up with is more practical in the heat of the moment.
A ex-colleague of mine was pretty keen on the track and wrote an app for his prototype Nokia N95 to do his telemetry (accelerometer, magnetometer, and GPS).
He may have used the mic for engine revs too, but I guess these days you would use bt odb2.
I’m trying to do something in the same vein. No Prep RC Drag Racing is becoming very popular, but timing systems are rare and expensive. I’d like to use something like a 9DOF sensor and integrate the accelerometer data to give how long it took to go 132 feet, and the speed at the end of the run. 10Hz GPS is too slow, the runs are only 2.2 to 2.5 seconds long and the cars are going 60-70mph at the end. 30Hz would maybe work, but they start to get expensive.
Has anyone found a good way to deal with accelerometer data like this?
For the RC stuff I’d say that a gate setup would would be the cheapest/easiest/most precise. Accelerometer will have quite a bit of noise so i don’t know if it will be any better than 10hz gps.
As for the actual topic, it’s a cool project but pretty much the same feature set is found racechrono that has been existing for ages.
What would us use for sensors on the gates? Ideally, they would be single sided.
Traxxas makes the DTS gate system but it uses a laser/detector on one side and a retro-reflector on the other, and it is kind of finnicky to get set up. I can’t even find a similar laser/detector combo part like they use.
I looked into using TOF sensors, but I’m having trouble finding one that goes 10′ and has a high enough refresh rate but I struck out.
Use a gnss gps in drag mode job done. Also can export to xl spreadsheet to see data in 0.2s data points for speed accel/gforces
My first thought is could you put a wheel speed sensor on the RC car? Assuming it’s RWD you could measure how far the front wheels have gone by counting revolutions.
Alternatively maybe you could break it down into a physics problem? I ran into a similar problem when it came to calculating lap times. At 10hz GPS points logged are before & after start/finish but we want to know when the car crosses the finish line. First using trigonometry we solve the distance from start/finish to the car between the GPS points. Then it’s a simply physics equations plugging in distance, time and acceleration. Exit Speed’s laptimes are within ±0.022 seconds while on average being off by only 0.008 seconds compared to the transponder timing from a race. But you already know the distance of the drag race.
https://github.com/djhedges/exit_speed#lap-timing
https://github.com/djhedges/exit_speed/blob/master/lap_lib.py
https://physics.stackexchange.com/questions/134771/deriving-time-from-acceleration-displacement-and-initial-velocity
no Rc experience, only “real” cars. but wheels speed is no good, assuming you have some decent power, front wheels lift and rear wheels slip. if its FWD. then yeah rear speed is good, or if your car definatly keeps the front planted then front speed is good. I seem to recall some folks using an optical mouse type system to look at the ground and work out speed. I know for a fact plenty of drag cars use an optical range finder to measure when the front wheels are about to become airborne as part of the traction controll strategy. most folks rely on a time based system for drag racing and even on n/t tracks you still get a slip. just no-one else see’s it.
Yeah, unfortunately even when you are hooked up with good traction, there is some amount of wheel slip. The tires also deform quite a lot leading to a variable radius.
That is a good point on the 10Hz problem. I could do some math on the final few points to calculate acceleration and estimate the point where 132′ is. Thanks!
That sure looks like a Corrado dash to me!