Corrected values for kiwi drive and Mecanum drive mixes

These omnidirectional drive mixes were originally part of my guide to EdgeTX Transmitter Programming for Combat Robotics. They received so many questions that I gave them a dedicated page to give space for full explanations.

EdgeTX Kiwi Drive Mix

Q: I'm building a three-wheel kiwi drive beetle and I'm looking for a mix for my Radiomaster transmitter. Your EdgeTX combat guide has a mix for a four-wheel Mecanum omnidrive but not for a kiwi drive. Is the mix for my three-wheel kiwi drive omnibot similar to the Mecanum mix?

A: The FIRST robotics competitors are fond of the kiwi drive and have written a good bit about them. Lots of vector analysis and trigonometry. You can find one such discussion of kiwi drive control at stackoverflow.com: How to Control a Kiwi Drive Robot. Translating the information from that discussion to an EdgeTX mix gives us this:

The drive ESCs plug into the receiver ports as labeled; receiver port CH4 is available for weapon control. With a standard mode 2 stick layout:

Right stick: ↔ lateral strafe and ↕ forward/back.

Left stick: ↔ rotation and ↕ weapon.

Note: The mix values assume that the wheels are equidistant and angled 120 degrees from each other - like the sketch above. If that's not true for your design you'll need to break out the trig tables and recalculate the speed weight for CH3 Aileron. Write to me if you need help with this.

Comment: I think the omni drive values are incorrect? For a standard equidistant/equal angle setup, The front wheels ELE should be sqrt(3)/2 = 87% scale, and AIL should be 50% as I understand it. The screen shot below shows my EdgeTX omni drive mix which works correctly.
Flawed Kiwi drive mix

Reply: The motor control inputs that you (and pretty much everybody else) are using are based on a set of equations developed to calculate the maximum Y and X axis speeds for each of the three wheels as a trig function of the available straight-ahead wheel speed -- see image inset. Transferring these speed function coefficients into Aileron and Elevator mix weights is flawed logic that results in a 'bot that is both unnecessarily slow and unable to maintain correct linear response to transmitter inputs.

These derived speeds are not targets that you must adjust your mix to attain -- they are the natural result of the kiwi drive geometry.

Correct mix weights will be either 100% or -100% with the exception of the aileron inputs for CH1 and CH2 which are limited to maintain a linear lateral strafe path. The Run Amok 100 Mix in the screenshot above produces much improved speeds (+15% forward/reverse and +100% side-to-side) and allows a true linear strafe.

The images below graphically show the percentage of available power applied to each of the three motors throughout the full range of non-rotational holonomic motion. An efficient mix will have less 'grey' underpowered area in their graph, and the grey areas will be triangular.

If you still have doubts, it will take only a few minutes to input and test the performance of the Run Amok mix on your robot.

Experimentally minded builders may wish to play with the Desmos Kiwi Drive Calculator.

BONUS: Someone will eventually point out that my Kiwi mixes for CH1 and CH2 are "non-linear" and that for perfect Kiwi control they should be "linear". Yes, although my Kiwi 100 mix is efficient it imperfectly fits the "ideal" Kiwi control profile -- off by as much as 9% in places.

I doubt you'd ever notice this disparity in the real world, but to head-off complaints from perfectionists I assembled a version of the mix that incorporates a set of six custom curves to warp all three Kiwi control channels into their correct shapes.

I'm not going to explain the process or detail the changes -- just download this Kiwi_Perfect.yml file, copy it into the BACKUP folder on your transmitter SD Card, and RESTORE it into an empty model slot.

I personally wouldn't bother.

Q: Will you please walk me through how the mix works? I'd like to know how to modify it for a non standard design. What changes if the wheels aren't set 120° apart? What changes if the wheels aren't equidistant?

A: Sure. Using the convention from the stackoverflow.com discussion, where a '+' value spins the motor clockwise and a '-' value spins the motor counter-clockwise:

Pushing the right stick forward (Elevator):

CH1 motor spins counter-clockwise;
CH2 motor spins clockwise;
CH3 motor does not spin;

...and the robot moves straight forward.

Nothing in the Elevator settings should change with reasonable design changes in angles and lengths.

Pushing the right stick to the right (Aileron):

CH1 motor spins counter-clockwise at 50% the speed of CH3;
CH2 motor spins counter-clockwise at 50% the speed of CH3;
CH3 motor spins clockwise at full speed;

...and the robot moves sideways to the right.

In standard omni-wheel positions, CH1 and CH2 are set at 60° relative to the sideways motion of the robot. At 60° angles, each lateral unit of motion will displace CH1 and CH2 0.5 unit perendicular to that motion (cosine 60 deg). To maintain linear lateral motion both CH1 and CH2 must rotate at 1/2 the speed of CH3 to compensate for that diplacement.

Pushing the left stick to the right (Rudder):

Spins the CH1 motor counter-clockwise;
Spins the CH2 motor counter-clockwise;
Spins the CH3 motor counter-clockwise;

...and the robot spins in place clockwise.

If all three omni-wheels set at the same distance from the point where the extended axes of their hubs intersect, their responses to Rudder input should also be the same. If you move the CH3 wheel in toward the intersection point to shorten your robot, the radius of the circle it makes when the robot spins will be reduced and so the CH3 response to Rudder input should also be proportionally reduced to keep the robot rotation centered.

Q: I'd rather put the sideways strafe control on the left stick and move rotation to the right stick. Is that an easy change?

A: Just swap the AIL and RUD weights for CH1, CH2, and CH3 in the MIXES screen to flip strafe and rotation sticks. The values after swaping are shown in red in the screenshot on right.

EdgeTX Mecanum Drive Mix

Q: You mentioned that it's possible to program a Mecanum wheel omni-drive mix in EdgeTX firmware. What would that look like?

A: It's surprisingly simple in EdgeTX. Mecanum drive requires four wheels, four motors, four speed controllers, and a transmitter mix to sort out the the right signals and provide omni-directional control (video).

Assuming that you want a standard single-stick drive on the right stick with the added side-strafe control on the left 'rudder' axis, your channel layout and MIXES page are shown in the pictures above.

Real omni-drive jockeys may prefer putting strafe on the right stick and rotation on the left. Just swap the 'Ail'eron and 'Rud'der weights on CH3 and CH4 in the MIXES screen to give that a try.

Comment: With your Mecanum mix as it is, the outputs will max out before you reach max stick travel. You have to scale the inputs by 1/3 accordingly if you want access to the full range of input values. A much better way of doing this would be to dynamically scale the values based on the largest single input, but as far as I've found, you'd have to implement this with Lua scripts in EdgeTx, which is another can of worms altogether that I haven't solved yet -- something about compiling EdgeTx yourself with certain flags to gain access to mix scripts.

Reply: Under some control combinations my Mecanum mix does reach maximum throttle before reaching full stick travel -- but so does the standard delta wing (elevon) mix so widely used in robot combat.

A Mecanum drive robot in an industrial application might require uniform and linearly precise speed control on all axes, but a Mecanum combat robot demands full power and speed along any given control axis. I encourage you to implement my control mix on a combat Mecanum drive 'bot to see if the loss of sensitivity actually causes any issues for you before pursuing exotic solutions.

EdgeTX Kiwi Drive Mix -- your kiwi mix is probably wrong.