I am working on a project using an IMU6050 (at the moment) and I am not sure if it is possible to achieve what I need with a mems type unit. I admit that I do not have a formal mathematics background that gets into Quaternions, proper math notation and such but I do have a grasp on coordinate systems and their matrix, vectors, Euler angles, roll-pitch-yaw, gimble lock...etc
Project details and what I am trying to achieve:
The system will be in a vehicle and used simply for data collection.
I need pitch angles that are NOT affected by vehicle physical acceleration and deacceleration.
I need roll angles that are NOT affected by cornering.
There is a small user display screen but that I have a handle on it.
The system needs to report accurate Roll and Pitch angles while going up and down hills, tilted in off camber while moving and accelerating/deaccelerating.
The Roll and Pitch should always be in reference to the calibrated zero plane or base calibration matrix((1,0,0),(0,1,0),(0,0,1)) as I call it.
Currently I am not in need to heading(yaw).
Currently have a Nano but will most likely be moving to something like a esp32.
What I have done and tried:
Using standard libraries MPU6050, EasyMPU6050(including MPU6050_6Axis_MotionApps_V6_12), and Kalman Filter Library and many others(these plus maybe 5 more).
-Testing input from IMU 6050 using any library that uses the MPU on the 6050 proves to be unreliable as the system will lock up after a random amount of time (3 seconds to 10 minutes) and I believe this is due to an unresolved issue with communications. I have not been able to determine if MPU output from the 6050 will provide output I can use.
Using libraries that apply complimentary, or Kalman filters do not achieve the roll and pitch that are not affected by the vehicle's acceleration. I understand the principal of how these filters are working(I think), but trying to tune the parameters never results in usable values for me.
I see projects where people are using a imu of some type or another(imu6050, 9250, Bno055..etc) for camera gimbal applications where for example motorcycle acceleration does not affect the pitch of the unit. I just don't know how exactly they are accomplishing it. Drones are another example I think that must probably deal with this same issue.
I have read many many 10+ papers on IMU and roll/pitch but I am failing to find any that relate to what I am trying to solve. Or I am not understanding something fundamental. I have also read 50+ different tutorials, threads, videos..etc over the last 2+ weeks trying to find something that relates.
I am asking:
1- Is this really possible with some degree of precision (1-2deg) using a low cost mems unit.
2 - If so - can someone can help point me in the proper direction to understand what concepts that I am missing or not understanding properly to continue with my project.
3 - I have found several threads about the I2c-imu lock up issue and it seems that there has not been a solution found for it yet. I have not gone into detail here about it because I am not sure it solves my issue anyhow.
I think you can get near 1-2 degrees accuracy with medium priced MEMS sensors.
See below.
There is never a lock up and the I2C works always 100% if it is done right. It must be done right, because the I2C bus is not a fault tolerant bus. If you have troubles with the I2C bus, then assume that there are four to ten major problems with it (not kidding).
The MPU-6050 is noisy and outdated and your MPU-6050 might not be the real one.
Arduino user @jremington put some serious work into this: https://github.com/jremington/LSM9DS1-AHRS. You need to calibrate the sensor.
The Nano is a 5V board, and the ESP32 is a 3.3V board. Most sensors are 3.3V sensors, so it is much easier to use a 3.3V board. Don't try the 5V board first, because you could damage the sensor. I'm not talking about the power to the sensor, but about trying to push a signal of 5V into the SDA and SCL pins of the sensor.
You have to know about pullup resistors of the I2C bus. I prefer a sink current of 1...3mA. Suppose the voltage is 3.3V and the sink current (to make the signal low) is 2mA, then all the pullup resistors combined is 1650 Ω, that would be pullup resistors of 1k5 or 1k8.
How long are the wires of the I2C bus ? Do you want to use a cable for the I2C bus. A flat-ribbon cable with SDA next to SCL is the worst. The I2C bus was not designed to go through a cable.
The sample rate to get data can only be so much. To keep track of all the motions of the vehicle, a very high sample rate is needed. The accelerometer is very sensitive for vibrations and short shocks. If you mechanically dampen the sensor, it becomes a lot easier to keep track of the motions of the vehicle.
Thank you for the info Koepel. Here is some additional info i should have added.
i only have lock up problem when trying to use DMP on the imu6050. It never locks up when i direcly get values not theough dmp.
i am using cheap amazon imu6050 (3 pack for like $10usd)
i only need a sample rate of 30 per second or so but 50 to 100 would not be bad...but not much gain for my purpose.
I will read through the info you privided and see if that can get me somewhere. Btw length of connection for I2c currenly is less than 4 inches but is through 2 wires
This is not possible with consumer grade IMUs. With a good 3D fusion filter the rate gyro will to some extend correct for errors due to forces other than gravity, but you will still see large effects on those angles, in either situation.
You need to decide what magnitude of errors are acceptable, and that will come only from experimental trials.
The 2-3 degree accuracy you see quoted for consumer grade IMUs is valid only for static measurements.
I follow what you are saying. So, with the cheap grade imu i am using....driving in normal traffic about 13-15 deg pitch on normal acceleration to say 50 mph. I can get into the 25 deg range when braking but depends on how hard the brake is applied as you can imagine.
integrating a higher quality sensor is not a problem depending on how high of cost we are talking.
Ideally if i could keep the cost sub $100 for the sensor, and keep the acceleration effect down to say a +-5 degree error due to acceleration and cornering then it may still work for my application.
The important data collection for me is at slow speeds (under 5 mph) and for that the current setup works generally ok but could be better. I assume a better mems unit would help that as well.
What type of sensor should I probably look into based on this application, if you dont mind me asking?
I have not determined the exact cause yet of the lockup but will be experimenting with my test rig and making changes per your wiki.
My current biggest problem is determining if the sensor and technology available to accomplish what i am after can fit into the budget to make it all worth continuing development.
It is absolutely impossible for a rate gyro to correct this sort of error.
The calculation used by all popular 3D fusion filters used for consumer grade IMUs assumes that the only acceleration is due to gravity, and that the acceleration vector points vertically. In fact, the accelerometer measurement defines the vertical direction.
Obviously, that is not true in a vehicle that is accelerating horizontally, so you have to measure the horizontal acceleration and subtract it from the observed to get "vertical". It is relatively easy to do that if the accelerometer is fixed to the vehicle frame, but very difficult and very inaccurate if not.
By "vehicle frame" you mean the physical frame of the vehicle? Just trying to clarify.
If so i do intend for the sensor unit to be in a fixed mounting and not just in some variable mounting like a suctioned mount like for a phone or gps. Which actually leads me to another hurdle of how i will handle calibration...lol
For the measurement of pitch and roll, the accelerometer must be carefully calibrated and perfectly level (when the vehicle is level), with the Z axis vertical.
ok. So to get rid of the acceleration from my values. I could possibly do the following?
1- use vehicle can bus to read the 4 wheel speed sensors from the abs system and average to get the vehicle speed to calculate real acceleration then subtract that from the orientation of the imu when the acceleration started to handle pitch. I'm thinking almost like a third 8nput into a complimentary filter.
Or 2- use a gps module to get the same vehicle accel (tell when its moving...turning...etc) and do the same
Do these sound like I'm thinking in the right direction?
Those are all worth trying, and it would be an educational experience. Not a particularly simple problem, especially if you insist on using MEMS sensors. A gyroscope (not a rate gyro) would solve the problem right away.
