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

[Ether]

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

4 wheel independent drive & independent steering ("swerve") by Ether

[Ether]

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]

[artdutra04]

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.

[buildmaster5000]

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
}

[Ether]

Originally Posted by buildmaster5000

I've developed code for a swerve drive that is based on magnitude and direction from the joystick origin...

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.

[buildmaster5000]

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.

[Ether]

Originally Posted by buildmaster5000

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.

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.

[Ether]

Originally Posted by Ether

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.

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

[Ether]

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.

* see this thread: http://www.chiefdelphi.com/forums/sh...ad.php?t=88233

[Ether]

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

[Ether]

Originally Posted by Ether

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

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.

[Ether]

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.

[Ether]

see updated post

[Ether]

Originally Posted by Ether

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.

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)

[Ether]

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