OpenBSD Journal

Building accelerometers with nmea, apsscale and OpenBSD 4.

Contributed by sean on from the taking current out for a <b>spin</b> dept.

Deanna Phillips and Chris Kuethe (with help from Marc Balmer) write:

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)


Comments
  1. By djm@ (203.217.30.86) on

    Wow, that looks really cool. How accurate does the accelerometer seem? However, it doesn't seem possible to get GPS position data from nmea(4) yet - do you have a patch for this too? :)

    Comments
    1. By mbalmer@ (213.189.137.178) on

      > Wow, that looks really cool. How accurate does the accelerometer seem? However, it doesn't seem possible to get GPS position data from nmea(4) yet - do you have a patch for this too? :)

      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
      1. By Chris Kuethe (129.128.11.75) chris.kuethe@gmail.com on

        The previous version of the logger connected to GPSD running on localhost. This was also not optimal - it could add some significant delays to logging data, but the delay was close to constant so you could always "fix it in post."

    2. By Chris Kuethe (129.128.11.75) chris.kuethe@gmail.com on

      Once calibrated, the accelerometer seems pretty reliable *at a given temperature*. Given a set of calibration factors that cause the accelerometer to read 0-1000fignewtons for 0-1G, my laptop will happily hold 0+/-3fignewtons (ie. +/- 0.003g) sitting on my desk. I wonder how much of that wobble is due to vibration from the fan, the hard disk and all the other stuff in my office.

      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
      1. By Yummy Snacks (24.84.108.103) on

        The solution to this is simple -- in hotter weather, eat more fig newtons.

  2. By kokamomi (193.65.51.118) on

    myself being a formula one fan (and i do love how they display on-screen graphs of xy-acceleration data in f1-broadcasts), i wonder what is the interest of openbsd developers in car racing? and what kind of automotive hardware do you use for testing this new solution?

  3. By MotelyFool (134.253.26.6) on

    That is one cool application of an IBM Thinkpad.

    Comments
    1. By Anonymous Coward (217.22.94.66) on

      > That is one cool application of an IBM Thinkpad.

      not as cool as the MacBook light saber though!
      only kidding! ;)

  4. By Chris Kuethe (129.128.11.75) chris.kuethe@gmail.com on

    While this tool make no efforts to actively destroy test hardware, I did lose 3 laptop disks driving around one week.

    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
    1. By X (81.56.211.110) on

      > While this tool make no efforts to actively destroy test hardware, I did lose 3 laptop disks driving around one week.
      >
      > 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
      1. By Anonymous Coward (81.56.211.110) on

        > > While this tool make no efforts to actively destroy test hardware, I did lose 3 laptop disks driving around one week.
        > >
        > > 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
        1. By Wim (194.78.167.231) wim@kd85.com on https://kd85.com/notforsale.html

          > 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 ;-)

          Comments
          1. 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

    2. By Tet (82.111.147.97) undeadly@astradyne.co.uk on

      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.

      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.

  5. By sng (12.18.141.172) on

    I blame Canada.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]