refactor GY521_readCalibration_2 (generate calibration code snippet) into a proper calibrate() function, as part of GY521 init about gy521

[mw66]

I saw this in readme:

calibrate function in the lib
  -- not as lib will grow too large.

I think it's over worry, right now GY521.cpp only 484 line of code.

Ask user to manually copy & paste the data numbers into application code is worse.

[RobTillaart]

I think it's over worry, right now GY521.cpp only 484 line of code.

It is not about source code, it is about runtime code for different boards including boards with less memory.
If time permits I will check how much the footprint increases.

Ask user to manually copy & paste the data numbers into application code is worse.

Your proposal is valid if

• the application has enough time to calibrate at start-up.
• the system is in a stable state so it can be calibrated.
• it is less work for the user.
• probably more

However not all applications might have time to calibrate at every startup, as they need to be operational right away. Imagine a drone that gets a watchdog reset and it is falling from the sky, it is not stable so calibrating during restart is not possible. You will be happy it restarts with hard coded calibration data.

That said I will not close the issue right now,

• investigate the increase in footprint and time it might take.
• investigate how to overrule auto calibration at startup and fall back to hard coded numbers.
  (not all boards have EEPROM)

[mw66]

Basically you have two concerns:

1. increased memory footprint (which I think is small)
2. when to call calibrate()

If memory footprint is not a concern, at least provide such function, so the user can call in his/her application instead of manually copy & paste the data numbers into source code.

E.g. suppose it's a commercial product sold to thousands of customers, the end user should just press some button on the device if calibrate() is needed (they have no access to the source code of the product).

[RobTillaart]

As said above I keep the issue open and will investigate when time permits.

At this moment your other issue of the drifting PITCH has to be understood first (higher prio imho)

[mw66]

Ah, I just realized C/C++ has macro: so define a macro INCLUDE_CALIBRATE_IN_BUILD.

Then the users can define it in the Makefile, so even the memory footprint is not a concern. If the memory is really tight, those users can simply set INCLUDE_CALIBRATE_IN_BUILD=0 for his / her own device build.

[RobTillaart]

Did a first test to check the footprint with one of the examples + UNO (as I have no sensor I cannot test duration)

hardcode errors: 10324 bytes + 747 RAM
calibrate(100): 11124 bytes + 747 RAM
Increase of 800 bytes footprint.
Duration not measured..

Adding duration math takes ~70 bytes on an UNO (estimate).

void GY521::calibrate(uint16_t times)
{
  //  set errors to zero
  axe = aye = aze = 0;
  gxe = gye = gze = 0;
  //  set  measurements to zero
  _ax = _ay = _az = 0;
  _gx = _gy = _gz = 0;

  for (uint16_t i = 0; i < times; i++)
  {
    read();
    _ax -= getAccelX();
    _ay -= getAccelY();
    _az -= getAccelZ();
    _gx -= getGyroX();
    _gy -= getGyroY();
    _gz -= getGyroZ();
  }

  //  adjust calibration errors so table should get all zero's.
  float factor = 1.0 / times;
  axe += _ax * factor;
  aye += _ay * factor;
  aze += _az * factor;
  gxe += _gx * factor;
  gye += _gy * factor;
  gze += _gz * factor;
}

[RobTillaart]

smaller version

void GY521::calibrate(uint16_t times)
{
  //  set errors to zero
  axe = aye = aze = 0;
  gxe = gye = gze = 0;

  for (uint16_t i = 0; i < times; i++)
  {
    read();
    axe -= getAccelX();
    aye -= getAccelY();
    aze -= getAccelZ();
    gxe -= getGyroX();
    gye -= getGyroY();
    gze -= getGyroZ();
  }

  //  adjust calibration errors so table should get all zero's.
  float factor = 1.0 / times;
  axe *= factor;
  aye *= factor;
  aze *= factor;
  gxe *= factor;
  gye *= factor;
  gze *= factor;
}

10956 - 10324 = 632 bytes more.

PS,
while posting this I realize throttling must be disabled and set to previous state to get non-cached reads.
So it needs 3 additional lines to handle that (12 bytes)
to be continued

[RobTillaart]

Note:
think calibrate() must be called after setAccelSensitivity(as); and setGyroSensitivity(gs);

[RobTillaart]

Going to merge the develop branch / PR - #49
This will include the calibrate() function as above and some more.
It does not include new Pitch Roll Yaw code