On a device I want to detect a range of forces: small forces (Minimum around 0.01g) but also stronger forces like 0.1g - 0.15g.
This device will have different positions in 3d space so in order to detect the small forces I have to know its angle in order to be able to subtract 1g. Because the device can have a random position (angle position).
What I did so far: I used the MPU6050 and used a complementary filter with accel. and gyro.
It's something like:
agnleX_k+1 = 0.98*(angle_k + deltaT * gyro_k+1) + 0.02*angle_acc_k+1;
angle_acc is the angle calculated from the accel. sensor. Something like:
arctan(accelX / sqrt(accelX^2 + accelY^2 + accelZ^2 + ))
So I am interested in:
forceX_k+1 = accelX_k+1 - 1g*sin(agnleX_k+1)
The problem is:
If I want to detect a small force coming in very fast, let's say on accelX_k+1 I would want to detect a Change from 0g to 0.01g or more but in a very small time range. The problem is that my calculated angle would then also be influenced by this small and fast change of the accel. sensor although the angle haven't really changed.
I think I would have to do the angle calculation independent of the accel. sensor. Can I do something like a complementary filter with gyro and magnetometer? Would that work the same as my filter described above but just with the mag. sensor instead? Or how would you do that? I was thinking about using MPU9250.
You stated using MPU6050, which contains both an accelerometer and a gyrosocpe. You could use them independantly - get acceleration from the accelerometer and get angles from the gyroscope, and then use the angles to compensate for rotation. There is no need for the angle to depend on your accelerometer.
Using DMP library fromJeff Rowberg will do the work for you.
it can compensate gravity acceleration internally way faster that Arduino code.
Link to github
Related
I have the following issue: I'm having an Arduino + accelerometer(MMA8452Q) mounted on a bike. I'm trying to read decelerations when braking. The issue is that, due to design constraints, I can only mount the above hardware setup on the bike rider. Since the rider will change position very often the accelerometer will also change the base values I'm using for measuring decelerations (e.g. when the Z axis is perpendicular to the ground it will measure 1g, but at a different angle it will show a different value), thus rendering my code unusable.
Here are some snippets from my code:
/* Set up thresholds - 0.42g is maximum braking force the bike can do */
maximum_value = 0.7;
soft_braking = 0.4 * maximum_value;
strong_braking = 0.6 * maximum_value;
if(val > strong_braking)
{
analogWrite(ledPin, 255);
}
else if(acc > soft_braking)
{
analogWrite(ledPin, 127);
}
*val is the acceleration on the axis I'm using for measuring deceleration (after some moving average filtering).
How I can reliably compute deceleration considering that the hardware is not having a fixed position relative to the bike frame and also readings are influenced by the angle of the terrain? I'm considering using a 6DOF board (e.g. MPU6050) with a gyro and measure the angle of the board continually and adjust accelerations values based on this, but I do not know on what math I should use for this? Does anybody had the same issue or can direct me to some similar project?
You're going to have to give up on using the acceleration in a particular direction, but you can use the norm of the acceleration measurement and infer the deceleration in the forward direction by assuming that it is roughly perpendicular to the acceleration downwards.
As for mounting on the rider, I suggest a belt around the waist. This is near the center of gravity of the rider, and you can ignore shortlived accelerations from the rider moving by standing up, etc.
Don't bother trying to track the angle of the board with a gyro. The movements are so small and the uncertainties accumulate so quickly that you won't get a useful result.
For the math, let g be the acceleration due to gravity, gb be the acceleration/deceleration of the bicycle, and gx, gy, gz, be the measurements of acceleration from the device. Then by the Pytagorean theorem, the square of the acceleration
gx^2 + gy^2 + gz^2 = g^2 + gb^2
gb = sqrt(gx^2 + gy^2 + gz^2 - g^2)
I am using arduino and accelerometer MMA7341 to measure the acceleration in x direction of an oscillating metal table. But the mounting of the accelerometer is tilted by a small angle (say Q) . Is it affect the acceleration?. If it is affect the acceleration in x direction , how can correct it without changing the tilt of the acceleration sensor.
"Tilt" and "acceleration" are both the same, from the perspective of most sensors, since both measure a force, rather than an actual angle (tilt) or change in velocity (acceleration).
What you should do is make sure the object on which the sensor is mounted is "level", within the best of your ability to determine such a thing, and use the values from analogRead() or whatever else your device provides, as the "0" values.
For the MMA7341 you'll also need to calibrate your analog signals, or else use a high precision reference as input to the Aref pin, assuming you're Arduino exposes that pin.
I think this depends on what you are measuring. THe MMA7341 looks to be able to be used for acceleration as well as tilt. If you are measuring acceleration then the mounting position doesn't matter since acceleration is a change of velocity and the velocity delta will be constant regardless of orientation.
If you are measuring tilt then thats obviously different. You could theoretically measure the initial tilt and then compensate for that in your code if you wanted to of course.
I've been trying to build a filter that can successfully combine compass, geomagnetic, and gyroscopic data to produce a smooth augmented reality experience. After reading this post along with lots of discussions, I finally found out a good algorithm to correct my sensor data. Most examples I've read show how to correct accelerometers with gyroscopes, but not correct compass + accelerometer data with gyroscope. This is the algorithm I've settled upon, which works great except that I run into gimbal lock if I try to look at the scene if I'm not facing North. This algorithm is Balance Filter, only instead of only implemented in 3D
Initialization Step:
Initialize a world rotation matrix using the (noisy) accelerometer and compass sensor data (this is provided by the Android already)
Update Steps:
Integrate the gyroscope reading (time_delta * reading) for each axis (x, y, z)
Rotate the world rotation matrix using the Euler angles supplied by the integration
Find the Quaternion from the newly rotated matrix
Find the rotation matrix from the unfiltered accelerometer + compass data (using the OS provided function, I think it uses angle/axis calculation)
Get the quaternion from the matrix generated in the previous step.
Slerp between quaternion generated in step 2 (from the gyroscope), and the accelerometer data using a coefficient based on some experimental magic
Convert back to a matrix and use that to draw the scene.
My problem is that when I'm facing North and then try to look south, the whole thing blows up and it appears to be gimbal lock. After a few gimbal locks, the whole filter is in an undefined state. Searching around I hear everybody saying "Just use Quaternions" but I'm afraid it's not that simple (at least not to me) and I know there's something I'm just missing. Any help would be greatly appreciated.
The biggest reason to use quaternions is to avoid the singularity problem with Euler angles. You can directly rotate a quaternion with gyro data.
Many appologies if information is delayed or not useful specifically but may be useful to others as I found it after some research:::
a. Using a kalman (linear or non linear) filter you do following ::
Gyro to integrate the delta angle while accelerometers tell you the outer limit.
b. Euler rates are different from Gyro rate of angle change so you ll need quaternion or Euler representation::
Quaternion is non trivial but two main steps are ----
1. For Roll, pitch,yaw you get three quaternions as cos(w) +sin(v) where w is scalar part and v is vector part (or when coding just another variable)
Then simply multiply all 3 quat. to get a delta quaternion
i.e quatDelta[0] =c1c2*c3 - s1s2*s3;
quatDelta[1] =c1c2*s3 + s1s2*c3;
quatDelta[2] =s1*c2*c3 + c1*s2*s3;
quatDelta[3] =c1*s2*c3 - s1*c2*s3;
where c1,c2,c3 are cos of roll,pitch,yaw and s stands for sin of the same actually half of those gyro pre integrated angles.
2. Then just multiply by old quaternion you had
newQuat[0]=(quaternion[0]*quatDelta[0] - quaternion[1]*quatDelta[1] - quaternion[2]*quatDelta[2] - quaternion[3]*quatDelta[3]);
newQuat[1]=(quaternion[0]*quatDelta[1] + quaternion[1]*quatDelta[0] + quaternion[2]*quatDelta[3] - quaternion[3]*quatDelta[2]);
newQuat[2]=(quaternion[0]*quatDelta[2] - quaternion[1]*quatDelta[3] + quaternion[2]*quatDelta[0] + quaternion[3]*quatDelta[1]);
newQuat[3]=(quaternion[0]*quatDelta[3] + quaternion[1]*quatDelta[2] - quaternion[2]*quatDelta[1] + quaternion[3]*quatDelta[0]);
As you loop through the code it gets updated so only quatenion is a global variables not the rest
3. Lastly if you want Euler angles from them then do the following:
`euler[2]=atan2(2.0*(quaternion[0]*quaternion[1]+quaternion[2]*quaternion[3]), 1-2.0*(quaternion[1]*quaternion[1]+quaternion[2]*quaternion[2]))euler[1]=safe_asin(2.0*(quaternion[0]*quaternion[2] - quaternion[3]*quaternion[1]))euler[0]=atan2(2.0*(quaternion[0]*quaternion[3]+quaternion[1]*quaternion[2]), 1-2.0*(quaternion[2] *quaternion[2]+quaternion[3]*quaternion[3]))`
euler[1] is pitch and so on..
I just wanted to outline general steps of quaternion implementation. There may be some minor errors but I tried this myself and it works. Please note that when changing to euler angles you will get singularities also called as "Gimbal lock"
An important note here is that this is not my work but I found it over the internet and wanted to thank who ever did this priceless code...Cheers
So I have a ship, that has thrusters at the bottom and that can only use these to move forward. It can also rotate itself around its center. Its thrusters gives it acceleration, so it doesn't move at a constant velocity. What I want to do is to tell it "move to point B".
I have come up with a solution but it doesn't work very well and it doesn't rotate smoothly, it moves jerkily and it doesn't end up exactly where it should be, so I have to have a big margin of error.
Is this a normal problem, and if so is there a "standard" way of doing it? Is this an easy problem? I want to make it look like the ship is steering itself to that point, using the constraints (thrusters, rotation) the player has. This excludes just lerping it from point A to B. Or does it?
I'd love some help in solving this problem. Positions are stored in vectors, and it's a 2D problem. Just for reference I'm including my solution, which basically is accelerating the ship until and rotating it to point to the point. I think my implementation of this idea is the problem:
Vector diff = vector_sub(to_point, pos);
float angle = vector_getangle(diff);
float current_angle = vector_getangle(dir);
float angle_diff = rightrange(angle) - rightrange(current_angle);
float len = vector_getlength(diff);
// "Margin of error"
float margin = 15.0;
// Adjust direction, only if we're not stopping the next thing we do (len <= margin)
if ( len > margin && fabs(angle_diff) > 2.0 )
{
dir = vector_setangle(dir, current_angle + (angle_diff)*delta*(MY_PI) - MY_PI/2);
}
else if ( len > margin )
{
dir = vector_normalize(diff);
}
// accelerate ship (if needed)
acc.x = acc.y = speed;
acc = vector_setangle(acc, vector_getangle(dir));
if ( len <= margin )
{
// Player is within margin of error
}
If you are not looking for a very general solution that works online, then there is a simple solution. What I mean by online is continuously re-calculating the actions along the complete trajectory.
Assuming the ship is at rest at start, simply rotate it towards your target point (while still at rest). Now, your ship can reach the target by accelerating for t seconds, rotating back while in motion (for 0.5 seconds as per your constraint), and decelerating for another t seconds. If the distance between current point and destination is d, then the equation you need to solve is:
d = 0.5*a*t^2 + 0.5*a*t + 0.5*a*t^2
The first term is distance traveled while accelerating. The second term is distance traveled while rotating (v*t_rot, v=a*t, t_rot=0.5). The final term is the distance traveled while decelerating. Solve the above for t, and you have your trajectory.
If the ship is moving at start, I would first stop it (just rotate in opposite direction of its speed vector, and decelerate until at rest). Now we know how to reach destination.
The problem with offline trajectory calculation is that it is not very accurate. There is a good chance that you will end up in the vicinity of the target, but not exactly on top of it.
Let's make the problem a little more interesting: the ship cannot rotate without acceleration. Let's call this acceleration vector a_r, a vector that is at a certain angle against the ship's direction (somewhat like having a thruster at an angle at the back). Your task now is to rotate the ship and accelerate in such a direction that the speed component perpendicular to the vector connecting the current position to the target is canceled out. Instead of trying to calculate the vectors offline, I would go with an online approach with this.
The easiest thing to do would be to add the following algorithm calculated at every time interval:
Calculate the vector pointing from ship to destination.
Split your current speed vector into two components: towards the destination, and perpendicular to it.
If perpendicular speed is zero, skip 4
Start rotating towards the negative of the perpendicular vector's direction. If already looking away from it (not exact opposite, but just looking away), also fire main thruster.
This will oscillate a bit, I suspect it will also stabilize after a while. I must admit, I don't know how I would make it stop at destination.
And the final approach is to model the ship's dynamics, and try to linearize it. It will be a non-linear system, so the second step will be necessary. Then convert the model to a discrete time system. And finally apply a control rule to make it reach target point. For this, you can change your state-space from position and speed to error in position and (maybe) error in speed, and finally add a regulation control (a control loop that takes the current state, and generates an input such that the state variables will approach zero).
This last one is fairly difficult in the maths compartment, and you'd probably need to study control engineering a bit to do it. However, you'll get much better results than the above simplistic algorithm - which admittedly might not even work. In addition, you can now apply various optimization rules to it: minimize time to reach target, minimize fuel consumption, minimize distance traveled, etc.
I'm working in a project that involves gyroscopes...
I'm using Arduino and an ITG 3200 to read the data from the gyroscope. I get 3 values in deg/s for each axis (x,y,z).
My question is: How can I know the actual (physical) position or direction of the device (let's say an airplane). There has to be a math formula or something like that.
Using only the gyroscope signal (which you have to integrate numerically), you'll eventually run into trouble, due to drift. What's normally done is combining an accelerometer (for low frequency signals, i.e. drift) with a gyroscope (for high frequency signals). Here's a link few links showing more or less exactly what you want:
http://www.starlino.com/imu_guide.html
http://www.instructables.com/id/Accelerometer-Gyro-Tutorial
http://www.starlino.com/quadcopter_acc_gyro.html
Also, see these StackOverflow questions:
Combine Gyroscope and Accelerometer Data
Integrating gyro and accelerometer readings
gyro, accelerometer, magnetometer and Kalman filter
How to determine relative position using accelerometer and gyro data
We are working on a similar problem.
We found this video on YouTube especially helpful, as it came with a paper as well as an implementation (which runs on Arduino):
http://www.youtube.com/watch?v=fOSTOnQzZCI
The paper and source code:
http://code.google.com/p/imumargalgorithm30042010sohm/
In our case (getting the orientation of a remote-controlled ball), we also had to include an accelerometer and a magnetoscope.