Notifications
Clear all

Inertial Navigation System (INS) - Gyros, Accelerometers & Magnetometers

17 Posts
4 Users
2 Likes
1,869 Views
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

I wanted to start a separate thread to discuss and explain using these little, cheap digital sensors.  Accelerometers, Gyroscopes and Magnetometers.  There are many flavors out there using the same principle.  Some of these chips are sold independently on break-out-boards and some are combined on one BOB - to give you 10DOF worth of data.  Examples include:

  • L3GD20
  • LSM303D
  • GY-89
  • GY-91
  • GY-521
  • MPU-6050
  • LSM6DS3
  • WT901
  •  

I'm by no means an expert and will be sharing what I think I know and what I discover as I try to use one of these units in an Inertial Navigation System (INS) for a robot.  I would ask that if you know anything about these - theoretical, manufacturing, design, usage, pitfalls, etc, please share.

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
Quote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

I wanted to start out specifically with the Gyro, because they are giving me the most trouble in regard to trying to use it for an INS.  I was trying to describe what I remember from my Father being an airline pilot.  https://forum.dronebotworkshop.com/user-robot-projects/inqling-junior-robot-mapping-vision-autonomy/paged/12/#post-33198

I'm sure your familiar with a Gyroscope.

image

As my Father described, the ones used in commercial aircraft used a very expensive, highly precise, spinning disk in a vacuum chamber that would be spun up at the beginning of a flight.  And because of it never changing its attitude no matter what the plane was doing, lasers could be used to peer inside the vacuum chamber and see what the angle of the plane was relative to the disk at any given time.

This combined with similarly accurate accelerometers readings could be Integrated  (as in Calculus) and could tell exactly where they were on the Earth.  In example, they were accurate enough after a 14 hour flight of some 6700 miles to be with 10 feet of their actual position.  Also when he was flying, GPS was not approved for use on an commercial aircraft by the FAA.

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  
image

This is a L3GD20 motion sensor - Three-axis digital output gyroscope.

Well, I don't know about you, but I don't see how they squeezed a spinning disk, vacuum chamber, lasers into a chip 4mm x 4mm x 1mm!  🤣 Joking aside... I, as yet, haven't seen anything of how this chip functions.  How does it know its been rotated in the last moment.  Obviously, it does not work on the same principles as the analog gyroscope.  Anyone know about these thing's working principle?

Also... it does not keep track of its starting orientation like an analog gyroscope.  It only tells you how fast it is currently being rotated.  (say in... degrees per second).

It is up to us and our program to check it periodically and keep track of its new orientation by simply summing its rate multiplied by the time interval and adding this to where it was before...  And do this for all three axes.

Next up... seeing some data spit out of one of these things and just how raw and crude and far removed it is from using it in an INS.

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2504
 
Posted by: @inq I, as yet, haven't seen anything of how this chip functions.  How does it know its been rotated in the last moment.  Obviously, it does not work on the same principles as the analog gyroscope.  Anyone know about these thing's working principle?
Try checking out Dejan's video on the subject ...
 

Also... it does not keep track of its starting orientation like an analog gyroscope.  It only tells you how fast it is currently being rotated.  (say in... degrees per second).

It is up to us and our program to check it periodically and keep track of its new orientation by simply summing its rate multiplied by the time interval and adding this to where it was before...  And do this for all three axes.

I think, to be fair, the spinning "top" doesn't keep track of anything either. Its orientation is constantly monitored by an external device and those measurements are analyzed and accumulated to provide an estimate of the current location.

It's probably more difficult than your silicon version because you don't have to worry about spherical orientation in your test school house (hopefully it's in better condition than that).

 

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

The graph below shows the output from a L3GD20 chip.  The chip is being sampled every 6ms.  It has not been calibrated.  The raw data has simply been converted to human understandable units of rotation rate (degrees/second).  The first (red) curve is only showing one of the three axes - Z axis (Yaw).  The second (green) curve is simply doing the numerical integration of this velocity data by summing the rate times the sample duration (6 ms).  This should be giving us the angle that it has been moved since the start of the plotting.  Note:  The sensor is not being moved!

image

The first thing you'll note... the chip thinks its moving.  In this display for 2 minutes, the sensor drifted 80 degrees!  They must be calibrated.  Apparently embedding them in the plastic chip case builds up stresses in them.  Heat from soldering them to a break-out-board adds stresses to them.  These stresses have to be calibrated out.  The recommended calibration is to take readings for a while (while not moving) and take an average.  In this second graph, the chip has been calibrated for 1000 samples at 6ms.  They also mention, that this calibration value should not change unless new stresses occur.  That supposedly, we can store this calibration value and save us this calibration time of 6 seconds.  I also tried 500 samples and it was not sufficient to get a reasonably zero norm.  Even after calibration, it still has drifted 8 degrees in 2 minutes.

image

Now if you think about this, how do you this sensor in a INS?  Even if your bot ran around the room in only two minutes and returned to its original spot, it would be 8 degrees off.  If it was using that drifting angle to "keep going strait" it would have veered by 8 degrees after two minutes.

Caveat!

Data Sheet - https://www.pololu.com/file/0J563/L3GD20.pdf

I'm still not sure if I'm using it to its best behavior.  I am currently using the library's default settings of +/-250 deg/sec range, 190 Hz sample rate and 50 Hz cut-off filter.  It is not clear if the value received at each sample is an average for that sample period or an instant value at the current moment.  Since the millisecond timer is only good at integer milliseconds I have the Sketch sample it at 6 ms intervals => 167 Hz.  What's going on in that other fraction of a millisecond?

I'm also not clear on what the cut-off filter is doing.  

More experimentation is necessary.

VBR,

Inq

 

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  
Posted by: @will
 

I got enough band-width to watch it at 360P.  Cool!

Two questions came to mind watching it...

  1. So... something is physically moving on the chip.  How in the heck do they do that on a silicon chip wafer?
  2. His illustrations, made sense for the two in-plane axes, how about the vertical (out of plane) on the chip?

Anyway... it is following mechanical principles that I can at least wrap my mind around that part, but the scale is mind-boggling.  

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1608
 

Hi @inq,

   re: So... something is physically moving on the chip. How in the heck do they do that on a silicon chip wafer?

Short answer ... MEMS ... very small machining!

I had a quick trawl for a description ... I found this overview ... don't expect to find much 'practical' information for your projects, and it's a couple of decades old, but you might find it interesting as a background flick read.

https://www.lboro.ac.uk/microsites/mechman/research/ipm-ktn/pdf/Technology_review/an-introduction-to-mems.pdf (1.5MByte)

And as for

His illustrations, made sense for the two in-plane axes, how about the vertical (out of plane) on the chip?

My simplistic understanding is that the constructions are done in all three axis directions..

 

Best wishes, Dave

 


   
Inq reacted
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Did more tests on the Gyro using different sampling rates (190, 380 and 760) and different frequency filtering (12.5, 20, 30...).  In all cases, the gyro is not moved at all.  In a perfect sensor, the Gyro rate should be zero and thus drift would also be zero.  I also ran some tests for multiple hours and in all cases, there is significant variability in the Gyro rate.  It does not seem to be heat related as the sensor was run continuously which should have heat stabilized it.

In this example run at 760 Hz, the Gyro rate changed significantly from the start of the test, but started coming back down and then back up.  Note the integrated total drift was approaching 140 degrees.  I used one hour as I feel most mappings of any significant area will take at least an hour.

image

As mentioned earlier, there are some residual stresses due to manufacturing and soldering, so the recommended procedure is to run it for a bit without movement to get a baseline rate.  In all cases, this rate changes continuously no matter how long it is run.  In essence, it needs to be recalibrated every time and even during use.  

When used in self-balancing robots, the drift angle is reset every time the robot returns to an upright position as determined by an accelerometer.  But even this is problematic as the Gyro's rate is changing even while stationary.  In essence the robot will think it is tilting over even though is not in reality. 

As balancing robots are pretty common, apparently this variable gyro rate is small enough over short periods of time to compensate and explains why some oscillate at top dead center.

Unfortunately, for this topic (INS) the lengths of time before it would have to be re-calibrated makes it unsuitable for Inertial Navigation.  In this one minute snapshot, the robot counting on this gyro sensor to maintain a strait line would have veered over 2 degrees.

1min

VBR,

Inq

P.S. - Next up seeing what we can do with a Magnetometer.

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Gyro Test Code

#include <InqPortal.h>
#include <Wire.h>
#include <L3G.h>

InqPortal svr;
L3G gyro;                   // Gyroscope    

const u8 LL        = 1;     // Log Level
const s32 AVERAGE  = 1000;  // Running average
const float OLD = (float)(AVERAGE - 1) / AVERAGE;
const float NEW = 1.0 / AVERAGE;
const float GF = 8.75 / 1000.0; // Convert raw data to degrees/sec.  

// Number of samples per second.
const u32 SPS = 190;        // Use same samples/sec as REG!!!!
//                          // Samples/sec, Filter
// const u8 REG = 0x6F;     // 190, 50  - Default
const u8 REG = 0x4F;     // 190, 12.5
// const u8 REG = 0x8F;     // 380, 20
// const u8 REG = 0xBF;     // 380, 100
//const u8 REG = 0xCF;     // 760, 30

const float dT = 1.0 / (float)SPS;
const u32 USEC = 1000000 / SPS + 1; // Microseconds to fetch results

float yaw = 0;
float drift = 0;
float Average = 0;

void setup() 
{
    // InqPortal stuff
    svr.autoSend(0);
    
    // GY-89 Sensor Data
    svr.publishRO("A", &Average, "Average Offset");
    svr.publishRO("Y", &yaw, "Yaw Rate (deg/sec)");
    svr.publishRO("D", &drift, "Drift (deg)");
    
    // Start up I2C software and sensors
	Wire.begin();
	Wire.setClock(1000000); 

    initGyro();   

    // Start the InqPortal Server
    svr.begin(DEFAULT_HOST_SSID, NULL, YOUR_SSID, YOUR_PW);
}

// -----------------------------------------------------------------------------

void loop() 
{  
    #define SECOND 1000000
    static u32 lastSample = micros();
    static u32 lastSecond = lastSample;
    u32 now = micros();    

    static s32 Y = 0;
    static s32 cnt = 0; // How many samples summed for this Yaw Rate
    
    static s32 sum = 0;

    if (now - lastSample > USEC)
    {
        gyro.read();
        Y += gyro.g.z;
        //Average = OLD * Average + NEW * gyro.g.z;
        cnt++;
        lastSample = now;
        
        if (now - lastSecond > SECOND)
        {
            Y -= Average * cnt; // Subtract-off all the offsets one time.
            yaw = GF * Y / cnt; // Average degrees/sec over the 1 second.
            drift += yaw * (now - lastSecond) / SECOND;

            svr.send("lflflf", "Y", yaw, "D", drift, "A", Average);
            cnt = 0;
            Y = 0;
            lastSecond = now;
        }
    }
}

// GYROSCOPE METHODS ===========================================================
// The sensor outputs provided by the library are the raw 16-bit values
// obtained by concatenating the 8-bit high and low gyro data registers.
// They can be converted to units of dps (degrees per second) using the
// conversion factors specified in the datasheet for your particular
// device and full scale setting (gain).

// Example: An L3GD20H gives a gyro X axis reading of 345 with its
// default full scale setting of +/- 245 dps. The So specification
// in the L3GD20H datasheet (page 10) states a conversion factor of 8.75
// mdps/LSB (least significant bit) at this FS setting, so the raw
// reading of 345 corresponds to 345 * 8.75 = 3020 mdps = 3.02 dps.

// -----------------------------------------------------------------------------

void initGyro()
{
    ESP.wdtDisable();
	if (gyro.init())
	{
		gyro.enableDefault();
        gyro.writeReg(0x20, REG); 
        
        // Calibrating the L3GD20 by reading the gyro offset AVERAGE times and
        // calculating the mean value
        delay(100);
        Average = 0;
        for(s32 i=0; i<AVERAGE; i++)
        {
            gyro.read();
            Average += gyro.g.z;
            delayMicroseconds(USEC); 
        }
        Average /= AVERAGE;
	}
	else
		svr.LOG(LL, "Gyro Initialization - Failed\n");
    ESP.wdtEnable(3000);    
}

// -----------------------------------------------------------------------------

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Magnetometers

I'm guessing that all electronic magnetometers (electronic compasses) work the same way and have the same basic limitations.  Here are my observations and my assumptions of what is going on.  By all means... if you have a different opinion or knowledge, please weigh-in and enlighten us all.

I have this GY-89 combined module sitting in the crotch of Inqling Jr.  It is the blue board to the right... RIGHT NEXT TO THE MAGNETS in the stepper motor.  I really didn't have any expectation of the magnetometer being worth even looking at the data.  The self-balancing aspect I want to eventually achieve only uses the accelerometer and the gyroscope.  So the... magnetometer, barometer and thermometer were pretty much sacrificial to the project.  I may monitor the thermometer just to keep track of heat in the chassis.

DryFit

The head for Inqling Jr is well above the stepper motors, but it has its own problem with the magnets in the servo to turn the head from side to side.  At first I was considering creating some kind of stalk sticking out of the top of this head unit and place its GY-89 module on top away from all motors.

Head2

To determine how far away it had to be, I configured just the ESP8266 and GY-89 setup on a breadboard running.  Simply moving an unconnected servo within 12 inches of the GY-89 started affecting it.  This was rather discouraging as I'm not willing to add that much height simply for the sensor.  Fortunately, I persevered studying its behavior.

Book 2 War and Peace coming up...

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Like the Gyroscope and Accelerometers, fabrication processes of the chip and even wave soldering the chip onto these break-out boards causes variability in every chip.  They all have to be calibrated.  A lot of compass aps on cell phones tell you to wave it over your head in a figure 8 pattern.  That didn't really make a lot of sense to me until I started doing the calibration on the sensor using the simple ESP8266 and sensor on a breadboard and seeing the raw data.  The ESP8266 is pumping out the data at 100 Hz (the fastest).

This image shows a plot of the raw data coming out of the sensor before calibration.  Note the wildly different ranges of each axis.  More on this later.

image

The purpose of the figure 8 pattern suggested to calibrate our phone's magnetometers is so we can see what the maximum and minimum is on all three axes.  Them telling us to do the figure 8 is to dumb-down the procedure because what we really need to do is move it around and make sure each positive AND negative axes sees its absolute extreme.  Anything else and the heading value calculation is less accurate.

Putting the Sketch (and sensor) in Calibration mode, all we're really doing is moving the sensor around and watching it fluctuate.  Here is the Admin page showing this raw data gathering.

image

Let me explain what these numbers mean.  Each of the three main lines Mx, My, Mz have four numbers out next to them.  These are:

  1. The most negative value sensed during the calibration.
  2. The current value sensed (this is flashing by at 100 Hz)
  3. The most positive value sensed during the calibration.
  4. This is the difference = Max - Min.

My speculation of what is going on is that the magnetic field being experienced by the sensor is (1) constant and (2) has an absolute maximum value in some, single direction.  It is not necessarily due North and it is not even necessarily in the same plane as the ground.  

It is our goal during the calibration process to make all six axes (+X, -X, +Y, -Y, +Z, -Z) line up with this real world maximum so that axis' gets its most extreme value.  In a perfect sensor, these would spread exactly evenly about zero and be the same for all three axes.  Since its not perfect, they will have different extremes, but I would think the difference between the MAX and MIN should be the same IF they all experienced that one single direction.

In the above example, as I rotated the sensor around the last number of each axis got larger and they do appear to arrive at the approximately same magnitude.  The only reason I can surmise for the discrepancy from ~10000 to ~13000 is that I didn't get all axes to point in that one direction OR the sensor just has different sensitivity on each axis due to manufacturing or design differences of the three axis.  This doesn't seem all that odd to me considering one axis has to be out of the plane of the chip. 

Book 3 War and Peace coming up...

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2504
 

@inq 

Just a quick question - does the rate of data collection make a difference at all ? That is, do you get comparable results if you collect at 10Hz as opposed to 100Hz ?

I'm just wondering if a longer time between readings would allow the device to de-saturate itself and give less violent oscillations ?

Anything seems possible when you don't know what you're talking about.


   
Inq reacted
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  
Posted by: @will

@inq 

Just a quick question - does the rate of data collection make a difference at all ? That is, do you get comparable results if you collect at 10Hz as opposed to 100Hz ?

I'm just wondering if a longer time between readings would allow the device to de-saturate itself and give less violent oscillations ?

Good question... the data sheet didn't indicate such a thing and it doesn't talk about integrating things like the ToF sensor does.  But, I will try it and let you know.

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Here is 10 seconds worth displaying with the sensor only spitting out 6.25 Hz for each Mx, My and Mz (Closest to 10 that it has).

image

Here is 10 seconds worth displaying the full 100 Hz.

image

Here is 10 seconds worth displaying the full 100 Hz coming from the ESP8266, but the Histogram is configured to average 16 points for every point it displays => giving 6.25 Hz.

image

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2504
 

@inq 

Very interesting, the (averaged by 16) chart looks the most stable, but that's not at all surprising. Visually, there appears to be no indication that a longer pause between readings has any stabilizing effect at all 🙁

Thanks for satisfying my curiosity Inq.

Anything seems possible when you don't know what you're talking about.


   
ReplyQuote
Page 1 / 2