uNav AHRS

Status
Not open for further replies.
Wondering if moving is weakening SPI line connects - or inducing noise on them?

My two T_3.6 and T_3.1 are female headered and velcro'd together side by side with min length 1-2" wires. The T_3.6 & T_3.5 pair are still using cheap fixed 4" molded tip jumper wires but Velcro tied at USB cables - wires run around sides under breadboard clear of GPS & IMU, when I get back to it I'll cut minimal length wires like the other pair.
 
you seen my bench on video, theres a good space between my teensies, even when handling the slave which is loose on desk, no issues, thats at 0ms 30mhz
 
Tim,
This version of uNavAHRS is not using the new SPI code. I'm guessing Mike was trying to get it more stable, then we'd bring it over.

Right now I'm running it, but when I move the IMU around the Yaw jumps from 0 to like 160 deg, so something's still wrong with it.

It'd be nice to get it to have stable solution, then try the SPI code on it. I'm slowly adding some hooks into the code to allow us to look at some of the inner workings of the EKF, but it's slow going as I've had issues with it crashing.
 
I'm guessing Mike was trying to get it more stable, then we'd bring it over.
Click to expand...
Yep. Shouldn't be jumping that much.. that's a new one on me. Using onehorse's version.

Tony - if you want a mpu-9250 breakout, I will send you one :) Basically its getting very stable yaw, pitch and roll angles. With the GPS version you also suppose to get better GSP positioning - more stable anyway.
 
Mike,
I ran onehorse's Mahoney and Madgwick filters a while back, worked well. Is that what you're running or does he have an EKF as well?

Thinking I need to go get the latest SPI library of Tony's and the Slave sketch and start using that for this uNavAHRS sketch. This sending to serial port is slow...

Don
 
Don,

No - I don't think so. At least I have not seen one. He basically uses the madgwick and Mahoney filters. You can basically use the master and slave sketched that you already have. Everything should be transparent on the back end.

If I am wrong - I am sure Tim or Tony will jump in here.

Mike
 
Hey guys. Chris O. has been doing a lot of work on the ublox library to allow for changing settings directly from the sketch. In his latest post he has been running GPS baud rates of 1.5M without an issue: see post 30
 
Here's something weird, wondering if anyone has seen this. I'm revising Brian's MPU9250 calibration routine so that I can calibrate each sensor (gyros, mags, accels) independently rather than all at once, and to output the calibration results. I wanted to go back and see if I was getting consistent calibrations.

For the MPU9250 that I have been using for uNavAHRS development, I'm not getting the Y and Z accelerometers to calibrate. What I get from calibration is this kind of result:

Current Accel Biases and Scale Factors:
0.640452, 0.998576
0.000000, 1.000000
0.000000, 1.000000

My other board (same Sparkfun MPU9250) calibrates just fine for all three axes. Anyway, guessing my MPU9250 board may have gyro issues. Anyone seen anything like this?

By the way, I'm wrapping up my mods to the CalibrateMPU9250 routine and will post if anyone's interested. Then my plan is to go back and dig into the 15-State some.

Don
 
Here's a revised version of Brian's CalibrateMPU9250 sketch. I wanted to dig in a bit more to calibration, as I thought that could be causing me some issues with getting some of my AHRS and INS routines to work.

This calibration version allows the user to select what they want to calibrate, provides instructions, and then shows you the before and after calibration result. This has been helpful for me to try to verify if my MPU9250s were getting calibrated and hopefully operating correctly.

View attachment CalibrateMPU9250Ver2.ino
 
Mike,
Good question. The MPU9250 I've been using lately definitely has an issue with the Y and Z gyros. For one thing, they won't calibrate at all.

This modified cal routine is showing me that my other MPU9250 not only calibrates, but repeated calibrations show consistent values, which is what I'd expect.

Ordered a couple more SparkFun MPU9250s today to have some more on hand...

Planning to dig into the 15-State uNavINS now that this cal routine is complete. Would be cool if someone has pulled together a simple IMU (and GPS) simulator to run the 15-State against. That would be a cool thing. I'll have to search and see if anyone has. Would be nice to feed known values to the 15-State and then veryify it's working before pumping real IMU and GPS data in. Using a second Teensy with the new SPI-Master interface would be a cool way to run a sim and send the data to the INS Teensy.
 
Quick question - are any of the three MPU9250 devices inherently better suited to FLOAT versus DOUBLE math in these calculations? That is: no value in the extra cost of Double handling where float would be so much faster with native instructions?

That may set up Apples to Oranges in the numbers - and pushing through Eigen might be the slow part - but I thought I'd throw it out just in case as any reduction in the math overhead could bump up to a full 500 IMU reads and updates /second. Bumping the TViewer format/output to the Slave gained 10% - but still 10% short of completing 500/sec. The MAG data is already introduced at a slower rate.

Obviously I'm working on the periphery not the core - been looking at SPI_MST exclusively for weeks and it can help - less overhead on Master - and much more usable and programmable with the Slave code static to TViewer and having USB direct to the main/Master unit not hobbled doing all that formatted output and keeping the DEBUG and potential for USB input to make on the fly adjustments if a 'command line' interface was added.

It looks like Chris O (?) got a UBlox unit that he can get PPS from the LED like I did - I should get back to that as a Cycle Counter time base - taking micros() out might buy a small amount of time and give a better Delta base for the clocking with improved resolution.
 
Tim,
Good question on the MPU9250. I only have the SparkFun version, and have had issues with one of them (bad gyros). Got two more on the way from SparkFun.

I'm still thinking that PPS is probably the best way to go for setting up a real RTC. My M8N doesn't have it, so thinking I'll need to pick up one that has PPS soon.

Don
 
Hi Don,
Figured out my problem. For some reason I had to reduce the I2C bus speed to 100K from the 400K I was running. Once I did that everything worked normally. Took a quick look at the code and it looked like the original version that Brian posted but with the GPS added. Like you said yaw still drifts a lot.

I say your notes on accel and gyro bias calibration and a few other things you want to do.

By the way I soldered up my new u-blox 8 UBX-M8030-KT gps (basically a M8) but it has the pps pin broken out. Works fine in the u-center. Have to do something with the pps to check it out. Going to look at linking it to SPI_MSTransfer between things. Also let me know what you want dumped and I will take a look at that as well. Your old Euler version 2 did some of that as well.

Mike
 
Mike, Odd it has to go that slow. Last I ran mine (3 weeks of SPI_MST?) I found the onehorse unit to work with 3.4 M:: #define IMU_SPD 3400000 //1000000 // 0==NULL or other
> That is what wiki or someplace told me was max standard i2c speed value.

Nice the uCenter works with that newly found uBlox. I followed the part number on the ebay to a PDF that suggested 2 ns jitter on PPS output ( and some note about 10 ns on input ?) - that is within the expected isr() interrupt response time. And at 120 MHz the cycle counter resolves to 8.3 ns per cycle.
 
The way that I found the problem was that I hooked up a completely different 9250 breakout board and it had the same problem. The only thing left that I didn't try was the i2c bus speed and then I did. I was actually running Onehorse's board at 1Mhz as a test and it worked fine but that was quite a while ago, think I was using TD1.41 for those tests. Wonder. Been using 1.42b3 lately so I am wondering - have to give it test with the old version.
I followed the part number on the ebay to a PDF that suggested 2 ns jitter on PPS output ( and some note about 10 ns on input ?) - that is within the expected isr() interrupt response time. And at 120 MHz the cycle counter resolves to 8.3 ns per cycle.
Click to expand...
Hmm. Didn't see that link to pps stats. Did you see what @TelephoneBill posted on the ublox primer thread on his test results?
 
The notes were this (50 ns not 10 as noted) from https://www.u-blox.com UBX-M8030-KT-FT_ProductSummary.pdf:
Time-pulse input Resolution: < 50 ns Time-pulse output Jitter: < 2 ns

Where ebay page noted : u-blox 8 UBX-M8030-KT chipset
Click to expand...

I saw those high freq notes from TBill - wasn't sure where he was reading those versus the PPS. In the PDF above that unit does not seem to have Temp Control Crystal - but if PPS timing derived from 'space clock math' the PPS should feed from that when it has a fix.

I suppose the 'input Resolution' is the variance from the 'space clock math'? With PPS base hour to hour the PPS might give error of 50-100 us versus Micros feeding from onboard crystal and measure being +/- 1 ms from second to second?
 
Timing would be a heck of a lot better for knowing when the fix occurred. I have no clue on the pps details. Guess I have some reading to do. :)

Oh, by the way, tested the i2c at 400khz with the old ide and same thing happened. I running it a 1Mhz now and it doesn't seem to happen. Was talking to Onehorse over on GITHUB since I thought I may have blown my 9250. He mentioned a little while ago that he had a similar problem when using the i2c_t3 library when he was testing a BNO55. Was
... traced to a bad timer call in the library. In that case, it
worked at some I2C clock speeds but not others. Wasn't limited to the interrupt though....it was an I2C problem.
Click to expand...
Good to know for future reference :)
 
mjs513 said:
Timing would be a heck of a lot better for knowing when the fix occurred. I have no clue on the pps details. Guess I have some reading to do. :)

Oh, by the way, tested the i2c at 400khz with the old ide and same thing happened. I running it a 1Mhz now and it doesn't seem to happen. Was talking to Onehorse over on GITHUB since I thought I may have blown my 9250. He mentioned a little while ago that he had a similar problem when using the i2c_t3 library when he was testing a BNO55. Was
Good to know for future reference :)
Click to expand...

Would be interesting to see/hear what it does 3.4 M:: #define IMU_SPD 3400000. It functions - but I wasn't moving anything or evaluating the returned data.
 
Had a problem with I2C again at IMU_SPD 1000000, so back to 100khz. Think we should probably post back to the i2c_t3 thread or revert back. What do you all think?
 
Status
Not open for further replies.
Back
Top