I'm using the C++ implementation of the Madgwick Algorithim, having my sensors (accelerometer, magnetometer and gyroscope) calibrated. Everything seems to work well, but when I put the sensor in vertical position (pitch to 90 degrees) the other angles start doing weird things. This is what I get:
Matlab plot problem
In fact, the angles I get are correct, but expressed in a different way. I should get only:
Roll: 0
Pitch: 90
Yaw: -150
But I get:
Roll: -180
Pitch: 90
Yaw: 50
Both results are the same, right? My questions are:
Is this the Gimbal Lock problem?
As far as I know, Gimbal Lock should get errors in the angles, but I'm getting them OK. Is the Madgwick algorithm trying to avoid that Gimbal Lock?
No, you can not Gimbal lock a sensor, as it is a physical object that you moved.
Gimbal lock refers to a state on where if you where to move 2 angles, they would have the same effect on the rotation. It is not an error, but an specific rotation state. But if you are personally moving the object by hand, Gimbal lock is impossible. Wikipedia has a brilliant gif:
Gimbal locked airplane. When the pitch (green) and yaw (magenta) gimbals become aligned, changes to roll (blue) and yaw apply the same rotation to the airplane.
However, note that the cause of Gimbal lock may be the cause of your data: In euler angles, there are multiple sets of angles that give the exact same end point. Which one does your system gives you? you cant know. Depends on the sensor and algorithm used to give you the data.
A good way of ensuring your further maths are consistent and knowing that 2 rotations are the same is to convert your measurements into quaternions. These are unique to every rotation, and will help you better understand what rotation has happened.
Related
I am well aware of the existence of this question but mine will differ. I also know that there could be significant errors with this approach but I want to understand the configuration also theoretically.
I have some basic questions which I find hard to answer for myself clearly. There is a lot of information about accelerometers and gyroscopes but I still haven't found an explanation "from first principles" of some basic properties.
So I have a plate sensor that contains an accelerometer and gyroscope. There is also a magnetometer which I skip for now.
The accelerometer gives information in each time t about the temporary acceleration vector a = (ax, ay, az) in m/s^2 according to the fixed coordinate system to the sensor.
The gyroscope gives a 3D vector in deg/s which says the temporary speed of rotation of the three axes (Ox, Oy and Oz). From this information, one can get a rotation matrix that corresponds to an infinitesimal rotation of the coordinate system (according to the previous moment). Here is some explanation how to obtain a quaternion, that represents R.
So we know that the infinitesimal movement can be calculated considering that the acceleration is the second derivative of the position.
Imagine that your sensor is attached to your hand or leg. In the first moment we can consider its point in 3D space as (0,0,0) and the initial coordinate system also attached in this physical point. So for the very first time step we will have
r(1) = 0.5a(0)dt^2
where r is the infinitesimal movement vector, a(0) is the acceleration vector.
In each of the following steps we will use the calculations
r(t+1) = 0.5a(t)dt^2 + v(t)dt + r(t)
where v(t) is the speed vector which will be estimated in some way, for example as (r(t)-r(t-1)) / dt.
Also, after each infinitesimal movement we will have to take into account the data from the gyroscope. We will use the rotation matrix to rotate the vector r(t+1).
In this way, probably with tremendous error I will get some trajectory according to the initial coordinate system.
My queries are:
Am I principally correct with this algorithm? If not, where am I wrong?
I would very much appreciate some resources with a working example where the first principles are not skipped.
How should I proceed with using the Kalman's filter to obtain a better trajectory? In what way exactly do I pass all the IMU data (accelerometer, gyroscope and magnetometer) to the Kalman filter?
Your conceptual framework is correct, but the equations need some work. The acceleration is measured in the platform frame, which can rotate very quickly, so it is not advisable to integrate acceleration in the platform frame and rotate the position change. Rather, the accelerations are transformed into a relatively slowly rotating frame and the integration to velocity change and position change is done there. Typically a locally-level frame (e.g. North-East-Down or Wander Aziumuth) or an Earth-centered frame (ECEF or ECI). Gravity and Coriolis force must be included in the acceleration.
Derivations from first principles can be found in many references, one of my favorites is Strapdown Inertial Navigation Technology by Titterton and Weston. Derivations of the inertial navigation equations in locally-level and Earth-fixed frames are given in Chapter 3.
As you've recognized in your question - the initial velocity is an unknown constant of integration. Without some estimate of initial velocity the trajectory resulting from integrating the inertial data can be wildly wrong.
I am writing an iPhone/iPad app. I need to compute the acceleration and deceleration in the direction of travel of a vehicle traveling in close to a straight horizontal line with erratic acceleration and deceleration. I have the sequence of 3 readings from the X,Y,Z orthogonal accelerometers. But the orientation of the iphone/ipad is arbitrary and the accelerometer readings include vehicle motion and the effect of gravity. The result should be a sequence of single acceleration values which are positive or negative depending on whether the vehicle is decelerating or accelerating. The positive and negative direction is arbitrary so long as acceleration has the opposite sign to deceleration. Gravity should be factored out of the result. Some amount of variable smoothing of the result would be useful.
The solution should be as simple as possible and must be computationally efficient. The answer should be some kind of pseudo-code algorithm, C code or a sequence of equations which could easily be converted to C code. An iPhone specific solution in Objective C would be fine too.
Thanks
You will need some trigonometry for this, for example to get the magnitude you need
magn = sqrt(x*x+y*y+z*z);
to get the angle you will need atan, then c function atan2 is better
xyangel = atan2(y,x);
xymagn = sqrt(x*x+y*y);
vertangle = atan2(z,xymagn)
no how you get negative and positive magnitude is arbitrary, you could for example interpret π/2 < xyangle < 3π/2 as negative. That would be taking the sign of x for the sign of magn, but it would be equally valid to take the sign from y
It is really tough to separate gravity and motion. It's easier if you can analyze the data together with a gyroscope and compass signal.
The gyroscope measures the rate of angular rotation. Its integral is theoretically the angular orientation (plus an unknown constant), but the integral is subject to drift, so is useless on its own. The accelerometer measures angular orientation plus gravity plus linear acceleration. With some moderately complex math, you can isolate all 3 of those quantities from the 2 sensors' values. Adding the compass fixes the XY plane (where Z is gravity) to an absolute coordinate frame.
See this great presentation.
Use userAcceleration.
You don't have to figure out how to remove gravity from the accelerometer readings and how to take into accont the orientation: It is already implemeted in the Core Motion Framework.
Track the mean value of acceleration. That will give you a reference for "down". Then subtract the mean from individual readings.
You'll need to play around with the sensitivity of the mean calculation, since, e.g., making a long slow turn on a freeway will cause the mean to slowly drift outwards.
If you wanted to compensate for this, you could use GPS tracking to compute a coarse-grained global acceleration to calibrate the accelerometer. In fact, you might find that differentiating the GPS velocity reading gives a good enough absolute acceleration all by itself (I haven't tried, so I can't say).
I want to use the iPhones's accelerometer to detect motions while driving. I'm a bit confused what the accelerometer actually measures, especially when driving a curve.
As you can see in the picture, a car driving a curve causes two forces. One is the centripetal force and one is the velocity. Imagine the iPhone is placed on the dashboard with +y-axis is pointing to the front, +x-axis to the right and +z-axis to the top.
My Question is now what acceleration will be measured when the car drives this curve. Will it measure g-force on the -x-axis or will the g-force appear on the +y axis?
Thanks for helping!
UPDATE!
For thoses interested, as one of the answers suggested it measures both. The accelerometer is effected by centrifugal force and velocity resulting in an acceleration vector that is a combination of these two.
I think it will measure both. But don't forget that the sensor will measure gravity as well. So when your car is not moving, you will still get accelerometer readings. A nice talk on sensors in smartphones http://www.youtube.com/watch?v=C7JQ7Rpwn2k&feature=results_main&playnext=1&list=PL29AD66D8C4372129 (it's on android, but the same type of sensors are used in iphone).
Accelerometer measures acceleration of resultant force applied to it (velocity is not a force by the way). In this case force is F = g + w + c i.e. vector sum of gravity, centrifugal force (reaction to steering centripetal force, points from the center of the turn) and car acceleration force (a force changing absolute value of instantaneous velocity, points along the velocity vector). Providing Z axis of accelerometer always points along the gravity vector (which is rare case for actual car) values of g, w and c accelerations can be accessed in Z, X and Y coordinates respectively.
Unless you are in free fall the g-force (gravity) is always measured. If I understand your setup correctly, the g-force will appear on the z axis, the axis that is vertical in the Earth frame of reference. I cannot tell whether it will be +z or -z, it is partly convention so you will have to check it for yourself.
UPDATE: If the car is also going up/downhill then you have to take the rotation into account. In other words, there are two frames of reference: the iPhone's frame of reference and the Earth frame of reference. If you would like to deal with this situation, then please ask a new question.
I am struck with a problem. I want to convert the CMAttitude information of an iPhone to Altitude (0 to 90deg) and Azimuth (0 to 360 deg). I have googled around and hit some threads which discuss about it, but none of threads turn out with a positive answer and most of the articles discussing Quaternion and Euler angles are too much mathematics to stuff into my brain!
Is there some open source material which does this task easy? Or someone has written code to perform this conversion?
Edit:
First off, sorry for being so abstract!
Azimuth is the direction on the surface of the earth towards which the device is pointing. Like North = 0 deg, North East = 45deg, East = 90 deg, South = 180 deg and so on. Ranges between 0 deg to 360 deg:
Altitude is the angle made from the plane of the earth to an object in the sky:
Thanks,
Raj
Using CMDeviceMotion, you can get a CMAttitude object with "roll, pitch and yaw" - where for example, given a phone held in portrait mode "yaw" is "azimuth", "pitch" is the tilt of the phone with respect to ground, or zenith, and "roll" is about the vector pointing through the screen and not what you're interested in.
Things get a bit tricky because "azimuth" is a projection of the 3D magnetic vector (pointing towards the magnetic north pole) on to the flat "ground" plane, which changes depending on device orientation, but given this understanding of the terms, threads like this one should be much more understandable. If you only need your application to work in one orientation things get much simpler.
P.S. "altitude" is almost exclusively used to refer to elevation or height about a given reference (sea level, geodetic height etc). "Zenith" or "pitch" are preferable, and since you're on iOS, you should stick to their coordinate scheme: (lat, lon, alt), (pitch, yaw, roll).
I noticed a really puzzling behavior on iPhone:
If I hold the phone in the vertical, and tilt it, the compass change.
I already figured the amount it changes is the same amount it would change for the same amount of tilting if it was in horizontal (ie: suppose that a vector coming from the screen is called Y, turning around Y does not matter the attitude of the iPhone results in a compass change).
I want to compensate that, my app was not made to you hold the phone in the horizontal (although I do plan also to allow some tilting in the X axis let's call it, from like 10 degrees to 135)
But I really could not figure how iPhone calculate the heading, thus where the heading vector actually points...
After some scientific style experiments, I found:
The iPhone has magnetometer, it has 3 axis, X, that goes from left to right from the screen. Y, that goes from bottom to up. And Z, that comes from behind the phone and comes to the front.
Earth magnetic field is as expected by the laws of physics not a sphere, in the location I am (brazil), it is slanted about 30 degrees. (meaning that I have to hold the phone in a 30 degrees angle to zero 2 axis).
One possible technique to calculate north, is use cross product of a vector tangential to the magnetic field (ie: the vector the magnetometer reports to you), and gravity. The result will be a vector that points east. If you wish you can make another cross product between east and gravity, resulting in a vector that points north.
Know that iPhone sensors are quite good, and every minor fluctuation and vibration is caught, thus it is good idea to use a lowpass filter, to remove the noise from the signal.
The iPhone itself, has a complex routine to determine the "true heading", I don't figured it completely, but it uses the accelerometer in some way to compensate for tilt. You can use the accelerometer and compensate back if that is your wish, for example if the phone is tilted 70 degrees, you can change the true heading by 70 degrees too, and the result will be the phone ignoring tilting.
Also the routine of true heading, verify if the iPhone is upside down or not. If we consider it in horizontal, in front of you as 0, then more or less at 135 degrees it decides that it is upside down, flipping the results.
Note the same coordinate system also apply to the accelerometer, allowing the use of vectors operations between accelerometer and magnetometer data without much fiddling.