Anyone try a field perspective differential drive?

Wanted to try out perspective drive but all the examples are for other drive types.

Has anyone tried it with differential drive?

I don’t think a differential drive can do field oriented driving. The best you could possible do is have it snap to the angle you command and then maybe return back to the angle prior to driving when stopped. Which seems like it would be pretty disorienting.

Not sure you’d need it to snap back. It’d be more to avoid the direction translation problem when driving toward you or away.

I’m interpreting the question as “how to do field oriented control of a differential drive robot”…If I’m understanding you right, I don’t believe I have seen anyone do this.

I think the core question to answer is: how do you handle a command to travel perpendicular to the orientation of the wheels?

I’m not sure I have a single or clear answer to that question.

1 Like

My post was just saying that a sideways command would have to first turn the robot 90 degrees then drive forward while commanded. The question they had was just to leave it pointed sideways at the end, where I would think you’d have to turn back 90 degrees to keep your orientation.

Maybe the question is just a drive that goes in the direction commanded. Maybe letting you steer the direction within an imposed deadzone.

My thought is that you lose some control when trying to drive in a style that isn’t really that compatible with the differential drive style. For example, you might not be keep the able to turn slow or fast or drive with smoother turning curves. I think a better idea is to implement buttons that orient the robots direction with the field, typically with scoring elements (like the angle to deliver gears in 2017 or cargo in 2019).


Here’s the idea. You have a joystick or xbox controller with a joystick / thumbstick.

The robot is facing away from you. You push the stick up or forward and the robot moves away from you.

You pull the stick down or back and the robot turns to face you and moves toward you.

You push the stick to the right and it turns and it goes that direction.

It essentially gets the angle to drive from the joystick position. Speed could be taken from the stick for from another slider.

If you have an xbox controller the bumper controls can turn the bot where it is left or right.

Just thought it might be a fun thing to try.

I did have a team in steam works that had problems driving backwards. So we set modes of the robot (this was for SteamWorks) one mode was "Getting gear) which considered the “back” of the robot the front (and did other things when the mode was switched) then had a different mode for the “placing gear” which considered the “front” of the robot the front. Notice this was very simple and did actually try to figure out anything it just switched what end was considered the “front” since we got gears on one side and placed them on the other.

I really don’t think this was a great idea. I think it would be better to just learn to drive it normally but it gave the programmers something to do and was what the driver wanted so…whatever.


So this could work. I haven’t seen anyone do it just yet. I’m not certain it would be more intuitive, especially for “fine-tune” positioning movements. You’d definitely want to run back-to-back experiments with drivers to see what they like better or worse.

I think the main intuitiveness issue would be the fact that a single joystick command turns into a time-separated rotation, then translation. It would be hard for the drivers to gauge at what point the robot would actually start moving forward.

One potential way around this: use one joystick as the “steering wheel”, aka the heading command on the field. Any time the stick is centered, retain the previous heading command. Any time the stick is pushed somewhere, use atan2 to get a new heading command. At all times, close-loop control the robot to rotate that heading.

Separately, use the trigger on the back of the xbox controller as a “gas pedal”. Pulling it should cause the robot to translate forward. Assuming the robot is pointed in the desired heading, it would travel along it.

This scheme gives the operators the ability to sequence the rotate and translate themselves, and possibly do some arcing control.

Whether it’s better or worse than traditional control… I will leave all of that judgement up to you. If it scores more points, it’s better - naysayers be darned!

We have done similarly in the past. Some years, the driver loved it (they were able to quickly switch their brain). Other years, the driver disliked it and preferred just to drive in reverse.

1 Like

449 wrote an implementation of it a while ago as a joke. It was surprisingly not unusable, but I would not recommend it.

I believe the implementation was a simple P loop on heading, and forward motion determined by the magnitude of the joystick input vector.


Did they publish the code?

Yes, but locating it may be nontrivial. It was some years ago.

1540 has been running a similar drive style for the past 2 years. The way we implement it, one joystick one joystick controls field centric robot heading and the other joystick controls robot centric speed. While we’ve found that this drive style can be helpful (especially for highly angle dependent game like 2019), we wouldn’t necessarily recommend it to other teams and our considering switch back to normal tank drive ourselves.

Code is on our github:

1 Like

We have done this on our traction differential swerve which essentially is like having 4 tank steer robots tied to one structure.

We used a single joystick. We broke out motor commands to 2 components, one based on joystick magnitude and one based on heading. Run a PID on heading command with gyro as feedback to develop that component of the motor command. Magnitude is joystick hypotenuse and only kicks in once within a tolerance band of the target angle. The larger the tolerance band the sooner the robot will start to translate but it will swing a wider radius to get to heading. The smaller the swing buy there will be a small delay in movement.

We did something very similar recently for “special purpose” code for a skills challenge at the recent Ozark Mountain Brawl with our 2020 bot “Mandevillorian”. It is a pretty traditional WCD skid steer bot.

The “driving in the dark” challenge had the driver(s) blindfolded, and having to drive the bot around an obstacle course of cones, intake a power cell, then complete the course and return to the starting area. One “coach” is allowed to provide verbal directions to the driver(s) – and man the E-stop button.

We used one stick as robot centric speed (forward/reverse) and the other stick was field centric heading. If your speed joystick is neutral, the robot will rotate in place until heading the way the steering stick is pointed (simple P only PID loop on gyro). With the steering joystick neutral, the bot drives forward/back in the current robot centric heading. If both are manipulated at the same time, the robot will turn towards the designated heading on a curve while moving.

While it wasn’t a complete success, it made that “driving blind” challenge somewhat easier. Doubt we would do it for “general game play”.

Note that this was somewhat easy to drive for robot “forward” movements, this was REALLY confusing for drivers to learn to drive when they tried to drive the bot in robot centric “reverse.”

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.