Driver-centric or Field-centric

The terms "Field-centric" and "Driver-centric" are used interchangeably in FIRST robotics. I think we need to differentiate them. I also think we need to use them properly. This drive system is common in both FTC and FRC since both have teams building holonomic drive systems. In FTC, Mecanum wheels are popular since defensive play is limited by the rules. In FRC, there are some teams with Mecanum wheels, but there are more teams building Swerve drive systems.

Both terms are used to refer to a control system where when the Driver moves the control input to the right, the robot moves to the right from the Driver's point of view. Since the Driver is in a fixed position on the field, the robot moves to the right side of the field. 

This control system is in contrast with a Robot-centric control system, which is where most teams start because it is easiest to understand. When you move the joystick forward, the robot goes forward, no matter which direction it is facing. When you move the joystick to the right, the robot goes to its right. This is also the way radio control (RC) cars and planes operate. The biggest challenge to this control system is that when the robot is facing the Driver, when the Driver moves the joystick right and the robot goes to the robot's right, it is the Driver's left. The Driver has to do a lot of work and a lot of practice to get used to driving this way.

The distinction is based on defining reference frames. Reference frames are the key to developing control systems for robots, aircraft, missiles, and drones. Once the reference frames are clearly defined, the transformations from one reference frame to another becomes easy and the programming is evident.

We'll start with a Driver Reference Frame. The Driver Reference Frame consists of Forward, Backwards, Right, and Left. As the Driver moves, this reference frame moves with them.

The Field Reference Frame is oriented with the field. We'll use ordinal directions (North, South, East, West) for this reference frame. Let's use the figure of the playing field in the Game Manual as a standard for this reference frame. In the figure, the Blue Alliance is to the left, we'll call this West. The Red Alliance is East. Now FTC and FRC build their figures differently.

The FTC Playing Field figure (Powerplay, Figure 4.2-2) has the Scoring Table at the top of the figure and the audience at the bottom. For FTC, the Scoring Table is North and the Audience is South.

The FRC Playing Field figure (Charged Up, Figure 5-2) has the Scoring Table at the bottom of the figure and the audience at the top. For FRC, the Scoring Table is South and the Audience is North.

If the control system were Field-centric, the robot would move North, South, East, and West based on the control inputs. Let's look at an FRC example. We're going to program the joystick with the following settings (Remember that the gamepad uses up or away from the user as the negative Y direction):

• Negative X = North
• Positive X = South
• Negative Y = East
• Positive Y = West

When you're on the Blue Alliance, this works great. Push the joystick away from you and the robot moves away from you. Pull back and the robot comes towards you. Move the joystick to the right and the robot moves to your right, towards the Scoring Table.

The challenge is when you're on the Red Alliance. In this case, everything is backwards. When the Driver moves the joystick to the right (positive X), the robot moves towards the Scoring Table, which is on the Driver's left. When the Driver moves the joystick away from them (negative Y), the robot moves East, which is towards them.

The purpose of moving away from the Robot-centric control system is to reduce the workload of the Driver. With the simpler Robot-centric control system, when the robot was driving towards the Driver, they had to convert everything from backwards. A Robot-centric control system actually works great with First Person View (FPV). The Driver perceives the environment as the Robot, so Robot-centric is the same as Driver-centric.

To reduce the workload on the Driver, what we want is a control system that is designed around the Driver. It isn't designed for the Robot and it isn't designed for the Field (which isn't an actor in the system). When the Driver changes position (i.e., between Blue Alliance and Red Alliance), we want the control system to move with them. What most teams build and call "Field-centric" is actually Driver-centric. Let's acknowledge that the control system is designed for the Driver and call it what it really is, Driver-centric control.

I know this sounds like a semantic nit. Most people out there think of driver-centric as field-centric and it is obvious to everyone. As a Systems Engineer, I've spent a career learning that what is obvious to everyone gets misinterpreted more than followed. 

I had a Control Systems professor in college who complained about Pilot Induced Oscillation (PIO) which is the cause of many fatal crashes. This is where the plane doesn't respond quickly to the pilot inputs, so the pilot increases the input until they have put in too much and then they have to reverse everything. My professor called this Pilot-Aircraft Coupling. It was a mismatch in the expectations of the pilot and the design of the aircraft. If you're reading a crash report that calls out Pilot Induced Oscillation, you're looking to fix it by training pilots better. If you're reading a crash report with the cause of Pilot-Aircraft Coupling, you're looking at both pilot training and aircraft design. In almost all of these situations, a minor tweak to the aircraft control system avoids many fatal crashes.

I think that calling it a Driver-centric control system better represents that the Driver was the focal point of the effort to modify the control system. It demonstrates that we are considering the various actors in the system and designing for a better Human-Machine Interface. I think this sort of subtle communication helps students gain an appreciation for considering different actors when they are in the Identify step of the FIRST Engineering Design Process.

Once we realize that we can build different control systems for different reference frames or for different users, we can build our AUTO code from a Robot-centric reference frame and our TELEOP code from a Driver-centric reference frame. We can also build separate control systems for the Driver and for the Co-Driver. In the FRC 2023 Charged Up game, the Driver can have a high speed, maneuverable control system while the Co-Driver can have a steady, precise control system. While the Driver is trying to avoid defense in the unprotected area between the Loading Zone and the Community, the Co-Driver is trying to align precisely with the Node so that the Game Piece isn't dropped and needing to be repositioned.