uNav INS

Mike, Tim,

I'm going back and trying to document some of the versions/changes we had. I have them all saved, but didn't a great job of documenting what we did. Started a log book for my IMU projects, so lesson learned for next time!

Attached are photos of the Perma-Board (from Adafruit) version I just soldered up this morning. Testing it with the cal routines now, looks like it's working. So will figure out how I want to plug in the GPS next (maybe second layer, i.e. GPS board on top). Then I'll start using it to start on some EKF testing again.

Don

uNavINS Perma-Proto, Front.JPG
uNavINS Perma-Proto, Back.JPG
 
Hey Don,
Documentation is my biggest problem as well, so don't feel bad. I start then get side tracked. I have been testing with the new version of the GPS library from Chris O. and its pretty much a drop in replacement for Brian's library. Except it allows you to change the GPS rate and NAV5 as well plus. I also tested with a 10hz update rate with the current version which basically gives updates about as fast as the IMU does.

Mike
 
Mike,

Sounds like I need to catch up on Chris O's library!

tonton81 - that is crazy stuff. thinking there could be some interesting applications for this!

Don
 
Hi Tim - Don
Found the source of the issue with the erratic YPR that I described a few posts ago. It is not the timing. The timing changes are fine. The issue is with the readSensorPMD function. Can't pin it down why since only the magnetometer should be affected or it may be in how I am using the data - have to do a double check of that. How did I find out - I changed back to the just using the readSensors call as opposed to the PMD call and it behaved nicely. The other thing I noticed is that it would just hang the data flow - loose imu data?

Mike
 
Here's my final hard-soldered config. GPS (M8N) mounted on top, JST-GH connector to main board. Did a quick test and it seems to be processing both IMU and GPS data. So solders look good. Can get back to looking at EKF now that this and cal routine done...

Don

IMG_1603.JPG
 
Don

First - nice job. I have just one question where are the connections for spi to the slave?

Mike
 
Mike,

My plan is to add another 4-wire JST-GH connector, like I did for the GPS. But I'm waiting for my JST cables to arrive from mRobotics. So in the meantime, I'm doing some experiments without the slave, and cataloging those earlier versions of uNavINS that we posted.

The JST connectors will allow me to easily plug-in/remove either the Slave T36 or the GPS.

Don
 
Last edited:
Don.
You got me worried for a minute:) I didn't see anyplace for them so....

Don and Tim
I made some headway with the PMD function. I figured out how to use the magnetometers data ready bit to determine when the mag is actually updated - I am also now testing for when there is an overflow condition on the magnetometer. Unfortunately, for some reason the GPS is not updating like it should so the filter gets stuck. Anyway if you are interested here is the code for the PMD function:
Code:
// Added to \libraries\MPU9250\MPU9250.cpp
int MPU9250::readSensorPMD(float* ax, float* ay, float* az, float* gx, float* gy, float* gz, float* hx, float* hy, float* hz, bool* MagD)
{
  _useSPIHS = false; // use the high speed SPI for data readout
  bool newMagData = 0;

  uint8_t rawData[7];  // x/y/z gyro register data, ST2 register stored here, must read ST2 at end of data acquisition
  uint8_t dest[1];
  
  readAK8963Registers(AK8963_ST1,1,dest);
  newMagData = (dest[0] & 0x01);
    
    readAK8963Registers(AK8963_HXL,7,rawData);
    //readRegisters(EXT_SENS_DATA_00,7,&_buffer[0]);
    readAK8963Registers(AK8963_ST2,1, dest); // End data read by reading ST2 register


  if(newMagData == 1 && rawData[6] == 0x10) { // wait for magnetometer data ready bit to be set
    _hxcounts = ((int16_t)rawData[1] << 8) | rawData[0];
    _hycounts = ((int16_t)rawData[3] << 8) | rawData[2];
    _hzcounts = ((int16_t)rawData[5] << 8) | rawData[4]; 
    *MagD = true;
  } else {
    *MagD = false;
    //_hxcounts = 0;
    //_hycounts = 0;
    //_hzcounts = 0;
  }  
  
  // grab the data from the MPU9250
  if (readRegisters(ACCEL_OUT, 14, _buffer) < 0) {
    return -1;
  }
  // combine into 16 bit values
  _axcounts = (((int16_t)_buffer[0]) << 8) | _buffer[1];
  _aycounts = (((int16_t)_buffer[2]) << 8) | _buffer[3];
  _azcounts = (((int16_t)_buffer[4]) << 8) | _buffer[5];
  _tcounts = (((int16_t)_buffer[6]) << 8) | _buffer[7];
  _gxcounts = (((int16_t)_buffer[8]) << 8) | _buffer[9];
  _gycounts = (((int16_t)_buffer[10]) << 8) | _buffer[11];
  _gzcounts = (((int16_t)_buffer[12]) << 8) | _buffer[13];


  // transform and convert to float values
  *ax = (((float)(tX[0] * _axcounts + tX[1] * _aycounts + tX[2] * _azcounts) * _accelScale) - _axb) * _axs;
  *ay = (((float)(tY[0] * _axcounts + tY[1] * _aycounts + tY[2] * _azcounts) * _accelScale) - _ayb) * _ays;
  *az = (((float)(tZ[0] * _axcounts + tZ[1] * _aycounts + tZ[2] * _azcounts) * _accelScale) - _azb) * _azs;
  *gx = ((float)(tX[0] * _gxcounts + tX[1] * _gycounts + tX[2] * _gzcounts) * _gyroScale) - _gxb;
  *gy = ((float)(tY[0] * _gxcounts + tY[1] * _gycounts + tY[2] * _gzcounts) * _gyroScale) - _gyb;
  *gz = ((float)(tZ[0] * _gxcounts + tZ[1] * _gycounts + tZ[2] * _gzcounts) * _gyroScale) - _gzb;

  *hx = (((float)(_hxcounts) * _magScaleX) - _hxb)*_hxs;
  *hy = (((float)(_hycounts) * _magScaleY) - _hyb)*_hys;
  *hz = (((float)(_hzcounts) * _magScaleZ) - _hzb)*_hzs;
  return 1;
}
 
Mike,

I also still have the old breadboard setup still, with Master and Slave T36s. Would just need to move the GPS back over.

Don
 
Thanks Don. Took me a while to break the code on to get it to read the data ready bit. But it seems to work. Now if I can figure out why the GPS is not updating :(

Mike
 
tonton81 - that is crazy stuff. thinking there could be some interesting applications for this!

Don

im sure someone might find 18 uarts and 3 usberials, 7spi busses, 12 wire busses, and ~180 gpio control useful lol :)

Just think what would happen if we could, instead of using the 12Mbps USBSerial, if the 480 ever worked out working on the T3.6...... :O
 
Last edited:
Don-Tim
Just as an update = I tried the code change with the library, but had to put the GPS in its own thread, seems like the method eats up too much time I guess. Unfortunately I still get the same as before. Has to be something with the way mag update is handled? Interesting thing, is that when I bring it back to rest it continues to oscillate in YPR.

Mike
 
Mike,

hmmm... weird...

i'm still studying calibrations, as I'm still seeing some unusual behaviors with the heading at times. Want to work on this a bit more before I get back to the 15-state. Have had house guests, so not much accomplished last couple days, but will get back to work on things tomorrow.

Don
 
Don

Thanks for getting back. I noticed heading follow yaw pretty closely. In other words, whatever, yaw does heading follows. So if heading in weird so is yaw. What you might be seeing may not be an issue with the calibration but an issue with yaw?

Mike
 
Mike,
In the calibration code, I'm calculating heading directly from the calibrated magnetometer readings, so not really even calculating yaw.

But if I'm understanding it, the EKF is continually tweaking heading (via the calibrated magnetometer readings) and yaw is just an offset from heading. But I'd need to go back and dig in to make sure that's correct.

Don
 
Don,

Got it. Thanks - thought you were doing it from the library.

By the way I just posted something you and Tim may interested on the UBLOX thread by Chris O (https://forum.pjrc.com/threads/4605...-for-beginners?p=177067&viewfull=1#post177067) I used his setup (screen and all) to change the pps frequency and then measured it with a T3.5. Good stuff. You want accurate time :)

Mike

EDIT:
Yaw from heading, yep
Code:
float uNavINS::getYaw_rad() {
  return constrainAngle180(psi-psi_initial);
 
...
By the way I just posted something you and Tim may interested on the UBLOX thread by Chris O (https://forum.pjrc.com/threads/4605...-for-beginners?p=177067&viewfull=1#post177067) I used his setup (screen and all) to change the pps frequency and then measured it with a T3.5. Good stuff. You want accurate time :)

Saw that - not sure how that would help having 1000 or 1000000 processor interrupts each second - if they are triggering the inbuilt timer it is hardware and not bad - but that give freq. With more information comes more effort to make sense of it?

Seems enough overhead once a second to get a baseline average to the elapsed cyclecounts that seem to be stable.
 
Mike,
I need to check out Chris O's GPS lib, have been spread thin lately with my data analytics project and other stuff.

Prob a dumb question, but assume Chris O's lib requires PPS pin access (which unfortunately my mRobotics Dual M8N doesn't have). Think I need to find another board that does, maybe even move up to the M8P (or similar) so I can eventually pass in RTK correction too.

Don
 
Don

Actually, no it does not require access to the pin. Everything is done through software and set via TP5 messages. I attached the pps pin to a 3.5 to check the pps pin output since the unit I picked up off ebay had one. Think Chris O. has one on order though.

Just started back up this morning on using the RTKLIB since I have not used it for a while :)

Mike
 
Mike,

Thx. I ordered the same one via ebay as well. So I'll finally have one with PPS pin...

I've been experimenting still with the cal routine. Am able to get what I think is really good cal now, and I can use the sigma values it calculates for the mag R values. I'm running the 1st mag version (before we added the slave capability), which is uNavINS_MPU9250_I2C_MAGV1. I want to keep testing this version a bit, making sure the PRY and Heading stay stable. Then I think I'll add that JST-GH connector to my setup so I can plug the Slave T36 in to see the 77 parameters too.

Don
 
Hi Don,

I have been using it and its actually not a bad little unit. I just got a Drotek M8T to play around with RTKLib again. Getting interesting.

Mike
 
Mike,

Which Drotek M8T did you get, the plain one without the compass? Think I'll do the same! Would like to think about incorporating RTK into what we've been doing here. Maybe kick off an RTK-Teensy thread???

Will be out-of-pocket for 5-6 days here, but might try to go ahead and get the M8T ordered...

Don
 
Back
Top