Triaxial accelerometer tilt compensation - embedded

I have a board which provides acceleration values of a triaxial accelerometer (X, Y, Z: Y is the up vector). I want to get the acceleration direction in the XZ-plane. But the board may be mounted with a tilt. Can I compensate the tilt and how would I do that? I appreciate any hint. It would be nice if someone could point me into the right direction.

You need to calibrate all accelerometer products so that they know what's normally the down direction. Based on your calibration, you get the true (x,y,z) coordinates in relation to the gravity component. The calibration values have to be added/subtracted from each accelerometer read.
Alternatively (and less professionally), you could make some sort of adaptive system which continuously saves the (x,y,z) coordinates whenever there is a total acceleration of 1G +/- margins. You can then apply a median filter to the sorted samples and hopefully you'll get the real coordinates of (x,y,z) corresponding to the gravity component. In order for this to be reliable, you'd have to implement some kind of AI, so that the program learns over time and stores the likely coordinates in NVM. Otherwise the program would always fail each time you get a use case where the total acceleration is 1G in any direction.

Related

Calibration of magnetometer attached to a vehicle as Figure 8 calibration isn't possible in such scrnaroo

I was trying to find a way to calibrate a magnetometer attached to a vehicle as Figure 8 method of calibration is not really posible on vehicle.
Also removing magnetomer calibrating and fixing won't give exact results as fixing it back to vehicle introduces more hard iron distortion as it was calibrated without the vehicle environment.
My device also has a accelerometer and gps. Can I use accelerometer or gps data (this are calibrated) to automatically calibrate the magnetometer
Given that you are not happy with the results of off-vehicle calibration, I doubt that accelerometer and GPS data will help you a lot unless measured many times to average the noise (although technically it really depends on the precision of the sensors, so if you have 0.001% accelerometer you might get a very good data out of it and compensate inaccuracy of the GPS data).
From the question, I assume you want just a 2D data and you'll be using the Earth's magnetic field as a source (as otherwise, GPS wouldn't help). You might be better off renting a vehicle rotation stand for a day - it will have a steady well known angular velocity and you can record the magnetometer data for a long period of time (say for an hour, over 500 rotations or so) and then process it by averaging out any noise. Your vehicle will produce a different magnetic field while the engine is off, idle and running, so you might want to do three different experiments (or more, to deduce the engine RPM effect to the magnetic field it produces). Also, if the magnetometer is located close to the passengers, you will have additional influences from them and their devices. If rotation stand is not available (or not affordable), you can make a calibration experiment with the GPS (to use the accelerometers or not, will depend on their precision) as following:
find a large flat empty paved surface with no underground magnetic sources (walk around with your magnetometer to check) then put the
vehicle into a turn on this surface and fix the steering wheel use the cruise control to fix the speed
wait for couple of circles to ensure they are equal make a recording of 100 circles (or 500 to get better precision)
and then average the GPS noise out
You can do this on a different speed to get the engine magnetic field influence from it's RPM
I had performed a similar procedure to calibrate the optical sensor on the steering wheel to build the model of vehicle angular rotation from the steering wheel angle and current speed and that does not produce very accurate results due to the tire slipping differently on a different surface, but it should work okay for your problem.

Forward and backward movement detection with IMU

We have an embedded device mounted in a vehicle. It has accelerometer, gyrosopce and GPS sensors on board. The goal is to distinguish when vehicle is moving forward and backward (in reverse gear). Sensor's axis are aligned with vehicle's axis.
Here's our observations:
It's not enough to check direction of acceleration, because going backwards and braking while moving forward would show results in the same direction.
We could say that if GPS speed decreased 70 -> 60 km/h it was a braking event. But it becomes tricky when speed is < 20 km/h. Decrease 20 -> 10 km/h is possible when going both directions.
We can't rely on GPS angle at low speeds.
How could we approach this problem? Any ideas, articles or researches would be helpful.
You are looking for Attitude and heading reference system implementation. Here's an open source code library. It works by fusing the two data sources (IMU and GPS) to determine the location and the heading.
AHRS provides you with roll, pitch and yaw which are the angles around X, Y and Z axises of the IMU device.
There are different algorithms to do that. Examples of AHRS algorithms are Madgwick and Mahony algorithms. They will provide you with quaternion and Eurler angles which can easily help you identify the orientation of the vehicle at any time.
This is a cool video of AHRS algo running in real time.
Similar question is here.
EDIT
Without Mag data, you won't get high accuracy and your drift will increase over time.
Still, you can perform AHRS on 6DoF (Acc XYZ and Gyr XYZ) using Madgwick algorithm. You can find an implementation here. If you want to dive into the theory of things, have a look at Madgwick's internal report.
Kalman Filter could be an option to merge your IMU 6DoF with GPS data which could dramatically reduce the drift over time. But that requires a good understanding of Kalman Filters and probably custom implementation.

Distance estimation based on signal strength

I have set of data which includes position of a car and unknown emitter signal level. I have to estimate the distance based on this. Basically signal levels varies inversely to the square of distance. But when we include stuff like multipath,reflections etc we need to use a diff equation. Here come the Hata Okumura Model which can give us the path loss based on distance. However , the distance is unknown as I dont know where the emitter is. I only have access to different lat/long sets and the received signal level.
What I am asking is could you guys please guide me to techniques which would help me estimate the distance based on current pos and signal strength.All I am asking for is guidance towards a technique which might be useful.
I have looked into How to calculate distance from Wifi router using Signal Strength? but he has 3 fixed wifi signals and can use the FSPL. However in an urban environment it doesnot work.
Since the car is moving, using any diffraction model would be very difficult. The multipath environment is constantly changing due to moving car, and any reflection/diffraction model requires well-known object geometry around the car. In your problem you have moving car position time series [x(t),y(t)] which is known. You also have a time series of rough measurement of the distance between the car and the emitter [r(t)] of unknown position. You need to solve the stationary unknown emitter position (X,Y). So you have many noisy measurement with two unknown parameters to estimate. This is a classic Least Square Estimation problem. You can formulate r(ti) = sqrt((x(ti)-X)^2 + (y(ti)-Y)^2) and feed your data into this equation and do least square estimation. The data obviously is noisy due to multipath but the emitter is stationary and with overtime and during estimation process, the noise can be more or less smooth out.
Least Square Estimation

Paraview. Volume fraction and/or mass flow rate

My goal is to achieve something that was previously asked in this site (outside from SO). In this external site the questions is unanswered, and in order to give more visibility and to try to get an answer I translate it to here:
The issue is:
I have a small simulation of particles flowing through a wire mesh structure, and I'm interested in calculating the mass flow rate and volume fraction of particles at certain cross sections. I think I understand how to calculate mass flow rate by setting up small regions and dumping particle count and velocity from that region. I assume that volume fraction works in a similar fashion, except I only need to know the size of my particles and my dump region.
What I'm wondering is this - is it possible to do these things in Paraview? I can set up planes and slices and such, but I can't seem to extract much useful information out of them.
Further on down the road, what I would like to do would be to plot contours of volume fraction at certain planes, and plot the volume fraction along the vertical axis so I can see how high the particles are piling up on top of the screen, based on particle size, wire size, etc. Can Paraview do any of this?
This is a visualization issue. I don't know how make it with Paraview. The idea is count how much particles cross the slice.
My first approach was piped: DataReader | Spherical Glyph | Slice with normal fixed handly along z axis but nothing results. Also I tried to adding the filter Surface Flow and nothing too. Probably I am piping the data in a bad way.
To see the pipelining process I add an image (focus in PlotOverLine1 and its above pipes):

accelerometer measuring negative peaks of velocity

I'm writing an application for iphone4 and I'm taking values from the accelerometer to compute the current movement from a known initial position.
I've noticed a very strange behavior: often times when I walk holding the cellphone for a few meters and then I stop, I register a negative peak of overall velocity when the handset decelarates. How is that possible if I keep moving in the same direction?
To compute the variation in velocity I just do this:
delta_v = (acc_previous + acc_now)/2 * (1/(updating_frequency))
Say you are moving at a constant 10 m/s. Your acceleration is zero. Let's say, for the sake of simplicity, you sample every 1 second.
If you decelerate smoothly over a period of 0.1 seconds, you might get a reading of 100 m/s/s or you might not get a reading at all since the deceleration might fall between two windows. Your formula most likely will not detect any deceleration or if it does, you'll get two values of -50 m/s/s: (0 - 100) / 2 and then (-100 + 0) / 2. Either way you'll get the wrong final velocity.
Something similar could happen at almost any scale, All you need is a short period of high acceleration or deceleration that you happen to sample and your figures are screwed.
Numerical integration is hard. Naive numerical integration of a noisy signal will essentially always produce significant errors and drift (like what you're seeing). People have come up with all sorts of clever ways to deal with this problem, most of which require having some source of reference information other than the accelerometer (think of a Wii controller, which has not only an accelerometer, but also the thingy on top of the TV).
Note that any MEMS accelerometer is necessarily limited to reporting only a certain band of accelerations; if acceleration goes outside of that band, then you will absolutely get significant drift unless you have some way to compensate for it. On top of that, there is the fact that the acceleration is reported as a discrete quantity, so there is necessarily some approximation error as well as noise even if you do not go outside of the window. When you add all of those factors together, some amount of drift is inevitable.
Well if you move any object in one direction, there's a force involved which accelerates the object.
To make the object come to a halt again, the same force is needed in the exact opposite direction - or to be more precise, the vector of the acceleration event that happened before needs to be multiplied with -1. That's your negative peak.
Not strictly a programming answer, but then again, your question is not strictly a programming question :)
If it's going a thousand miles per hour, its acceleration is 0. If it's speeding, the acceleration is positive. If it's slowing down, the acceleration is negative.
You can use the absolute number of the velocity to invert any negative acceleration, if that's needed:
fabs(delta_v); // use abs for ints