Weight on Mecanum or Slide

[Dukenator76]

Hello my team is trying to decide between slide drive and mecanum we have no experience in either of the drives and the way our robot is going to work is our stacked totes are going to go in the front of our robot. I am wondering if anyone has experience in uneven weight towards the front of their bot with mecanum or slide drive and how much we will need to compensate in code or mecanical?

Also we would like to know what your team is thinking about doing between Mecanum and Slide.

[IronicDeadBird]

The biggest time weight distribution matters is when your drivers can't compensate for the effects

[Monochron]

Originally Posted by IronicDeadBird

The biggest time weight distribution matters is when your drivers can't compensate for the effects

My gut reaction is that this is a bad assessment of the effects. I would love for you to correct me though Do you have any links to data or videos to back that up? Basically, I have a feeling that a change in drive characteristics mid-match would be something that is very hard to deal with regardless of driver skill.

[EricH]

Originally Posted by Monochron

My gut reaction is that this is a bad assessment of the effects. I would love for you to correct me though Do you have any links to data or videos to back that up? Basically, I have a feeling that a change in drive characteristics mid-match would be something that is very hard to deal with regardless of driver skill.

I don't have data, but I do offer this: an 8-lb tetra, hung a short distance off of a mecanum's frame, produced a very significant arcing motion in strafe mode. It would have been very difficult to deal with via driver control.

[vScourge]

Originally Posted by EricH

I don't have data, but I do offer this: an 8-lb tetra, hung a short distance off of a mecanum's frame, produced a very significant arcing motion in strafe mode. It would have been very difficult to deal with via driver control.

Your drive code can automatically compensate for this with a gyro sensor. Pobots Team 353 was kind enough to create a walkthrough for implementing this in LabView: PDF, discussion.

Our team just added this last night and it works well. There's similar C++ and Java examples here: Gyros to control robot driving direction

[IronicDeadBird]

Originally Posted by Monochron

My gut reaction is that this is a bad assessment of the effects. I would love for you to correct me though Do you have any links to data or videos to back that up? Basically, I have a feeling that a change in drive characteristics mid-match would be something that is very hard to deal with regardless of driver skill.

The max stack you could get in my mind during Auton is 3 yellows I know some team will do it. We put 4 totes on a plywood board that was attached to a mecanum robot and we had a gentle curve that could be compensated for with driver practice (more so with programming I would imagine since code seems to be more consistent then caffeinated student input)
My thought though is that the most weight you will get on a robot is during Tele-Op where the driver is in full control and should be able to compensate for the weight distribution. Of course this depends on if you use an on robot stacking procedure or point to point stacking procedure
Either way I would say its a valid point to say that you are most likely going to deal with more weight in tele-op then in auton.

[mshafer1]

Originally Posted by Monochron

My gut reaction is that this is a bad assessment of the effects. I would love for you to correct me though Do you have any links to data or videos to back that up? Basically, I have a feeling that a change in drive characteristics mid-match would be something that is very hard to deal with regardless of driver skill.

As for data, only that year of mecanum on 3288, it was logomotion and had implemented it with a large arm with a claw on the end (again, probably not a good design on our part) the robot drove drastically differently depending on the orientation of the arm, and if my physics studys tell me anything here, it is that the changimg effect will be greater the more weight is moved around.
This is why I stated that is theoretically possible although likely difficult (physical objects tend to have more factors than we like to account for in math)
And yes, a robot that behaves differently whether due to a change in weight or a mistake in programming is difficult to control.
Regarding the afore mentioned white paper, every mecanum robot I have ever seen drifted/coasted a little further than similar tank drive bots - likely due to inconsistencies in wheel construction.
Again, these can be compensated for by a practiced driver, but the drive base needs to get built soon to allow for that.

[Jacksonnash6]

Team 2883 is going with the omni wheels because the mecanum wheels respond much differently with weight added to the robot. They drive great, but if you add 50 pounds of crates on the front of the robot the wheels do not work as well together.

[mathking]

We have experience with both mecanum and omni wheels. We have not made an omni wheeled omni-drive competition robot but have built prototypes. So a few observations you can take for what their worth:
(1) Both types are harder to control with uneven loads. But remember, so is tank drive with traction wheels. It's a matter of degree.
(2) Mecanum tends to be harder to strafe in a straight line.
(3) Omni wheeled designs tend to be more difficult to control when you are turning the robot under load.
(4) Both 2 & 3 can be compensated for, at least to a degree, in code by using a gyroscope. (I have found it is easier to compensate for the strafing.)
(5) A good driver who gets to practice a lot will tend to be able to much better control their robot with any drive train.
(6) Because of 5, driver practice, in my experience, trumps drive train type in teleop.
(7) This year various slide drives (those with one or more centrally mounted wheels perpendicular to four omni wheels) are going to have control difficulty with the scoring platform unless you are very mechanically adept. This is not insurmountable but it is a consideration.
(8) You want to get your drive train done as quickly as you can, but not so quickly that it is not robust.
(9) When you have a working drive train, particularly if you are using code to help it drive straight, there will be tension between programmers wanting to program (and test) it and drivers wanting to practice. Make sure you come up with a schedule to assure adequate access.

[Ether]

There is some useful info about slide drive in this thread:

http://www.chiefdelphi.com/forums/sh...d.php?t=132630

[mshafer1]

The experience that I had with mecanum (while on 3288) was not positive. Keep in mind that mecanum relies on counter angled rolers to produce a net vector to the side. This means that when you wish to stop (especially moving forward or backwards) that there is a free roller on the ground for each wheel yielding the freedom for the body in motion (the robot) to continue in its path until friction wins out. Granted, the counter angle of the rollers helps lower this a little bit, but the more weight your robot is carrying, the more kinetic energy there is, and the farther the robot will drift. It may be possible to use the accelerometer and to counter this effect from software, although likely difficult.
Slide or H-drive is basically tank drive with extra functionality, and the cross wheel will need to be designed for the extra weight, but the drift effects from extra weight will be significantly less noticeable due to the energy working on the entire drive chain and the motor.
An alternative solution to either of these is to have the robot built early enough that your driver has practice and knows how it will behave.

[Lone Wolf]

Originally Posted by mshafer1

The experience that I had with mecanum (while on 3288) was not positive. Keep in mind that mecanum relies on counter angled rolers to produce a net vector to the side. This means that when you wish to stop (especially moving forward or backwards) that there is a free roller on the ground for each wheel yielding the freedom for the body in motion (the robot) to continue in its path until friction wins out. Granted, the counter angle of the rollers helps lower this a little bit, but the more weight your robot is carrying, the more kinetic energy there is, and the farther the robot will drift. It may be possible to use the accelerometer and to counter this effect from software, although likely difficult.
Slide or H-drive is basically tank drive with extra functionality, and the cross wheel will need to be designed for the extra weight, but the drift effects from extra weight will be significantly less noticeable due to the energy working on the entire drive chain and the motor.
An alternative solution to either of these is to have the robot built early enough that your driver has practice and knows how it will behave.

Actually there was a whitepaper somewhere (sorry I don't have time to dig for the link) where they showed that when the wheel goes forwards/backwards, the rollers do not spin. Thus there will be no drift.

[Gregor]

At this point in build season I strongly suggest you choose a drive system within the next day or two. The most important part is your implementation of the drivetrain. If you put off this decision any longer both choices will be the wrong one.

[lcoreyl]

Originally Posted by Dukenator76

Hello my team is trying to decide between slide drive and mecanum we have no experience in either of the drives and the way our robot is going to work is our stacked totes are going to go in the front of our robot. I am wondering if anyone has experience in uneven weight towards the front of their bot with mecanum or slide drive and how much we will need to compensate in code or mecanical?

Also we would like to know what your team is thinking about doing between Mecanum and Slide.

If you've had a intro physics class, then you have dealt with this type of problem before: net torque. It's not too hard of a problem particularly if you are doing things qualitatively. As mathking pointed out all drives have to deal with this, so it would be good for a better understanding of how these drivetrains compare/contrast to go through this problem.