uNav INS

mjs513 · Apr 13, 2018

Tim

Code:

'readSensorCounts

Nope readSensorCounts I added because I have an alternate method for calibrating that I am testing.

It just returns the raw data from the sensor in counts.

Thanks for temp.

I agree but haven't really been monitoring at this point - worked on getting baro installed and alternate messages working. Which they are now

When a version 7 gets posted with the new dt? I will incorporate my changes as well. Oh - I made the baro optional using a define, will be easy enough to add a different baro - like the MS5611 if Don wants to use it - have a library for that as well

Don
Here are those screenshots you asked for:

Mike

mjs513 · Apr 13, 2018

Hey Guys
Here's a link to a new version of Telemetry Viewer, https://www.dropbox.com/s/dz7hcga9vyoms1e/Telemetry Viewer_v1.jar?dl=0. Its a little different than the old version. Has a frequency domain and dial chart added. Also, scrollbars have been added to the chart selection and update chart windows. You will have to resize the window. Grid boxes are no longer but the number is now proportional to the size of the window

Mike

mjs513 · Apr 13, 2018

Tim

Forgot to mention, probably because I didn't notice before - but you didn't post the changes to the sketch to get the mag counts out?

Mike

Don Kelly · Apr 13, 2018

Thx, will check the screenshots out. Also looking forward to trying your TViewer as well!

I went back and did some runs of the original version of the 15-State (w/o mag) I posted back on 3/16 (post #41). The output looks nice and stable. PRY all start out fairly nominal at near +/- 1 deg, seems to behave well.

Then I did some runs of the first version of the 15-State (w/ mag), post 56 on 3/28. The PRY are +/- 1 deg initially, but on second iteration they jump to 5, -2, 11.9. Heading goes 348, then 0, then 354. So I'm thinking the mag noise levels (Q, R) are off, or something maybe off in the code. They shouldn't jump like that on the second iteration, at least it seems like it shouldn't!

I suppose I'll dig into to this for a bit, see if changing some weightings help or hurt. There are also other ways to incorporate mag info, which might be worth investigating at some point.

At least the first 15-State (w/o mag) looks very stable, so I have a potentially good point to start from!

Don Kelly · Apr 13, 2018

Mike,
Running your modified TViewer now on my PC. Nice. By any chance do you have any idea on how I'd get it to run on my iMac? I tried to run the earlier jar file on the iMac, and I get errors. I've got the JDE installed on the iMac, but guessing I need to make the jar natively on the iMac maybe, and probably change the way it connects to the serial ports.

Looks nice!
Don

mjs513 · Apr 13, 2018

Hi Don

Yeah - I don't have a mac so I can not compile it for a iMac. Only have a Windows 10 machine. Have to see if I can do it somehow.

Mike

mjs513 · Apr 13, 2018

Don
"Then I did some runs of the first version of the 15-State (w/ mag), " think you change R? as well it was 10x10? or something like that - you may want to check.

Don Kelly · Apr 13, 2018

R is 6x6 for the 15-State w/o mag measurements, and is a 9x9 for the 15-State w/ mag measurements. The Rw matrix (noises on accel and gyro) remains the same for either case, as it's used for calculating Q.

Right now I'm spending some time on the 15-State w/o mag to see how heading is initialized, and to see how the cal biases are used. Want to make sure that all looks right. If that makes sense, I'll move over to seeing how the R values are for the 15-State w/ mag, like make sure units and values seem to be reasonable.

I'm guessing I would need to create a jar file on the iMac for it to work. Not sure I'm wanting to take on Java right now too! Already confused enough going back and forth between Matlab, C, C++, Python. But hey, just another language I suppose...

Don

mjs513 · Apr 13, 2018

Hey Don
About the only thing I can do is generate a Jar file for java. I use intelijidea and it makes it easy - lots of instructions out there. Don't really have to know Java just how to generate the JAR.

Mike

mjs513 · Apr 13, 2018

Hi all
With tonton's help I am now able to send commands over serial from the slave to master so if I want to change messages while on the slave I don't have to switch back and forth - works nice.
Mike

defragster · Apr 13, 2018

With these present before loop():

Code:

uint32_t Mcnt = 0;
uint32_t McntN = 0;

Here is the gpsDebug() code:

Code:

void debugGPS( )
{
  static uint32_t cctLast = 0;
  static uint32_t GPScnt = 0;
  static unsigned char lastT = 'a';
  static uint32_t cctLast_IMU = 0;
  static uint32_t cctLast_GPS = 0;

  uint32_t ccNow = ARM_DWT_CYCCNT;

  qBlink();
  GPScnt++;
  if ( lastT != uBloxData.utcSec ) {
    coutD.print( "-----" );
    coutD.print( "Loop#:" );
    coutD.print( CntLoop );
    coutD.print( " IMU#:" );
    coutD.print( CntIMU );
    coutD.print( " >> 1Sec:" );
    coutD.print( ccPartSec( cctLast, ccNow ) );
    cctLast = ccNow;
    coutD.print( " >> IMUcc:" );
    coutD.print( ccPartSec( ccTimeNow_IMU, ccNow ) );
[B]    coutD.print( "\t >> Mcnt:" );
    Serial.print(Mcnt);
    coutD.print( " & !Mcnt:" );
    Serial.print(McntN);
    McntN = Mcnt = 0;
[/B]    coutD.println( );
    CntLoop = 0;
    CntIMU = 0;
  }
  lastT = uBloxData.utcSec;
  coutD.print( "    #" );
  coutD.print( GPScnt );
  coutD.print( "  @" );
  coutD.print( uBloxData.utcHour);
  coutD.print( ":" );
  coutD.print( uBloxData.utcMin);
  coutD.print( "." );
  coutD.print( uBloxData.utcSec);
  coutD.print( "_" );
  coutD.print( uBloxData.utcNano);
  coutD.print( " [fix:" );
  coutD.print( uBloxData.fixType);
  coutD.print( " #:" );
  coutD.print( uBloxData.numSV);
  coutD.print( " GPScc:" );
  coutD.print( ccPartSec( ccTimeNow_GPS, ccNow ) );
  coutD.print( " > cctAv:" );
  coutD.print( cctAvg );
  coutD.print( " > GSecs:" );
  char textTemp[30];  // won't match TViewer as it is done on GPS detect before serialPrint reset
  dtostrf(DrtcTime, 10, 6, textTemp);
  coutD.print( textTemp );
  coutD.print( " > IMUdt:" );
  dtostrf( FccPartSec( cctLast_IMU, ccTimeNow_IMU ), 10, 8, textTemp);
  coutD.print( textTemp );
  coutD.print( " > GPSdt:" );
  dtostrf( FccPartSec( cctLast_GPS, ccTimeNow_GPS ), 10, 8, textTemp);
  coutD.print( textTemp );
  cctLast_IMU = ccTimeNow_IMU;
  cctLast_GPS = ccTimeNow_GPS;
  coutD.println( );
}

My code still has this for IMU interrupt:

Code:

void runFilter() {
  ccTimeNow_IMU = ARM_DWT_CYCCNT; // use with ccPartSec(); to get time offset
  newIMUData = 1;
}

I still have the test dt in the uNavINS.cpp that uses this in the MAIN.ino I think I posted?

Code:

// a flag for when the MPU-9250 has new data
volatile int newIMUData;
volatile uint32_t ccTimeNow_IMU = 0;
volatile uint32_t ccTimeNow_GPS = 0;
volatile uint32_t cctAvg = F_CPU;
Circular_Buffer<uint32_t, 4> cctASec;

mjs513 · Apr 13, 2018

Thanks Tim. Put it back to the original while I was testing some SPI changes. Thanks for the dbug. Just wanted to make sure there were no other changes to timing.

Mike

defragster · Apr 13, 2018

mjs513 said:
Thanks Tim. Put it back to the original while I was testing some SPI changes. Thanks for the dbug. Just wanted to make sure there were no other changes to timing.

Mike

No - just that quick edit from where I was to confirm the time Mag data was changed.

Don Kelly · Apr 13, 2018

Mike,
got the MS5611 baro board in today. Still want to finish what I was doing with the 15-State w/o mag code, so I might mess with the MS5611 next week some time.
Don

mjs513 · Apr 13, 2018

"MS5611 baro board in today." Have fun with it. I still getting better and more consistent results with it than the GPS altitude - it may be the GPS has to be moving to get a better results. Good luck with the code review.

Tim - finally got your changes incorporated into the my version 6. But seeing a lot more instability. Yaw is cycling about 10degs as well pitch and roll where as before pitch and roll are rock steady for the most part. While yaw wasn't perfect it was better behaved without the changes.

I also checked the loop counter before and after your change - it went about 9200 down to 8950 so got a little worse. Oh, keep adding extra commands so I figured I add in one to turn the debugGPS messages on and off as well

works nice.

Mike

defragster · Apr 13, 2018

I should have posted my whole _Ver6.001 - ... who knows what kind of a monster you have created . . . from the crumbs I left.

Not sure why it would alter anything - unless you picked up the new dt and the prior dt spasms had been countered with code and the change to it being the int to int timing is messing with it?

I didn't track it from the first after Don put it up - but it seemed to jump with the drop of the func() calls to get values.

mjs513 · Apr 14, 2018

Tim - your probably right. For now I put it back mostly and will wait for the new version to make sure everything is covered. MIke

Don Kelly · Apr 14, 2018

Have been looking into my IMU heading data. I took the 15-State (w/o mag) and added the few lines of atan(x/y) code that calculates heading from the IMU hx and hy readings. I'm showing that when I align my IMU towards N, I'm getting pretty much a steady reading of 30 deg heading calculation rather than 0 deg. Am inside (away from metal), but will check it outside when rain stops.

I'm also using the circular_buffer to calculate a mean and sigma. The sigma comes out to be about 2.5 deg. I'll have to look at the units for the mag terms in R, think they are in uT so I will need to calc the sigma for hX, hY, and hZ directly too.

Anyway, I'm wondering if I'm either getting a bad cal, or if I need to check the cal with a compass and add a heading correction of -30 deg with my IMU. Going to let it go for a while and see if it remains steady.

defragster · Apr 14, 2018

Here is what I got from Don with my various changes - including the core MPU9250 files as I have them:

View attachment uNavINS_CB_Ver6_xx.zip

File names unchanged so you could do a DIFF.

One thing I did not do was add the counter to IMU int code to track at Imu.readSensorPMD() to skip IMU data when IMU data was missed. I started to put in a CB array to get Min/Max/Avg for the two versions of dt - old versus IMU_isr().

Question: how do you pass an 'extern' reference between files for a "Circular_Buffer<uint32_t, 512> Odt"? Between files "uNavINS_CB_Ver6.ino" and "uNavINS.cpp"? Or pass a CB as a parameter? Circular_Buffer is a template not a type.

mjs513 · Apr 14, 2018

Thanks Tim. I will check it out. Have a few things to do on the house while the weather is nice today.

To be honest don't know. Never tried. I know you can 'extern' variables. Maybe try putting extern Circular_Buffer<uint32_t, 512> Odt in the .cpp and populate it in the .ino or vice versa?

Mike

tonton81 · Apr 14, 2018

you can access them by scopes if necessary,
ex if its the library as a public: CB

library::Odt.mean();

mjs513 · Apr 14, 2018

Hi Tim,
Loaded up your code, yes I used code compare. Still missed one thing on first go

Anyway here are my observations, not sure if you see the same things:
1. Yaw is a more stable that it was before, now its about +/- 1.5 degrees
2. Pitch and roll - not so much. In previous iterations it pretty stable with minimal variation. Now I am seeing about +/- 1 degree variation in roll and pitch.
See screenshots for 1 and 2.

3. dt is very choppy - can see it as it is printing so I took a look at the loop counter and its all over the place:

Code:

GPS Debug On !
_
-----Loop#:5266 IMU#:199 >> 1Sec:60181672 >> IMUcc:135844	 >> Mcnt:35 & !Mcnt:164
    #2768  @18:22.57_-371507 [fix:3 #:10 GPScc:327464 > cctAv:167998902 > GSecs:646.928589 > IMUdt:0.20594513 > GPSdt:0.20565817
    #2769  @18:22.57_199628576 [fix:3 #:10 GPScc:256267 > cctAv:167998902 > GSecs:647.134521 > IMUdt:0.19994675 > GPSdt:0.20070846
    #2770  @18:22.57_399628660 [fix:3 #:10 GPScc:336585 > cctAv:167998902 > GSecs:647.334473 > IMUdt:0.19994679 > GPSdt:0.19910119
    #2771  @18:22.57_799628828 [fix:3 #:10 GPScc:20184330 > cctAv:167998902 > GSecs:647.534424 > IMUdt:0.39989358 > GPSdt:0.20145711
-----Loop#:9813 IMU#:365 >> 1Sec:100177160 >> IMUcc:139669	 >> Mcnt:67 & !Mcnt:298
    #2772  @18:22.58_-371088 [fix:3 #:10 GPScc:255699 > cctAv:167998900 > GSecs:647.934326 > IMUdt:0.20194618 > GPSdt:0.40122241
    #2773  @18:22.58_199628995 [fix:3 #:10 GPScc:298974 > cctAv:167998900 > GSecs:648.136292 > IMUdt:0.19794729 > GPSdt:0.19748650
    #2774  @18:22.58_399629079 [fix:3 #:10 GPScc:283695 > cctAv:167998900 > GSecs:648.334229 > IMUdt:0.19394839 > GPSdt:0.19412528
    #2775  @18:22.58_799629246 [fix:3 #:10 GPScc:19365456 > cctAv:167998900 > GSecs:648.528198 > IMUdt:0.40189302 > GPSdt:0.21107100
-----Loop#:9734 IMU#:362 >> 1Sec:99573656 >> IMUcc:139826	 >> Mcnt:65 & !Mcnt:297
    #2776  @18:22.59_-370669 [fix:3 #:10 GPScc:272595 > cctAv:167998899 > GSecs:648.930054 > IMUdt:0.20194623 > GPSdt:0.39288476
    #2777  @18:22.59_399629497 [fix:3 #:10 GPScc:20165374 > cctAv:167998899 > GSecs:649.132019 > IMUdt:0.40189302 > GPSdt:0.20294914
    #2778  @18:22.59_599629581 [fix:3 #:10 GPScc:337346 > cctAv:167998899 > GSecs:649.533936 > IMUdt:0.20594521 > GPSdt:0.40419236
    #2779  @18:22.59_799629665 [fix:3 #:10 GPScc:252613 > cctAv:167998899 > GSecs:649.739868 > IMUdt:0.19194947 > GPSdt:0.19285166
-----Loop#:9892 IMU#:367 >> 1Sec:100592016 >> IMUcc:158612	 >> Mcnt:66 & !Mcnt:301
    #2780  @18:23.0_-370251 [fix:3 #:10 GPScc:220824 > cctAv:167998899 > GSecs:649.931824 > IMUdt:0.20594457 > GPSdt:0.20644464
    #2781  @18:23.0_199629832 [fix:3 #:10 GPScc:219638 > cctAv:167998899 > GSecs:650.137756 > IMUdt:0.19394839 > GPSdt:0.19232634
    #2782  @18:23.0_399629916 [fix:3 #:10 GPScc:307060 > cctAv:167998899 > GSecs:650.329834 > IMUdt:0.19994688 > GPSdt:0.20049839
    #2783  @18:23.0_599629999 [fix:3 #:10 GPScc:280174 > cctAv:167998899 > GSecs:650.531677 > IMUdt:0.20794456 > GPSdt:0.20821542
    #2784  @18:23.0_799630083 [fix:3 #:10 GPScc:302874 > cctAv:167998899 > GSecs:650.739563 > IMUdt:0.19994679 > GPSdt:0.19971874
-----Loop#:14344 IMU#:531 >> 1Sec:140139584 >> IMUcc:135483	 >> Mcnt:93 & !Mcnt:438
    #2785  @18:23.1_399630333 [fix:3 #:10 GPScc:41164936 > cctAv:167998899 > GSecs:650.939514 > IMUdt:0.59984052 > GPSdt:0.19119579
    #2786  @18:23.1_599630417 [fix:3 #:10 GPScc:220499 > cctAv:167998899 > GSecs:651.539368 > IMUdt:0.19994667 > GPSdt:0.60959548
    #2787  @18:23.1_799630500 [fix:3 #:10 GPScc:279060 > cctAv:167998899 > GSecs:651.739319 > IMUdt:0.19594783 > GPSdt:0.19517535
-----Loop#:5246 IMU#:198 >> 1Sec:59988464 >> IMUcc:139919	 >> Mcnt:37 & !Mcnt:161
    #2788  @18:23.2_-369415 [fix:3 #:10 GPScc:273431 > cctAv:167998896 > GSecs:651.935303 > IMUdt:0.20394577 > GPSdt:0.20402886
    #2789  @18:23.2_199630667 [fix:3 #:10 GPScc:248727 > cctAv:167998896 > GSecs:652.139221 > IMUdt:0.19794734 > GPSdt:0.19820562
    #2790  @18:23.2_399630751 [fix:3 #:10 GPScc:290888 > cctAv:167998896 > GSecs:652.337158 > IMUdt:0.20194623 > GPSdt:0.20150642
    #2791  @18:23.2_599630834 [fix:3 #:10 GPScc:219156 > cctAv:167998896 > GSecs:652.539124 > IMUdt:0.19994684 > GPSdt:0.20111836
    #2792  @18:23.2_799630918 [fix:3 #:10 GPScc:252759 > cctAv:167998896 > GSecs:652.739075 > IMUdt:0.19794737 > GPSdt:0.19916181
-----Loop#:8729 IMU#:330 >> 1Sec:99974296 >> IMUcc:140822	 >> Mcnt:58 & !Mcnt:272
    #2793  @18:23.3_-368998 [fix:3 #:10 GPScc:269842 > cctAv:167998897 > GSecs:652.939026 > IMUdt:0.19994679 > GPSdt:0.19978666
    #2794  @18:23.3_199631085 [fix:3 #:10 GPScc:340024 > cctAv:167998897 > GSecs:653.138977 > IMUdt:0.19994682 > GPSdt:0.19919641
    #2795  @18:23.3_399631168 [fix:3 #:10 GPScc:296206 > cctAv:167998897 > GSecs:653.338928 > IMUdt:0.20194627 > GPSdt:0.20240147
    #2796  @18:23.3_599631252 [fix:3 #:10 GPScc:285281 > cctAv:167998897 > GSecs:653.540833 > IMUdt:0.19794783 > GPSdt:0.19806530
    #2797  @18:23.3_799631335 [fix:3 #:10 GPScc:220695 > cctAv:167998897 > GSecs:653.738770 > IMUdt:0.20194571 > GPSdt:0.20116404
-----Loop#:8756 IMU#:331 >> 1Sec:100171400 >> IMUcc:138872	 >> Mcnt:57 & !Mcnt:274
    #2798  @18:23.4_-368581 [fix:3 #:10 GPScc:258888 > cctAv:167998897 > GSecs:653.938843 > IMUdt:0.19994684 > GPSdt:0.20099632
    #2799  @18:23.4_199631502 [fix:3 #:10 GPScc:221670 > cctAv:167998897 > GSecs:654.140686 > IMUdt:0.19794729 > GPSdt:0.19842273
    #2800  @18:23.4_399631585 [fix:3 #:10 GPScc:305285 > cctAv:167998897 > GSecs:654.338623 > IMUdt:0.19594790 > GPSdt:0.19500075
    #2801  @18:23.4_599631668 [fix:3 #:10 GPScc:221084 > cctAv:167998897 > GSecs:654.534546 > IMUdt:0.20594516 > GPSdt:0.20539935
    #2802  @18:23.4_799631752 [fix:3 #:10 GPScc:258420 > cctAv:167998897 > GSecs:654.738708 > IMUdt:0.19794737 > GPSdt:0.19899045
-----Loop#:11441 IMU#:427 >> 1Sec:119395944 >> IMUcc:166573	 >> Mcnt:79 & !Mcnt:348
    #2803  @18:23.5_199631918 [fix:3 #:10 GPScc:20218838 > cctAv:167998897 > GSecs:654.938477 > IMUdt:0.39589468 > GPSdt:0.19654664
-----Loop#:12881 IMU#:464 >> 1Sec:99545296 >> IMUcc:138337	 >> Mcnt:85 & !Mcnt:379
    #2804  @18:23.6_199632335 [fix:3 #:10 GPScc:78775144 > cctAv:167998900 > GSecs:655.334351 > IMUdt:0.99573529 > GPSdt:0.40988979
    #2805  @18:23.6_399632418 [fix:3 #:10 GPScc:230274 > cctAv:167998900 > GSecs:656.330139 > IMUdt:0.20394577 > GPSdt:0.98944157
    #2806  @18:23.6_599632502 [fix:3 #:10 GPScc:220731 > cctAv:167998900 > GSecs:656.534058 > IMUdt:0.20594525 > GPSdt:0.20464887
-----Loop#:10938 IMU#:400 >> 1Sec:100403464 >> IMUcc:168487	 >> Mcnt:73 & !Mcnt:327
    #2807  @18:23.7_199632752 [fix:3 #:11 GPScc:40239840 > cctAv:167998899 > GSecs:656.738220 > IMUdt:0.59384209 > GPSdt:0.19529729
    #2808  @18:23.7_599632919 [fix:3 #:11 GPScc:20818048 > cctAv:167998899 > GSecs:657.333862 > IMUdt:0.40789154 > GPSdt:0.60034680
    #2809  @18:23.7_799633003 [fix:3 #:11 GPScc:219824 > cctAv:167998899 > GSecs:657.739807 > IMUdt:0.19994684 > GPSdt:0.40593490
-----Loop#:8107 IMU#:301 >> 1Sec:80546256 >> IMUcc:136176	 >> Mcnt:53 & !Mcnt:248
    #2810  @18:23.8_-366913 [fix:3 #:10 GPScc:309978 > cctAv:167998898 > GSecs:657.939758 > IMUdt:0.19794737 > GPSdt:0.19847955
    #2811  @18:23.8_199633170 [fix:3 #:10 GPScc:325899 > cctAv:167998898 > GSecs:658.139648 > IMUdt:0.19194898 > GPSdt:0.19179150
    #2812  @18:23.8_599633337 [fix:3 #:10 GPScc:20588592 > cctAv:167998898 > GSecs:658.331604 > IMUdt:0.40589213 > GPSdt:0.20377058
    #2813  @18:23.8_799633421 [fix:3 #:10 GPScc:235727 > cctAv:167998898 > GSecs:658.737488 > IMUdt:0.18795019 > GPSdt:0.39303449
-----Loop#:15353 IMU#:563 >> 1Sec:139768736 >> IMUcc:142055	 >> Mcnt:101 & !Mcnt:462
    #2814  @18:23.9_399633671 [fix:3 #:10 GPScc:40613664 > cctAv:167998898 > GSecs:658.927429 > IMUdt:0.60983777 > GPSdt:0.20605388
    #2815  @18:23.9_799633838 [fix:3 #:10 GPScc:18828936 > cctAv:167998898 > GSecs:659.537231 > IMUdt:0.39989376 > GPSdt:0.61816233
-----Loop#:6324 IMU#:233 >> 1Sec:60182612 >> IMUcc:140658	 >> Mcnt:40 & !Mcnt:193
    #2816  @18:23.10_-366077 [fix:3 #:10 GPScc:228941 > cctAv:167998895 > GSecs:659.937195 > IMUdt:0.19994688 > GPSdt:0.38751099
    #2817  @18:23.10_199634005 [fix:3 #:10 GPScc:221024 > cctAv:167998895 > GSecs:660.139099 > IMUdt:0.19794741 > GPSdt:0.19809462
    #2818  @18:23.10_399634089 [fix:3 #:10 GPScc:280785 > cctAv:167998895 > GSecs:660.337036 > IMUdt:0.19794737 > GPSdt:0.19725440
    #2819  @18:23.10_599634173 [fix:3 #:10 GPScc:251017 > cctAv:167998895 > GSecs:660.534973 > IMUdt:0.20394582 > GPSdt:0.20427915
    #2820  @18:23.10_799634256 [fix:3 #:10 GPScc:219438 > cctAv:167998895 > GSecs:660.738953 > IMUdt:0.19994684 > GPSdt:0.20041685
-----Loop#:8736 IMU#:330 >> 1Sec:99970544 >> IMUcc:137769	 >> Mcnt:61 & !Mcnt:269
    #2821  @18:23.11_-365659 [fix:3 #:10 GPScc:297042 > cctAv:167998897 > GSecs:660.938904 > IMUdt:0.19994688 > GPSdt:0.19897938
    #2822  @18:23.11_199634424 [fix:3 #:10 GPScc:221477 > cctAv:167998897 > GSecs:661.138855 > IMUdt:0.19994688 > GPSdt:0.19927253
    #2823  @18:23.11_399634507 [fix:3 #:10 GPScc:261374 > cctAv:167998897 > GSecs:661.336914 > IMUdt:0.19194894 > GPSdt:0.19301651
    #2824  @18:23.11_599634591 [fix:3 #:10 GPScc:243234 > cctAv:167998897 > GSecs:661.530701 > IMUdt:0.20994423 > GPSdt:0.21011838
    #2825  @18:23.11_799634675 [fix:3 #:10 GPScc:329928 > cctAv:167998897 > GSecs:661.740662 > IMUdt:0.19794744 > GPSdt:0.19704294
-----Loop#:8900 IMU#:336 >> 1Sec:101176552 >> IMUcc:141201	 >> Mcnt:59 & !Mcnt:277
    #2826  @18:23.12_-365240 [fix:3 #:10 GPScc:238549 > cctAv:167998899 > GSecs:661.938599 > IMUdt:0.21194367 > GPSdt:0.21290007
    #2827  @18:23.12_199634843 [fix:3 #:10 GPScc:289335 > cctAv:167998899 > GSecs:662.150574 > IMUdt:0.18994950 > GPSdt:0.18941274
    #2828  @18:23.12_399634927 [fix:3 #:10 GPScc:247934 > cctAv:167998899 > GSecs:662.340515 > IMUdt:0.19794741 > GPSdt:0.19837773
    #2829  @18:23.12_599635012 [fix:3 #:10 GPScc:220620 > cctAv:167998899 > GSecs:662.538452 > IMUdt:0.19994684 > GPSdt:0.20045410
    #2830  @18:23.12_799635096 [fix:3 #:10 GPScc:252202 > cctAv:167998899 > GSecs:662.738403 > IMUdt:0.19994688 > GPSdt:0.19941913
-----Loop#:11380 IMU#:425 >> 1Sec:118964544 >> IMUcc:137358	 >> Mcnt:77 & !Mcnt:348
    #2831  @18:23.13_199635266 [fix:3 #:10 GPScc:20198100 > cctAv:167998897 > GSecs:662.938354 > IMUdt:0.40189326 > GPSdt:0.20238626
    #2832  @18:23.13_399635351 [fix:3 #:10 GPScc:323903 > cctAv:167998897 > GSecs:663.340271 > IMUdt:0.20394582 > GPSdt:0.40267339
    #2833  @18:23.13_599635435 [fix:3 #:10 GPScc:310021 > cctAv:167998897 > GSecs:663.544189 > IMUdt:0.19594796 > GPSdt:0.19609012
    #2834  @18:23.13_799635521 [fix:3 #:10 GPScc:221124 > cctAv:167998897 > GSecs:663.740112 > IMUdt:0.19794741 > GPSdt:0.19888894
-----Loop#:6932 IMU#:262 >> 1Sec:79582256 >> IMUcc:140758	 >> Mcnt:50 & !Mcnt:212
    #2835  @18:23.14_-364393 [fix:3 #:10 GPScc:245577 > cctAv:167998897 > GSecs:663.938110 > IMUdt:0.19794741 > GPSdt:0.19769533
    #2836  @18:23.14_199635691 [fix:3 #:10 GPScc:278360 > cctAv:167998897 > GSecs:664.136047 > IMUdt:0.19794744 > GPSdt:0.19759130
    #2837  @18:23.14_399635776 [fix:3 #:10 GPScc:220288 > cctAv:167998897 > GSecs:664.333984 > IMUdt:0.20194635 > GPSdt:0.20107396
    #2838  @18:23.14_799635947 [fix:3 #:10 GPScc:20000800 > cctAv:167998897 > GSecs:664.533997 > IMUdt:0.40189326 > GPSdt:0.20556228
-----Loop#:9842 IMU#:366 >> 1Sec:100366152 >> IMUcc:133569	 >> Mcnt:67 & !Mcnt:299
    #2839  @18:23.15_-363966 [fix:3 #:10 GPScc:345189 > cctAv:167998895 > GSecs:664.937805 > IMUdt:0.20194638 > GPSdt:0.39843786
    #2840  @18:23.15_199636119 [fix:3 #:10 GPScc:278013 > cctAv:167998895 > GSecs:665.139771 > IMUdt:0.20394585 > GPSdt:0.20466530
    #2841  @18:23.15_399636205 [fix:3 #:10 GPScc:254160 > cctAv:167998895 > GSecs:665.343689 > IMUdt:0.19994688 > GPSdt:0.20021483
 
GPS Debug Off !

defragster · Apr 14, 2018

My unit is just online to provide a data stream for the - sitting stable. So I've not ever monitored YPR.

dt is very choppy

If referring to the "IMUdt:0.20594513" on the Loop# line - that was just for example purposes - it is near 0.2 secs because it is only shown on the GPS data reception complete. That's why I was considering a CB to hold each dt { one for old and new scheme } to get Max and Min and Avg on those.

If I can get those stats I can show how much the old and new dt differ - where that difference would have been feeding into the Filter.

The IMU is overdriving the Teensy - shown in these observed Second times (should be near 1 sec } and the GPSdt (should be near 0.2) - and the one Loop# group only shows 3 GPS reports instead of 5:
>> 1Sec:140139584, 1Sec:59988464, 1Sec:99974296, 1Sec:100171400
>> GPSdt:0.19119579, GPSdt:0.60959548, GPSdt:0.19517535

mjs513 · Apr 14, 2018

Tim - by choppy dt, from more of observational quality than measurement, is that as the data streams to the Tviewer it periodically stops streaming smoothly, like a longer time between samples, than at other times.

If I look at the loop numbers it goes from a min of 5200 to a max around 14000. The imu count goes from 199 to 500?

Oh, I typically look at YPR to see the impact of changes on yaw stability/drift as well as pitch/roll.

My extra sanity check

Mike

defragster · Apr 14, 2018

That is shown in the Master Debug output as noted - the IMU is coming in too fast to be processed sequentially and it overwhelming the Teensy. Indeed the IMU# should be STEADY and should closely match what the SRD specifies. The counts displayed are based on when the GPS data completes so IMU==500 is right and 499 - 501 is normal when the GPS second crosses a second of IMU updates - that would then show in the "1Sec:" number as below.

You should increase the SRD used to 2, and see it is can keep up with 333 IMU updates/sec. It should catch all IMU updates and should have a perhaps a consistent and larger number of free Loop#'s. That is the diagnostic value in showing IMU# and Loop#.

I just completed using CB's to record the NEW versus OLD "dt" calculations. You can see the OLD dt [ dtO ] based on elapsedMicros _t; as it was used maintains a good average - but regularly shows VERY extreme MIN and MAX values.

The NEW dt - based on the interrupt reception for IMU data ready may as well be a constant value because the MPU9250 ejects the data like clockwork. { except the one shown below somewhow has a DOUBLED MAX ? }

NOTE: These number are put as uint32_t counts of microseconds. They are done in parallel and something is wrong with the CB count >> Odt Count: 0

-----Loop#:590978 IMU#:500 >> 1Sec:99883384 >> IMUcc:134228 >> Mcnt:93 & !Mcnt:407
>> New_dt Avg: 1997_ Ndt Min: 1995_ Ndt Max: 3997_ Ndt Count: 500
>> Old_dt Avg: 1995_ Odt Min: 929_ Odt Max: 3467_ Odt Count: 0

-----Loop#:592660 IMU#:501 >> 1Sec:100136592 >> IMUcc:188248 >> Mcnt:93 & !Mcnt:408
>> New_dt Avg: 1997_ Ndt Min: 1997_ Ndt Max: 1997_ Ndt Count: 500
>> Old_dt Avg: 1995_ Odt Min: 931_ Odt Max: 3465_ Odt Count: 0

uNav INS

Senior Member+

Attachments

Senior Member+

Senior Member+

Well-known member

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Attachments

Senior Member+

Senior Member+

Senior Member+