Open romatou18 opened 4 years ago
The Madgwick and Mahony filters are not Kalman filters per se, and these parameters are not being used in the usual Madgwick filter anyway, so it doesn;t matter if they are zero.
The accle and gyro should be calibrated in the setup.
On Wed, Feb 12, 2020 at 6:54 PM romatou18 notifications@github.com wrote:
Hi Kris,
I have remarks and questions about the code that initialises the constants of the Kalman filter used to fusion the accelero and the gyro readings :
// global constants for 9 DoF fusion and AHRS (Attitude and Heading Reference System) float GyroMeasError = PI (40.0f / 180.0f); // gyroscope measurement error in rads/s (start at 40 deg/s) float GyroMeasDrift = PI (0.0f / 180.0f); // gyroscope measurement drift in rad/s/s (start at 0.0 deg/s/s) // There is a tradeoff in the beta parameter between accuracy and response speed. // In the original Madgwick study, beta of 0.041 (corresponding to GyroMeasError of 2.7 degrees/s) was found to give optimal accuracy. // However, with this value, the LSM9SD0 response time is about 10 seconds to a stable initial quaternion. // Subsequent changes also require a longish lag time to a stable output, not fast enough for a quadcopter or robot car! // By increasing beta (GyroMeasError) by about a factor of fifteen, the response time constant is reduced to ~2 sec // I haven't noticed any reduction in solution accuracy. This is essentially the I coefficient in a PID control sense; // the bigger the feedback coefficient, the faster the solution converges, usually at the expense of accuracy. // In any case, this is the free parameter in the Madgwick filtering and fusion scheme. float beta = sqrt(3.0f / 4.0f) GyroMeasError; // compute beta float zeta = sqrt(3.0f / 4.0f) GyroMeasDrift; // compute zeta, the other free parameter in the Madgwick scheme usually set to a small or zero value #define Kp 2.0f * 5.0f // these are the free parameters in the Mahony filter and fusion scheme, Kp for proportional feedback, Ki for integral #define Ki 0.0f
float GyroMeasDrift = PI (0.0f / 180.0f); means that this constant is 0 => 0/180 = 0 Pi = 0. It means that the Gyro drift is considered to be 0 ? This also means that float zeta = sqrt(3.0f / 4.0f) * GyroMeasDrift; the zeta parameter is 0 ?
I am not an IMU or Kalman filter specialist but I am confused with that as I understand that a good kalman filter parameter evaluation is quite crucial to getting reliable results.
Could you shed a light on why these 2 parameters would tend towards zero and thus not taking into account the Gyro drift over time if I am correct?
Also I have another question about the Accelero and Gyro bias vectors:
float gyroBias[3] = {0, 0, 0}, accelBias[3] = {0, 0, 0}; // Bias corrections for gyro and accelerometer
Shouldn't the bias be calculated during i.e. the selfTest or during accelero and gyro calibration ? Regards
Romain
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/408?email_source=notifications&email_token=ABTDLKTLE7E4HWH5CHP3MITRCSY7XA5CNFSM4KUIZBTKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INEFAJA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQJOKLEH3O5HLMQYG3RCSY7XANCNFSM4KUIZBTA .
Hi Kris,
Ok thanks a lot for the quick answer ! Btw im wanting to use an IMU to measure this kind of thing ;-)
Mount Aoraki Top of New Zealand 3764m, kiting on lake Pukaki at the foot of it just a few km away !
Maybe this https://www.tindie.com/products/onehorse/all-st-motion-sensor-breakout-board/ one?
On Wed, Feb 12, 2020 at 7:09 PM romatou18 notifications@github.com wrote:
Hi Kris,
Ok thanks a lot for the quick answer ! Btw im wanting to use an IMU to measure this kind of thing ;-) [image: 81025560_10156500879397167_5154462574883897344_o] https://user-images.githubusercontent.com/60049000/74398046-2fe98b00-4e7b-11ea-8083-b2c1773db230.jpg
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/408?email_source=notifications&email_token=ABTDLKWLZF3NRIUZ3PCY4R3RCS2WLA5CNFSM4KUIZBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELTHEIA#issuecomment-585527840, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUCFAA3ND55HYLAVSLRCS2WLANCNFSM4KUIZBTA .
After more research into it, I noted the NXP FXOS8700 Accel + mag combined with the the FXAS21002 Gyro. Just like Bosch is doing for the BN)55 NXP provide their own library the NXPMotionSense to both perform the reading of the sensor and the fusion.
I had a quick look to what is an overwhelming amount of math in that lib, but also the sense that the code is very consistent and clean, non withstanding the math the flow of it and comments makes sense. Also the Filtering implemented differs from Mahony or Madgwick and given the constant used, purposefully for these 2 sensors, I guess this high degree of integration between the lib and the sensors can only be beneficial.
I read on the TDK invense website that they provide SDK and code only for OEMs, so not the average Joe, i.e. for their new ICM 20948 that seem to correct some defect of the MP9250.
By the look of it, if Bosch and NXP / Freescale are the only 2 guys that do provide highly integraed libs and fusion algorithm with their sensors, then I guess I will try these 2. It is hard to defeat an army of engineers that work on it full time and are in direct contact with the guys that designed the sensor in the first place.
I used to work in Cadence Design systems (Virtuoso team in Edinburgh), was in the Software R&D and working with the actual chip designers hand in hand, on Schematics, simulation and parasitics. Being in the same office and having a direct and precise answer to questions on the hardware design and the Design Software was hard to beat. Same here, and to be honest I don't understand why the sensor manufacturer don't always provide open source demo code and libs, it's understood they make $$$ not with the IOT tinkers but with the Smartphone and appliance industry. But what would they have to lose in disclosing code that make their hardware more accessible ?
I guess Bosch and NXP got that already. We do the same at Flightcell.com, we give open source code to the adopters of our GPS tracking solution, makes their time to market way shorter and saves us support calls and endless emails if we were (in the past) only giving them a PDF technical manual i.e. the equivalent of "this is my sensor specs, and the sensor register".
Who else than the system designers can design a good library for it ?!
Silly...
None of these solutions can beat this https://hackaday.io/project/160283-max32660-motion-co-processor for heading accuracy. Not even close...
On Wed, Feb 12, 2020 at 9:22 PM romatou18 notifications@github.com wrote:
After more research into it, I noted the NXP FXOS8700 Accel + mag combined with the the FXAS21002 Gyro. Just like Bosch is doing for the BN)55 NXP provide their own library the NXPMotionSense to both perform the reading of the sensor and the fusion.
I had a quick look to what is an overwhelming amount of math in that lib, but also the sense that the code is very consistent and clean, non withstanding the math the flow of it and comments makes sense. Also the Filtering implemented differs from Mahony or Madgwick and given the constant used, purposefully for these 2 sensors, I guess this high degree of integration between the lib and the sensors can only be beneficial.
I read on the TDK invense website that they provide SDK and code only for OEMs, so not the average Joe, i.e. for their new ICM 20948 that seem to correct some defect of the MP9250.
By the look of it, if Bosch and NXP / Freescale are the only 2 guys that do provide highly integraed libs and fusion algorithm with their sensors, then I guess I will try these 2. It is hard to defeat an army of engineers that work on it full time and are in direct contact with the guys that designed the sensor in the first place.
I used to work in Cadence Design systems (Virtuoso team in Edinburgh), was in the Software R&D and working with the actual chip designers hand in hand, on Schematics, simulation and parasitics. Being in the same office and having a direct and precise answer to questions on the hardware design and the Design Software was hard to beat. Same here, and to be honest I don't understand why the sensor manufacturer don't always provide open source demo code and libs, it's understood they make $$$ not with the IOT tinkers but with the Smartphone and appliance industry. But what would they have to lose in disclosing code that make their hardware more accessible ?
I guess Bosch and NXP got that already. We do the same at Flightcell.com, we give open source code to the adopters of our GPS tracking solution, makes their time to market way shorter and saves us support calls and endless emails if we were (in the past) only giving them a PDF technical manual i.e. the equivalent of "this is my sensor specs, and the sensor register".
Who else than the system designers can design a good library for it ?!
Silly...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/408?email_source=notifications&email_token=ABTDLKXPGK3QCDJFQCNMHDTRCTKHRA5CNFSM4KUIZBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELTOFPI#issuecomment-585556669, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUM6ZHAOMK32CZGEM3RCTKHRANCNFSM4KUIZBTA .
I read the article, one of your project if I understand. The more i read articles about chips the more people claim that this one is better than the other. Sure ST is talented company, so is Bosch, TDK or NXP. I guess side by side tests are required to tell which one is the best. it seems that the ST one is not the most recent or the less noisy in terms of zero move noise if you look at experiments of Adafruit on this one and a couple of others.
The solution proposed if I understand, is to include a MCU on the same board as the sensor in order to compute the AHRS fusion, thus offloading it from the the main MCU. But what is the fusion algorithm implemented for it ? That is much more important to the measure accuracy if im correct, rather than what MCU computes it.
If im interested in chips like the Bosch or NXP it is that plenty of official documentation and libs are provided and maintainted. And unless spending months optimising and testing, how could anyone on their own hope to come close to a full time team effort that's designed or worked with the sensor designers ? I guess again tests would be required to compare, suppositions are only suppositions, only comparative tests can give a conclusive answer.
However if you can disclose the details of your algorithm, that is intended to go on that MAX32 MCU that would be of great interest. At least some pseudo code or detailed outline.
And for instance this why I chose the ESP32 to develop my experiemtn, got 2 cores at 240MHZ, one dedicated to polling the IMU and computing the AHRS, just the same as the MAX 95MHZ mcu, more than enough power to update the AHRS at 400HZ or more, but again if my algorithm behind is not robust and optimised that's all in vain. Anyhow i intend to do my own tests and compare the BN)80, 55, the NXP and the new TDK ICM20948, simple tests, like measuring the zero noise and then the 3D cube test and the altitude estimator test.
Btw where can your project be purchased i looked around couldnt find a buy link.
I looked some more on the TDK invensense side of things and it turns out it's easy to get their evaluation software and sensor drivers including their in house fusion algorithm as per the following screenshots, all that's necessary it to provide a corporate email and Company name, which I have like many, so Invensense can be added to the list along with Bosch and NXP as the manufacturers that give access to drivers and sensor software libs.
It might be worth trying as the ICM-20948 is cheaper than most, is supposed to be lower power hungry than most as well. Kris have you considered testing it ? not mentioning doing an MCU equiped board with it at some point ?
I have used the ICM42605 accel/gyro and it is a superb IMU, about as good as the LSM6DSM. Either of these would make a good choice for IMU. I would expect the ICM 20948 to be also a good choice. What I don't like about it is that one needs two power rails, so unnecessarily complicates any design.
In addition to a good enough sensor suite (these all are, the BNO055 is not) one needs proper calibration of all of the sensors.
These two ingredients are by far more important than the sensor fusion solution one uses. No amount of Kalman filtering will make up for crappy sensor data.
On Thu, Feb 13, 2020 at 4:28 PM romatou18 notifications@github.com wrote:
I looked some more on the TDK invensense side of things and it turns out it's easy to get their evaluation software and sensor drivers including their in house fusion algorithm as per the following screenshots, all that's necessary it to provide a corporate email and Company name, which I have like many, so Invensense can be added to the list along with Bosch and NXP as the manufacturers that give access to drivers and sensor software libs.
It might be worth trying as the ICM-20948 is cheaper than most, is supposed to be lower power hungry than most as well. Kris have you considered testing it ? not mentioning doing an MCU equiped board with it at some point ?
[image: Screenshot_2020-02-14_13-21-41] https://user-images.githubusercontent.com/60049000/74490499-90390500-4f2d-11ea-908a-3e1816b5a6d5.png
[image: Screenshot_2020-02-14_13-22-22] https://user-images.githubusercontent.com/60049000/74490503-95964f80-4f2d-11ea-9483-a8b777682e42.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/408?email_source=notifications&email_token=ABTDLKWVYVHJCQKQV3JTX63RCXQRJA5CNFSM4KUIZBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXD4RA#issuecomment-586038852, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQXK3FMNL5ND6QWE43RCXQRJANCNFSM4KUIZBTA .
The only sensible test is measured vs actual heading. Accurate heading estimation is what is hard about 9 DoF motion sensor fusion.
There is simply no solution offered by Bosch, ST, TDK or NXP that has demonstrated routine 0.5 degree absolute heading accuracy and ~0.25 degree rms heading accuracy. If there is evidence to the contrary, please post a link.
The MAX32660 + ST sensor suite solution discussed here has done so.
I don't expect most people to understand what an amazing achievement this is for a $40 sensor board. This kind of performance usually costs thousands if not tens of thousands of dollars.
It took a lot of work to get here, so we will not make the methods open source. That's just a business decision.
But the boards will be available for sale on Tindie soon.
Hey Kris,
Let alone having precise heading having something that small and that cheap working is plain amazing I'm aware of it.
Just trying to find a solution and totally understand that you need to make a living on your hard work, everyone here knows and see how much you've published on the subject and wrote in code.
As for my project I'm mostly interested in the altitude measurements at first, then once this works, in the heading. It's too expensive for my needs, but the company i work for Flightcell international, needs a better IMU to replicate the Hobbs meter and record the flights parameters in case an aircraft crashes, then do a post crash analysis, kind of a cheap and lightweight black box for helicopters rescues, firefighters and Police mainly.
If you can convince my boss that your solution can work you might be onto something, we use the ST LS6DSM if im correct and have a big problem with mag and gyro calibration. The device is installed in the cockpit, can't be moved, in a foxed position, and this screws up everything because past the initial calibration we can't readjust later.
My boss is really eager to tackle this issue. If you have something that can propose a smart calibration solution then my guess is he'd be ready to buy. Our device is cheap for aviation grade stuff but still a few 1000USD. Checkout www.flightcell.com, send an email and I'll put in a good word if needed.
I believe we have two things that can help in addition to superb heading accuracy in a low-cost, small form factor device..
We are fusing the barometer with the accel to drift stabilize the altitude estimation, and we have a dynamic hard iron correction algorithm that allows good heading estimation even when the sensor board is mounted in a vehicle (like a car, but also a plane or helicopter).
Please contact us at tleracorp@gmail.com for more info or if you have questions.
On Thu, Feb 13, 2020 at 10:54 PM romatou18 notifications@github.com wrote:
Hey Kris,
Let alone having precise heading having something that small and that cheap working is plain amazing I'm aware of it.
Just trying to find a solution and totally understand that you need to make a living on your hard work, everyone here knows and see how much you've published on the subject and wrote in code.
As for my project I'm mostly interested in the altitude measurements at first, then once this works, in the heading. It's too expensive for my needs, but the company i work for Flightcell international, needs a better IMU to replicate the Hobbs meter and record the flights parameters in case an aircraft crashes, then do a post crash analysis, kind of a cheap and lightweight black box for helicopters rescues, firefighters and Police mainly.
If you can convince my boss that your solution can work you might be onto something, we use the ST LS6DSM if im correct and have a big problem with mag and gyro calibration. The device is installed in the cockpit, can't be moved, in a foxed position, and this screws up everything because past the initial calibration we can't readjust later.
My boss is really eager to tackle this issue. If you have something that can propose a smart calibration solution then my guess is he'd be ready to buy. Our device is cheap for aviation grade stuff but still a few 1000USD. Checkout www.flightcell.com, send an email and I'll put in a good word if needed.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/408?email_source=notifications&email_token=ABTDLKQ7MMR746HB45NF5ITRCY52DA5CNFSM4KUIZBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXYXDI#issuecomment-586124173, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWSZXSNIMRZTRKDECDRCY52DANCNFSM4KUIZBTA .
I believe we have two things that can help in addition to superb heading accuracy in a low-cost, small form factor device.. We are fusing the barometer with the accel to drift stabilize the altitude estimation, and we have a dynamic hard iron correction algorithm that allows good heading estimation even when the sensor board is mounted in a vehicle (like a car, but also a plane or helicopter). Please contact us at tleracorp@gmail.com for more info or if you have questions. … On Thu, Feb 13, 2020 at 10:54 PM romatou18 @.***> wrote: Hey Kris, Let alone having precise heading having something that small and that cheap working is plain amazing I'm aware of it. Just trying to find a solution and totally understand that you need to make a living on your hard work, everyone here knows and see how much you've published on the subject and wrote in code. As for my project I'm mostly interested in the altitude measurements at first, then once this works, in the heading. It's too expensive for my needs, but the company i work for Flightcell international, needs a better IMU to replicate the Hobbs meter and record the flights parameters in case an aircraft crashes, then do a post crash analysis, kind of a cheap and lightweight black box for helicopters rescues, firefighters and Police mainly. If you can convince my boss that your solution can work you might be onto something, we use the ST LS6DSM if im correct and have a big problem with mag and gyro calibration. The device is installed in the cockpit, can't be moved, in a foxed position, and this screws up everything because past the initial calibration we can't readjust later. My boss is really eager to tackle this issue. If you have something that can propose a smart calibration solution then my guess is he'd be ready to buy. Our device is cheap for aviation grade stuff but still a few 1000USD. Checkout www.flightcell.com, send an email and I'll put in a good word if needed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#408?email_source=notifications&email_token=ABTDLKQ7MMR746HB45NF5ITRCY52DA5CNFSM4KUIZBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXYXDI#issuecomment-586124173>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWSZXSNIMRZTRKDECDRCY52DANCNFSM4KUIZBTA .
Hi @kriswiner,
I want to implement "dynamic hard iron correction algorithm" you mentioned. Any suggestion or recommendations for this function? I know you already selling product but want to know how it's getting done.
Best I can do is refer you to this https://github.com/gregtomasch/USFSMAX#dynamic-hard-iron-dhi-corrector page that describes how to make use of it in our USFSMAX product. We are not going to tell you exactly how we do it though....
On Mon, Aug 19, 2024 at 6:34 PM Cogito666 @.***> wrote:
I believe we have two things that can help in addition to superb heading accuracy in a low-cost, small form factor device.. We are fusing the barometer with the accel to drift stabilize the altitude estimation, and we have a dynamic hard iron correction algorithm that allows good heading estimation even when the sensor board is mounted in a vehicle (like a car, but also a plane or helicopter). Please contact us at @. for more info or if you have questions. … <#m424401596494206764> On Thu, Feb 13, 2020 at 10:54 PM romatou18 @.> wrote: Hey Kris, Let alone having precise heading having something that small and that cheap working is plain amazing I'm aware of it. Just trying to find a solution and totally understand that you need to make a living on your hard work, everyone here knows and see how much you've published on the subject and wrote in code. As for my project I'm mostly interested in the altitude measurements at first, then once this works, in the heading. It's too expensive for my needs, but the company i work for Flightcell international, needs a better IMU to replicate the Hobbs meter and record the flights parameters in case an aircraft crashes, then do a post crash analysis, kind of a cheap and lightweight black box for helicopters rescues, firefighters and Police mainly. If you can convince my boss that your solution can work you might be onto something, we use the ST LS6DSM if im correct and have a big problem with mag and gyro calibration. The device is installed in the cockpit, can't be moved, in a foxed position, and this screws up everything because past the initial calibration we can't readjust later. My boss is really eager to tackle this issue. If you have something that can propose a smart calibration solution then my guess is he'd be ready to buy. Our device is cheap for aviation grade stuff but still a few 1000USD. Checkout www.flightcell.com, send an email and I'll put in a good word if needed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#408 https://github.com/kriswiner/MPU9250/issues/408?email_source=notifications&email_token=ABTDLKQ7MMR746HB45NF5ITRCY52DA5CNFSM4KUIZBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELXYXDI#issuecomment-586124173>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWSZXSNIMRZTRKDECDRCY52DANCNFSM4KUIZBTA .
Hi @kriswiner https://github.com/kriswiner,
I want to implement "dynamic hard iron correction algorithm" you mentioned. Any suggestion or recommendations for this function? I know you already selling product but want to know how it's getting done.
— Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/408#issuecomment-2297797326, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQBLLNGYNKGFH73H4LZSKMJ7AVCNFSM6AAAAABMY4JDTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJXG44TOMZSGY . You are receiving this because you were mentioned.Message ID: @.***>
Thank you so much! Great help! I got the clue!
Hi Kris,
I have remarks and questions about the code that initialises the constants of the Kalman filter used to fusion the accelero and the gyro readings :
` // global constants for 9 DoF fusion and AHRS (Attitude and Heading Reference System) float GyroMeasError = PI * (40.0f / 180.0f);
// gyroscope measurement error in rads/s (start at 40 deg/s) float GyroMeasDrift = PI * (0.0f / 180.0f);
float beta = sqrt(3.0f / 4.0f) * GyroMeasError; // compute beta
float zeta = sqrt(3.0f / 4.0f) * GyroMeasDrift; // compute zeta, the other free parameter in the Madgwick scheme usually set to a small or zero value
define Kp 2.0f * 5.0f
// these are the free parameters in the Mahony filter and fusion scheme, Kp for proportional feedback, Ki for integral
define Ki 0.0f
`
float GyroMeasDrift = PI (0.0f / 180.0f); means that this constant is 0 => 0/180 = 0 Pi = 0. It means that the Gyro drift is considered to be 0 ? This also means that float zeta = sqrt(3.0f / 4.0f) * GyroMeasDrift; the zeta parameter is 0 ?
I am not an IMU or Kalman filter specialist but I am confused with that as I understand that a good kalman filter parameter evaluation is quite crucial to getting reliable results.
Could you shed a light on why these 2 parameters would tend towards zero and thus not taking into account the Gyro drift over time if I am correct?
Also I have another question about the Accelero and Gyro bias vectors:
float gyroBias[3] = {0, 0, 0}, accelBias[3] = {0, 0, 0}; // Bias corrections for gyro and accelerometer
Shouldn't the bias be calculated during i.e. the selfTest or during accelero and gyro calibration ? Regards
Romain