uNav INS
- Thread starter brtaylor
- Start date
defragster
Senior Member+
SRD==9? That post was showing funny #'s? Something wasn't right.
Found the count issue - copy paste error - here are good one - except I caught another DOUBLE MAX on NEW dt??? That needs to be checked!:
I didn't look into extern'ing the CB's across units - I used an array to extern the data to gpsData.
Here's the code - it is .average:: for uNavINS.cpp
uNavINS_CB_Ver6.ino::
Found the count issue - copy paste error - here are good one - except I caught another DOUBLE MAX on NEW dt??? That needs to be checked!:
I didn't look into extern'ing the CB's across units - I used an array to extern the data to gpsData.
Here's the code - it is .average:: for uNavINS.cpp
Code:
dtO = _t;
dt = FccPartSec( cctLast_IMU, ccTimeNow_IMU );
cctLast_IMU = ccTimeNow_IMU;
if ( 0 == Ndt_s[0] ) {
Ndt_s[0] = Ndt.average();
Ndt_s[1] = Ndt.min();
Ndt_s[2] = Ndt.max();
Ndt_s[3] = Ndt.size();
Ndt.clear();
Odt_s[0] = Odt.average();
Odt_s[1] = Odt.min();
Odt_s[2] = Odt.max();
Odt_s[3] = Odt.size();
Odt.clear();
}
Odt.push_back( dtO );
Ndt.push_back( 1000000 * dt );uNavINS_CB_Ver6.ino::
Code:
coutD.print( " >> New_dt Avg: " );
Serial.print( Ndt_s[0] );
coutD.print( "_ Ndt Min: " );
Serial.print( Ndt_s[1] );
coutD.print( "_ Ndt Max: " );
Serial.print( Ndt_s[2] );
coutD.print( "_ Ndt Count: " );
Serial.print( Ndt_s[3] );
coutD.print( "\n >> Old_dt Avg: " );
Serial.print( Odt_s[0] );
coutD.print( "_ Odt Min: " );
Serial.print( Odt_s[1] );
coutD.print( "_ Odt Max: " );
Serial.print( Odt_s[2] );
coutD.print( "_ Odt Count: " );
Serial.print( Odt_s[3] );
coutD.println( );
Ndt_s[0] = 0;defragster
Senior Member+
I put the IMU Counter in.
I see what is happening with the NEW isr based dt! Not on the start of EVERY GPS second - but it seems ONLY on the start of the GPS second.
A second IMU interrupt is triggering before the first is processed! Using the count I can avoid counting these in the stats New & Old -
This doesn't change or fix the problem with the OLD dt based on elapsedMicros though.
Removed some Serial.print ( Stuff Don added still there )::
Now removed extra from :: masterSerialPrint() - So glad tonton81 worked out the SPI_MSTransfer! Formatting and printing those 8 values BREAKS the timing cycle!!!!
Here at 1398 (1/5th) seconds and the only detected DOUBLE is the first entry! Above there were 6 more in 247 (1/5th) seconds!
But the OLD method dt is still giving erratic times!
After 20 minutes now - That stopped the overlapping IMU's running at SRD==1 with 500 Hz that was too much:
I see what is happening with the NEW isr based dt! Not on the start of EVERY GPS second - but it seems ONLY on the start of the GPS second.
A second IMU interrupt is triggering before the first is processed! Using the count I can avoid counting these in the stats New & Old -
This doesn't change or fix the problem with the OLD dt based on elapsedMicros though.
Removed some Serial.print ( Stuff Don added still there )::
Now removed extra from :: masterSerialPrint() - So glad tonton81 worked out the SPI_MSTransfer! Formatting and printing those 8 values BREAKS the timing cycle!!!!
Here at 1398 (1/5th) seconds and the only detected DOUBLE is the first entry! Above there were 6 more in 247 (1/5th) seconds!
But the OLD method dt is still giving erratic times!
After 20 minutes now - That stopped the overlapping IMU's running at SRD==1 with 500 Hz that was too much:
Last edited:
defragster
Senior Member+
Mike - if interested - here is the code behind the update with the count in the IMU_isr() { that func should really have _isr in the name }
I closed TyCommander a bit - machine being sluggish - 42 Browser pages open in Edge not helping - but single FireFox open on FB and it is killing my machine!
Anyhow - it looks like a single other event caused another Double - they happen in pairs as two get compromised.
Solution for this could be to use a CB to record incoming IMU data and timestamp. Reading IMU data should take 300-400 uS for the 18 DWORD read at 2 Mbit. Might see if I can set up the i2c_t3 code to perform a DMA/Interrupt read of the data?
Only one more some time later - more than double the run time . . . Not always in doubles - must have caught it mid interrupt and had a non-atomic race to update the vars ...
I closed TyCommander a bit - machine being sluggish - 42 Browser pages open in Edge not helping - but single FireFox open on FB and it is killing my machine!
Anyhow - it looks like a single other event caused another Double - they happen in pairs as two get compromised.
Solution for this could be to use a CB to record incoming IMU data and timestamp. Reading IMU data should take 300-400 uS for the 18 DWORD read at 2 Mbit. Might see if I can set up the i2c_t3 code to perform a DMA/Interrupt read of the data?
Only one more some time later - more than double the run time . . . Not always in doubles - must have caught it mid interrupt and had a non-atomic race to update the vars ...
mjs513
Senior Member+
Hi Tim,
By the way when I said I was running at 100hz I was wrong. Somewhere along the line I must have changed it. The problem I was seeing was because I was running at 500hz
. Changed it to 200hz and running as I expected. Don't remember why I changed it though. Anyway incorporated you latest changes and will test it as soon as I get a satellite lock at. This time of the morning is always hard for a lock.
Mike
EDIT: Got my lock Seeing double last every loop.
By the way when I said I was running at 100hz I was wrong. Somewhere along the line I must have changed it. The problem I was seeing was because I was running at 500hz
. Changed it to 200hz and running as I expected. Don't remember why I changed it though. Anyway incorporated you latest changes and will test it as soon as I get a satellite lock at. This time of the morning is always hard for a lock.Mike
EDIT: Got my lock
Seeing double last every loop.
Code:
---Lp#:18681 IMU#:136 > 1S:100512960 > IMUcc:353544 >> Mcnt:65
>> N_dt Avg: 4997_ Ndt Mn: 4997_ Ndt Mx: 4997_ Ndt Dbl: 252
>> Old_dt Avg: 4931_ Odt Min: 3247_ Odt Max: 5169
#252 @9:25.54 [fix:3 #:8 GPScc:221083 > cctAv:167999319 > GPSdt:0.21076608
__DOUBLED__LAST> 10467 Cnt= 10481
#253 @9:25.54 [fix:3 #:8 GPScc:219861 > cctAv:167999319 > GPSdt:0.18973464
__DOUBLED__LAST> 10505 Cnt= 10519
#254 @9:25.54 [fix:3 #:8 GPScc:221504 > cctAv:167999319 > GPSdt:0.19326086
__DOUBLED__LAST> 10544 Cnt= 10558
#255 @9:25.54 [fix:3 #:8 GPScc:221693 > cctAv:167999319 > GPSdt:0.20149061
__DOUBLED__LAST> 10584 Cnt= 10598
#256 @9:25.54 [fix:3 #:8 GPScc:221768 > cctAv:167999319 > GPSdt:0.20158003
__DOUBLED__LAST> 10624 Cnt= 10638
---Lp#:18379 IMU#:134 > 1S:99498552 > IMUcc:394591 >> Mcnt:62
>> N_dt Avg: 4997_ Ndt Mn: 4997_ Ndt Mx: 4998_ Ndt Dbl: 257
>> Old_dt Avg: 4932_ Odt Min: 3248_ Odt Max: 5018
#257 @9:25.55 [fix:3 #:8 GPScc:220575 > cctAv:167999319 > GPSdt:0.20892443
__DOUBLED__LAST> 10666 Cnt= 10680defragster
Senior Member+
200 Hz is way too fast for the setup in use. On prior - I knew it was not running at 100 given the printed values.
This will compromise the Filter results as the data coming in is not all being processed, some large portion of the IMU data is discarded.
The LAST> and Cnt= value should be off by at most TWO for a single skip. { below shows ++pre-INC - before printing I put the value back with coutD.print( --LastCnt_IMU ); }
When running properly it is OFF by ONE - that new one is incremented beyond the last and that is expected and tested with :: if ( ++LastCnt_IMU == Cnt_IMU ) {
The differences above show MANY case of FOURTEEN misses, this is also shown in IMU#:136 and IMU#:134 - that IMU# number when it doesn't track the SRD number of IMU/sec means it is busted - IMU# would read ~200 if keeping up.
Mine jumped to "Dbl: 6" after last post - ran overnight and it is still there.
This will compromise the Filter results as the data coming in is not all being processed, some large portion of the IMU data is discarded.
The LAST> and Cnt= value should be off by at most TWO for a single skip. { below shows ++pre-INC - before printing I put the value back with coutD.print( --LastCnt_IMU ); }
When running properly it is OFF by ONE - that new one is incremented beyond the last and that is expected and tested with :: if ( ++LastCnt_IMU == Cnt_IMU ) {
The differences above show MANY case of FOURTEEN misses, this is also shown in IMU#:136 and IMU#:134 - that IMU# number when it doesn't track the SRD number of IMU/sec means it is busted - IMU# would read ~200 if keeping up.
Mine jumped to "Dbl: 6" after last post - ran overnight and it is still there.
defragster
Senior Member+
Mike - My T-3.6 is running at 180 MHz and keeping up with 500 Hz IMU. What speed is your T_3.5 running at? Only processing 100 Hz IMU safely is a big drop! I'd say it is time to get a T_3.6 running there so you have the horsepower to properly process the data at hand with the processing being done in a timely fashion. When the data gets ahead of the processing as indicated by these debugGPS() prints the displayed results will be problematic.
Also I just noticed another indicator >> Mcnt:65 this means many of the MAG updates are never being processed. Per my earlier analogy: '5 liters may be added - but you'll only measure 4 liters coming out' when IMU data isn't 100% accounted for.
<EDIT>: I can clean up that debugGPS to minimize SPEW - it doesn't need to show all 5 GPS reports - it could go back to only printing/counting missing ones. And the Alternate 'dt' stuff was just a TEMP thing.
The TEMP dt testing shows a fixed incoming rate of ~1995-1997 microseconds at 500 Hz. But some of that stuff shows critical info that the Teensy is catching all incoming data and properly processing it:
could be just this where I could add GPS miss count - these values when in balance show data in being put to Filter:
debugGPS( Value ) could get a parameter [0,1,2] to show : NONE, Minimal/critical, Critical plus each GPS as it is now. That could then be changed from the USB terminal input.
Also I just noticed another indicator >> Mcnt:65 this means many of the MAG updates are never being processed. Per my earlier analogy: '5 liters may be added - but you'll only measure 4 liters coming out' when IMU data isn't 100% accounted for.
<EDIT>: I can clean up that debugGPS to minimize SPEW - it doesn't need to show all 5 GPS reports - it could go back to only printing/counting missing ones. And the Alternate 'dt' stuff was just a TEMP thing.
The TEMP dt testing shows a fixed incoming rate of ~1995-1997 microseconds at 500 Hz. But some of that stuff shows critical info that the Teensy is catching all incoming data and properly processing it:
could be just this where I could add GPS miss count - these values when in balance show data in being put to Filter:
debugGPS( Value ) could get a parameter [0,1,2] to show : NONE, Minimal/critical, Critical plus each GPS as it is now. That could then be changed from the USB terminal input.
Last edited:
mjs513
Senior Member+
Hi Tim
The T3.5 is running at 168Mhz as well as the slave. I just changed to 100Hz updates for the IMU and still getting doubles, here is a sample:
Now, here is the problem I am now having with the methodology that we are using. Please don't take what I about to say wrong. You and Don put a lot into this and I am learning a lot. I am doing some other things that I haven't posted yet like I am about to mention.
If I can simply run a non-EKF solution to get stable YPR and run an EKF for the GPS (See the example I posted a few examples ago). I can then probably run it on a T3.5/T3.6 or T3.2. We are forcing ourselves into a corner and limiting the applicability of the uNAVIns to a T3.6 Master. If I start throwing other stuff into the mix, like other sensors (since I am also now using the barometer) and using sSer3 method to send commands from the slave I am probably going to throw the whole thing off. Maybe we need to start thinking about a different approach. This is just my two cents.
As a update to kind of proving the point I just turned off the Baro and no doubles:
The T3.5 is running at 168Mhz as well as the slave. I just changed to 100Hz updates for the IMU and still getting doubles, here is a sample:
Code:
---Lp#:21771 IMU#:70 > 1S:100030800 > IMUcc:683196 >> Mcnt:64
>> N_dt Avg: 9996_ Ndt Mn: 9996_ Ndt Mx: 9996_ Ndt Dbl: 1256
>> Old_dt Avg: 9867_ Odt Min: 8303_ Odt Max: 10018
#1255 @19:30.22 [fix:3 #:7 GPScc:220183 > cctAv:167999199 > GPSdt:0.20092505
__DOUBLED__LAST> 25545 Cnt= 25552
#1256 @19:30.22 [fix:3 #:7 GPScc:220993 > cctAv:167999199 > GPSdt:0.19810477
__DOUBLED__LAST> 25565 Cnt= 25572
#1257 @19:30.22 [fix:3 #:7 GPScc:220343 > cctAv:167999199 > GPSdt:0.20114391
__DOUBLED__LAST> 25585 Cnt= 25592
#1258 @19:30.22 [fix:3 #:7 GPScc:221579 > cctAv:167999199 > GPSdt:0.20122981
__DOUBLED__LAST> 25605 Cnt= 25612
#1259 @19:30.22 [fix:3 #:7 GPScc:220561 > cctAv:167999199 > GPSdt:0.19849481
__DOUBLED__LAST> 25625 Cnt= 25632
---Lp#:21625 IMU#:70 > 1S:99660072 > IMUcc:381566 >> Mcnt:65
>> N_dt Avg: 9995_ Ndt Mn: 9995_ Ndt Mx: 9996_ Ndt Dbl: 1261
>> Old_dt Avg: 9867_ Odt Min: 8302_ Odt Max: 10018
#1260 @19:30.23 [fix:3 #:7 GPScc:219376 > cctAv:167999199 > GPSdt:0.19763555
__DOUBLED__LAST> 25645 Cnt= 25652
#1261 @19:30.23 [fix:3 #:7 GPScc:221347 > cctAv:167999199 > GPSdt:0.20266876
__DOUBLED__LAST> 25665 Cnt= 25672
#1262 @19:30.23 [fix:3 #:7 GPScc:221483 > cctAv:167999199 > GPSdt:0.19731759
__DOUBLED__LAST> 25685 Cnt= 25692
#1263 @19:30.23 [fix:3 #:7 GPScc:220679 > cctAv:167999199 > GPSdt:0.20167968
__DOUBLED__LAST> 25705 Cnt= 25712
#1264 @19:30.23 [fix:3 #:7 GPScc:219622 > cctAv:167999199 > GPSdt:0.19843487Now, here is the problem I am now having with the methodology that we are using. Please don't take what I about to say wrong. You and Don put a lot into this and I am learning a lot. I am doing some other things that I haven't posted yet like I am about to mention.
If I can simply run a non-EKF solution to get stable YPR and run an EKF for the GPS (See the example I posted a few examples ago). I can then probably run it on a T3.5/T3.6 or T3.2. We are forcing ourselves into a corner and limiting the applicability of the uNAVIns to a T3.6 Master. If I start throwing other stuff into the mix, like other sensors (since I am also now using the barometer) and using sSer3 method to send commands from the slave I am probably going to throw the whole thing off. Maybe we need to start thinking about a different approach. This is just my two cents.
As a update to kind of proving the point I just turned off the Baro and no doubles:
Code:
---Lp#:33649 IMU#:101 > 1S:100453448 > IMUcc:411763 >> Mcnt:99
>> N_dt Avg: 9996_ Ndt Mn: 9996_ Ndt Mx: 9996_ Ndt Dbl: 1
>> Old_dt Avg: 9988_ Odt Min: 9654_ Odt Max: 10163
#69 @19:42.28 [fix:3 #:7 GPScc:220126 > cctAv:167999152 > GPSdt:0.20503160
#70 @19:42.28 [fix:3 #:7 GPScc:229233 > cctAv:167999151 > GPSdt:0.19712971
#71 @19:42.28 [fix:3 #:7 GPScc:221354 > cctAv:167999151 > GPSdt:0.20310731
#72 @19:42.28 [fix:3 #:7 GPScc:220208 > cctAv:167999151 > GPSdt:0.19504377
#73 @19:42.28 [fix:3 #:7 GPScc:220211 > cctAv:167999151 > GPSdt:0.20516260
---Lp#:33411 IMU#:100 > 1S:99734064 > IMUcc:182944 >> Mcnt:99
>> N_dt Avg: 9996_ Ndt Mn: 9996_ Ndt Mx: 9996_ Ndt Dbl: 1
>> Old_dt Avg: 9994_ Odt Min: 9791_ Odt Max: 10163
#74 @19:42.29 [fix:3 #:7 GPScc:221704 > cctAv:167999151 > GPSdt:0.19688143
#75 @19:42.29 [fix:3 #:7 GPScc:220411 > cctAv:167999115 > GPSdt:0.19985212
#76 @19:42.29 [fix:3 #:7 GPScc:220744 > cctAv:167999115 > GPSdt:0.19994153
#77 @19:42.29 [fix:3 #:7 GPScc:219644 > cctAv:167999115 > GPSdt:0.19345319
#78 @19:42.29 [fix:3 #:7 GPScc:220961 > cctAv:167999115 > GPSdt:0.20658559mjs513
Senior Member+
No I haven't. Don't think its a NVIC issue. Baro's are notorious for taking time to get an stable accurate reading. You have to use a high over sampling rate but that comes with a large delay in getting a reading. I should try putting it is own thread and let it run at its own update rate and just pull that data in as it updates. I could lower the sampling rate but will have a broader variation in altitude. I will give it a try and see what happens.
Tim - I like the dt methodology that you put in place and think the problem lies in the fact that we are really only sampling at GPS update rate. GPS has the priority. In other implementations I have seen IMU data is updated as it comes in and when GPS data is available the solution is updated.
Mike
Tim - I like the dt methodology that you put in place and think the problem lies in the fact that we are really only sampling at GPS update rate. GPS has the priority. In other implementations I have seen IMU data is updated as it comes in and when GPS data is available the solution is updated.
Mike
Still working on refining calibration. I'm seeing something weird when using the MPU9250 library calibration. My X and Y bias values for accel come out the same (see below). Are you guys seeing this?
Don
***************************************
Serial Initialized
Loading Accel and Mag Biases and Scale Factors
Accel and Mag Biases and Scale Factors Loaded
Accel Biases and Scale Factors:
-0.039584, 0.999486
-0.039584, 0.999870
-0.184881, 0.990542
Mag Biases and Scale Factors:
16.411831, 1.012316
43.833965, 0.989071
-21.315411, 0.998885
Gyro Calibration Underway
Gyro Calibration Complete
Setup Complete
Don
***************************************
Serial Initialized
Loading Accel and Mag Biases and Scale Factors
Accel and Mag Biases and Scale Factors Loaded
Accel Biases and Scale Factors:
-0.039584, 0.999486
-0.039584, 0.999870
-0.184881, 0.990542
Mag Biases and Scale Factors:
16.411831, 1.012316
43.833965, 0.989071
-21.315411, 0.998885
Gyro Calibration Underway
Gyro Calibration Complete
Setup Complete
Found the issue. The accel Y bias calculation has a typo in it, in the MPU9250 library. It's in the calibrateAccel() routine.
the line that reads
_ayb = (_axmin + _axmax) / 2.0f;
should read
_ayb = (_aymin + _aymax) / 2.0f;
That produces accel Y biases that look much better now!
I'm going through all the cal stuff still to make sure things really make sense to me. Slow going, but am checking all IMU readings before and after cal to see that they go where I expect them to go. Then I think things will be (hopefully) more stable in the EKFs.
Don
the line that reads
_ayb = (_axmin + _axmax) / 2.0f;
should read
_ayb = (_aymin + _aymax) / 2.0f;
That produces accel Y biases that look much better now!
I'm going through all the cal stuff still to make sure things really make sense to me. Slow going, but am checking all IMU readings before and after cal to see that they go where I expect them to go. Then I think things will be (hopefully) more stable in the EKFs.
Don
Mike,
You're getting hit by a double whammy on your accel calibration. It looks like you're not getting calibration values for axb (0.0) and axs (1.0), and your ayb (4.872) with the current MPU9250 library is really the axb value...
I'm extending the calibration sketch so that it shows before and after IMU values so the user can verify accel and gyro readings go to ~0 after cal, and that mag values point correctly in all four quadrants. It's been bugging me that my numbers after cal haven't seemed right, and it's been due to several different factors (this ayb code error, one bad MPU9250, and issues with h-field readings indoors).
Don
You're getting hit by a double whammy on your accel calibration. It looks like you're not getting calibration values for axb (0.0) and axs (1.0), and your ayb (4.872) with the current MPU9250 library is really the axb value...
I'm extending the calibration sketch so that it shows before and after IMU values so the user can verify accel and gyro readings go to ~0 after cal, and that mag values point correctly in all four quadrants. It's been bugging me that my numbers after cal haven't seemed right, and it's been due to several different factors (this ayb code error, one bad MPU9250, and issues with h-field readings indoors).
Don
defragster
Senior Member+
First set shows IMU# coming up short which explains the DOUBLED's - the second keeps up as it should.
For 168 MHz - it should be keeping up better? Something is dragging it down doing too much - that on my 180 MHz T_3.6 is easy?
If you can find and remove the 'hotspot' eating up the CPU time that is needed to be understood and 'tamed'
My setup still going and one more added DOUBLED:
Not sure what triggers the rare one - SEEMS TO BE having SerMon go away!
The one added last night and the couple today were from that - and I just clicked 'Serial Off' on TyComm and sure enough almost 1 for 1 it added to :: Ndt Dbl: 7 ==> Ndt Dbl: 12
One did not, one created a couple. I think this was behind some of the early fails on the SPI_MSTransfer testing too - but I never saw it as clear as this.
perhaps I'll set up a small sketch with the RTC and CycleCounter running and track when time gets lost - and see if Paul can debug how Serial dropping might be causing trouble. It may be fixed in the new TD_1.42 - compiling with 1.41 now.
defragster
Senior Member+
Just closed IDE w/1.41 and went to Beta 1.42 - had to bump 180 MHz CPU to F_BUS 90 to run with my selected i2c speed of 2400000.
So then MPU9250 came up running - closing the IDE - TeensySerMon in the beta indeed still results in increase in :: Ndt Dbl: 3, so it is some interaction with loss of the USB Serial - will have to try that example bug sketch - it may be related to SPI_MST - or some other thing in use ... will go back to the SPI_MST examples and add the cyclecounter and RTC code and see if I can provoke it with something easy to reproduce.
So then MPU9250 came up running - closing the IDE - TeensySerMon in the beta indeed still results in increase in :: Ndt Dbl: 3, so it is some interaction with loss of the USB Serial - will have to try that example bug sketch - it may be related to SPI_MST - or some other thing in use ... will go back to the SPI_MST examples and add the cyclecounter and RTC code and see if I can provoke it with something easy to reproduce.
mjs513
Senior Member+
Tim - know I put a lot into the last message. But I did trace what was causing the doubles - it was the MS5637 pressure sensor causing the problem.
Depending on the OSR selected there is a built-in delay (per spec) between when reading the sensor. It increases for higher OSRs. Example: For an OSR_8192 there is a 34ms delay while for a OSR_1024 there is 10ms delay. At 512 its 6ms.
Once I changed the OSR to 1024, for SRD9 it worked fine no issue with double hits. Unfortunately for an SRD4 can't use the sensor.
Mike
Depending on the OSR selected there is a built-in delay (per spec) between when reading the sensor. It increases for higher OSRs. Example: For an OSR_8192 there is a 34ms delay while for a OSR_1024 there is 10ms delay. At 512 its 6ms.
Once I changed the OSR to 1024, for SRD9 it worked fine no issue with double hits. Unfortunately for an SRD4 can't use the sensor.
Mike
defragster
Senior Member+
Such long delays won't work - Ick. Don't see details in a quick scan . . . Assuming that is i2c? Would be a great test for the i2c_t3 Interrupt/DMA callback on completion code. Or put it on Slave and get reports when ready ... but that could break TViewer too.
tonton81 - not sure of context of ' bug in the usbserial buffer'? I posted a note for Paul on the TD 1.42 beta thread - it may just be message catch up as any buffered messages are likely sent on connect - that could cause even a short delay at just the wrong time?
Got my calibration analysis routine working. It's been really interesting to try different things out. I'm finally able to get what seems to be a very solid calibration now, and to verify that the calibration is good. I'll clean up the code, write up some instructions, and post soon.
A couple of things it does:
1. Allows for independent calibration of gyro, accel, and mag sensors using the MPU9250 library cal functions
2. Can view the IMU cal values before and after the cal to make sure they make sense
3. Can run a complete "static cal" where you place the IMU flat and level, pointing to magnetic North
4. Can compare static cal values to MPU9250 library calculated cal values
5. Can upload the static cal values to either the Teensy EEPROM or the IMU cal registers
6. Can stream the nine raw IMU values before and after the cal to see the effect. I also added a 10th parameter, heading, so you can verify the magnetometer cal was successful (i.e., check each quadrant, verify with iPhone compass reading).
7. Can see the effects of objects on the mag (and heading) readings in real-time. For example, using the iPhone compass is great for checking alignment to magnetic north, but it needs to be far away when you actually start calibrating!
I might also add calculating the noise sigmas for each of the IMU parameters since it's so easy to do with the circular buffer routine!
Don
A couple of things it does:
1. Allows for independent calibration of gyro, accel, and mag sensors using the MPU9250 library cal functions
2. Can view the IMU cal values before and after the cal to make sure they make sense
3. Can run a complete "static cal" where you place the IMU flat and level, pointing to magnetic North
4. Can compare static cal values to MPU9250 library calculated cal values
5. Can upload the static cal values to either the Teensy EEPROM or the IMU cal registers
6. Can stream the nine raw IMU values before and after the cal to see the effect. I also added a 10th parameter, heading, so you can verify the magnetometer cal was successful (i.e., check each quadrant, verify with iPhone compass reading).
7. Can see the effects of objects on the mag (and heading) readings in real-time. For example, using the iPhone compass is great for checking alignment to magnetic north, but it needs to be far away when you actually start calibrating!
I might also add calculating the noise sigmas for each of the IMU parameters since it's so easy to do with the circular buffer routine!
Don