paper: Bomb Squad Swerve Steering Code

[Ether]

Originally Posted by Jefferson

The spreadsheet does exactly that for a given set of inputs. Those inputs will be interpreted as operator interface inputs by most people.

As indeed they should. They are operator interface inputs, for the "general case" operator interface where the operator has three +/-1 inputs: forward/reverse, strafe right/left, and rotate CW/CCW about the center of geometry of the wheels. The vehicle motions possible with these three degrees of freedom are a superset of all other motions (such a Ackermann steering or 4-wheel steering).

Now, this is not an operator interface that you'd want to give your driver to use in competition - it's too difficult to control.

But that's not the purpose of the spreadsheet. The purpose is to test swerve code, to make sure it is creating the correct wheel speeds and angles... where "correct" in this context means "no translational motion of any wheel parallel to its axis".

If you have to do significant calculations to describe your intended robot motion in the terms of the spreadsheet (FWD, STR, RCW), I don't see the utility of the spreadsheet to check your calcs.

It's OK to disagree about this. But I would make 2 observations:

1) Even if you have to do significant calculations, those calculations are likely to be quite different from the analysis you originally had to do to create the equations for your code. If you get the same answers for wheel speeds and angles, that's a pretty good check.

2) I would argue that it is easier to translate your operator interface commands at a point in time into the equivalent FWD|STR|RCW degrees of freedom than it is to develop the swerve code in the first place.

I don't want to badger you, but if you have any interest in pursuing this I have a suggestion. Give me a set of operator interface commands for your operator interface, describe what those commands are supposed to make the robot do, and tell me what each wheel speed and angle is calculated by your code at a point in time, given those commands. I will convert that to the associated FWD|STR|RCW and see if we get the same answer.

[Jefferson]

Originally Posted by Ether

I don't want to badger you, but if you have any interest in pursuing this I have a suggestion. Give me a set of operator interface commands for your operator interface, describe what those commands are supposed to make the robot do, and tell me what each wheel speed and angle is calculated by your code at a point in time, given those commands. I will convert that to the associated FWD|STR|RCW and see if we get the same answer.

I'm intrigued by this offer. I'll drag this back up after Razorback this weekend and take you up on it.

[Ether]

Originally Posted by Jefferson

I'm intrigued by this offer. I'll drag this back up after Razorback this weekend and take you up on it.

Whenever you're ready.

[Jefferson]

Originally Posted by Ether

Whenever you're ready.

Unfortunately, not now. We are all working on a pretty significant retooling on the robot. I will circle back to this, though.

[Jefferson]

Originally Posted by Ether

Whenever you're ready.

Better late than never eh?

Our OI consists of a steering wheel and 2-axis joystick.

In what we call Steer mode, the steering wheel simply changes the turning radius of the robot, much like a car steering wheel, and the Y-axis on the joystick is the throttle. We find this setup is intuitive for most people. Our third degree of freedom is fixed in this mode. It is the point in the Y direction of the robot where the center of the turn is. We fix this at the midway point between the front and back wheels, creating a 4-wheel steered robot. We have used a similar setup with the center of the turn fixed on the front wheels, so the back wheels do all the turning and the front wheel directions are fixed... but I digress.
The joystick has a range of 0 to pi with neutral at pi/2. When the steering wheel is at 0, the turning radius is 0 and throttle forward will spin the robot about its axis to the left. At pi/2, all wheels are pointed forward. At pi, the turning radius is again 0, but forward throttle will spin the robot about its axis to the right. All wheel speeds are calculated based on the turning radius of each wheel and multiplied by the throttle (-1 to 1).

Our crab mode is somewhat field-centric in that we zero the gyro when the driver initiates crab by pulling the trigger on the joystick. The direction and speed of crab are defined by the X and Y values from the joystick. The robot can be re-oriented by turning the steering wheel. The X-Y direction and speeds are based on the original orientation of the robot. The orientation is reset when the driver lets off the trigger. Crab (and switching between modes) is MUCH less intuitive for the driver, so practice is an absolute necessity.
We shamelessly stole your calculations to make crab work the way we wanted (and then worked it out for ourselves), so thank for your help in that.

Our 2013 code in case anybody is interested... https://github.com/FRCTeam16/TMW2013