[Feature] Toggle gyro use in GyroDriveBase

[laurensvalk]

Is your feature request related to a problem? Please describe.

I think I will run into situations where I want to do straights with and without gyro in the same program. I don't know how to do that with the separate GyroDriveBase class

See https://fosstodon.org/@laurensvalk/110276807095122260

Describe the solution you'd like
I think it makes sense to add a method like .enable_gyro(False) to the GyroDriveBase class to toggle gyro use.

This will essentially just change the use_gyro setting inside pbio, but crucially also reset the relevant offsets for gyro and motor angles.

[LegoPink]

I think that will work for me.

[laurensvalk]

Added support for this to the GyroDriveBase class. It's used like this:

# Don't use the gyro!
drive_base.use_gyro(False)

# Drive forward (so without gyro)
drive_base.straight(500)

# Use the gyro again
drive_base.use_gyro(True)

# Turn around counterclockwise (with gyro)
drive_base.turn(-180)

Still needs documentation, so keeping this issue open.

[Vinz1911]

First of all, it's absolutely great how the robots act with the GyroDriveBase class.

I also looked for something like this to have the option to disable the Gyro. So I saw this here and does it makes senses having two DriveBases classes if one has the ability to disable the Gyro and act like the normal one. Does it not makes sense to have just the normal DriveBase class with the setting to additional enable the Gyro?

Or is this just for know and will be later merged into one?

[laurensvalk]

You've read my mind - I've been wondering about this when I added the use_gyro method this week 😄.

One reason for doing it this way is because the gyro is not available on all platforms, so the GyroDriveBase is not enabled everywhere. That said, we could of course disable this one method on those hubs.

[laurensvalk]

I was 50/50 about it, but @Vinz1911 broke the tie. use_gyro will be available on the normal DriveBase class, and GyroDriveBase can be dropped. This is done in pybricks/pybricks-micropython@3ae1fb8.

Keeping this open until we update the documentation to match.

[Vinz1911]

Thats a Good decision 👍🏻

Thanks @laurensvalk

[dctian]

Hi, just discovered GyroDriveBase in the beta version. The drive_base.straight() works wonders! I can push the robot when it is running, and it will self-correct to the original heading!

1. just wondering, when will this change (GyroDriveBase or DriveBase.use_gyro) make it to https://beta.pybricks.com/ online code editor, so I can get our FLL team to use it?

2. I tried GyroDriveBase.turn(90). It seemed inaccurate, i.e. it always underturns, and only turns about 84~86 degrees, never 90 degrees. Is this a known issue with GyroDriveBase? or it is using gyro at all?

Let me know. thanks

[laurensvalk]

Hi @dctian,

Hi, just discovered GyroDriveBase in the beta version. The drive_base.straight() works wonders! I can push the robot when it is running, and it will self-correct to the original heading!

Glad to hear it!

just wondering, when will this change (GyroDriveBase or DriveBase.use_gyro) make it to https://beta.pybricks.com/ online code editor, so I can get our FLL team to use it?

I think the use_gyro method should already be available in the beta; it's just not shown in the documentation.

2. I tried GyroDriveBase.turn(90). It seemed inaccurate, i.e. it always underturns, and only turns about 84~86 degrees, never 90 degrees. Is this a known issue with GyroDriveBase? or it is using gyro at all?

For this, see:

Since it is not a compass, it doesn't know what a degree is precisely, but it should at least be consistent.

So by scaling you could adjust for it. To find the scale, put your hub flat on the table measure/print the hub.imu.heading() and rotate it 10 rotations. Maybe it will now say 3456 degrees. So you then for a 90- degree turn you can make it rotate: 90 * 3600 / 3456 to correct.

What we could perhaps do is add a built-in routine and store the scale adjustment on the hub. For now you can do it yourself.

[afarago]

+1 for the scaling factor of the gyro - this would simplify the life of the users and add a one-time calibration routine/factor to the top.

classDriveBase(left_motor, right_motor, wheel_diameter, axle_track, use_gyro)
use_gyro could be True or a number to for a complete turn (ideally 360)

[laurensvalk]

It would seem nice to have this as a separate calibration routine you’d do once, with the result saved in storage on the hub.

It would be nice to avoid such values in user programs because they’d be tied to one specific hub and you couldn’t share them with your team or online.

The main thing holding this back is how to do it properly in 3D, but maybe we can start off with a single constant for 1D as we have everywhere else.

[dctian]

+1 to have a calibration function that we run on each robot and save the calibration value on the hub. +1 to do this for 1D (yaw) for now. Thank you for such a wonderful upgrade to spike prime’s python module! On Sep 13, 2023, at 1:38 PM, laurensvalk ***@***.***> wrote:  It would seem nice to have this as a separate calibration routine you’d do once, with the result saved in storage on the hub. It would be nice to avoid such values in user programs because they’d be tied to one specific hub and you couldn’t share them with your team or online. The main thing holding this back is how to do it properly in 3D, but maybe we can start off with a single constant for 1D as we have everywhere else. — Reply to this email directly, view it on GitHub<#1054 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALM4V3WJJQ2AKU45IZSVKMDX2IKSJANCNFSM6AAAAAAXPJOUUI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[laurensvalk]

At the moment, the use_gyro method seems to be persistent between program runs, which is a bug. Now fixed.

[laurensvalk]

This is done. A separate issue is open for calibration in #943