Crab-drive steering modes?

[gorrilla]

There seems to be alot of talk going around about crab-drives...

So my team is currently working on our(first)crab drive,

We have the module itself designed and everything....

So,now we are talking about how we want to control it,
We are planning on having the 2 Left-side wheels turned by the same motor(probobly a globe) and the 2 Right-side wheels turned together,

Which would give us(we hope) 5 different steering modes out of the same setup,

1. Full 3dof Crab

2. "Long" with tank steering

3. "Wide" with tank steering

4. "Ackerman" steering(is it possible to "code" a differential?)

5. And what we have dubbed "slalom"(aka "warthog")
(In which the the back wheels would turn opposite the front)hopefully allowing the robot to swerve around in big "S bends"(I dont know if this might be as practical as we think )

I've been told controlling a crab drive is the hardest part(hopefully Im not about to find out the hard way ) but this is becoming more evident to me as we continue to simplify the modules themselves...

so basically, I was just wondering if you guys had any input on this?
(I searched around but I couldent seem to find a thread that fit)

like maybe there is an easier way to do this than we are thinking about...

Sorry, I dont have any pictures of our modules(yet )
Partly because we havent actually built them yet,but one of our mentors is trying to teach me to think things through all the way before we "just do" them(then maybe I'd loose this nickname they've given me )

any Input is helpful(wanted!!)

[daltore]

In answer to your question on point 4, yes you can code a differential. It involves turning radii and scaling, but it shouldn't be TOO difficult. Basically, the equation is angular velocity times the distance of the wheel from the turning centerpoint (the dot on the ground that the robot is rotating around).

Also, your Slalom or Warthog style driving is classically known as 4-wheel Ackermann or all-wheel steering (specifically in cars, note ice racing).

And yes, control is generally the hardest part. Of regular crab drive, where all the wheels point the same direction, control is relatively simple. Just have some sort of closed-loop feedback for angle (pot or encoder), arctangent for angle calculation of the joystick, and Pythagorean theorem for wheel speed. Alternatively, you could have a Y-axis for speed and X-axis for angle, avoiding trig altogether.

The most complex is all-wheel independent swerve drive. That's where each of the 4 wheels has its own turning motor, and you adjust every wheel angle and speed individually to exactly match the overall vector of the robot. This is what we're trying to do for our summer project, and I've got the glorious task of figuring out the math for that, woo hoo!

Your drive train is a hybrid between the two, which cuts the complications of swerve drive in half. To figure out how to get all of the vectors to line up, first figure out the crab steering, the straight-line direction calculation with all the wheels pointing in the same direction. Then add in the rotational vector. Basically, going in a circle counter-clockwise, all the wheels would be pointed sideways with the front two going to the left and the rear two going to the right. Going forward and rotating counter-clockwise, the front two wheels would be pointing at a 45* angle to the left and forward, and the rear two would be pointing 45* to the right and forward. Take specific cases like that and figure out the equation that matches them all up.

[sgreco]

Originally Posted by gorrilla

So,now we are talking about how we want to control it,
We are planning on having the 2 Left-side wheels turned by the same motor(probobly a globe) and the 2 Right-side wheels turned together,

Which would give us(we hope) 5 different steering modes out of the same setup,

1. Full 3dof Crab

2. "Long" with tank steering

3. "Wide" with tank steering

4. "Ackerman" steering(is it possible to "code" a differential?)

5. And what we have dubbed "slalom"(aka "warthog")
(In which the the back wheels would turn opposite the front)hopefully allowing the robot to swerve around in big "S bends"(I dont know if this might be as practical as we think )

any Input is helpful(wanted!!)

If you are going to steer left and right as opposed to front and back, it's going to be a lot harder to program in a differential. Your robot will likely have to be facing sideways in this instance because your number 5 mode won't work if unless you are constantly driving sideways. Your left wheels will always be in the same diection in comparison to the other and your right side will work the same way. So number 5 can't work, because of the way you have steering set to two wheels on the same side. The wheels sharing the same side, left or right, physically cannot face in opposite directions. Your number 4 won't work either if you steer left and right, because when you turn the two front wheels to face in the same direction, your back wheels will have to move too because they are conected to the front ones. I would steer front and back, because that way, you turn the two front wheels (without steering the back) when you want steering like a car. When you want four wheel steer where the front and back wheels go in opposite directions you can do that as well. If you steer front and back it shouldn't have any difference of effect on steering modes 1,2,3. Steering the front modules together and the back modules together makes a lot more sense than left and right, given the steering modes that you want.

+$.02

[gorrilla]

Originally Posted by daltore

In answer to your question on point 4, yes you can code a differential. It involves turning radii and scaling, but it shouldn't be TOO difficult. Basically, the equation is angular velocity times the distance of the wheel from the turning centerpoint (the dot on the ground that the robot is rotating around).

And yes, control is generally the hardest part. Of regular crab drive, where all the wheels point the same direction, control is relatively simple. Just have some sort of closed-loop feedback for angle (pot or encoder), arctangent for angle calculation of the joystick, and Pythagorean theorem for wheel speed. Alternatively, you could have a Y-axis for speed and X-axis for angle, avoiding trig altogether.

Your drive train is a hybrid between the two, which cuts the complications of swerve drive in half. To figure out how to get all of the vectors to line up, first figure out the crab steering, the straight-line direction calculation with all the wheels pointing in the same direction. Then add in the rotational vector. Basically, going in a circle counter-clockwise, all the wheels would be pointed sideways with the front two going to the left and the rear two going to the right. Going forward and rotating counter-clockwise, the front two wheels would be pointing at a 45* angle to the left and forward, and the rear two would be pointing 45* to the right and forward. Take specific cases like that and figure out the equation that matches them all up.

you mean like,
having and encoder to measure the rotation of each module right? We were going to limit the rotation to 180,thats easy enough, do you know any good places to get good(preferably cheap) pot's and encoders
thanks for the info ..

Originally Posted by Sgreco27

If you are going to steer left and right as opposed to front and back, it's going to be a lot harder to program in a differential. Your robot will likely have to be facing sideways in this instance because your number 5 mode won't work if unless you are constantly driving sideways. Your left wheels will always be in the same diection in comparison to the other and your right side will work the same way. So number 5 can't work, because of the way you have steering set to two wheels on the same side. The wheels sharing the same side, left or right, physically cannot face in opposite directions. Your number 4 won't work either if you steer left and right, because when you turn the two front wheels to face in the same direction, your back wheels will have to move too because they are conected to the front ones. I would steer front and back, because that way, you turn the two front wheels (without steering the back) when you want steering like a car. When you want four wheel steer where the front and back wheels go in opposite directions you can do that as well. If you steer front and back it shouldn't have any difference of effect on steering modes 1,2,3. Steering the front modules together and the back modules together makes a lot more sense than left and right, given the steering modes that you want.

+$.02

IF we steer the right and left sides,
#5 and #4 both work?, but the robot would be in the "wide" orientation....

switching to steering the front-back set,as apposed to the left-right sides would be just as easy..
which is probobly what we would end up donig anyways to save space..

[sgreco]

Originally Posted by gorrilla

you mean like,
having and encoder to measure the rotation of each module right? We were going to limit the rotation to 180,thats easy enough, do you know any good places to get good(preferably cheap) pot's and encoders
thanks for the info .

Cheap is always good. , but do be careful, my team had a good deal of trouble finding the proper feedback sensors. Definitely use absolute sensors, they're much easier to work with, and you don't have to manually straighten.

[gorrilla]

Originally Posted by Sgreco27

Cheap is always good. , but do be careful, my team had a good deal of trouble finding the proper feedback sensors. Definitely use absolute sensors, they're much easier to work with, and you don't have to manually straighten.

why do we actually need these?

Couldent we just use limit switches on each module? since the 2 wheels on each side are linked together,

Like in full-crab mode, have one joystick for "gas" and one that turns both sets of wheels the direction you point it? and the same for "ackerman"and "Slolam" modes?

And maybe have something coded so they return to the middle if you let off the sticks?
or is there something im missing?

also what motor could we use to turn the modules? ive seen alot of teams use globes,but they're not the fastest thing...only 100rpm

[sgreco]

Originally Posted by gorrilla

why do we actually need these?

Couldent we just use limit switches on each module? since the 2 wheels on each side are linked together,

Like in full-crab mode, have one joystick for "gas" and one that turns both sets of wheels the direction you point it? and the same for "ackerman"and "Slolam" modes?

And maybe have something coded so they return to the middle if you let off the sticks?
or is there something im missing?

also what motor could we use to turn the modules? ive seen alot of teams use globes,but they're not the fastest thing...only 100rpm

You could get away with limit switches, but the modules won't center unless you have feedback sensors. If you want a limit on both sides and one to find center, that's 3 sensors and at that point, it's probably easier to just use a rotational sensor. My team finds that it is a little bit easier to use rotational sensors because that way one sensor takes care of every angle. It also makes driving with precision to certain angles easier. If you use switches, the robot won't know where the wheels are pointing when they aren't touching a limit switch, and if you have wheels pointing in slightly opposite directions, it can be a problem when trying to go straight. It may not seem that bad, but it can turn into a problem.

As for motors, my team has used the window motors the past two years, but they're kind of weak. I would use globe motors, they should work just fine. If you are really careful about friction between the module and the ground and the bearings that support it, you should be able to gear globes to be fast enough. You could also use FPs. They require a lot of reduction, but are more powerful than globes. The only reason I wouldn't use FPs is because they are typically good to have for game piece manipulation.

[gorrilla]

Originally Posted by Sgreco27

You could get away with limit switches, but the modules won't center unless you have feedback sensors. If you want a limit on both sides and one to find center, that's 3 sensors and at that point, it's probably easier to just use a rotational sensor. My team finds that it is a little bit easier to use rotational sensors because that way one sensor takes care of every angle. It also makes driving with precision to certain angles easier. If you use switches, the robot won't know where the wheels are pointing when they aren't touching a limit switch, and if you have wheels pointing in slightly opposite directions, it can be a problem when trying to go straight. It may not seem that bad, but it can turn into a problem.

As for motors, my team has used the window motors the past two years, but they're kind of weak. I would use globe motors, they should work just fine. If you are really careful about friction between the module and the ground and the bearings that support it, you should be able to gear globes to be fast enough. You could also use FPs. They require a lot of reduction, but are more powerful than globes. The only reason I wouldn't use FPs is because they are typically good to have for game piece manipulation.

could you recommed any places to get good pots' or encoders?

[Aren_Hill]

ma3 absolute analog encoders, from usdigital
http://usdigital.com/products/ma3/

we've used them on all of our swerves, and started using them instead of pots for other functions like arm position and such, they've been very reliable for us.

111 has used them and has noticed some static issues as a warning though.

this year we had 4 on our bot, 1 on each side of the drive, and 1 on each sides bogey wheel. no issues with them

[gorrilla]

Originally Posted by Aren_Hill

ma3 absolute analog encoders, from usdigital
http://usdigital.com/products/ma3/

we've used them on all of our swerves, and started using them instead of pots for other functions like arm position and such, they've been very reliable for us.

111 has used them and has noticed some static issues as a warning though.

this year we had 4 on our bot, 1 on each side of the drive, and 1 on each sides bogey wheel. no issues with them

where did you mount them at? and how?

Im not 100% sure I understand how those work......

How do they actually measure the rotation?
I was thinking they are in contact with the rotating object? And then it just counts the rotation of its shaft? That would be a mechanical encoder then right?...those are magnectic encoders..how do they work?

sorry about all the questions,I dont do electronics(although now's a good time to learn i guess)

[Aren_Hill]

Originally Posted by gorrilla

where did you mount them at? and how?

Im not 100% sure I understand how those work......

How do they actually measure the rotation?
I was thinking they are in contact with the rotating object? And then it just counts the rotation of its shaft? That would be a mechanical encoder then right?...those are magnectic encoders..how do they work?

sorry about all the questions,I dont do electronics(although now's a good time to learn i guess)

you have to connect the shaft of the encoder to some part in your steering driveline



we mounted it with the same size sprocket as the one on the module to make the math easy.

questions are never an issue, unless your asking who dean kamen is

[gorrilla]

how is the encoder mounted to the sprocket?

[AustinSchuh]

Originally Posted by gorrilla

how is the encoder mounted to the sprocket?

I don't know how 1625 does it, but 971 has always turned down the end of the axle with the sprocket on it to about 1/8th inch diameter, and fitted a piece of rubber tube over the new reduced diameter end of the shaft and the encoder shaft. You don't have to worry about it being slightly misaligned that way. That's how we connected the encoders on this year's bot to the CIMs and the ground speed follower wheels.

If, and hopefully when since we are trying to build a swerve too this summer, we try to control a swerve, I was thinking that the best way would be to slap encoders on everything and program it to drive with a joystick to specify the direction vector relative to either the front of the robot or down field, and a steering wheel to specify the turn rate. We would then need to work out the math to angle the modules accordingly and set their speeds so the robot follows these instructions. Of course, this will be a great excuse to learn as much as possible from our Controls mentor and potentially have completely closed loop control.

[Aren_Hill]

Originally Posted by gorrilla

how is the encoder mounted to the sprocket?

its just got a little aluminum hub with a setscrew holding the hub to the encoder shaft, nothing special

then encoder is then mounted on an arm that is spring loaded into the steering chain

[gorrilla]

Originally Posted by Aren_Hill

its just got a little aluminum hub with a setscrew holding the hub to the encoder shaft, nothing special

then encoder is then mounted on an arm that is spring loaded into the steering chain

Oh,thats cool

but couldent you just attach it to the module itself?

like our module is supported by a lazy-susan on the bottom, couldent we just turn the encoder sideways and rest it on the lazy-susan? kind-of like a friction wheel....