Hex Kiwi Drive

[caume]

Over the past few weeks, I have been working on a hex kiwi drive train. It is a six-sided drive, with an omni wheel on each side. This allows for nearly identical speed and pushing power in every direction. A rough weight estimate of this is ~35lb, without bumpers, battery, or electronics.

Specs:

12:64 Drive Ratio
4 inch Omni Wheels
Theoretical Speed: 17 ft/s
Stall Force: 196-227 lb, depending on direction


If you see any mistakes after looking at this, please let me know! Thanks!

[Jay O'Donnell]

i would definitely work on adding some gussets or other type of support between the drive rails and the upper frame. Looks like it only held on by 6 standoffs right now. Keep in mind all of the force of a defense hit goes into the bumpers, so you want that connection to be really strong.

Also, keep in mind pushing with omnis isn't very efficient. The major point of an omni directional drivetrain is to avoid collisions.

[asid61]

That might be a tad fast even for 6 CIMs, because of brownouts. Apart from that, I really love this implementation.
Your CIMs appear to be bleeding into the bellypan. :P
Have you thought about using the Vex clamping gearboxes instead of custom? I like your implementation as it keeps this low to the ground, but it's something to think about.

EDIT: Missed the upper fame. :P As Jay said, adding some 2x1s or something with cuts to that they fit into the main rail and upper rail would be much more secure.

[caume]

i would definitely work on adding some gussets or other type of support between the drive rails and the upper frame. Looks like it only held on by 6 standoffs right now. Keep in mind all of the force of a defense hit goes into the bumpers, so you want that connection to be really strong.

Also, keep in mind pushing with omnis isn't very efficient. The major point of an omni directional drivetrain is to avoid collisions.
I was thinking the same thing about the bumpers.

For the omnis, shouldn't coefficient of friction be high in the direction of the wheel? The added pressure from the sides of the rollers should help, no? The reason omnis are used to get away is because they are more maneuverable, but if the rollers aren't consistent in every direction, they should be good for pushing, I thought.

[Jay O'Donnell]

I was thinking the same thing about the bumpers.

For the omnis, shouldn't coefficient of friction be high in the direction of the wheel? The added pressure from the sides of the rollers should help, no? The reason omnis are used to get away is because they are more maneuverable, but if the rollers aren't consistent in every direction, they should be good for pushing, I thought.

Not sure what you mean by added pressure from the sides of the rollers, so forgive me if my thoughts don't make sense with yours.

The main issue is that most collisions are directly applied to a bumper side. This means that only two of your wheels will be driving directly against the pushing robot, and you're not using all of the power that you have efficiently since the driving vectors are at an angle.

Edit: other problem with omni directional drivetrains like this is that it is easier to get pushed from the side and be moved. A good driver can get out of it, but usually it ends up not being worth it.

[caume]

Your CIMs appear to be bleeding into the bellypan. :P
Have you thought about using the Vex clamping gearboxes instead of custom? I like your implementation as it keeps this low to the ground, but it's something to think about.


My original version of the cad actually used the vex clamping gearboxes. My team has had problems with motors sagging down, so I went on to make the motors lower, with cutouts in the bottom plate. The idea was the bottom plate would support the motors a bit. I attached the other images.

[messer5740]

So I have difficulty seeing what previous game a hex chassis would be effective for. Would someone care to enlighten me on what benefits there are for having a hex chassis? I feel that an H drive or mecanum is a more efficient way of driving for you still have the omnidirectional movement. Also, with the electronics that would need to be added, I do not see how attachments could go onto the robot without having a tangled mess of wire and electronics on the belly pan. Perhaps even an additional pan would be good for adding attachments... I know Simbotics used a kiwi drive in 2015 in a non defensive game, but their chassis was not a hex like the one shown above. So why Hex and why kiwi?

EDIT: can you send me the CAD so I can review it some more?

[caume]

So I have difficulty seeing what previous game a hex chassis would be effective for. Would someone care to enlighten me on what benefits there are for having a hex chassis? I feel that an H drive or mecanum is a more efficient way of driving for you still have the omnidirectional movement. Also, with the electronics that would need to be added, I do not see how attachments could go onto the robot without having a tangled mess of wire and electronics on the belly pan. Perhaps even an additional pan would be good for adding attachments... I know Simbotics used a kiwi drive in 2015 in a non defensive game, but their chassis was not a hex like the one shown above. So why Hex and why kiwi?
Hex kiwi could be really good 2014, or any flat field really, because it can be so fast and maneuverable

[messer5740]

So how would you be able to get a shooter or kicker on the robot?

[CalTran]

So I have difficulty seeing what previous game a hex chassis would be effective for. Would someone care to enlighten me on what benefits there are for having a hex chassis? I feel that an H drive or mecanum is a more efficient way of driving for you still have the omnidirectional movement. Also, with the electronics that would need to be added, I do not see how attachments could go onto the robot without having a tangled mess of wire and electronics on the belly pan. Perhaps even an additional pan would be good for adding attachments... I know Simbotics used a kiwi drive in 2015 in a non defensive game, but their chassis was not a hex like the one shown above. So why Hex and why kiwi?

EDIT: can you send me the CAD so I can review it some more?

To be fair, 148 won a Championship with a nonagon chassis.

[Alan Anderson]

To be fair, 148 won a Championship with a nonagon chassis.

The frame had nine sides, true. Count the wheels, though.

[messer5740]

The frame had nine sides, true. Count the wheels, though.


Most likely not 6...

[caume]

Most likely not 6...
To counter that argument, look at like 90% of the robotics this year, 6WD. This is just a fancy 6WD if you think about it

[messer5740]

To counter that argument, look at like 90% of the robotics this year, 6WD. This is just a fancy 6WD if you think about it

True true didn't think about our own robot:p

[Jonny_Jee]

Most likely not 6...

148 had a three wheel swerve drive that year.

[Cash4587]

The programming on this would be very very tricky. Figuring out how much power to give each motor in the "Forward" direction would take some playing with and tuning because two wheels are pointed "Forward" and the other four are angled.

Although this is a cool idea and looks interesting it probably is not very practical. In most cases it would make the most sense to just do a 3 wheel kiwi or an H-Drive. For that matter, even a swerve would probably make more sense.

[Dan_Karol]

Interesting idea,

Something to think about is that it will be really hard to guarantee that all 6 wheels are contacting the floor and transferring force. This is especially true since there are no real specifications on the flatness of the field that get measured during setup

Most groups that use force-vector drive trains (kiwi,mecanum) either rely on flexibility in the chassis to help the wheels touch the floor at all times or they limit themselves to 3 wheels.

It may not matter if there is not uniform contact for this implementation as each wheel will contribute less to the overall robot motion so the loss of any single wheel should have less of an impact. If the robot is sitting on three wheels, two or more of which are adjacent there will still be strange behavior.

A way to get around this could be to use the a suspension. one implementation could be similar to the VersaDrop sold by Vex pro with the pressure regulated down just low enough to not cause the pneumatic cylinders to deploy when pressurized. With this system, when a wheel encounters a dip or sag in the floor it will follow the contour and stay in contact.

That said a simple proof of concept would make all of these concerns unnecessary.

Good luck!

[ThaddeusMaximus]

To counter that argument, look at like 90% of the robotics this year, 6WD. This is just a fancy 6WD if you think about it

6 wheels? yep. fancy? You betcha. Same thing? Heavens no.

6wd gives you maximum pushing force (for both motor and traction) in the direction of orientation. Omniwheels currently available are less grippy than solid wheels currently available, and having 2/3s of your wheels basically inactive when in a straight line reduces motor power. These are not perks...

Not to mention the normal force on any set of wheels is half of that in a kiwi. I'd think for this reason that a kiwi would beat this in a pushing match, which would proceed to get dominated by a 6wd with good solid wheels.

[ThaddeusMaximus]

The programming on this would be very very tricky. Figuring out how much power to give each motor in the "Forward" direction would take some playing with and tuning because two wheels are pointed "Forward" and the other four are angled.


Unsure why this would be any more confusing than kiwi drive inverse kinematics. Just do the geometry what with the velocity vectors.

[caume]

6 wheels? yep. fancy? You betcha. Same thing? Heavens no.

6wd gives you maximum pushing force (for both motor and traction) in the direction of orientation. Omniwheels currently available are less grippy than solid wheels currently available, and having 2/3s of your wheels basically inactive when in a straight line reduces motor power. These are not perks...

Not to mention the normal force on any set of wheels is half of that in a kiwi. I'd think for this reason that a kiwi would beat this in a pushing match, which would proceed to get dominated by a 6wd with good solid wheels.
I was mostly joking when I said it's a 6WD. Obviously, the only real similarity is the number of wheels. Where did you get the information about omnis being less grippy? I'm not doubting it at all, I just haven't been able to find info about the CoF when I've looked.

[Cash4587]

Only thing I would be worried about is that it probably will act a bit weird when trying to go forward since the side wheels would not be at the 30 degree angle like the other 4. As long is the math is done out right though it probably would be fine.

[EricH]

I was mostly joking when I said it's a 6WD. Obviously, the only real similarity is the number of wheels. Where did you get the information about omnis being less grippy? I'm not doubting it at all, I just haven't been able to find info about the CoF when I've looked.
0.8-0.88 for an AM 6" aluminum omni (AM site)
A 6" "normal" wheel (rubber tread, not high grip) is 0.9 (AM site).
"HiGrip" wheels are 0.95.

That's going to be a 10%-20% increase in grippiness when using non-omni wheels instead of omniwheels.

[ctt956]

Very interesting drivetrain! I like the shape. As others have said, the bumper mounts on the frame probably need to be stronger. If you use those custom gearboxes, covering them would be a good idea to keep debris, wires, loose parts, etc. out of the gears. There is a PCM near a CIM motor, but I don't see any pneumatics...is it there just in case some will be added? I think the battery connector mounted on the robot is a good idea, but could be higher to avoid bending the wires too much. Maybe a smaller mount too so connecting/disconnecting would be easier. As for practical use in a game, this would probably only be effective if the robot needed to reach something higher up so the frame wouldn't get in the way of doing so, as in 2011. But just because there hasn't yet been a game where this would be practical doesn't mean there won't be one in the future... If nothing else, this would be an impressive demo bot. I wonder how fast that thing could spin in place with all 6 CIMs running at full speed...:]

[Ether]

The programming on this would be very very tricky.


wheel1 = STR + ωR
wheel2 = - FWDcos30 + STRcos60 + ωR
wheel3 = - FWDcos30 - STRcos60 + ωR
wheel4 = - STR + ωR
wheel5 = FWDcos30 - STRcos60 + ωR
wheel6 = FWDcos30 + STRcos60 + ωR

(Then divide all wheel speeds by the maximum one if any one exceeds the maximum achievable wheel speed)

[caume]

There is a PCM near a CIM motor, but I don't see any pneumatics...is it there just in case some will be added?

That is a VRM

[Cash4587]

wheel1 = STR + ωR
wheel2 = - FWDcos30 + STRcos60 + ωR
wheel3 = - FWDcos30 - STRcos60 + ωR
wheel4 = - STR + ωR
wheel5 = FWDcos30 - STRcos60 + ωR
wheel6 = FWDcos30 + STRcos60 + ωR

(Then divide all wheel speeds by the maximum one if any one exceeds the maximum achievable wheel speed)

I hadn't thought of doing it this way. I had just assumed that "Forward" would be a point of the hexagon moving forward utilizing all six wheels when going forward, instead of just four using this setup. Even still, this all makes more sense now.

[Ether]

I hadn't thought of doing it this way. I had just assumed that "Forward" would be a point of the hexagon moving forward utilizing all six wheels when going forward, instead of just four using this setup. Even still, this all makes more sense now.

If you want FWD to be a point on the hexagon, just change the inverse kinematics like so:


wheel1 = - FWDcos60 + STRcos30 + ωR
wheel2 = - FWD + ωR
wheel3 = - FWDcos60 - STRcos30 + ωR
wheel4 = FWDcos60 - STRcos30 + ωR
wheel5 = FWD + ωR
wheel6 = FWDcos60 + STRcos30 + ωR


(Then divide all wheel speeds by the maximum one if any one exceeds the maximum achievable wheel speed)

[caume]

I hadn't thought of doing it this way. I had just assumed that "Forward" would be a point of the hexagon moving forward utilizing all six wheels when going forward, instead of just four using this setup. Even still, this all makes more sense now.

I should have added the pseudo to the original post, but this guy did it just how I did. The only difference is I would have field orientation, so it could have any part of the robot set as forward.

[ctt956]

That is a VRM

OK, it was hard to tell from the CAD as the two look similar: VRM (http://www.andymark.com/product-p/am-2857.htm) PCM (http://www.andymark.com/product-p/am-2858.htm)

[GeeTwo]

Although this is a cool idea and looks interesting it probably is not very practical. In most cases it would make the most sense to just do a 3 wheel kiwi..

Yes. The great advantage of 3 wheels is the relative insensitivity to irregularities in the drive surface. Unless you reach really high angles or high center on at least one side, all three wheels will carry a share of the robot weight, enabling the vector drive forces to add up as intended. With six wheels, it is rather easy for some of the wheels to come off the floor, sending the net drive force in unintended directions.


That might be a tad fast even for 6 CIMs, because of brownouts.

For brownout/gear ratio purposes, this is not the same as a 6 CIM skid/swerve. If you're driving parallel to two of the wheel axles, two of the CIMs do not contribute to the drive at all, and the other four are reduced about 13%. If you're driving perpendicular to two of the wheel axles, two CIMs are fully engaged and four are limited to about half contribution. Due to different efficiencies at different speeds and that you're drving different motors at different levels, things will get more complicated quickly. With a holonomic drive train, you should be more concerned about avoiding or escaping pushing contests than about winning them.

[Ether]

I should have added the pseudo to the original post, but this guy did it just how I did. The only difference is I would have field orientation

@caume: I'm curious to see how you would go about this. Please post your pseudocode with field orientation.

[wildwaffle]

I might have missed someone saying this(correct me if they did), but a hexagonal robot would not be for pushing power. The design makes it easy to get out of being pinned. A perk to an omni wheel drivetrain is that if you know how to drive it well, then you can use another robot pushing you to your advantage. I know it's a different shaped chassis but team 33 in 2014 had a four omni wheel drivetrain. It wasn't omni directional unless another team applied the force to their side, and they used this to their advantage. (They won 2 districts, their district champs, and we're finalists in their division at worlds)

[caume]

@caume: I'm curious to see how you would go about this. Please post your pseudocode with field orientation.




With this model, the battery is the back of the drive, the point opposite it is the front. flMotor would be the motor on the left side, closest the point opposite the battery.

Psuedocode:

if (fieldOriented) {
cosA = cos(( target - gyroAngle ) * 3.14159 / 180 )
sinA = sin(( target - gyroAngle ) * 3.14159 / 180 )

x = (driverLX * cosA) - (driverLY * sinA)
y = (driverLX * sinA) + (driverLY * cosA)
}


flMotor = y*sind(60) + x*cosd(60) + turn
mlMotor = y + turn
blMotor = y*sind(60) - x*cosd(60) + turn
frMotor = - y*sind(60) - x*cosd(60) + turn
mrMotor = - y + turn
brMotor = - y/sind(60) + x/cosd(60) + turn

[TheMagicPenguin]

I'm not 100% sure if having six wheels woild give you an advantage over having 3 or 4. The real advantage with this design is manuvrability.

Having a hexagon robot would allow you to not get pinned easily, and also the added advantage of having a smaller turning diameter.

I can attest to this advantage. In my first year of FTC we created a 4 omni wheel robot hexagon frame, and a round shell. Having this rounded shell let us cut corners that no one else could, not get pinned, and when turning we had no corners that could get caught on obstacles (i.e robots, field elements, field perminiter).

Here is an attached picture:

[Ether]

With this model, the battery is the back of the drive, the point opposite it is the front. flMotor would be the motor on the left side, closest the point opposite the battery.

Psuedocode:

if (fieldOriented) {
cosA = cos(( target - gyroAngle ) * 3.14159 / 180 )
sinA = sin(( target - gyroAngle ) * 3.14159 / 180 )

x = (driverLX * cosA) - (driverLY * sinA)
y = (driverLX * sinA) + (driverLY * cosA)
}


flMotor = y*sind(60) + x*cosd(60) + turn
mlMotor = y + turn
blMotor = y*sind(60) - x*cosd(60) + turn
frMotor = - y*sind(60) - x*cosd(60) + turn
mrMotor = - y + turn
brMotor = - y/sind(60) + x/cosd(60) + turn



If I assume the following:

driverLX is the driver's field-centric move right command
driverLY is the driver's field-centric move downfield command
turn is the driver's rotate clockwise command
target is an angle offset which defines the "front" of the robot relative to the point opposite the battery

... then your code gives incorrect answers for the wheel speeds. See example (http://www.chiefdelphi.com/forums/attachment.php?attachmentid=20837&stc=1&d=1465182782) with target=0 (front is defined as the point opposite the battery as stated above) and gyroAngle=0 (robot front is facing straight downfield).


this guy did it just how I did.

Apparently not. The code I posted (http://www.chiefdelphi.com/forums/showpost.php?p=1590089&postcount=27) gives the correct wheel speeds for robot-centric driver FWD and STR commands.

To make that code give the correct wheel speeds for field-centric driver FWD and STR commands, just modify those commands as follows before calculating the wheel speeds:


temp = FWD·cos(θ) + STR·sin(θ);
STR = -FWD·sin(θ) + STR·cos(θ);
FWD = temp;

... where θ is the gyro angle, measured clockwise from straight downfield.