Offseason Project: Holonomic Kiwi Drive Robot

[EthanMiller]

A little intro...

1713, and by extension the FTC teams 4093 and 4356, have never experimented in holonomic drive chains before. Because an omni wheel was included in both KOPs for the FTC teams, we decided that offseason would be a great time to experiment with them. Because the wheels are FTC, we'll be using FTC parts for it.

We ordered another wheel (which hasn't arrived yet) and built a frame for kiwi drive that places them 2π/3 (120 deg) around a circle, tangent to the circle. Each wheel will be directly driven by a motor with an encoder.

Every place I've seen Kiwi drive, the 'front' has been located directly between two wheels, that powering them towards each other at the same speed would be forward. Would having the forward be directly opposite that be a problem? (Such that two wheels powered away from each other was forward)

[efoote868]

Forward is just a notation. Realistically you could put it anywhere you want in whatever polarity you want. Between two wheels for a kiwi makes sense because when you're going "forward" only two wheels are powered (simplifying your trig problem).

Regardless of what you do, kiwi drives shouldn't have a problem driving forward or backward

Hope this helps.

[MikeE]

Originally Posted by EthanMiller

Every place I've seen Kiwi drive, the 'front' has been located directly between two wheels, that powering them towards each other at the same speed would be forward. Would having the forward be directly opposite that be a problem? (Such that two wheels powered away from each other was forward)

In the normal configuration for going forward the two front wheels are moving at the same speed, although the motors are rotating in opposite directions, while the third wheel is perpendicular to the direction of motion so is stationary. In effect the third, wheel is pulled sideways on the edge rollers. If you reverse the sense of forward, the math is basically the same but with the non-axial-rotating wheel now at the front of the robot.

The only issue is that the wheel which was pulled behind the robot is now being pushed in front of the robot. Since the radius of the rollers which are rotating is obviously very much smaller than the radius of the wheel, you now have a much lower tolerance for surface bumps or obstructions.

[EthanMiller]

Bumps and obstructions seem like it's worth planning for - thanks for the info.

However, once those things are under the robot, the 'back' wheel being dragged would still catch on objects, right?

[Ether]

Originally Posted by EthanMiller

We ordered another wheel (which hasn't arrived yet) and built a frame for kiwi drive that places them 2π/3 (120 deg) around a circle, tangent to the circle. Each wheel will be directly driven by a motor with an encoder.

Every place I've seen Kiwi drive, the 'front' has been located directly between two wheels, that powering them towards each other at the same speed would be forward. Would having the forward be directly opposite that be a problem? (Such that two wheels powered away from each other was forward)

That should work fine. If you're interested, here's a graphic showing the inverse kinematics for the three-omniwheel vehicle you described. Scroll to the bottom and grab file "Kiwi Omniwheel Inverse Kinematics"

[MikeE]

Originally Posted by EthanMiller

Bumps and obstructions seem like it's worth planning for - thanks for the info.

However, once those things are under the robot, the 'back' wheel being dragged would still catch on objects, right?

Right, but the moments are different: think of the force relative to the CoG of the robot.
Or consider the the difference between pushing a wheelbarrow over an obstruction vs pulling a trailer over an obstruction. When you are pushing an object there is a tendency to "dig in".

But as Ether shows in detail above, the control scheme is the same - there is rotational symmetry with Kiwi drive, so "forward" is just a convention.

[WizenedEE]

Hey I built a killough drive.. It's much cooler if you make it so that there isn't a front at all. Mine's circular, so that's not a problem.

What are you planning to do with the front? Why don't you just make everything symmetric?

Also, you should be able to get the same amount of force in any direction. PM me if you need any help with coding, I managed to get mine to be field relative with a gyroscope so I can give you some programs.

[MentorOfSteel]

This is just a bit off topic, but you've touched on a pet peeve of mine. I have noticed that many people in the FRC community (and many people working in the field of robotics in general) use the word "holonomic" interchangeably with the word "omnidirectional". This usage is incorrect, and I would like to take this opportunity to explain why.

The words holonomic and nonholonomic refer to types of velocity constraints that can be placed on a robot (see, e.g., Murray, Li, and Sastry, A Mathematical Introduction to Robotic Manipulation, CRC Press, 1994). Holonomic constraints are those that result in an algebraic constraint on the position of the robot. Train tracks, for example, introduce a holonomic constraint. A vehicle on train tracks is constrained so that the velocity perpendicular to the tracks is always zero, and the effect of this constraint is that the position (i.e., configuration) of the vehicle will always stay on the track.

Nonholonomic constraints refer to velocity constraints that do not result in an algebraic constraint on the position of the robot. Most wheeled vehicles have a velocity constraint that the wheels cannot slip sideways, however these velocity constraints do not result in corresponding constraints in position. You can drive your car anywhere you want, but the nonholonomic constraint is still there.

Most people think that nonholonomic constraints are bad because the word is so long and because they pose difficulties to automatic vehicle control, but in fact holonomic constraints are much worse because there is nothing you can do about them. No matter how fancy of a controller you come up with, a vehicle on train tracks will never leave the tracks, so if you want to get to a point that is not on the tracks you are out of luck.

Linguistically, at some point in time, people started calling robots with nonholonomic constraints "nonholonomic robots". This usage is technically incorrect. A robot cannot be nonholonomic, only a constraint can (OK, technically, a robot can be nonholonomic, but it doesn't mean what you think, see CRAZY FOOTNOTE below). There is an implicit convention used there that "nonholonomic robot" means "robot with nonholonomic constraints". That meaning is clear enough, so I can live with it.

Omnidirectional robots remove the nonholonomic constraints, so it is tempting to call them "non-nonholonomic robots". Again, this is technically incorrect, but the meaning is still clear enough, "non-nonholonomic robot" means a robot without nonholonomic constraints.

But the word non-nonholonomic just seems silly. Two "non"s should cancel each other, so people started calling omnidirectional robots "holonomic robots". But this is wrong (regardless of Wikipedia says :-). By the convention, a holonomic robot should be a robot with holonomic constraints. But an omnidirectional robot does not have velocity constraints, holonomic or otherwise, that is the point of building them!

So how is that for a long, off-topic rant about something that doesn't really matter anyway?

-George

[CRAZY FOOTNOTE] The word holonomic has Greek roots and means "altogether lawful" (see Mason, Mechanics of Robotic Manipulation, MIT Press, 2001). So after your robot passes inspection, it is correct to call it a holonomic robot.

[Ether]

@George:

I must admit I smiled when I read your post since somewhat similar thoughts have passed through my mind in the past couple of years.

However, words enter the English language through repeated usage which facilitates communication, and in the field of robotics the adjective "holonomic" when applied to a robot has come to mean that the robot can translate (X,Y) and rotate (theta) simultaneously and independently.

This usage of the word is a good thing, in the sense that it is widely understood and there is no other word available that captures quite the same meaning.

many people in the FRC community (and many people working in the field of robotics in general) use the word "holonomic" interchangeably with the word "omnidirectional"

an omnidirectional robot does not have velocity constraints, holonomic or otherwise, that is the point of building them!

Omnidirectional robots remove the nonholonomic constraints,

A unicycle has nonholonomic constraints (see Mason, pages 31 & 32), so is it not omnidirectional?

What is your definition of omnidirectional? Do you consider a “crab” drive to be omnidirectional? If not, what technical term do you suggest be used? But if so, what word should then be used for, say, a mecanum, to distinguish its freedom of motion from a crab’s?

Linguistically, at some point in time, people started calling robots with nonholonomic constraints "nonholonomic robots". This usage is technically incorrect.

Mason (e.g. c.f. p31) uses the phrase nonholonomic to refer to systems with nonholonomic constraints.

Nonholonomic constraints refer to velocity constraints that do not result in an algebraic constraint on the position of the robot.

Holonomic constraints are those that result in an algebraic constraint on the position of the robot.

The above is a good non-technical way to explain it. Some experts, when arguing the finer points, would say however that there are nonholonomic constraints which do result in an algebraic constraint on the position of the robot (Mason, p27)... although Mason goes on to say "the robotics literature often neglects this point, and in fact this book will henceforth also neglect it".

[Ether]

Originally Posted by WizenedEE

you should be able to get the same amount of force in any direction

Not so.

In the "forward" direction (as specified by the OP), the maximum vehicle force is

Fvehicle_forward = 2*Fwheel*COS(30) = Fwheel*sqrt(3)

... whereas the maximum vehicle force in the sideways direction is

Fvehicle_sideways= Fwheel + 2*Fwheel*COS(60) = Fwheel*2

where Fwheel is the maximum available drive torque on the wheel times the wheel radius, or the maximum available wheel traction, whichever is less.

[EthanMiller]

Originally Posted by WizenedEE

What are you planning to do with the front? Why don't you just make everything symmetric?

Also, you should be able to get the same amount of force in any direction. PM me if you need any help with coding, I managed to get mine to be field relative with a gyroscope so I can give you some programs.

The front was planned only until a gyro or compass could acquired. I'd still like to look at those programs, though - what language are they in?

Originally Posted by MentorOfSteel

This is just a bit off topic, but you've touched on a pet peeve of mine. I have noticed that many people in the FRC community (and many people working in the field of robotics in general) use the word "holonomic" interchangeably with the word "omnidirectional". This usage is incorrect, and I would like to take this opportunity to explain why.

I didn't know that - thanks.

Originally Posted by Ether

That should work fine. If you're interested, here's a graphic showing the inverse kinematics for the three-omniwheel vehicle you described. Scroll to the bottom and grab file "Kiwi Omniwheel Inverse Kinematics"

Thanks for the document. I'd done something similar when figuring out the programming, nice to see it laid out that way.

(We've hit a slight roadblock - RobotC license expired. Purchasing the new one soon, hopefully will be back on track ... )

I do have one question on scaling. If the equations used are (ignoring rotation for now, and with joyX1 being the X axis of the first joystick, and so on)

W1 = joyX1
W2 = (- joyX1 / 2) + sqrt(3) joyY1 / 2
W3 = (- joyX1 / 2) - sqrt(3) joyY1 /2

And the joysticks give a value between -157 and +156, and the motors take a power command of between -100 and 100, I'd divide the results of those equations by 157 and multiply by 100, right?

Then, to add rotation, it would be added to each equation before the scaling, and I'd have to check for out-of-rangeness, and correct it if it was. Would I do that before or after the scaling to correct it? I don't think it would matter, but just in case it does.

[Ether]

Originally Posted by EthanMiller

I do have one question on scaling. If the equations used are (ignoring rotation for now, and with joyX1 being the X axis of the first joystick, and so on)

W1 = joyX1
W2 = (- joyX1 / 2) + sqrt(3) joyY1 / 2
W3 = (- joyX1 / 2) - sqrt(3) joyY1 /2

And the joysticks give a value between -157 and +156, and the motors take a power command of between -100 and 100, I'd divide the results of those equations by 157 and multiply by 100, right?

Then, to add rotation, it would be added to each equation before the scaling, and I'd have to check for out-of-rangeness, and correct it if it was. Would I do that before or after the scaling to correct it? I don't think it would matter, but just in case it does.

Whenever you do inverse kinematics to find wheel speeds from joystick commands, you should always normalize the wheel speeds after they are calculated.

So for your example, what I would recommend is this:

1) divide each of the joystick values by 1.57 before plugging them into the inverse kinematic formulas

1) Look at the wheel speed values W1 W2 W3 calculated using the formulas, and find the one that has the maximum absolute value. Call this answer "max"

2) If "max" is less than or equal to 100, you're done. If "max" is greater than 100, divide each wheel speed by "max".

Then, to add rotation, it would be added to each equation before the scaling, and I'd have to check for out-of-rangeness, and correct it if it was. Would I do that before or after the scaling to correct it? I don't think it would matter, but just in case it does.

It does matter.

The front was planned only until a gyro or compass could acquired.

All that is required to do field-oriented control is to run the "forward" and "strafe right" commands through a Cartesian coordinate rotation before feeding them into the inverse kinematic formulas.

There's a paper titled "1-26-2011 mecanum & omni with gyro for field-centric control" here that shows how to do this.

[EthanMiller]

Okay... bear with me here.

(I made an error in my previous post - the sticks return from -127 to 126, but that won't effect values)

If I divide my joystick values by 157 before throwing them into the equations, wouldn't the equations return a value between -1 and 1?

For example, my math suggests that if the joystick were at (0,157), the value returned would be W2 and W3 running towards each other at .866 speed. I would then multiply that value by 100 to get the motor speed. The 86.6 would then be looked at in the abs val as the max, and left alone, right?

This also suggests to me (I could be wrong) that in that configuration, the robot wouldn't be going to maximum speed it was capable of - Or at least, I would expect that to be with both motors spinning towards each other at 100%. Is there a way to correct for that, or am I just wrong?

And for rotation, that would make my formulas...

W1 = joyX1 + R
W2 = (- joyX1 / 2) + sqrt(3) joyY1 / 2 + R
W3 = (- joyX1 / 2) - sqrt(3) joyY1 /2 + R

where R is rotation, scaled down from the joystick by dividing by the maximum joystick reading?

And then, I'd have to check that none of the equations returned values greater than 100, and if so, make it 100? (100 after being scaled up, 1 before)

[MentorOfSteel]

Nice rebuttal, Ether!

Originally Posted by Ether

However, words enter the English language through repeated usage which facilitates communication, and in the field of robotics the adjective "holonomic" when applied to a robot has come to mean that the robot can translate (X,Y) and rotate (theta) simultaneously and independently.

I grudgingly agree, I am fighting a losing battle, but it is fun to rant about it once in a while.

Originally Posted by Ether

A unicycle has nonholonomic constraints (see Mason, pages 31 & 32), so is it not omnidirectional?

What is your definition of omnidirectional? Do you consider a “crab” drive to be omnidirectional? If not, what technical term do you suggest be used? But if so, what word should then be used for, say, a mecanum, to distinguish its freedom of motion from a crab’s?

I would not classify either a unicycle or a crab drive as omnidirectional. My definition of omnidirectional is that the kinematics allow instantaneous velocity in all directions in the configuration space. Omni drives and mecanum drives satisfy this definition. A crab drive can seemingly move in every direction at once (especially with some of the ridiculously skilled FRC drivers at the helm) but a closer look reveals that it must first take the time to properly orient it's wheels. Viewed instantaneously, a crab drive only has two (or fewer in some wheel configurations) degrees of freedom at any given instant.

I don't have an alternate term to describe the nature of the crab drive, but I'm not sure there needs to be one. Speaking mathematically, I do not see any qualitative difference between a crab drive and unicycle or an Ackerman steered car. All are controllable, kinematic systems with nonholonomic constraints, they just have different degrees of difficulty associated with doing the actual control. We might consider the crab drive to be a member of the class of vehicles with fully articulated wheels, but I don't know of an agreed upon name for that class of vehicles.

Originally Posted by Ether

The above is a good non-technical way to explain it. Some experts, when arguing the finer points, would say however that there are nonholonomic constraints which do result in an algebraic constraint on the position of the robot (Mason, p27)... although Mason goes on to say "the robotics literature often neglects this point, and in fact this book will henceforth also neglect it".

That is a great quote, I love Mason's style. But in that passage he was referring to unilateral constraints, which are different beasts altogether than the bilateral equality constraints we face with wheeled vehicles.

These are all minor details and I admit that they don't matter much from a practical perspective. But I like to think about them and talk about them, and I sincerely appreciate your interest and indulgence.

-George

[Ether]

Originally Posted by EthanMiller

Okay... bear with me here.

Not a problem.

The 157 was a typo. It should have been 1.57


As for your other concerns, I should have explained more fully.

The maximum speed of a Kiwi drive is different in different directions. If the max speed that a Kiwi can drive in the sideways direction is, say, 6 feet per second, then the max speed in the forward direction will be (6)(2/sqrt(3)) = 6.93 feet per second... 15% faster.

When doing an inverse kinematic calculation to obtain wheel speeds, the inputs to the formulas (the joystick values) represent vehicle speed commands. The inverse kinematic formulas convert those into the individual wheel speeds necessary to achieve the desired overall vehicle speed.

The formulas I gave you were scaled to present the driver with a uniform vehicle speed response in all directions.

So for example, suppose your Xj and Yj joystick values were first scaled to a range of -6 to +6 (representing +/-6 feet per second vehicle speed) before feeding them to the inverse kinematic formulas.


To command the vehicle to go forward at 6 feet per second, you would issue joystick commands Xj=0 and Yj=-6.

Calculating the wheel speeds for Xj=0 and Yj=-6, you would get:

W1 = 0

W2 = -6*0.866 = -5.2 feet per second tangential wheel velocity

W3 = -6*(-0.866) = +5.2 feet per second tangential wheel velocity

... which would cause the vehicle to go forward at 6 feet per second, as commanded.


Now look at what happens if you command the vehicle to go sideways to the right at 6 feet per second. To do this, you would have Xj=6, Yj=0.

Putting Xj=6 and Yj=0 into the inverse kinematic formulas would give:

W1 = 6

W2 = -3

W3 = -3

... which would cause the vehicle to go straight to the right at 6 feet per second, as commanded.


Suppose you wanted to command the vehicle to go 6 feet per second diagonally. You would set Xj=6/sqrt(2) and Yj =-6/sqrt(2), so that sqrt(Xj^2 + Yj^2) would be 6:


W1 = 6/sqrt(2) = 4.24

W2 = -(6/sqrt(2))/2 +0.866*(-6/sqrt(2)) = -5.8

W3 = -(6/sqrt(2))/2 -0.866*(-6/sqrt(2)) = 1.55

... which would cause the vehicle to go 6 feet per second diagonally


But what if you give joystick commands Xj=6, Yj=-6. You would be commanding the vehicle to go 6*sqrt(2) = 8.5 feet per second diagonally. What would happen?

Plugging in Xj=6 and Yj=-6:

W1 = 6

W2 = -6/2 +0.866*(-6) = -8.2

W3 = -6/2 -0.866*(-6) = 2.2

Notice that the maximum absolute value exceeds 6. Multiplying all 3 wheel speeds by 6/(8.2) gives:

W1 = 4.4

W2 = -6

W3 = 1.6

... and the normalization gives wheel speeds pretty close to the previous example