Dinkyness

This weekend’s Mitochondioning produced a whole bunch of virtual stuff, and the successful testing of this new shiny thing:

Yup, it’s dinky. It’s so dinky, and dinky is good. It’s an accelerometer – it measures acceleration. Your iPhone has one. If it’s sitting still, then it measures the direction of gravity, so it can be used as a tilt sensor. (In three dimensions, plus or minus not much, in about a millisecond, using less than ten milliWatts of power.)

It won’t be sitting still.

But mainly, I’m happy, coz I soldered up four wires, wrote three lines of code, and it just worked.

Having things ‘just work’ has not been a major feature of this project. In fact, I’m only using these coz I couldn’t get the ultrasonic range finder to work within the space constraints that I’ve got. Now, whether I’ll be able to write enough signal processing to get from the raw data to the information I want, that’s another question…

26 thoughts on “Dinkyness

  1. That’s very clever. So to turn it into velocity, you integrate the outputs and to measure position, you do the same again.

    The only difficulty I’d see is that the reference point will drift in time as a result of accumulated errors. So if you take your accelerometer for a walk and put it back where it was, the new measured position won’t match the old one.

    Calibration might be in order.

    1. Well, you could, or you could get a GPS that’s this big:

      Accelerometers for acceleration, GPS for location, I reckon. And as for speed, I’ve heard it said that some form of rotating cable assembly linked to a vehicle/ground interface unit possessing rotational symmetry could be used, but in my expert opinion that seems pretty unlikely to work. I think we need some form of sensor intergration processing package to combine the outputs from both the accelerometer and the GPS. Wirelessly, of course.

      (Also, the 21st Century is totally enabling the destruction of humanity by our location-aware robot overlords.)

      1. A GPS measures speed, too. (depending on the design, they can do this a bunch of ways).

        People use Kalman filters to integrate such inputs. A model aware of the constraints on the motion of what you are trying to measure is better, I believe. (I used to do this kinda stuff for work, back in the day. It was more interesting than my current job).

        1. Do you know of any simple guides to implementing a Kalman filter? Coz I could probably work it out from the Wikipedia page, but that’d take a while and make my head hurt…

        1. Yup, this coin is a prop from some long-forgotten theatre show. It’s actually about a metre across. Soldering components this size is a major problem and requires the use of phuge gas torches.

    2. Wouldn’t it be impossible to figure out actual POSITION just from an accelerometer. Just thinking… if the accelerometer was in a car that was moving at a constant speed, it wouldn’t know that it was moving.

      Then again, it would have felt the car accelerating… An interesting mind-bender. But either way, exactly as you said, a bunch of errors would surely add up and the position and orientation would keep getting more wrong and would need to be constantly calibrated. Something designed to measure change probably isn’t the best for trying to measure absolute values. This is where a GPS unit would maybe come in more handy if possible.

      Mike

        1. Yeah, the more I think about it the more it definitely makes sense. The only problem I’d see would be rotation happening in any of the axis would completely throw it off. If you could no longer assume X is actually the X axis, then plotting position would be impossible. If you had sensors that could detect the rotation too (I wonder if Three, 3-axis sensors work for that) and then your code could take that all into account… definitely.

          Mike

          1. Thinking about it, a gyrocompass, which is basically a rotation sensor (spinning rotor on gimbals that points the same way it started) is an input into most nav systems.

            I guess, like happy says, you can emulate this with two (3?) separated 3-axis accelerometers. In non-rotating motion, the values from each will be equal. As rotation happens, they will change.

          2. yeah 3 makes sense.. aligned along the different axis. If there’s just 2, then it won’t be able to detect rotation that happens along the axis made between the two sensors.

            Talking about this stuff is fun, a lot more so than working! I definitely wouldn’t have minded one of those little accelerometer boards to mess with along with my arduino to try to make some fun things (lights that change colour based on their position would be a fun one that comes to mind… everything I’ve been doing lately seems to involve lights).

          3. Or one 3-axis accelerometer and three laser-ring gyros for each rotation, which you can now get for only US$350 all up.

            Still, the datasheet doesn’t seem to show how much drift you could expect for that price.

            I am not going to do anything with this kit till I’ve completed what I already have on.

          4. Ah, have just done a bit order and am now swamped with small things in big plastic bags. I need to put stuff together and get rid of plastic bags before getting more bits.

      1. As Rich says, it can be done, and often is. You need to also detect rotation as well, hence all the 6 degrees-of-freedom units at this page. Also pls note the price.

        Still, even 10 years ago, doing this with any degree of precision required aviation-grade kit.

    3. Positioning

      FWIW, most of the autonomous vehicles use a combination of GPS and accelerometer-based dead-reckoning for their positioning. Whenever they have enough view of the sky to get a GPS position they calibrate to that, and whenever they lose lock they switch to dead-reckoning based on last known position and accelerator they know about. The accelerometer also gives them more detailed position than you can get out of non-known-reference-point GPS. The combination seems to work pretty well.

      Ewen

  2. So any more details about what this is for?

    So there’s an output for each axis and they output a voltage depending on the movement? So it’s up to the microcontroller to read these through analog inputs and actually figure out what’s going on?

    I figured it’d be an all in one unit that actually sends out data streams with values for the G forces. Still very cool though.

    Also neat that you can set the range using jumpers.. are you only expecting 1.5G’s for your application?

    Mike

    1. Purpose – nah – but 6G’s is about what I’m after.

      The kit kicks out three voltages dependent upon on acceleration, so ADCs on the microcontroller can directly read acceleration, albeit in units of something like G/mV. Okay, I then want to convert that to speed and position, but that should be trivial… except that the centre of motion is moving wrt where the accelerometers are. Proposed solution is to put two in there at some distance apart to attempt to cancel that out and still read what I want to read.

      Hmm… I really do need to sit down with a pencil and paper and work through the equations to prove to myself that this plan will work before I start on the software. But hey, we’re just at the stage of understanding what the technology can do at the mo.

        1. That’s the plan. It helps that I’ve 256 kB onboard the current test board, so can grab a decent chunk of input.

          This is also the case for the input to the audio algorythms.

    1. I attached that cable. It’s colour-coded so that there’s no confusion about which part goes in which hole. Confusion would be bad, wouldn’t you agree?

Leave a Reply

Your e-mail address will not be published. Required fields are marked *