Kiwi Drive Concept

[Ginger Power]

Originally Posted by GeeTwo

This could also be achieved by raising the axles relative to the chassis while keeping them horizontal.



This is the point of dualies - there is always a roller in contact with the carpet, provided that they're mounted on a horizontal axis. Having multiple rollers in contact with the carpet at that angle will also introduce some additional friction as the rollers point in different directions.

The biggest issue is the one Wayne presented - wheels weren't meant to be loaded that direction. Omnis probably even more so - the whole point of omnis is that they don't exert a force parallel to the shaft. As a result, sound engineering would tend to reduce the sustainable force parallel to the shaft in favor of other requirements.

Both of these points make sense. The same functionality behind the "kizzy drive" can be achieved with wheels that are tangent to the ground. Thanks for the comments!

[Ginger Power]

Originally Posted by MikeE

...Kinematic calculations are left as an exercise for the student...

Ironic that you say that just as I'm leaving my last dynamics class of the year... but I agree!

[Dunngeon]

Originally Posted by Ginger Power

Obviously some years are better than others for kiwi drives but I think 1425 and 1501 proved that a well built kiwi drive can compete amidst heavy defensive pressure. My initial thought process for having dualie omni wheels was that I was worried about a single omni wheel not being strong enough. Now that you've pointed that out, my logic doesn't make a whole lot of sense!

I can't speak to 1501, but I know that 1425 had major issues when under heavy defense last year. They were effective at low levels of play, where coordinated defense wasn't common but at DCMP I remember watching them get pushed around the field extremely easily.

[GeeTwo]

Originally Posted by Ginger Power

Both of these points make sense. The same functionality behind the "kizzy drive" can be achieved with wheels that are tangent to the ground. Thanks for the comments!

Also, it would require a lot less machining to mount the feet on pneumatic cylinders (though you'd still have to harden them against lateral forces, perhaps with a pipe-within-a-pipe), and hard-mount the wheels. Whichever you actuate, moving the feet close to the where the wheels contact the carpet will decrease the vertical travel required to reliably switch.

[The other Gabe]

Originally Posted by Dunngeon

I can't speak to 1501, but I know that 1425 had major issues when under heavy defense last year. They were effective at low levels of play, where coordinated defense wasn't common but at DCMP I remember watching them get pushed around the field extremely easily.

This happened to many of the robots with Mechanum and Omni... compared to those robots, they were slightly more successful, simply because their triangle design was hard to push, but at the same time, they were pretty easy to spin

[Ginger Power]

I wonder how useful the ability to plant itself would be for the kizzy drive? Would this added ability combined with shifting its center of turn make up for the low traction inherent to all omni/mecanum drives?

[GeeTwo]

Actually, a kiwi drive (as with any holonomic drive) should already be able to rotate about any desired center of rotation, without the legs. To rotate around one of the wheels, just keep that wheel fixed, and rotate the other two at the same speed and direction (clockwise or counterclockwise). if the rotation center is desired to be closer to the center of the robot, rotate the pivot wheel in the same direction (but more slowly). If the rotation center is desired to be farther from the center, rotate the pivot wheel in reverse direction. I'll look around later to see if anyone has done the kinematics in terms of center of rotation and rotation speed; usually they're presented in terms of translation and rotation.

Unless the leg did more than just sit there or go vertically, they would presumably only be useful to stay in place. There are certainly times and games for which this is useful - planting to take a shot, for example. For defense (apart from being an obstruction), they're not likely to be effective except possibly in a few oddball orientations.

[GeeTwo]

I skipped the research when I realized that all of the square roots and trig functions canceled out, and the mapping was pretty straightforward. To map rotation about a point x_r, y_r at angular speed w_r (measured in radians/second, with rotation from the positive x axis towards the positive y axis being a positive angular speed) to translation speed v_x,v_y and rotation w₀:

w₀ = w_r
v_x = w y_r
v_y = -w x_r

you can use this same preliminary mapping to make a mecanum drive rotate around a desired point.

For conversion purposes, 1 radian per second is 30/pi ~ 9.55 rpm.

---

Using the WPIlib convention for your coordinate system (+x to the right, +y forward, rotations clockwise as viewed from above), your angular speeds will be reversed from this, and you will need to use:

w₀ = w_r
v_x = -w y_r
v_y = w x_r

[Ginger Power]

Originally Posted by GeeTwo

I skipped the research when I realized that all of the square roots and trig functions canceled out, and the mapping was pretty straightforward. To map rotation about a point x_r, y_r at angular speed w_r (measured in radians/second, with rotation from the positive x axis towards the positive y axis being a positive angular speed) to translation speed v_x,v_y and rotation w₀:

w₀ = w_r
v_x = w y_r
v_y = -w x_r

you can use this same preliminary mapping to make a mecanum drive rotate around a desired point.

For conversion purposes, 1 radian per second is 30/pi ~ 9.55 rpm.

---

If you use mathematical conventions for your coordinate system (+x to the right, +y forward), and measure your rotations with the navigation convention of clockwise as viewed from above, your angular speeds will be reversed from this, and you will need to use:

w₀ = w_r
v_x = -w y_r
v_y = w x_r

Thanks a ton for all the information about kiwi drives! It has definitely influenced my plans moving forward!

[Ether]

Originally Posted by GeeTwo

Using the WPIlib convention for your coordinate system (+x to the right, +y forward, rotations clockwise as viewed from above), your angular speeds will be reversed from this, and you will need to use:

w₀ = w_r
v_x = -w y_r
v_y = w x_r

Once you've got Vx (strafe right speed), Vy (forward speed), and ω,
the inverse kinematics for your 3 wheel tangential speeds are:

S₁ = r*ω + Vx

S₂ = r*ω - 0.5*Vx - 0.866*Vy

S₃ = r*ω - 0.5*Vx + 0.866*Vy

(see attached sketch)

[GeeTwo]

Combining the two transformations, to rotate an equilateral kiwi drive around a pivot point (x_p, y_p) with angular speed ω, the inverse kinematics using Ether's diagram above are:

S₁ = ω * (r - y_p)

S₂ = ω * (r + 0.5*y_p - 0.866*x_p)

S₃ = ω * (r + 0.5*y_p + 0.866*x_p)

Checking rotation points to verify that we didn't swap sign conventions along the way:

(0,0): all are ωr, check
(0,r): S₁ = 0, S₂ = S₃ = 1.5ωr, reasonable
(0,2r): S₁ = -ωr, S₂ = S₃ = 2ωr, reasonable
(0,-2r): S₁ = 3ωr, S₂ = S₃ = 0, check
(1.155r, 0): S₁ = ωr, S₂ = 0, S₃ = 2ωr, ok
(-1.155r, 0): S₁ = ωr, S₂ = 2ωr, S₃ = 0, ok

---

If you want "forward" to be directly between wheels rather than through one (for example if you'll be picking up pieces or doing an internal stack), rotate the robot 180 degrees, leaving the axes and forward arrow in place. Then, the inverse kinematics for rotation about (x_p, y_p) become:

S₁ = ω * (r + y_p)

S₂ = ω * (r - 0.5*y_p + 0.866*x_p)

S₃ = ω * (r - 0.5*y_p - 0.866*x_p)