getYaw, getPitch and getRoll go past 360 degrees about gy521

[RobTillaart]

Thanks for your question,

It is not 100% clear what you need.
If I understand the question correctly you want the output always be in the range 0 .. 359 degrees?
Or is it just the opposite, that you want it to go to 360 then to 720, 1080 and so on.

Problem with the latter is that at some moment you loose precision causing the math to be incorrect.
(that is what the library does if I am correct, do not recall testing that.)

[RobTillaart]

Is your goal to calculate the RPM rounds per minute ?

[Estebanmister]

As of now, your library already does the latter (it continues to infinity), I would like the output to be in the range of 0 to 359.

…

On Fri, Oct 7, 2022 at 1:47 AM Rob Tillaart ***@***.***> wrote: Thanks for your question, It is not 100% clear what you need. If I understand the question correctly you want the output always be in the range 0 .. 359 degrees? Or is it just the opposite, that you want it to go to 360 then to 720, 1080 and so on. Problem with the latter is that at some moment you loose precision causing the math to be incorrect. — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIZGZDUTSPOTDA5MA3DMTGLWB62Q3ANCNFSM6AAAAAAQ7GNCRA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[RobTillaart]

@Estebanmister

Quick patch is to change the following lines in the GY521.cpp file (around line 195)

  _gax += _gx * duration;
  _gay += _gy * duration;
  _gaz += _gz * duration;

to

  _gax += _gx * duration;
  _gay += _gy * duration;
  _gaz += _gz * duration;

  if (_gax < 0) _gax += 360.0;
  else if (_gax >= 360.0) _gax -= 360.0;
  if (_gay < 0) _gay += 360.0;
  else if (_gay >= 360.0) _gay -= 360.0;
  if (_gaz < 0) _gaz += 360.0;
  else if (_gaz >= 360.0) _gaz -= 360.0;

If you always rotate in the same direction you might need less tests, however this is the robust way.

give it a try

[RobTillaart]

mmm, (thinking sounds)
at second thought pitch and roll still can under / overflow the 360.

you also need

  _yaw   = _gaz;   
  _pitch = 0.96 * _gay + 0.04 * _aay;
  _roll  = 0.96 * _gax + 0.04 * _aax;

  if (_pitch < 0) _pitch += 360;
  else if (_pitch >= 360) _pitch -= 360;
  if (_roll  < 0) _roll  += 360;
  else if (_roll  >= 360) _roll  -= 360;

[RobTillaart]

You need both as you do still not want an overflow of the _gax, _gay and _gaz values.

I'll prepare a new branch

[RobTillaart]

Develop branch created,
Please verify if it works for you

[Estebanmister]

Develop branch created, Please verify if it works for you

Just tried the fixes above, it works!! thanks!

[RobTillaart]

How fast does your setup rotate?
If possible could you post a photo?
Just interested.

[Estebanmister]

Fast enough for persistence of vision to kick in :), currently using the gyro to calculate RPS

[RobTillaart]

Looks pretty cool, well done 👍

[RobTillaart]

How many RPS does it make, 25?

[Estebanmister]

yeah about 20-25, but right now I'm having some problems with drifting(the position of the 'H' drifts in the direction that the device is spinning), probably because i depend on the gy521 for reaching the angle 0 (to then proceed with the function that turns the LEDs on) I should add a hall sensor and a magnet.

[RobTillaart]

you can try to prevent drifting by predicting the angle 0 moment.
Say you have 25 RPS, then the angle 0 is 40.000 us after the last one.

Then use the GY521 to adjust the 40.000 us with the angle you measure after predicted time.
just in steps of 4-40 us.

suppose expected time = 40000
Instead of Angle 0 you measure 342 then you know you are 18 degrees == 1/20 too early
So 40000 = 342/360 x timeNeeded ==> timeNeeded = 40000 x 360/342 = 42105 us for 360°

As you are 18 degrees of the 0 angle the sync moment will be at 42105 - 40000 = 2105 usec.

This method should converge quite fast to a good value, and adapts to speed variations quite well.
(there are variations on this method possible)

A point of attention is that you need to include the time your math makes.

just some

BTW, you can add a round weight to the axis to get a flywheel effect which helps to dampen variations.

[RobTillaart]

Will merge and release new version tomorrow.
Did also some cosmetic changes to the code.

[Estebanmister]

you can try to prevent drifting by predicting the angle 0 moment. Say you have 25 RPS, then the angle 0 is 40.000 us after the last one.

Then use the GY521 to adjust the 40.000 us with the angle you measure after predicted time. just in steps of 4-40 us.

suppose expected time = 40000 Instead of Angle 0 you measure 342 then you know you are 18 degrees == 1/20 too early So 40000 = 342/360 x timeNeeded ==> timeNeeded = 40000 x 360/342 = 42105 us for 360°

As you are 18 degrees of the 0 angle the sync moment will be at 42105 - 40000 = 2105 usec.

This method should converge quite fast to a good value, and adapts to speed variations quite well. (there are variations on this method possible)

A point of attention is that you need to include the time your math makes.

just some

BTW, you can add a round weight to the axis to get a flywheel effect which helps to dampen variations.

But how would we know if we are late instead of early? methinks this would end up with the device doing two rotations just to get to 0.

So I tried to implement this, but it doesn't seem to work, the draw() function makes the LEDs turn at random locations, changing the speed doesn't seem to improve things (I ran it at like, 1 rps, just to be sure).

The 'Strt' variable is the time of the previous loop, 'previous_reading' is the yaw of the previous loop. The highlighted part is your algorithm

[RobTillaart]

If the read is too late the idea is pretty similar.
Suppose the angle < 180, then you should add 360 to it. Then the factor 360.0 / yaw is smaller than 1 thus reducing the time.
Be sure to use 360.0 for constants so all your math is done in float. An integer division would break the algorithm.

Instead of calculating the new time you can just increase or decrease the estimate e.g with 20 us. Then the value will slowly converge to the right one.

[RobTillaart]

Idea
Code wise it might be easier to detect and work with the 180 degrees. Then handling over and undershoot would be handled by the same lines of code.

The 0 angle would be halve a rotation later.

[RobTillaart]

Note to myself.

Q: Is it possible to optimize the under- overflow correction math?

Now the overflow detection math is done at every call => expensive => always 10 to 15 float operations in read function.
There is no 100% guarantee that e.g. if _gax overflows and is corrected, that roll does not need correction anymore.

The only optimization I can think of is if you know the direction of rotation, the order of test < 0 and >360 will make a small difference. In fact if one direction is used consequently only one test is needed. For a generic library this is not knowable.