Calibration for field-centric driving

[DetroitMentor]

We use the controller's Back button for IMU re-init. Our auton should end with the robot's "nose" facing away but if it doesn't then the driver needs to "remember his nose" and re-calibrate. (We use the word "nose" because it's easier for the drive coach to shout "nose!" than to say, "Do a re-calibration of the IMU!")

So the driver just needs to take a couple seconds to spin the robot so the "nose" is facing away (the same direction the driver is facing) and then hit the Back button. The re-init of heading happens within a second.

This image shows the blocks we use in the init section (before waitForStart) and then the listener for Back button inside the green loop to do the imu.initialize (with the same parameters set-up in init section).

[FTC12676]

4634 Programmer suggestion works fine. Just make sure do not initialize IMU in teleop. Your ZERO will be same as what you initialized in Auton init

[FTC12090]

RatLab - What our team does is at the beginning of Teleop we hold X button, then use the left joystick to have the student point it in the direction the robot is facing. Then the student releases X and it uses that heading of the joystick. In the if(gamepad1.x) {} we set drive and rotation to 0 to make sure the robot doesn't move.

[4634 Programmer]

save the heading to a file at the end of autonomous and reload it at the start of tele

Just store your gyro as a 'static' object, and don't reinitialize it in teleop.

[Cheer4FTC]

And if the students don't like the time lost pointing "north", you can have 4 recalibrate buttons for north, east, south, and west, and recalibrate with any of the 4 orientations (which only takes a second or two at most).

[Cheer4FTC]

Either save the heading to a file at the end of autonomous and reload it at the start of tele, or have one or more buttons on the robot that reset the heading.

As an example for the latter, turn the robot so it is facing "away" from the driver, then hit the "away" button. The code can then read the current heading, know that this heading corresponds to "away" and now update headings relative to this reference going forward.

[3805Mentor]

https://ftcforum.usfirst.org/forum/f...mous-to-teleop

[RatLabGuy]

During the off-season, we had just switched to Rev hubs and the students spent time getting field-centric driving to work; e.g. using the built in BNO055 magnetometer for positional orientation information to use for steering, so that "up" on the stick is always "away from me" regardless of which way they are facing and such. This works well for robots with no clear "front" and especially cases where the driver orientation doesn't match the robot's direction.

The problem we have run into however is that it requires a calibration - you have to first assess "north" and then subtract everything from that from then on for everything to work. No big deal, it only takes a second and in a match, at the beginning the robot always starts facing the same direction (or 90 degrees off of that).

But - how do you deal with this at the beginning of the Teleop portion of a match? You can't accurately predict which way the robot will be facing when you start (b/c the Autonomous may or may not have ended perfectly), so if you calibrate then, your controls could be really weird. A cludgy solution is to use regular driving to point the robot "north" then recalibrate, but the students do not like the time lost to do this. Sicen we must use different programs from Auto and Teleop, we can't carry the calibration over as a variable.

So how do teams deal with this?