|
|
|
![]() |
|
|||||||
|
||||||||
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)
Derivation of Inverse Kinematics for Swerve.pdf
Calculate Swerve Wheel Speeds and Steering angles.pdf
Ackermann7a.pdf
swerve_tester_6.xls
convert_XY_degrees revE.pdf
swerve_tester_8.xls
swerveForwardKinematics.zip
CWYdeg.pdf
Cartesian2angle.zip
moon.pdf
rotary.pdf
dosado.pdf
swerveN.pdf
02-01-2011 22:27
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]
02-01-2011 23:27
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.
03-01-2011 17:56
buildmaster5000I'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
}
03-01-2011 18:04
Ether|
I've developed code for a swerve drive that is based on magnitude and direction from the joystick origin...
|
03-01-2011 19:00
buildmaster5000You 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.
03-01-2011 19:29
Ether|
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.
|
05-01-2011 23:30
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. |
06-01-2011 11:51
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.The first way effectively disables the "D" portion of the PID (which you probably don't need for this application anyway).
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.
17-01-2011 09:29
EtherI just posted a 2-page summary explanation for those who just want the equations and don't care about the derivation.
25-03-2011 23:21
Ether|
I just posted a 2-page summary explanation for those who just want the equations and don't care about the derivation.
|
15-04-2011 14:31
EtherJust 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.
17-04-2011 13:48
Ethersee updated post
18-04-2011 12:11
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. |
FWD=FWD_Ackermann, STR=Turn_Ackermann*sign(FWD) RCW=STR*sqrt(L^2+W^2)/L
FWD=FWD_Ackermann STR=Turn_Ackermann RCW=STR*sign(FWD)*sqrt(L^2+W^2)/L
FWD=FWD_snake RCW=Turn_snake*sign(FWD)
25-04-2011 18:15
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
01-05-2013 23:25
MoHottaMoBetta|
Sorry, the link got broken when I uploaded a corrected version. Here's the new link: http://www.chiefdelphi.com/media/papers/download/2858 |
02-05-2013 07:10
Clem1640We 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.