11

Before I reinvent the wheel I wanted to see if anyone can share code or tips for the following:

In order to get relative position of the iPhone, one needs to

  • Set the accelerometer read rate
  • Noise filter the accelerometer response
  • Convert it to a vector
  • Low pass filter the vector to find gravity
  • Subtract gravity from the raw reading to find the user caused acceleration
  • Filter the user caused acceleration to get the frequencies you are interested in ( probably bandpass depending on the application)
  • Integrate to find relative speed
  • Integrate to find position

So what I'm hoping is that people have already written some or all of the above and can provide tips, or better yet code.

A few questions I haven't found the answer to:

What is the frequency response of the iPhone accelerometer? What hardware filters exist between the accelerometer and the analog to digital converter?

What is the fastest reading rate the accelerometer delegate can be called without duplicating reading values?

Differences in the above for the various phones?

Any good tips for designing the filters, such as cutoff frequency for separating gravity and user motion?

Any code or tips for the integration steps? Any reason to integrate in the cartesion coordinate system rather than as vector, or vise versa?

Any other experiences, tips, or information that one should know prior to implementing this?

Adam Davis
  • 91,931
  • 60
  • 264
  • 330
  • 1
    Additional notes: Yes, this is hard. Yes, one cannot get absolute position, only relative motion. Yes, drift is a big issue, especially across two integrations. Go ahead and tell me these things, especially if you have more detail and experience with them, but please don't submit an answer solely of "it can't be done" without further explanation and detail. – Adam Davis Oct 30 '10 at 02:22
  • Any luck with this lately? I'm interested in the idea. Since the double integration is so imprecise, I figured I'd have to incorporate camera data and object tracking for more detail. Definitely a lot of work. If you've written or found any useful code for this, I'd be interested in an update. – Qaz Jun 27 '14 at 19:55
  • @Qaz No, but given that there is at least one app out there that measures rooms by placing the phone on each wall, I'm guessing it's possible with the latest devices. – Adam Davis Jun 27 '14 at 20:03
  • @AdamDavis any breakthroughs in the meantime? currently working on that problem. funny thing: working on the app you have just mentioned... – David Seek Apr 26 '16 at 09:26
  • @DavidSeek I haven't looked at it in years, so I don't know if the newer iOS devices have better sensors or a better API for reading them. I've tried one of the room measuring apps, but it's fairly finicky, so I'm guessing it's not yet a solved problem. – Adam Davis Apr 26 '16 at 13:14
  • well. the one you've spoken about: "roomscan" does a pretty awesome job. I have tryed it like 20 times and it is ridiculously accurate... that's why I'm after a possible solution... – David Seek Apr 26 '16 at 13:16
  • @DavidSeek Well, please let us know what you learn! – Adam Davis Apr 26 '16 at 13:22

2 Answers2

9

As I find information out, I'll be collecting it in this answer.

Hardware

The 3GS uses an ST LIS331DL 3-axis ±2g/±8g digital accelerometer.

The iPhone 4 and iPad use an ST LIS331DLH 3-axis ±2g/±4g/±8g digital accelerometer.

They are both capable of being read at 100Hz and 400Hz, although on the iPhone 3G (under iOS 4.1) the accelerometer delegate is not called more frequently than 100Hz even if setUpdateInterval is set for faster updates. I do not know if the API permits faster updates on the iPhone 4, and Apple's documentation merely states that the maximum is determined by the hardware of the iPhone. (TBD)

The A/D converter is on the same silicon as the MEM sensor, which is good for noise immunity.

The DL version is 8 bits (3GS) while the DLH version is 12 bits (iPhone 4). The maximum bias (offset) in the DL version is twice the bias of the DLH (0.04g vs 0.02g) version.

The data sheet for the DLH reports acceleration noise density, but that value is not reported on the DL datasheet. Noise density is reasonably low at 218 μg/√Hz for the DLH.

Both sensors give either 100Hz sampling or 400Hz sampling speeds, with no custom rate. The sensor discards values if the iPhone doesn't read the output register at the set sampling rate.

The "typical" full scale value for the DL sensor is ±2.3g, but ST only guarantees that it's at least ±2g.

Temperature effects on the sensor are present and measurable, but not very significant.

TBD:

  • Is the hardware filter turned on, and what are the filtering characteristics?
  • How noisy is the power supply to the accelerometer? (Anybody just happen to have the iPhone schematic laying around?)
  • The accelerometer uses an internal clock to provide timing for the sample rate and A/D conversion. The datasheet does not indicate the accuracy, precision, or temperature sensitivity of this clock. For accurate time analysis the iPhone must use an interrupt to sense when a sample is done and record the time in the interrupt. (whether this is done or not is unknown, but it's the only way to get accurate timing information)

API

Requesting lower than 100Hz sampling rates results in getting selected samples, while discarding the rest. If a sampling rate that is not a factor of 100Hz is requested in software, the time intervals between real sensor readings cannot be even. Apple does not guarantee even sampling rates even if a factor of 100 is used.

It appears that the API provides no software filtering.

The API does scale the raw accelerometer value into a double representing Gs. The scaling factor used is unknown, and whether this is different for each phone (ie, calibrated) and whether the calibration occurs on an ongoing basis to account fo sensor drift is unknown. Online reports seem to suggest that the iPhone does re-calibrate itself on occasion when it's lying flat on a surface.

Results from simple testing suggest that the API sets the sensor to ±2g for the 3GS, which is generally fine for handheld movements.

TBD:

  • Does Apple calibrate each unit so that the UIAccelerometer reports 1G as 1G? Apple's documentation specifically warns against using the device for sensitive measurement applications.
  • Does the reported NSTimeInterval represent when the values were read from the accelerometer, or when the accelerometer interrupt indicated that new values were ready?
Community
  • 1
  • 1
Adam Davis
  • 91,931
  • 60
  • 264
  • 330
0

I'm just dealing with the same problem. The only difference to your approach is that I don't want to rely on the low pass filter to find gravity. (TBH I don't see how I can reliably tell the gravity vector from the accelerometer readings) Am trying it with the gyros right now.

Dave
  • 19
  • 1
  • welcome to Stack Overflow Q&A site. SO is not a discussion forum and this is not an answer. You would be better off starting a new question referencing this one. – McDowell Jan 15 '11 at 13:07
  • 1
    @McDowell - No offense but maybe you should read the questions first. One of them was: "Any good tips for designing the filters, such as cutoff frequency for separating gravity and user motion?" My comment/answer is that I use a different way - gyros. – Dave Jan 17 '11 at 20:14
  • fair point, I mistook this for a _me too!_ "answer." Apologies! – McDowell Jan 18 '11 at 09:36
  • @Dave Have you had any further success with this technique? I too attempted to complete this project with the gyro, and while it helped (by eliminating the need to filter for gravity) I still was unable to get reasonable results for displacement. – Adam Davis Apr 19 '12 at 07:13