Hex Kiwi Drive

[Ether]

Originally Posted by caume

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]

Originally Posted by Ether

@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]

Originally Posted by caume

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 with target=0 (front is defined as the point opposite the battery as stated above) and gyroAngle=0 (robot front is facing straight downfield).

Originally Posted by caume

this guy did it just how I did.

Apparently not. The code I posted 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.