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,
Full 3dof Crab
“Long” with tank steering
“Wide” with tank steering
“Ackerman” steering(is it possible to “code” a differential?)
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:rolleyes: )
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:rolleyes: )
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:p )
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.
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.
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;) …
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…
Cheap is always good. :D, 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.
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.
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
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)
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.
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…
One problem with that is that if you ever need to remove a module you would need to remove the sensor as well. If you make your sensor part of the base, you never have to worry about it. I had to ruin the resolution of the picture to get it small enough to attach, but it should be good enough to show the concept. This is our base and single chain crab from this year. You can see the blue pot on the left side of the picture. We didn’t use a second pot, but you can see where it would go on the right side. The pots were mounted to a small sheet metal piece that fit snugly in the recepticle (you can see it on the left). This allows us to quickly drop a new pot in if necessary. The shaft is keyed to prevent the pot from slipping, and the shaft runs down to a sprocket that the chain wraps around. The pot shafts were fitted with a collar that matched the key and fixed in place with a set screw. When we do 2 chain crab, the setup is identical.
The best thing to do in my opinion is to attach the sensor to an idler sprocket that is along the chain line that is actuating it. I’m assuming you are using chain or belt. If you are using cable, it might be a little different…I’ve never dealt with cable, but I’ve heard through the grape vine that it works pretty well…
Like Aren said, the numbers are easier if you use the same sized sprocket, but you don’t have to. The math isn’t too complicated if the size is different though
Is this going to be co-axial, or is the motor going to be on the module?
we are going to use the Gates-KIT-belting and pullies for steering,
its NonCo-axial,with a CIM in each module,and 2 globes for turning each set of wheels…
we thought about co-axial but we dont really have the machining tools to do it(or the experience) and we assumed it would be alot heavier(i dont know about this)
Dave-thanks for explaining that,I’d never really thought about that…hopefully we wont ever have to remove a module after we put it in(we tend to sacrifice weight for strength on our robots,06’ escpecially)
The belt will work just fine for steering, my team used it this year and it worked fine. Just becareful though, if it slips, it can totally mess up you feedback sensors. My team found that you need a little more wrap around you sprockets with chain than you do with belt. My team also needed a spring tensioner to keep proper tension, but it these aren’t really big problems.
Non-Coaxial isn’t really much heavier than co-axial, the only thing is co-axial is typically much less efficient. So I’d say noncoax is a good call.
Sorry for going off topic, but I have seen this statement on Chief Delphi a number of times from a number of different posters.
Maybe I’m missing something coming from my EE/CS background, but I don’t really see why a coax crab would be appreciably more inefficient than a non-coax. Well meshed bevel gears have very similar published efficiency numbers to spur gears (~95-98%). And shafts rotating within each other shouldn’t be an issue if ball bearings are used. Does anyone have any actual experience to the contrary?
Sure, there are potential issues with steering (as the wheel would rotate slightly even if the drive motor was held still during turning) and without being able to independently power the wheels some steering modes aren’t as efficient (i.e. ackerman or warthog), but in terms of raw power transfer I have not been convinced of this perceived “inefficiency”.
