Experiments with a Swerve "Steering Knob"

[nuclearnerd]

Last year was the first year our team competed in the regular season with a swerve drive chassis. We noticed that our drivers spent a lot more time than expected lining up with the various field targets (double substation, grid, and game pieces on the field floor). During one of our debriefs, we discussed whether the control scheme we used was the best way to translate driver intent into robot action. That discussion led to an idea: What if there was a better interface for driving swerve?

1. Background

Here’s our 2023 driver control scheme, which used a standard X-Box controller. Having spoken with a lot of other teams, I gather this is a pretty typical layout:

• Translation is on the left thumbstick, and is “field-centric” (ie, up on the stick goes straight down field, away from the driver wall, no matter what angle the robot is pointed in).
• Rotation (or Yaw Velocity) of the whole robot (not the modules themselves) is on the left-right axis of the right stick.
• Both sticks are in “Rate Mode”, where the stick angle controls the speed (not the angle or position) of the robot. That means you have to move the right stick and hold it for a precise amount of time to turn the robot to a desired Yaw angle.
• Holding the right stick at the far left or far right makes the robot spin at full speed.

The Swerve API we’re using “YAGSL” has the option for a different control mode, shown below. In this “Angle Mode” (I’m sorry - I don’t know the YAGSL name for this mode, and I can’t find a reference):

• You move the right stick to a given angle from vertical, and the robot turns itself to match that angle relative to the field.
• Holding the right stick at the far left makes the robot point to the left side of the field and stay at that angle.
• When you let go of the stick, the robot holds the last angle set by the right stick.
  
  

We experimented with the Angle Mode layout in the early season. It seemed to offer more alignment precision, but our drivers found it had some flaws. If they accidentally let go of the right stick, it would be difficult to move the stick back to the exact same angle. So the robot would snap to some unpredictable yaw angle whenever they tried to make an adjustment. It was also more difficult to “spin” while driving to avoid defense. For those two reasons we stuck with “Rate Mode” in 2023.

2. Steering Knob Idea

I had an idea this fall which resurrected the idea of Angle Mode control. What if we lightly modified the X-Box controller so that the right stick didn't snap back to center. That way we could maybe get the extra precision, without having unpredictable motions when you take your thumb off the stick. The first prototype of this idea looked like this:

But we found that the stick tended to jam if you put too much thumb pressure towards the center. So we took the original thumb stick off completely, and designed a new 3D printed “knob” that fit in its place. This knob has an angled slot in the underside that captures the joystick module below and keeps in pointing in the set direction:

In fact, the shape of the knob became a bit of a Human Factors design exercise:

3. Testing

The drivers seemed to like the knob, but we needed to test to make sure it offered a performance benefit. After all, the easiest person to fool is yourself! So yesterday we prepared our field as follows:

• Placed four sand-bagged milk crates, each with a Charged Up Cone taped to one side, around the field as “Target Cubes”.
• Attached another cone to the front of each of our robots with the flange pointing outwards from the bumper.
• One robot was programmed with “Rate Mode” steering, using a regular X-Box controller.
• The other robot was programmed with “Angle Mode” steering, using the modified controller with 3D printed knob.
• Both robots have very similar specs (same gearing, motors and wheels), although the robot with “Rate Mode” steering was a little lighter.

The goal of the test was for the driver to tag each Target Cube in order for as many laps as we could within a 2 minute time cap.

So how did the Steering Knob / Angle Mode idea compare? Here’s a table of our results:

Trial #	Robot	Time Cap	Number of Targets Tagged
1	Edwin (Angle Mode)	2:00	24
2	Q-Bert (Rate Mode)	2:00	30
3	Edwin (Angle Mode)	2:00	27
4	Q-Bert (Rate Mode)	2:00	28

So, basically, the same!

4. Conclusions

You could argue that since the driver was more familiar with Rate Mode, and since the Angle Mode robot was a bit heavier, getting results this close is actually a good result for Rate Mode. However, we were hoping that we’d see a really clear improvement that would justify the extra effort it would take to bring modified controllers to competition. So while we’re proud of the effort and the idea, Celt-X is abandoning the pursuit of a Swerve Steering Knob. Ideas don’t always pan out - STEM be like that sometimes .

If anyone wants to pick up on our research and carry it further, you can find 3D models for the knob designs we liked best in OnShape here.

If you’re still reading at this point, thanks for your attention. I’m happy to answer any questions about our concept or testing? Has any other team experimented with alternate control schemes for Swerve drives?

[mrnoble]

@nuclearnerd

Has any other team experimented with alternate control schemes for Swerve drives?

Yes, and for similar reasons. Our drive team was messing around with this at the beginning of the school year. I will ask @Dresden to reply with more details. I really like the idea of the modified controller! Great job y’all.

[Skyehawk]

Just drive your swerve with a racing sim wheel. Worked for bomb squad for years.

[nuclearnerd]

That’s definitely a possibility. The large travel of a racing wheel is a benefit for precision. But that would still be “Rate Mode” (which is why I titled this “Angle Mode” modification a “knob” rather than a “wheel”).

We also like handheld controllers because we want our drivers to be able to move around if they need to get a better sightline.

[Skyehawk]

Wii mote maybe? Then you have all the fun add-ons

[truher]

we’ve tried a custom absolute controller, but found two issues with it:

1. lag. you can move the control much faster than the robot can move, which gives the driver another thing to worry about. we thought about correcting this issue with haptic feedback, but that idea was several bridges too far.
2. precision. if you’re not looking at it, it’s hard to feel exactly what the rotational control position is, and if you get into a feedback loop with it (“whoops a little more clockwise”), then you’re subject to the lag problem.

we replaced the idea of absolute control with “snaps” using the POV switch. all the requirements for precise alignment in 2023 were either 0 or 180 degrees, so this approach worked fine.

i’d like to explore these control topics further sometime, especially the haptic feedback idea, but maybe for other mechanisms.

[Woolly]

@nuclearnerd

The large travel of a racing wheel is a benefit for precision. But that would still be “Rate Mode”

There should be a way to turn off the centering spring in drivers for a lot of racing wheels so you could in theory use the wheel to control the heading and a joystick to control translation. The most complicated part might be setting the degrees of rotation such that you can map the wheel to the robot 1:1 but also not run into the deadstops super often. I guess just leave the wheel at it’s max 900 degrees or 1080 degrees and then just do the math in robot code.

The REAL complex part is picking up swerve modules’ deviations from their target angle and feeding that to the driver as force feedback

[Amicus1]

We considered a steering knob approach, but our driver decided it would not help. The main problem we were trying to solve with it was balancing precision and rotation speed. We ended up writing a custom slew rate limiter which had one rate limit for “going away from 0” and one for “going towards 0”. This made the robot rotation accelerate slowly but decelerate almost instantly, to make it easier for the driver to stop the spin at the right direction.

[Akash_Rastogi]

The design work put into this is really neat! Nice work to your team.

[troy_dietz]

Yessssss. I have been shilling the field-centric “paddle controller” (spinner) since first driving a swerve bot with the standard stick rotation control.

Getting it to work on a gamepad is a huge improvement, and hopefully new swerve teams realize how much more intuitive this can make things for a brand new driver.

Coming from a standard stick it will seem a bit worse for a while, but you get good at pre-setting the rotation and letting the robot get there as you translate into position. When it comes to being aggressive against defense things do get pretty weird though.

[Zaque]

Just to provide another possible option for controls layouts:

• Translation and rotation sticks in “rate mode” as you described it. However, both of these rates are multiplied by a variable “rate gain”
• The default (no input) rate gain is game and driver dependent, but is typically somewhere around 0.6. The rate constant is modified by inputs from the triggers; right trigger increases the rate constant up to a max of 1 for a “boost mode”, while the left trigger decreases the constant down to a minimum of around .3 (again game and driver dependent) for a “slow mode”
• Additionally, we have heading presets on the A/B/X/Y buttons that face down field, left field, right field, and up field (can also press a combo to get 45deg angles).

Using last year as an example, this typically looked like angle presets being used most frequently for aligning with substation and grid, thrust mode being used when sprinting between community and loading zone, default (~75%) speed when in the community, and slow mode for fine alignment at the substation and grid.

We also use the dpad to allow for switching to robot-centric mode, steering wheel mode, or “snake mode” in which the robot rotation always points the front of the robot in the direction of movement. However, last year at least, none of these modes ever saw use, but they are in our back pocket in case they are ever useful.

[nuclearnerd]

@Zaque

However, both of these rates are multiplied by a variable “rate gain”

Is this the same thing as an exponential stick response, or something else?

We’re leaning towards keeping the Rate Control linear, even if it means the end-of-travel spinning speed is pretty slow. We were thinking about adding dedicated buttons or a modifier to spin fast (such as when evading defense). What do your drivers prefer?

[Ankur-Raghavan]

@Zaque

The default (no input) rate gain is game and driver dependent, but is typically somewhere around 0.6. The rate constant is modified by inputs from the triggers; right trigger increases the rate constant up to a max of 1 for a “boost mode”, while the left trigger decreases the constant down to a minimum of around .3 (again game and driver dependent) for a “slow mode”

We were considering using a non-centering axis on our flight control stick (throttle I think) to provide a modifier to the speed of both translation and rotation, but ultimately chose to go with the buttons as you described. We also used that on our tank drive in 2022 (and probably before). However, we normally try to get to the point where the driver is comfortable to be at 100% default and only have a medium and a slow button, though not for rotation.

[Zaque]

The output of the translation and rotation sticks remains linear, we are basically just modifying the slope of the line by multiplying the stick output by the rate constant. So during normal driving, the maximum output magnitude would be 0.6; when the boost trigger is pressed that would increase up to 1 when fully pressed, and when the slow trigger is pressed the max magnitude would decrease down to 0.3.

We just used the same modifiers for rotation rate limiting as for translation, so I can’t really speak to your question about what they prefer since they really only use the one style.

[Gold87]

My team had a very similar idea a few months ago. What we did is have the right stick be the normal angular velocity control, but have left bumper turn it into angle mode, sometimes our driver needs more direct control over the rotational speed than the angle it is pointing at

[Skyehawk]

I just attach super shifters to each azimuth/steering motor. Torque on demand.

[nuclearnerd]

Another idea would be to borrow “Horizon Mode”, which is a bit of a hybrid between Angle and Rate Mode:

When the right thumb stick is moved between, say -80% and +80%, the robot turns to a given angle between, say -45° and +45°, but when the stick is pushed all the way to the edge, the robot spins and a continuous rate. So drivers can soon the robot quickly until they’re within a quarter of a turn, and then adjust the angle precisely from there.

I think that kind of hybrid mode would work well in a game like 2023 where the targets are fixed, and maybe not well where a target could move at the last minute like 2022.

[ohowe]

Really cool post! I loved the modded controllers.

We had a brief exploration with the absolute swerve control last year, and abandoned it for similar reasons as you brought out in your post (behavior issues when driver lets go, poor control when trying to spin off a defender).

After we removed it we added some snap controls to the driver controller (0, 90, 180, 270 degree presets that the robot will automatically go toward) (name credit to 1678 I think?). As a not very talented person with the controller, I really liked these to drive with when I was doing some programming things with the bot. However, during the season, our driver who is talented on the sticks used the snap feature exactly (checks logs) zero times during a match (and I think only when I asked him to try it out at practice). This came as somewhat a surprise to me because I thought it would have just been a lot easier, but nope. The driver was just as fast and precise at aligning to one of those angles as the snap.

So, at least for our team and drivers, the loss of controllability with the absolute control, the less similarity with video games that drivers might already have muscle memory with, and the little gain it gives with an experienced driver makes absolute control not really the way to go. There’s a reason every pro drone racer uses rate mode. The trade off with ease of use and controllability really hits hard.

[gerthworm]

Really cool experiments.

In my experience *, humans tend to do best when given interfaces that correlate to “if I push harder, I get more acceleration, but with diminishing returns”.

Brake pedals and gas pedals on cars work this way. So do levers in bulldozers. So do joysticks that control voltage in robots.

* = well versed in this area, but feeling inadequate because I can’t point to a good academic study proving my experiences to be generally true.

I’m not sure why. My best guess is that “push harder to accelerate more” corresponds to how our muscles work - if you push harder, you’ll move faster, but to a limit.

Controls where pushing harder causes more velocity are better, but feel unintuitive when you hit resistance (because the thing… automatically??? pushes more?). Controls where pushing harder correspond to position are very hard to work - you basically have to trust the thing’s gonna get where you want on its own, you’ll have nearly no fine-tuned control over motion.

It seems humans are easy to adapt to different “gain” (IE, acceleration per unit of push). But doing calculus in your head in real-time to adapt to a difference in relationship between motion and unit of push is much harder.

[nuclearnerd]

@gerthworm

Controls where pushing harder correspond to position are very hard to work - you basically have to trust the thing’s gonna get where you want on its own, you’ll have nearly no fine-tuned control over motion.

You might be on to something. But here’s a counterpoint - there are lots of examples of precision controls that work on position, rather that rate. Off the top of my head, these include:

• Manual lens focus,
• CNC pendants,
• and my original example - Quadcopters are way way easier to fly accurately (if not quickly) in Angle Mode