Author Topic: 16bit inclinometer accuracy problem  (Read 1580 times)

0 Members and 1 Guest are viewing this topic.

Offline webgiorgioTopic starter

  • Regular Contributor
  • *
  • Posts: 70
  • Country: dk
16bit inclinometer accuracy problem
« on: May 21, 2020, 11:55:55 am »
https://www.st.com/en/mems-and-sensors/lsm303agr.html
LSM303AGR is described as a high accuracy 3 axis accelerometer that I use to measure the gravity acceleration and to calculate the inclination (I use it for a solar tracker). I find that the output is very unstable. The oscillations are huge, like 2 degrees. That's far from "high accuracy" in my opinion.
I think I configured the chip correctly (Normal power mode, high accuracy, 50Hz sampling), via i2c. I read at 20 Hz.
Here is a plot of the results, with the inclinometer standing still.
Am I doing something wrong or it is normal for a high accuracy digital inclinometer to be that bad?

The i2c code where I configure the chip:
Code: [Select]
void configure_inclinometer(){
  Wire.beginTransmission(0x19); // Set accel
  Wire.write(0x20);             // CTRL_REG1_A register
  Wire.write(0x47);             // 50 Hz, normal power, all 3 axis enabled. 0x47 0b0100 0111
  Wire.endTransmission();

  Wire.beginTransmission(0x19); // Set accel
  Wire.write(0x23);             // CTRL_REG4_A register
  Wire.write(0x08);             // continuous update, littleendian, 2g, high resolution, 4-wire spi //0x08 0b0000 1000
  Wire.endTransmission();
 
}
« Last Edit: May 21, 2020, 09:18:22 pm by webgiorgio »
 

Offline Alti

  • Frequent Contributor
  • **
  • Posts: 404
  • Country: 00
Re: 12bit inclinometer accuracy problem
« Reply #1 on: May 21, 2020, 01:21:10 pm »
If that is just plain white noise then you can filter out as much noise as you want, till thermal, slow changing drifts, take over. 12-bit resolution refers to the resolution of ADC converter inside. The "high accuracy" is high relative to "something". Find that "something".
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9336
  • Country: fi
Re: 12bit inclinometer accuracy problem
« Reply #2 on: May 21, 2020, 04:38:30 pm »
Some thoughts in general (didn't look at the datasheet),

What does "normal power" mean? Some IMU products require a higher-power mode for lower noise.

Average the shit out of the readings. If you need very quick response (i.e., quickly moving objects), fuse a slowly averaged gravitation vector from an accelerometer, with gyroscope integral. But I guess this isn't a problem. So just average it.

Then, increase sampling rate: rms noise is approximately the same, but now you can average more samples and still get your desired output responsitivity.

Because the sampling time itself is probably very short, if you sample at lowish sample rates, classical signal processing things apply: you are aliasing high-frequency noise (such as any vibration; even electrical noise) on your band of interest. Oversampling (using higher sampling rate than you need), then filtering and decimating, solves the problem. You can go on and design a nice gazillion-tap FIR filter if you want to for a nice brickwall response, but a simple average, say, sum the readings until you have some 128 samples summed, then divide by 128 and output a value - is nearly as good.

And, of course, average the x, y, z values separately. Calculate the angle with averaged values. I would avoid calculating the angles with noisy data, then average the angles, especially if there is any possibility you encounter a wrap-around of angles.

And wait until you have to work with magnetometers, you'll love the amount of noise and drift you see with accelerometers.

Compensating for the angular error is trivial, calibrate it once on a level surface. Thermal and aging drifts, OTOH, are your worst enemies.

There is a reason a proper module costs $200 while the chip inside costs $2. When you DIY barebones, you need to do the necessary math yourself.
« Last Edit: May 21, 2020, 04:47:25 pm by Siwastaja »
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1951
  • Country: us
Re: 16bit inclinometer accuracy problem
« Reply #3 on: May 22, 2020, 01:13:52 am »
Agree 100% with what Siwastaja said, and I'll add the following.

I designed in an ST MEMS chip a few years ago. Fought like crazy to get it to work, but finally got it settled down. Fast forward and it's time to update that design, and that particular chip was considered "not for new design" (MEMS devices seem to have very short production lifespans for some reason). So I found another suitable ST part... and could NOT get it to work. Bug after bug, problem after problem. The worst one was it could get itself into a lockup mode where its SPI/I2C interface became inoperative and there was no way to recover it (since you couldn't issue a soft reset) except power cycle the chip. Since that experience I've always incorporated the hardware to firmware-control the supply rail(s) on MEMS devices. You have been warned.

Eventually I gave up on ST MEMS devices. They abandoned customer support to their online forums. So in addition to troublesome devices, you couldn't count on applications support to get them working. Life's too short.

I revised the design again, this time using a Bosch-Sensortec part. MUCH better. The spec sheet is one of the most disorganized messes I've encountered since the STM32 MCU, but if you're patient and cross-reference all over the place the data is usually in there somewhere. That design is still in production. I did keep the hardware to power-cycle the MEMS device, though. I won't go without it again.

A few more hints:

Do not use the on-chip filters no matter how much they brag about them. I've never found a device where the on-chip filters work properly. If they work at all, they often seem to exceed the part's onboard processing capacity (this was one of the lockup conditions in the ST part mentioned above). Just do your own filtering off-chip in firmware, you'll save tons of time and frustration.

Unless you're in a cellphone or tablet, always run the part at "full power". It's usually microamps anyway and the parts operate far more reliably. The power-saving modes are too much hassle for the theoretical savings.

Definitely run the ODR as high as you can, then filter/decimate in firmware as recommended above. Usually the ODR is inversely related to the max resolution, but seriously consider just how much resolution you actually need. Just eight bits in 360 degrees is 1.41 degrees/LSB... does a solar tracker really need more accuracy than that? Let's say horizon to horizon is 180 degrees, that's ~128 increments. Hard to imagine that you can even measure the impact of "solar misalignment" of less than two degrees. In which case, you can average your raw data in its full 16 bits, and then apply filtering to that, ultimately emitting eight useful bits. You can get very reasonable performance from numbers like those.

Try to do your math in integer format. Unless you're correcting for angular misalignment in real time (in which case you'll have to do dot-product trig and you'll probably want to use floating point), you can get plenty of resolution from integer math while saving gobs of clock cycles.

My biggest tip: Don't get too frustrated. MEMS devices are like a world all their own. They're finicky and difficult, but once you get the feel for them they can work really well.

EDIT: One more thing... many MEMS devices are affected by package stress. For example, if the package is soldered to the board with some twist, that twist can cause what appears to be a DC bias (fixed nonzero output value) on one or more axes. You can experiment with this by twisting the PCB of an otherwise unmoving assembly and watching the "acceleration" values move around (!!!). One solution is to calibrate that out in each assembly. Or, another approach is to route slots in the PCB around three sides of the footprint, so the package is mounted on a sort of "tab" supported on only one side. Obviously all traces have to pass through that tab. This makes it difficult for stress from the outside world to be coupled through the PCB to the package. I ran into this on a product a while back; units would factory calibrate great but their mounting surfaces were not machined flat and imparted some torsion to the enclosure when installed. My solution in this case, rather than revise the PCB, was to deepen the amount of potting compound and change to a compound with greater Shore hardness. We had enough capacity in the enclosure that we could get the more-solid potting compound deep enough to resist stress from external mounting.

Report back!
« Last Edit: May 22, 2020, 01:55:49 am by IDEngineer »
 
The following users thanked this post: mycroft

Offline jmelson

  • Super Contributor
  • ***
  • Posts: 2852
  • Country: us
Re: 16bit inclinometer accuracy problem
« Reply #4 on: May 22, 2020, 01:40:24 am »
https://www.st.com/en/mems-and-sensors/lsm303agr.html
LSM303AGR is described as a high accuracy 3 axis accelerometer that I use to measure the gravity acceleration and to calculate the inclination
An inclinometer can't tell the difference between changes in inclination and horizontal movement.  They are basically a pendulum.  So, unless you have the thing bolted to a granite surface plate sitting on inflated inner tubes, you can't be sure it isn't picking up vibrations through the floor, etc.

Jon
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1951
  • Country: us
Re: 16bit inclinometer accuracy problem
« Reply #5 on: May 22, 2020, 01:46:09 am »
That's true but unless the horizontal movement is sustained acceleration, you can filter it out.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9336
  • Country: fi
Re: 16bit inclinometer accuracy problem
« Reply #6 on: May 22, 2020, 08:07:58 am »
I have the exact same experience as IDEngineer: a ST part required quite some work to get reliable operation out of it. Then when changed to another newer ST part which should have been pin-compatible and almost software-compatible, I never got it work properly. Changing to BOSCH part, zero issues whatsoever, just works out of box with obvious configuration.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9336
  • Country: fi
Re: 16bit inclinometer accuracy problem
« Reply #7 on: May 22, 2020, 08:20:00 am »
Also note the fundamental difference between acceleration and inclination.

An accelerometer measures the total acceleration, obviously. In an inclinometer, you would like to only measure the gravitation vector. So if the object accelerates due to external force (you touch it or move it), the indicated inclination naturally shows a wrong result, a combination of the gravitation vector and your applied acceleration vector. This is obvious if you move the object sideways. Z stays at 1.0g all the time, but there will be an X component, say 0.1g, during the acceleration; the calculated inclination isn't horizontal even though the object actually is oriented the same way during the movement.

When you stop moving it, you get the opposite deceleration. Hence, trivial way is to average over a very long time. Say, if you average over a minute, then you can do quite a lot of wiggling and still get reliable gravity vector out of it.

Now if you need even remotely quick response to actual quick changes in inclination, the only way is to add gyros to the mix. Basically, you get a gyro heading by integrating, for example:

At 1kHz:
cur_yaw = cur_yaw + yaw_rate * 1ms
cur_roll = cur_roll + roll_rate*1ms
cur_pitch = cur_pitch + pitch_rate*1ms

But this has no way to reset to the correct absolute values (the accumulators boot at zero and only track changes), and, with a cheap MEMS gyro, these drift some 2 deg / second, or maybe 0.2 deg/second if you calibrate it properly.

Now, pitch and roll can be calculated from the accelerometer (yaw naturally can't, which is a shame). Average them slowly enough, and correct the gyro roll and pitch with a small coeff, say:

roll_err = roll_from_accelerometer - cur_roll;
cur_roll = cur_roll + 0.001*roll_err;

So given these mechanical/physical reasons to average over a long time anyway, you get the reduced electrical noise as a bonus.
« Last Edit: May 22, 2020, 08:31:19 am by Siwastaja »
 

Offline webgiorgioTopic starter

  • Regular Contributor
  • *
  • Posts: 70
  • Country: dk
Re: 16bit inclinometer accuracy problem
« Reply #8 on: May 22, 2020, 09:25:33 am »
Thanks for all the hints, very interesting!
Note: the datasheet front page say "16 bit data out", but page 27 for high resolution mode says 12bit. Anyway, I get about 16300 for 1g, so it is 16 bit. (range is set to +-2g, so 2^16/4=16384).  :-//
Yes it's a solar tracker, but we need better than 0.05 degrees accuracy. The rotational axis is close to the accelerometer so the acceleration due to movement is modest (though visible and I also see additional vibrations when the structure moves).
There is some math to go from the accuracy on the accelerometer axis to the accuracy on the angle, but I won't bother you with that.
Anyway currently I get garbage out because I've garbage in, so I'm trying to improve the XYZ acceleration signals.

I'm almost sure that I configured the chip correctly, I've spend a lot of time understanding the functions and i2c commands of this chip.
It has two modes, low power and normal mode. I've set it in normal mode. Yes it takes the high power, which is a few micro A.
I've added some filtering (moving average), and it surely gets better, but filtering adds delay to the real value, which is like loosing accuracy (in the short term). So, 16 bit is just a dream unless I wait the time of the filter. See my attached image with 0.2s and 2s filter.
I've the PCB standing on a desk besides my desk. The noise on the three axis measurements are quite similar and stable, I think that it isn't related to vibrations.

Currently the chip ADC is set at 25 Hz and I read it at 20 Hz. Then I do the averaging. I am not happy of the large delay introduced by the averaging. 10 samples*50ms period means already 500 ms.
I am wondering, what about setting inclinometer's ADC and i2c's read at higher frequency?
The chip's ADC can return at 50, 100, 200, 400, 1344 Hz in the normal power mode.

Is this the Bosh part you used? (that's the only 16bit out, the others are 14 or 12 bit)
https://www.mouser.dk/ProductDetail/Bosch-Sensortec/BHA260AB?qs=YwPsRIUVAOfIt89bfYiNvA%3D%3D
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 15157
  • Country: de
Re: 16bit inclinometer accuracy problem
« Reply #9 on: May 22, 2020, 09:55:16 am »
I very much doubt a solar tracker would need 0.05 degree accuracy. The received intensity goes like the cosine of the angle to the sun. So a small error of some 5 degree would cause only some 0.5% intensity lost.

The 12 Bit / 16 Bit numbers would be the difference between the numeric resolution and the noise level: 16 bit numbers that a accurate to about 12 bit level.

The sun is moving in a rather predictable way, relatively slow and also tidal movements of the ground are not that fast. So I see to be deal with a few seconds of delay.  If mounted on something like a boat, the horizontal movement is more of a problem anyway.
 

Offline webgiorgioTopic starter

  • Regular Contributor
  • *
  • Posts: 70
  • Country: dk
Re: 16bit inclinometer accuracy problem
« Reply #10 on: May 22, 2020, 10:28:54 am »
It's a solar tracker using a parabolic mirror, 2 degree off and the focal point moves out of the receiver tube, leading to a complete loss of performance.
For the prototype on my desk I have a small DC motor, that moves at about 2 deg/s at the lowest speed.
If the angle measurement is late, I stop the movement too late, and I overshoot the target angle.
I would like to get the best out of my hardware, even if the application requires less (as the real solar tracker will move slower than my desk prototype, there is time for the average to build up a value close to the real value).
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4705
  • Country: au
  • Question Everything... Except This Statement
Re: 16bit inclinometer accuracy problem
« Reply #11 on: May 22, 2020, 10:50:08 am »
For your requirements, I am a little confused why your motors would not have servo feedback, as that would exceed your requirements,

Other sensorless multi-mirror systems tend to compare the output power / temperature vs the mirror angle,

To make your actual system work, the normal solution is a 9 axis IMU, the gyro resolves accelerometer noise by subtracting rotations, the magnetometer helps subtract accelerations, and the accelerometer cancels out the drift of the other 2.
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 15157
  • Country: de
Re: 16bit inclinometer accuracy problem
« Reply #12 on: May 22, 2020, 10:51:24 am »
For a concentrating system better tracking makes sense.

The delay due to digital filtering is perfectly predictable. So the software can compensate for this to a large part.
 

Offline hasc

  • Newbie
  • Posts: 3
  • Country: us
Re: 16bit inclinometer accuracy problem
« Reply #13 on: May 22, 2020, 11:09:55 am »
The datasheet specifies 3 mg typical for "linear acceleration RMS noise" which in terms or angle would be about 3 mrad or 0.17 deg so your first plot of inclination looks about right, I think, unless the data was filtered.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9336
  • Country: fi
Re: 16bit inclinometer accuracy problem
« Reply #14 on: May 22, 2020, 12:29:20 pm »
I fail to understand what you do with the acceleration information. No matter how accurate, you can't use it for absolute positioning in the yaw axis (rotation around the surface normal of the earth), only against the gravitation vector, i.e., roll and pitch, so your tracker is still missing an degree of freedom. What is wrong feeding back from the power output? Because this Sun thing has a track record of following the theoretical path very closely, just feedforward the motion (i.e., open loop) based on the expected path, then feedback a tiny correction parameter based on the power output.

If the whole system is moving in unexpected ways due to external interactions, you would need a truly capable IMU to track this motion. You could scan the area, finding the brightest spot, lock to it, and then start following, which would be fairly easy to do unless the thing moves regularly during operation.

Gyros solve the responsivity problem as I have explained, but seeing you are actually driving motors, not sensing externally-applied motors, why not just use encoders to measure the axle rotation? Knowing the delay from averaged accelerometer, it's trivial to add the integral of the applied motor movement during that delay, to get exact real-time result.
« Last Edit: May 22, 2020, 12:32:49 pm by Siwastaja »
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1951
  • Country: us
Re: 16bit inclinometer accuracy problem
« Reply #15 on: May 22, 2020, 07:29:58 pm »
I too think an accelerometer (here used as an inclinometer) is the wrong approach. I see this type of thing a lot, and now refer to it as follows: "You're measuring the wrong thing."

Very often this is because you're measuring some secondary effect and not the parameter you actually care about. Sometimes a secondary effect is the only option, or the most convenient (measuring electrical RMS via heat dissipation is a classic example). But here you have access to the parameter in question. Let's measure that. You'll remove a layer of abstraction (always good when measuring something) and probably get better results too.

In this application, an accelerometer/inclinometer measures acceleration relative to the center of the Earth. (I'm going to ignore the gravitational effects of the sun, moon, and large nearby geographical objects.) But what you really care about is optical alignment to the sun. Those two things not only aren't necessarily related, but their relationship changes with time. Granted that can be (mostly) predicted, at least until your device gets bumped or windblown at which time you'll need fresh calibration. But why bother when you can actually measure what you care about - the angle of the sun relative to your concentrator?

One approach - measuring power output - has already been suggested and has the elegance of using a "sensor" you already have in the system. Another technique would be to put 2-3 simple optical sensors on your device and measure the relative incident intensity. You might even be able to get away with a single sensor with a straw-like extension tube that narrows its field of view to whatever "degree" (pun intended!) you desire. Use that to close the loop around your positioning motors and you're done. Add a little dither to avoid long term drift and large scale corrections. If you need to do large-angle resyncs regularly, you could use two sensors each with differing lengths of extension tubes... start with the wide angle sensor at first to do the coarse acquisition, then use the narrow angle sensor to do the closed loop tracking.

I suspect you'll have a much better system with far less effort and tweaking by measuring what you really care about. Give it some thought and let us know what you decide.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 9336
  • Country: fi
Re: 16bit inclinometer accuracy problem
« Reply #16 on: May 23, 2020, 08:51:28 am »
A very cheap CMOS camera module (a few $, a few megapixels) could "scan" a relatively large area in milliseconds to find the brightest spot. If fast response is required, that is. If it isn't, just scan using the "sensor" you already have, the solar power thing itself.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf