[FeatureRequest] Additional GyroDriveBase turn function with absolute target yaw angle

[Ic33s]

Would be great to have an additional function where it's possible to give an absolute target yaw angle instead of working with a relative only.

For example independent on the current yaw angle I can makes sure with TurnToYaw(0), that I look in the start direaction again.

Maybe I can create an own wrapper function doing the job, but at the moment I'm not sure where to find the yaw angle of the spike hub in the api.

Best

[laurensvalk]

You can read either the angle() method on the drive base or hub.imu.heading to get the current angle.

We could consider adding a method to go to an absolute angle though.

[Kermit647]

My team did write their own drive and turn funktions to do this, its quite helpful.

[Ic33s]

Yeah, in the Lego WRO elementary team, the kids are using both approaches e.g. to continue from different paths (relative angles used) and they want to ensure the correct angle for the next step (here the use of absolute angle makes it easy :).

I'm currently evaluating pybricks for the teams because the Lego Spike App V3.2.1 and V3.2.4 is nearly unusable with the size of model the team has created so far (> 1500 blocks). To bad performance, annoying usability bugs and some breaking bugs in the newer version (already reported and tested/reproduced extensively here at windows, chrome os and iOS clients) are really demotivating for the kids. Sure it's not longer "easy" modelling, but will make more fun again to use the time, instead of waiting for the Lego app to react all the time. So we will include some python training next time (this time it might be to short to switch).

[Kermit647]

Do the switch. I was facing the same problem. (About 1000 blocks). Lego Software is so buggy and annoying to work with.

My kids did the switch in no time. Even my 9-year old wrote a small program in 30 minutes. Its not really harder.
Dragging the move block to the screen or using drive_base.move is not harder.
The kids dont need to understand everything to use it, you just need to teach them to move copy this line and adjust these parameters. Its basically the same.

Working with pybricks really feels a little like cheating compared to original lego.

[Kermit647]

My team has now worked some time with an absolut angle method.
In the current state I would not recomend it. You can make it work, but it requires a significant amount of work and knowledge to get it working good over a complete mission.

[laurensvalk]

Going to an absolute angle can be done like this:

target = 90

remaining_angle = target - hub.imu.heading()

drive_base.turn(remaining_angle) 

What didn't work for you? We'd love to improve the gyro further for the next release.

[Kermit647]

My Team is currently working on WRO junior class. (We go to the german finals this friday with pybricks, wish us luck !)

For this mission for example, a error of about 4 or 5 degrees will absolutely ruin your run.

This can quickly happen with the gyro build in the hub.
There are just many pitfalls. If you just switched on the hub, the temperature drift of the warming up of the gyro will totaly ruin everything.
First 10 minutes are unusable, best ist to wait at least 20 minutes.

The bias will only be ok if it is calibrated seconds before the run.
Even then, the bias drift will akumulate in the 2 minute mission time, so you have to make anchor point where you reset the heading. Thats quite hard to do, because you need to know your heading at some point with a very high precision

Then there is a scale error. Our gyro had an error of about 0.5%. This does not sound much, but after 3 360 turns, you have an error of 4 or 5 degrees, that will again ruin your day. So you have to hand calibrate the scale error to your personal gyro.

I have developed commercial autopilots for airplanes in the past, so I know a little bit about gyros. Most problems are inherent to the quality of the gyro build in the brick, and there is not much you can do about it firmware-wise.

It is all no problem if you just use the gyro to do accurate turns and drive straight, but if you try to maintain the heading for a prolonged time it gets much harder.

By the way, I am not very happy with the way the gyro is calibrated now. but currently I dont have a better alternative at hands. If I have spare time in the future I will try to contribute to this great project.

[laurensvalk]

Thanks for the input and best of luck to your team!

I agree, the calibration could be better. This might be something we could do for the next release.

We could add a user calibration routine that asks you to rotate the hub manually so it can calibrate. This should reduce the scaling error.

But you're spot on about the absolute gyro angle over prolonged runs. This is precisely why so far we only offer the accurate straight moves and turns, to avoid the perception of everything magically working.

[dlech]

If you just switched on the hub, the temperature drift of the warming up of the gyro will totally ruin everything.
First 10 minutes are unusable, best is to wait at least 20 minutes.

We previously investigated temperature at https://github.com/orgs/pybricks/discussions/675#discussioncomment-3341131. So this makes me curious if this is really temperature or something else (was our previous investigation faulty?).

[laurensvalk]

It's also possible that it didn't register as stationary because the thresholds are a bit sensitive.

To verify, check the value of hub.imu.stationary()

[Kermit647]

I now have the following start procedure :
When the program starts, the sensitivity will be increased to 5/9999 and the light will be red, kids do not touch the robot in this phase.

The programm will then wait until imu->ready AND imu-stationary for another second to make sure it just got calibrated.

When this is done, light will turn green. Motion of the robot is then startet with another button press.

Before motion start, senitivity is reduced to 0.01 so it does not re-calibrate during the run. (We had this happen in some rare cases when the robot pushes something and shortly stalls, and it always led to disaster. I am not sure why this leds to disaster, because theoretically it should be no problem)

When thy brick is just switched on after a longer of-phase, this procedure does not help, the robot just runs very inaccurate. I watched the heading with the robot stationary and it wanders off at about 1 degree in 10 to 15 seconds if I remeber correctly. You wont notice this if you dont disable recalibration by setting the treshold verly low, and you wont notice it on the run if you only do gyro assisted turns.

[Kermit647]

Here is a code snippet I use:

print("Imu init")
hub.light.on(Color.RED)
hub.imu.settings(6,999)
wait(1000)

while not hub.imu.ready():
    wait(50)

while not hub.imu.stationary():
    wait(50)

wait(1000)
print("Imu Ready")
hub.light.on(Color.GREEN)
hub.imu.settings(2,999)

while  not hub.buttons.pressed():
    wait(50)

hub.imu.settings(0.01,999)
hub.imu.reset_heading(0)
stopwatch = StopWatch()
stopwatch.reset()

while True:
    print(stopwatch.time()/1000,hub.imu.heading())
    wait(300)

Directly after power on, the heading will walk away by about 1 degree per 10 to 15 seconds. After a warm up period, this changes to 1 degree per 30 to 90 seconds, depending on the mood of the brick and the phase of the moon.
I tried this on two different PrimeHubs, the result is very similar