Mechanum Wheels?

I'm not saying no mecanums (or however you spell it), but these are some points made in previous threads:

-Less traction on the key
-As already said, loss in pushing power
-Heavy
-Forces you to use maximum number of motors for drivetrain (not usually an issue)
-While they may not affect your ability to go on the bridge, the ability to stay without being pushed off or falling off of the bridge tips your direction will be tough to deal with
-You won't be driving circles around other's bots unless you have a lot of practice.
-In order to work to their fullest extent, require a lot of thorough engineering
-More complicated to code, even at the minimum level


Like I said, I'm not telling you not to use them, but when you do, be careful and engineer it through (Not meant to sound like most interesting man in the world meme, though I'm tempted. )

[O'Sancheski]

Originally Posted by SuperNerd256

-More complicated to code, even at the minimum level

I disagree with this statement. WPI has a complete library for mecanum wheels. My old team used them last year for the first time and had them programmed on the drivetrain the day we received the shipment from AndyMark.

Originally Posted by O'Sancheski

I disagree with this statement. WPI has a complete library for mecanum wheels. My old team used them last year for the first time and had them programmed on the drivetrain the day we received the shipment from AndyMark.

I mean when you go into the real nitty gritty coding stuff. THe code they give you is fine, but to make it better takes some work.

This is just what I've been told by our programmers, I'm not a master of code myself, however my trustful programmers are.

[Ether]

Originally Posted by SuperNerd256

I mean when you go into the real nitty gritty coding stuff. THe code they give you is fine, but to make it better takes some work.

This is just what I've been told by our programmers

Could you please ask your programmers to tell us how they made it better than the WPI code.

Originally Posted by Ether

Could you please ask your programmers to tell us how they made it better than the WPI code.

The themselves haven't programmed it, but from reading the WPI code and looking at how to make it better, they said getting it perfect (not 100%, but a close 99%) would take some extra code.

I'll ask them at our next meeting, though. Now I'm interested, too.

[theprgramerdude]

Originally Posted by SuperNerd256

The themselves haven't programmed it, but from reading the WPI code and looking at how to make it better, they said getting it perfect (not 100%, but a close 99%) would take some extra code.

I'll ask them at our next meeting, though. Now I'm interested, too.

void RobotDrive::MecanumDrive_Polar(float magnitude, float direction, float rotation)
{
	// Normalized for full power along the Cartesian axes.
	magnitude = Limit(magnitude) * sqrt(2.0);
	// The rollers are at 45 degree angles.
	double dirInRad = (direction + 45.0) * 3.14159 / 180.0;
	double cosD = cos(dirInRad);
	double sinD = sin(dirInRad);

	double wheelSpeeds[kMaxNumberOfMotors];
	wheelSpeeds[kFrontLeftMotor] = sinD * magnitude + rotation;
	wheelSpeeds[kFrontRightMotor] = cosD * magnitude - rotation;
	wheelSpeeds[kRearLeftMotor] = cosD * magnitude + rotation;
	wheelSpeeds[kRearRightMotor] = sinD * magnitude - rotation;

	Normalize(wheelSpeeds);

	m_frontLeftMotor->Set(wheelSpeeds[kFrontLeftMotor] * m_invertedMotors[kFrontLeftMotor]);
	m_frontRightMotor->Set(wheelSpeeds[kFrontRightMotor] * m_invertedMotors[kFrontRightMotor]);
	m_rearLeftMotor->Set(wheelSpeeds[kRearLeftMotor] * m_invertedMotors[kRearLeftMotor]);
	m_rearRightMotor->Set(wheelSpeeds[kRearRightMotor] * m_invertedMotors[kRearRightMotor]);
}

This is straight from the RobotDrive source. What could possibly be improved?

Originally Posted by theprgramerdude

void RobotDrive::MecanumDrive_Polar(float magnitude, float direction, float rotation)
{
	// Normalized for full power along the Cartesian axes.
	magnitude = Limit(magnitude) * sqrt(2.0);
	// The rollers are at 45 degree angles.
	double dirInRad = (direction + 45.0) * 3.14159 / 180.0;
	double cosD = cos(dirInRad);
	double sinD = sin(dirInRad);

	double wheelSpeeds[kMaxNumberOfMotors];
	wheelSpeeds[kFrontLeftMotor] = sinD * magnitude + rotation;
	wheelSpeeds[kFrontRightMotor] = cosD * magnitude - rotation;
	wheelSpeeds[kRearLeftMotor] = cosD * magnitude + rotation;
	wheelSpeeds[kRearRightMotor] = sinD * magnitude - rotation;

	Normalize(wheelSpeeds);

	m_frontLeftMotor->Set(wheelSpeeds[kFrontLeftMotor] * m_invertedMotors[kFrontLeftMotor]);
	m_frontRightMotor->Set(wheelSpeeds[kFrontRightMotor] * m_invertedMotors[kFrontRightMotor]);
	m_rearLeftMotor->Set(wheelSpeeds[kRearLeftMotor] * m_invertedMotors[kRearLeftMotor]);
	m_rearRightMotor->Set(wheelSpeeds[kRearRightMotor] * m_invertedMotors[kRearRightMotor]);
}

This is straight from the RobotDrive source. What could possibly be improved?

They said something about advanced controls to make the omnidirectional drive more intuitive and easy to use.

[theprgramerdude]

Originally Posted by SuperNerd256

They said something about advanced controls to make the omnidirectional drive more intuitive and easy to use.

Controls aren't part of the drive code; they're the parameters that are passed into the drive code. What your programmers don't seem to understand is it's their code, not the WPILib code, that can be improved.

It's like saying even though the motor controller is already set to 100%, the code can be improved to set it to 110% via "better controls". That doesn't happen.

Originally Posted by theprgramerdude

Controls aren't part of the drive code; they're the parameters that are passed into the drive code. What your programmers don't seem to understand is it's their code, not the WPILib code, that can be improved.

It's like saying even though the motor controller is already set to 100%, the code can be improved to set it to 110% via "better controls". That doesn't happen.

We don't use mecanums. Never have. The point they made was in order to have the best quality controls for the drivers and have the driving experience be the most controllable and intuitive that our drivers can have, more complex programming would be required for mecanums compared to the traditional tank drive.

That's that, let's not derail this thread further.

[Joe Schornak]

My team has done quite a bit of experimentation with mecanum wheels this season, since we were initially doubtful of their effectiveness in certain critical areas, like traversing the barrier and climbing the bridge. Unfortunately, until we get some videos and pictures up (hopefully this weekend!) you'll have to trust me that our inadequately-described mechanisms actually work.

Surprisingly, the mecanum roller material grips better on plastic than on plywood. I suspect that fine sawdust is the culprit here, as our test of taping a sheet of plastic to one half of the bridge and then driving up resulted in the robot turning away from the side with the plastic, demonstrating higher traction on that side. We would be able to ascend while strafing, but our bridge has a significant lip that makes it very difficult to go from the ground to the bridge while sideways. No problems with turning sideways partway up and balancing that way, though!

We devised a system of raised powered traction wheels to pull the robot onto the barrier and provide a better point of contact to the mecanum wheels. Our prototype long chassis has no problems climbing over the barrier, even from a stop very close to the barrier without a high-speed run-up. The mecanum rollers function exactly as they should, in that the force vectors cancel due to the wheel orientation and no disadvantageous rolling occurs.

We use mecanum wheels because the extra range of motion is highly useful in offensive play. The ability to strafe has been particularly helpful when lining up on the bridge and will likely be very useful when the robot is sideways while trying to balance three robots. From a control perspective, we use flight simulator joysticks with a twist axis, a setup which has proved highly intuitive and easy to explain to 6th-graders during our school's open house.

In short, while mecanum wheels are certainly not perfect for everything, they have none of the negative traits frequently attributed to them, namely low traction, and we expect to use them to great advantage this season.

[372 lives on]

Originally Posted by SuperNerd256

We don't use mecanums. Never have. The point they made was in order to have the best quality controls for the drivers and have the driving experience be the most controllable and intuitive that our drivers can have, more complex programming would be required for mecanums compared to the traditional tank drive.

That's that, let's not derail this thread further.

just stop...

they aren't that hard to use and if you gave them a chance you would see that. now can you stop posting all of your opinions on something you clearly don't understand because it could mess up peoples decisions on what wheels to use.

[jvriezen]

Originally Posted by theprgramerdude

Controls aren't part of the drive code; they're the parameters that are passed into the drive code. What your programmers don't seem to understand is it's their code, not the WPILib code, that can be improved.

It's like saying even though the motor controller is already set to 100%, the code can be improved to set it to 110% via "better controls". That doesn't happen.

One relatively simple improvement you can make for mecanum drive is to add the option for 'field oriented' drive. Using a gyro, you can arrange the code to so that pushing the joystick forward *always* makes the bot move away from you, regardless of which way it is pointing. Moving stick right, the bot always moves directly to the right side wall of the field. This can make driving easier. Our bot last year allowed you to choose via a joystick button which type of drive mode you wanted.

[Djur]

Originally Posted by SuperNerd256

I'm not saying no mecanums (or however you spell it), but these are some points made in previous threads:

-Less traction on the key
-As already said, loss in pushing power
-Heavy
-Forces you to use maximum number of motors for drivetrain (not usually an issue)
-While they may not affect your ability to go on the bridge, the ability to stay without being pushed off or falling off of the bridge tips your direction will be tough to deal with
-You won't be driving circles around other's bots unless you have a lot of practice.
-In order to work to their fullest extent, require a lot of thorough engineering
-More complicated to code, even at the minimum level


Like I said, I'm not telling you not to use them, but when you do, be careful and engineer it through (Not meant to sound like most interesting man in the world meme, though I'm tempted. )

• We've been using Mecanums for the past three years and have found no huge loss of traction
• Usually, but this depends on the drivetrain.
• Definitely; Mecanums are a lot heavier than conventional wheels.
• I think most teams use 4 CIMs to drive anyway because it gives the robot a ton of power.
• Mecanums powered by Toughboxes don't get pushed around as much as people think, but it's defeinitely soemthing to consider.
• Agreed, a lot of practice is needed with Mecanums to be extremely good at them.
• Not a lot of engineering, it's really only the initial one-time assembly that matters in the long run.
• Actually, my team uses all of 20 characters for our Mecanum code, not counting the button to turn it on

Just my experiences with Mecanums.

Originally Posted by Djur

• We've been using Mecanums for the psat three years and have found no huge loss of traction
• Usually, but this depends on the drivetrain.
• Definitely; Mecanums are a lot heavier than conventional wheels.
• I think most teams use 4 CIMs to drive anyway because it gives the robot a ton of power.
• Mecanums powered by Toughboxes don't get pushed around as much as people think, but it's defeinitely soemthing to consider.
• Agreed, a lot of practice is needed with Mecanums to be extremely good at them.
• Not a lot of engineering, it's really only the initial one-time assembly that matters in the long run.
• Actually, my team uses all of 20 characters for our Mecanum code, not counting the button to turn it on

Just my experiences with Mecanums.

Thanks for posting this! I like the other opinions.

[Mara]

They're expensive and our team doesn't have any experience with them. We always end up sticking with good ol' tank drive.