Crab-drive steering modes?

[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....

[Dave Scheck]

Originally Posted by gorrilla

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.

[sgreco]

Originally Posted by gorrilla

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....

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?

[gorrilla]

Originally Posted by Sgreco27

The best thing to do in my opinion is to attach the sensor 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)

[sgreco]

Originally Posted by gorrilla

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)

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.

[Jared Russell]

Originally Posted by Sgreco27

... 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".

I'm looking forward to being enlightened.

[Dave Scheck]

Originally Posted by gorrilla

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)

Based on experience, expect to replace modules at some point during the season. When we ship the robot, we remove the modules to protect them as well as to help prevent the robot from rolling around in the crate. We also replace them to perform routine maintenance. Most of all, you need to plan for the worst case. If you have module fail, you want to be able to replace it quickly. For us, it's 4 bolts to the mounting plate (you can see it in the bottom left of the picture) and 1 or 2 electrical connections. We've had to use that "feature" a few times in the heat of competition. One year we had our signage fall off and get sucked into the module gearing during a match. Without the quick replacement it would have made it tough to get to the next match reliably.

A big lesson that every engineer should take seriously is that it is critical to design for failure. What happens when it breaks? How will you be able to recover? This applies to all aspects of engineering. On the mechanical side, cars are designed to crash safely. On the software side, divide by zero exceptions are handled to prevent crashes.