Contributed by sean on from the taking current out for a <b>spin</b> dept.
Chris Kuethe has written an application which, by taking advantage of some unique OpenBSD features, has allowed him to turn his laptop into a race car data logger. aps(4) is a driver that utilizes the OpenBSD sensors framework to retrieve and report various statistics provided by IBM/Lenovo Thinkpads. The important ones here were the X and Y acceleration features, which provide the same functionality found in expensive accelerometer devices.
Since a typical consumer GPS will only update its data once per second, and a race car might be travelling in excess of 200 km/h, on its own, it is not capable of generating much meaningful performance data. It is even less fit to record information about turns and other sudden changes in position. Digital signal processing and sound editing fans might recognize a parallel problem: sampling frequencies too low to properly describe a signal (Nyquist/Shannon Sampling Theorem, anyone?). Since GPS receivers that can provide navigation solutions several times tend to be slightly expensive and less common than those that produce only one solution per second, and 'real' dataloggers are even more expensive, it occurred to Chris that he already had all the necessary hardware, as well as a framework for putting it to use for his task.
The beginning of a solution to the problem arrived when Marc Balmer (mbalmer@) wrote the nmea(4) driver, which is a tty interface to the NMEA line discipline. This allows the operating system to use NTP timedelta sensors in conjunction with the information retrieved from the connected GPS. In this way, it becomes possible to track the latitude and longitude of the computer itself with great accuracy.
nmea(4) was written with the knowledge that this information could be tracked by the operating system, however, the practical applications were, at the time, unknown.
Enter apsscale.
Chris wrote this utility to calibrate the output of the aps(4) sensors in his Thinkpad by measuring the pull of gravity on each edge and face. This is a necessary step because the sensors are not mounted in the same orientation in every model, and the absolute values reported by individual laptops vary quite significantly. Once a set of correction factors was calculated, they could be loaded into the kernel with sysctl(8). Once this was done, any further readings were scaled to more meaningful quantities - either G or m/s2. Combining this data with the GPS allows for the generation of accurate position information previously only available through dedicated hardware.
The work on nmea(4) and appscale is highly experimental. Interested parties who have access to the hardware mentioned are invited to contact mbalmer and ckuethe to help with testing. The appscale source is available at http://www.ualberta.ca/~ckuethe/apsscale.tgz. Chris insists that this tool is dangerous and will crash your hard drive, shave your pets and set your CPU on fire if you use it. Still, any Thinkpad owners who wish to help test the calibration routines are welcome to try it out and give feedback to ckuethe@openbsd.org.
Note that since the initial posting of apsscale, Chris has realized that aps(4) currently updates at only 2Hz (50Hz was wishful thinking) but there is work going on to change that.
The nmea driver appeared in OpenBSD-current on June 1, 2006.
(Comments are closed)
By djm@ (203.217.30.86) on
Comments
By mbalmer@ (213.189.137.178) on
Work is being done on this... For this little experiment I wrote an addition for chris to provide longitude and latitude data as sensors. But this experiment revealed that the sensors framework is likely not the right way to provide position data.
Comments
By Chris Kuethe (129.128.11.75) chris.kuethe@gmail.com on
By Chris Kuethe (129.128.11.75) chris.kuethe@gmail.com on
I'm not about to subject my laptop to more severe accelerations to determine the maximum range of the accelerometers, and as my laptop is still under warranty, I'm not cracking it open to see what chip they use.
For a drive through the Crowsnest Pass I calibrated in the shade outside the KFC in Coleman. It was quite a hot day and the interior of my car is black, so my accelerometer readings were skewed about 200fignewtons high at the end of the run.
Why temperature is a factor:
http://www.silicondesigns.com/tech.html
http://www.eng-tips.com/viewthread.cfm?qid=62710&page=9
Or google for MEMS Accelerometer..
Comments
By Yummy Snacks (24.84.108.103) on
By kokamomi (193.65.51.118) on
By MotelyFool (134.253.26.6) on
Comments
By Anonymous Coward (217.22.94.66) on
not as cool as the MacBook light saber though!
only kidding! ;)
By Chris Kuethe (129.128.11.75) chris.kuethe@gmail.com on
operating specs for my drive:
http://www.hitachigst.com/tech/techlib.nsf/products/Travelstar_7K60
200G/2ms shock
0.67G, 5-500Hz random vibration
1.0G, 5-500Hz sine wave
Yeah, maybe driving around with the disk spinning isn't such a bright idea. Consider using a CF card in a 2.5" carrier if you're going to be bouncing around a lot.
Comments
By X (81.56.211.110) on
>
> operating specs for my drive:
> http://www.hitachigst.com/tech/techlib.nsf/products/Travelstar_7K60
>
> 200G/2ms shock
> 0.67G, 5-500Hz random vibration
> 1.0G, 5-500Hz sine wave
>
> Yeah, maybe driving around with the disk spinning isn't such a bright idea. Consider using a CF card in a 2.5" carrier if you're going to be bouncing around a lot.
Use it on soekris or wrap would be cool!
is it possible ?
i will be very happy to use it for drift race
Comments
By Anonymous Coward (81.56.211.110) on
> >
> > operating specs for my drive:
> > http://www.hitachigst.com/tech/techlib.nsf/products/Travelstar_7K60
> >
> > 200G/2ms shock
> > 0.67G, 5-500Hz random vibration
> > 1.0G, 5-500Hz sine wave
> >
> > Yeah, maybe driving around with the disk spinning isn't such a bright idea. Consider using a CF card in a 2.5" carrier if you're going to be bouncing around a lot.
>
> Use it on soekris or wrap would be cool!
> is it possible ?
>
> i will be very happy to use it for drift race
with a sensor
something that could do:
http://www.driftbox.com/
Comments
By Wim (194.78.167.231) wim@kd85.com on https://kd85.com/notforsale.html
http://www.gtechpro.com/why.html
(very usefull, especially in Germany ;-)
Comments
By x (81.56.211.110) on
> with a sensor
> something that could do:
> http://www.driftbox.com/
>
>
> Nah, the only thing that comes close is the Gtech Pro, it does not depend on GPS but uses a
> triaxial accelerometer covering all three axes (x,y and z)
>
> http://www.gtechpro.com/why.html
>
> (very usefull, especially in Germany ;-)
>
Thanks wim
By Tet (82.111.147.97) undeadly@astradyne.co.uk on
Sounds familiar! Lacking the money to buy a Racepak, I ended up building a homebrew datalogger for our top fuel dragster. It's based around a Gumstix ARM board, and I write data to a CF card during the run. Even then, the vibration causes no end of problems in other ways -- batteries popping out of their holders, connectors coming loose, etc. So far, we've got decent traces for the startup, burnout and backing up. But we've yet to record anything after the hit. It's just so violent, it's shaken something loose every run so far. Next month is the European Finals, where hopefully, my latest changes will have cured the gremlins, and we'll be able to get some decent data.
By sng (12.18.141.172) on
By Chris Kuethe (129.128.11.75) chris.kuethe@gmail.com on http://www.ualberta.ca/~ckuethe/apsscale.tgz
http://www.ualberta.ca/~ckuethe/apsscale.tgz