Paper: 4 wheel independent drive & independent steering ("swerve")

CD-Media: Papers
, , , ,
1

Thread created automatically to discuss a document in CD-Media.

4 wheel independent drive & independent steering (“swerve”)
by: Ether

calculate robot-centric and field-centric wheel speeds and wheel steering angles for a vehicle with four-wheel independent drive and independent steering (“swerve” drive)


UPDATED FILES ARE AT THE BOTTOM, SO SCROLL ALL THE WAY DOWN

Derivation of inverse kinematic equations for three-degree-of-freedom (3 DoF) control for 4-wheel independent steering and independently driven swerve.

Equations and pseudo-code for above.

Convert Ackermann commands to 3 DoF control.

Convert Cartesian coordinates to 0 to 360 degrees, CW or CCW, from +/- X or Y axis, or from an arbitrary Initial Ray. See Errata note below

Inverse kinematics Excel spreadsheet with graphical display to test and display swerve wheel speed and steering angle calculations.

Forward kinematics calculator implemented in Maxima.

Inverse Kinematics for swerve with 3 or more wheels. The wheels can be located anywhere on the robot; they don’t have to be at the corners of a rectangle.

Errata:

There is a typo on Page 2 of document convert_XY_degrees RevE.PDF: The equation should read theta -= 360*floor(0.5+theta/360)

Derivation of Inverse Kinematics for Swerve.pdf (48.1 KB)
Calculate Swerve Wheel Speeds and Steering angles.pdf (15.3 KB)
Ackermann7a.pdf (49.2 KB)
swerve_tester_6.xls (27.5 KB)
convert_XY_degrees revE.pdf (25.3 KB)
swerve_tester_8.xls (28 KB)
swerveForwardKinematics.zip (16.3 KB)
CWYdeg.pdf (9.32 KB)
Cartesian2angle.zip (6.6 KB)
moon.pdf (25.6 KB)
rotary.pdf (25 KB)
dosado.pdf (25.6 KB)
swerveN.pdf (60.2 KB)
convert_XY_degrees revF.pdf (36.9 KB)

32 Likes
2

*The first release of the paper presents the solution to the inverse kinematic problem, i.e., given a desired vehicle translational plus rotational motion, what angle and speed should be commanded for each wheel.

The paper addresses both robot-centric and field-centric commands.

I am working on algorithms for the “do I reverse the wheel speed or do I turn the wheel 180 degrees” problem, and will post those here when they’re done.

[edit]

Additional explanation of “180 problem”:

The algorithms and reference code in the paper properly calculate the correct wheel speed and wheel angle (setpoint variables) for each wheel, for any possible combination of input commands (fwd/rev, strafe, and rotate). Each wheel angle computed will be in the range -pi to +pi. An angle of zero is the straight-ahead direction (relative to the robot). Positive angles are CCW from zero, negative angles are CW from zero. Each wheel speed computed will be in the range 0…+1.

The “180 problem” is how to control each wheel’s angle and speed, assuming you have correct setpoint variables (speed and angle) and process variables (speed and angle) for that wheel.

The simplest approach is to control each wheel’s speed and angle separately: make each wheel angle go to that wheel’s angle setpoint, and each wheel’s speed go to that wheel’s speed setpoint. For the drivetrain stipulated in the paper in Figure 1 (unlimited steering and continuous wheel angle sensor with no gaps) this may well be perfectly adequate - if the steering motors are powerful enough to provide satisfactory response against the given floor material and wheel tread material.

The initial “180 problem” I hope to address is the case where the steering motors are not sufficiently powerful to provide satisfactory steering response for rapid maneuvers. If, for example, the process variables for a wheel are 10% speed straight forward, and the setpoint variables for that wheel are 10% speed straight backward, perhaps it makes more sense to reverse the wheel’s rotational speed rather than turning it 180 degrees. The challenge is to design a tunable (parameterized) algorithm which addresses the shades of gray in between seamlessly.

The second “180 problem” I am looking at is more difficult: if the drivetrain does not have unlimited steering, or if the sensors have have gaps (dead zone). The design goal is to minimize the “bad behavior” around the discontinuity. One approach might be to build some smarts into the control algorithm so that it looks for opportunities to steer the wheels away from the discontinuity whenever doing so would be least disruptive (for example when speeds are very low).

[/edit]

**

3

Nice, simple explanations of the inverse kinematics* of an independent swerve. We derived the same end result for the independent swerve for our 2010 robot, but wrote all the control code in Java.

Because we had to use the ~20W Denso motors for turning the wheel pods, the max omega of the individual wheel pods was rather slow. While translating was rather zippy with a max speed of around 10 ft/sec, complex motion was somewhat sluggish due to slow wheel pod rotation. It was an unfortunate situation, but we were able to combat this by increasing the maximum range of motion of the pod rotation to 400°-450° (I don’t remember the exact value off the top of my head), to decrease the number of times the pod would have to pivot 180° and reverse the wheel direction.

  • I remember back when implementing PID control was considered something of a dark art on FRC robots, much like inverse kinematics is now. I’d love to see more teams utilize inverse kinematics for various arms/elevators on their robots, especially since the inverse kinematics for a 2 or 3DOF open-kinematic-loop mechanism isn’t particularly difficult and can be solved with only high-school geometry.
4

I’ve developed code for a swerve drive that is based on magnitude and direction from the joystick origin (using halo style controls) and have found that a simple code snippet produces the 180 degree limitation (90 degrees from straight ahead), but certain situations prove this to only work to a limited degree (when the angle moves from 180 to 190, the wheels rotate 170 degrees)

if(angle>180)//zero is the positive x axis and positive is in the counter clockwise direction
{
angle-=180;
magnitude*=-1;//magnitude is distance from joystick center, it is always positive unless modified in this line
}
5

Could you please clarify… Are you asking for help, or are you proposing this as a solution to some problem? It isn’t clear to me. Thanks.

**

1 Like
6

You mentioned that you were working on creating a solution for when the wheels go past an arbitrary 180 degree point. I was proposing the solution that I came up with to your problem. It has it’s limitations, but it is simple and reliable.

7

Thank you for clarifying, Alex. I think you misunderstood what I was saying (which could be partly my fault - I will go back and edit that post to add more explanation).

The joystick inputs are not the problem. If you copy and paste the reference code from, say, Example 1 (Figure 7b) into a text file, edit it to add some window dressing, and compile it and test it, you will see that the reference code as shown already cleanly handles all possible combinations of joystick commands (fwd/rev, strafe, and rotate) and correctly calculates the angles and speeds of each of the four wheels.

The 180 problem I mentioned in the earlier post relates to how to control each wheel’s speed and angle, given the correct setpoint and corresponding process variables for each wheel.

The solution to this problem depends on whether the wheels (and sensors) have continuous or limited rotation, and whether the sensors have “dead zones” (gaps). It may also depend on the floor surface and tread material of the wheels, and the power of the steering motors vs the power of the driving motors.

**

8

Just uploaded a description of how to calculate shortest-path angle error and how to use it with LabVIEW PID.

http://www.chiefdelphi.com/media/papers/download/2858

**

9

*Sorry, the link got broken when I uploaded a corrected version. Here’s the new link:

http://www.chiefdelphi.com/media/papers/download/2858

Also, note that there are two different ways to connect the angle error signal to the LabVIEW PID:

  1. Connect the error to the Setpoint input, and connect a constant zero to the ProcessVariable input. This is the way mentioned in the paper.

  2. Connect the negative of the error (i.e. -error) to the ProcessVariable input, and connect a constant value of zero to the Setpoint input.

The first way effectively disables the “D” portion of the PID (which you probably don’t need for this application anyway).

The second way allows the “D” action of the PID to be used, but in a way perhaps not intended by the designer of the PID, since it causes the PID to use the derivative of both the ProcessVariable and the Setpoint. The PID is designed to take the derivative of the ProcessVariable input only*, so using this second way may result in instability or other unexpected behavior.

**

2 Likes
10

I just posted a 2-page summary explanation for those who just want the equations and don’t care about the derivation.

**

11

There was a typo error in the fourth equation at the top of Page 2. It should read D = FWD + RCW*(W/R)

I corrected the typo, and updated the paper to use clockwise angles for the gyro and the wheel steering.

**

12

Just added a very simple Excel spreadsheet to demonstrate the swerve wheel speed and steering angle calculations. Might be a useful teaching tool for mentors (or learning tool for students).

User inputs values into cells A1 thru A6. Spreadsheet calculates and displays wheel speed command and wheel steering angle command for each of the 4 wheels.

**

13

see updated post

14

For students who are visual learners, I updated the spreadsheet to add a graphical display of the wheel speeds and steering angles.

Input the vehicle’s wheelbase and trackwidth into cells A1 and A2.

Input the forward, strafe_right, and rotate_clockwise commands into cells A4, A5, and A6.

As a point of interest, note that if you enter FWD=1, STR=0.3, and RCW=0.384, you get Ackermann steering.

In fact, for any values of FWD_Ackerman and Turn_Ackermann, if you input

FWD=FWD_Ackermann, 
STR=Turn_Ackermann*sign(FWD)
RCW=STR*sqrt(L^2+W^2)/L

…you will get Ackermann steering. The derivation of this relationship is shown in the PDF attachment “convert Ackermann commands to holonomic”.

Or you can get front-wheel Ackermann steering when going forward and rear-wheel Ackermann steering when backing up if you enter:

FWD=FWD_Ackermann
STR=Turn_Ackermann
RCW=STR*sign(FWD)*sqrt(L^2+W^2)/L

Or you can get “snake” steering (both front and rear wheel steering) if you simply set STR=0 and use:

FWD=FWD_snake
RCW=Turn_snake*sign(FWD)

**

15

Here’s a handy “cheat sheet” for converting Cartesian coodinates to zero to 360 degrees, measured either clockwise or counterclockwise from any of the four quadrantal angles (0, 90, 180, 270):

convert Cartesian coordinates to angle

**

16

Unless its just my bad luck, it looks like the links are not working. Can anyone else access the sample LabVIEW file?

Bruce

17

We use a “minimum angle” algorithm to in our swerve code and reverse the drive direction as needed. This works out very well. We code in Labview. 1640 has built 4 wheel independent drive & steering swerve robots for 4 years.

Very clear paper. Thanks.

1 Like
18

Why is _R defined as sqrt(L^2 + W^2) in the excel spreadsheet, but defined as sqrt(L^2 + W^2)/2 in the Derivation of Inverse Kinematics powerpoint?

19

R is not defined in the PDF. r is. r= R/2.

The formulas for A,B,C,D are the same in both.

For example:

PDF: 
A = Vx - ω*(L/2)

Excel:  
A = STR - RCW*(L/R) 
  = Vx - ω*r*(L/(2*r))
  = Vx - ω*(L/2)
  = same as PDF
20

what if we want to derive the formulas for wheel angle and wheel speed takes from counter clockwise and from +x axis ? please tell me, thank you