Crab Drive

[=Martin=Taylor=]

Awesome job! Even if you never build this, you'll have learned a lot!

My Opinion on Crab:

Crab will only offer an advantage when you must maintain a specific angle of orientation with the game piece or goal. Crab will NOT offer any major advantage when the game pieces can be picked up from any angle, and/or the goal can be accessed from any angle. A good example of this is 2008. The balls were round... It didn't matter what angle you approached them from (same for the overpass). There was no need to go sideways, you could just turn and approach them from a different angle. As a result robots that used crab were almost exactly as successful as robots that didn't. Of course this is all just my own opinion, take it or leave it.

On another note...

I was recently researching a battlebot when I found something very cool which yall might be interested in seeing. If I didn't know better I'd say they built this for FIRST. (click 'robots,' and then 'Mechanical Maniac'). Its certainly a very innovative Crab design - uses no gears and looks like it might be easy to build.

Check it out! They are using some neat bearings you might want to incorporate into your swerve design.

[Nikhil Bajaj]

Originally Posted by AdamHeard

I'm not sure what you mean by tension by hand. Do you mean try to stretch the train onto the sprockets? that won't work.

We were able to tension by hand two years ago--we had #25 chain running on two sides of our robot in two different loops to turn the wheels, and we used turnbuckles as our "master-links" in order to tension it by hand. Easy as pie.

It seemed to work okay, although after a competition or two the turnbuckle would break because it was some cheap thing from a local hardware store. If you got a bigger/nicer turnbuckle, that could work. But you should be sure that you have enough chain that the turnbuckles don't go anywhere near the sprockets!

Just an option.

Nikhil

[RMS11]

Originally Posted by Hachiban VIII

Awesome job! Even if you never build this, you'll have learned a lot!

My Opinion on Crab:

Crab will only offer an advantage when you must maintain a specific angle of orientation with the game piece or goal. Crab will NOT offer any major advantage when the game pieces can be picked up from any angle, and/or the goal can be accessed from any angle. A good example of this is 2008. The balls were round... It didn't matter what angle you approached them from (same for the overpass). There was no need to go sideways, you could just turn and approach them from a different angle. As a result robots that used crab were almost exactly as successful as robots that didn't. Of course this is all just my own opinion, take it or leave it.

On another note...

I was recently researching a battlebot when I found something very cool which yall might be interested in seeing. If I didn't know better I'd say they built this for FIRST. (click 'robots,' and then 'Mechanical Maniac'). Its certainly a very innovative Crab design - uses no gears and looks like it might be easy to build.

Check it out! They are using some neat bearings you might want to incorporate into your swerve design.

Maybe next design, but that is an awsome drive system. I think you have to use gears just to gear down the CIM enough. We were shooting for 12 fps, a big reduction for just 1 sprocket.

[Alex Cormier]

Originally Posted by Hachiban VIII

On another note...

I was recently researching a battlebot when I found something very cool which yall might be interested in seeing. If I didn't know better I'd say they built this for FIRST. (click 'robots,' and then 'Mechanical Maniac'). Its certainly a very innovative Crab design - uses no gears and looks like it might be easy to build.

Check it out! They are using some neat bearings you might want to incorporate into your swerve design.

Yeah, that guy makes amazing battlebots. Greg actually got his big one destroyed by one of his robots.

[JVN]

Originally Posted by RMS11

We would like some feedback on our design.

The main feedback I wanted to give you is NOT to do a crab drive until you've successfully prototyped one during the off-season. There is a lot of development involved and you don't want to be learning how to make a crab drive behave when you're in the middle of robot design for a new game. This is a lot for a team to handle, especially a team as young as yours.

Don't bite off more than you can chew, especially for minimal gain. The best way to be successful is to simplify!

Good Luck,
John

PS - I lied a little bit; my real advice is to never to a swerve drive at all, they don't provide any huge benefit to your robot design beyond a basic skid steer.

[Andrew Y.]

just to give you guys a idea of how far these kids have come. at the close of 2008 Championships.....these kids knew NOTHING about inventor besides...draw it and that i would put it into inventor for em.

Now they have ON THEIR OWN designed a crab drive.

I originally started this project so the kids could get some GREAT engineering experience. They have self taught Inventor and i am now greatly encouraged for the 2009 season. This comforts me as the mentors have decided to take a step back, and push the kids forward for the 2009 season

thanks for the comments!! keep em rollin!

[Nikhil Bajaj]

Originally Posted by RMS11

We would like some feedback on our design.

Speaking of feedback on your design, it doesn't look like you have any! (At least not in the model!) I just wanted to remind you guys that although crab drives are usually tougher to design mechanically, they are also more complicated to control. If you want to control your wheel speeds or count distance during autonomous mode, think about where encoders or other such sensors need to go.

As an example, you will want some sort of potentiometer/encoder that keeps track of current wheel angle. How many chain loops will you have turning the pods, so how many potentiometers or encoders will you need in order to make sure all the wheels are pointed the same direction? Will you use a gear ratio to increase or decrease sensor resolution?

So, as you're doing the mechanical design, think about how you will code/control the crab drive, and what information you will need in order to do that and then put those sensors in the mechanical CAD design to make sure they can get mounted and the wires routed and all that sort of good stuff. Adding sensors to a design that wasn't designed with them in mind can be a terrible headache. You may even want to be picking sensors as part of your design exercise just like picking gears or sprockets.

[RMS11]

What would be a good speed for the modules to turn at. We were thinking about 60 RPM's

[Nikhil Bajaj]

Originally Posted by RMS11

What would be a good speed for the modules to turn at. We were thinking about 60 RPM's

I would suggest doing an expected torque calculation (just ask if you need help) for turning the wheel, and then seeing what kind of speeds that you can get using candidate motors using that. I know it is kind of backwards, but it may be an easier and better approach, because you may say "I want 150 RPM" and the only way you can get that is to use FP motors--which you might not want to dedicate to the drive train. So get an idea of what motors you'd want to dedicate, then run the numbers with them to see how fast you can turn the wheels at appropriate current levels, and then choose the speed. Obviously you will want it at a certain speed or above. From my experience, Globe motors and Window motors are fairly appropriate for this task, but you should calculate it with other motors just to be sure you don't want to use them. I would personally be wary of investing my FP's or Banebots RS-550 into the drivetrain--the rest of the robot usually needs some oomph, too.

[EricH]

Originally Posted by RMS11

What would be a good speed for the modules to turn at. We were thinking about 60 RPM's

I'm not sure I understand this. Do you mean:
a) What speed should the wheels turn to move the robot at;
b) What speed should the modules for the wheels rotate at (to translate);
or c) what should the output speed for the motors be?

If it's b), which is the impression I get, that's way too fast. 60 RPM = 1 rev/sec. That's going to be uncontrollable, or close to it. You tell it to turn, and by the time you tell it to stop turning, you've done a 180-degree turn.

If it's a) or c), you're too slow by a long shot. With a), 60 RPM would get you (assuming 6" wheels):
6" * Pi = circumference "
Circumference " * 60 RPM = x" / minute
x" / minute / 60 sec/min = y"/second
y"/second / 12 = z fps

If I did my math right, that's about 1.5 fps. That's not fast enough.

Now, if it's motor output, then you need a faster motor, or one that can take being geared up. Otherwise, you'll be even slower than the above calculations indicate.

[RMS11]

Yes, I was talking about B. I was thinking that we would have preset controls to go to 0, 90, 180, and 270 degrees. We would turn at these speeds for the preset commands. We would do some testing and would have it programmed to turn at slower speeds when we turn the modules manually. Would this work?
I will try to calculate the torque needed, if i can find the coefficient of friction for the wheels we are going to use.
As for the pots, we have discussed sensors but have not planned mounts yet. I was thinking for mounting purposes that we should attach it to the shaft of the globe motor. I am kinda woried though about the wheels shifting into slightly different angles. Should this be a concern. As for other sensors, for the test system we are going to throw on as many sensors as we see a possible use for, for programming practice and to see what works well and doesnt.

[EricH]

Originally Posted by RMS11

Yes, I was talking about B. I was thinking that we would have preset controls to go to 0, 90, 180, and 270 degrees. We would turn at these speeds for the preset commands. We would do some testing and would have it programmed to turn at slower speeds when we turn the modules manually. Would this work?
I will try to calculate the torque needed, if i can find the coefficient of friction for the wheels we are going to use.
As for the pots, we have discussed sensors but have not planned mounts yet. I was thinking for mounting purposes that we should attach it to the shaft of the globe motor. I am kinda woried though about the wheels shifting into slightly different angles. Should this be a concern. As for other sensors, for the test system we are going to throw on as many sensors as we see a possible use for, for programming practice and to see what works well and doesnt.

I would say that it would work, or a function that "steps" the modules x degrees left when a given command is sent and x degrees right on a different command could also help. Definitely slow it if you're rotating them manually.

For a pot or encoder, you would want it as close to the rotating part as you can get it reasonably for best accuracy. One per wheel would be good, though you could probably get away with one for the system.

[Aren_Hill]

Originally Posted by EricH

If it's b), which is the impression I get, that's way too fast. 60 RPM = 1 rev/sec. That's going to be uncontrollable, or close to it. You tell it to turn, and by the time you tell it to stop turning, you've done a 180-degree turn.

umm about that... Last year our module turning rate was set at 60rpm, worked out great, quite responsive, this year it was 56rpm.
So its not "way too fast" it actually works quite nicely

plus ma3 absolute analog encoders from USdigital work very well for the steering control.

[EricH]

Originally Posted by Aren_Hill

umm about that... Last year our module turning rate was set at 60rpm, worked out great, quite responsive, this year it was 56rpm.
So its not "way too fast" it actually works quite nicely

So you're telling me that you can control it when it'll make one complete turn in one second. OK. Automatic or manual? Was it always at 60 RPM or was it often slower? More info would probably be a good thing in this thread.

[Aren_Hill]

Originally Posted by EricH

So you're telling me that you can control it when it'll make one complete turn in one second. OK. Automatic or manual? Was it always at 60 RPM or was it often slower? More info would probably be a good thing in this thread.

all 4 modules were turned by 1fp on both of our swerves. This year was geared at 60rpm free speed. We have a control loop running in which i point the joystick whichever direction i want the wheels to point in relation to the robot. so forward=forward and 360deg all around. It involved some nifty programming.

if you steer 148's style then i wouldn't go at 60rpm