Help with Gearboxes
 

I am in charge of my team's engineeing section and I am contemplating of machining 2 gearboxes (1 per side) to connect 2 motors to one output essentially driving each side with 2 motors. Keep in mind that this will be designed entirely by students but will be machined by professionals. Can you guys give me some tips and suggestions as to the feasibility of this (I know its possible, but is it over the head of a student) and ways I can go about doing this. Thank you very much.

On my team, two groups of people came up with hypothetical gearbox designs. I head one of the groups, and I feel it has a better design than the other (shift gears on the fly). This is my third year doing robotics, so I did a full hypothetical model in Inventor (sans a motor mount, and other smaller details). We'll have to see the game and kit to procede further. To use four motors, I planned to make a separate box for each wheel, two motors per side. (inspired by team 60 :) ) Bit it depends on the game...

I'm no expert, but instead of putting the output of two motors on one shaft, it might be eaiser to make 4 gearboxes and have two motors per side. That's what I hope to do. But if you want just two boxes, I think it's better to use chain instead of gears, cause they're a bit more... forgiving than gears.

Also, there's tons of boxes in the whitepapers. Take a look:

http://www.chiefdelphi.com/forums/pa... SC&sort=date

Wouldn't weight be a problem with 4 boxes? We aren't really looking to closely at shifting due to the complexity. Also, if you have a different box for each wheel wouldn't you get 4 slightly different speeds from your wheels. Even with mathematically correct gear ratios, you will obviously get slightly different speeds from different motors.

when thinking about shifting on the fly, keep in mind, that for all practical purposes, this is only accomplised by using a Pneumatic. This is the bad part. I too like team 60's four gearboxes, but that is the problem. They have four gearboxes. If you have four gearboxes, shifting each one, you have just used four pneumatics, which leaves you with only one for use anywhere else on the robot. For many teams this year, only having one pneumatic usable, they would not have been able to release the goals, like 60.

Anyways, I think it is a great idea if you dont have any other use for those pneumatics.

Cory

Weight? Well, you can use some pretty thin metal (.25 in Al 2024-T4 for me) and with lean construction the weight should be reasonable. But yeah, one box per side probably would be lighter.

60 doesn't really shift on the fly, but I've seen their boxes up close at a workshop. Wonderfully simple+reliable mechinism, you've got to hand it to them... Actually, someone proposed running levers to the boxes so all could run off one cylinder. I think this would be way too complex, but if you need the pneumatics for something else, I have some ideas with springs, motors ,and cables... :)

two motors into one gearbox
 

It you want to put two motor into one gearbox what you need to do is gear them so at the point where they combine they will freespin at the same RPM. That way the motor curves will match up for each motor, if you do not do that one motor will always be running with poor efficiency. That can cause both the tripping of breakers and drain your battery quickly.

...have you checked out DLAVERYs "Dual-Motor, Dual-Speed Drive Transmission Design" in the technical white papers? It may be useful.

D.
I have seen some two motor designs. It is pretty simple to have both motors gear-coupled to a common driven gear. (i.e. when viewed from the shaft end you would see three gears, two small and one large)If you are attempting to have the motors turn on in a single and/or dual drive then it is recommended that you make provisions to take one motor mechanically offline when not used. I would not recommend that you feed two motors from one speed controller either as this produces some unusual loads for the controller. One controller feeding each motor should work OK. (BTW if you are going to use this approach be mindful that the braking function of the speed controllers need to be set the same and you may find that using braking at all is a problem when hard coupled) Keep in mind that if the motors are not closely matched or compensated for in software, the slower motor will provide some loading on the faster motor. In general this will not be a problem but off the top of my head the current in such a case would seem to be a little higher than the sum of the two motor currents when operated as single units.
Happy New Year

Here is an idea I had for a non-shifting two motor gearbox. Can you guys and gals take a look at it and let me know how I can improve it. Keep in mind it is just a concept and is extremely rough with no actual measurements, just a concept. It put it as an attachment. Thank you very much for your help.

Erg, here is the attachment. Edit post didn't work

In concept, that is what a non-shifting coupled motor transmission would look like. It's just a matter of determining gear ratios to minimize losses and designing a framework to house all of it.

The only part that I would show concern over is the need for chain at all. It is redundant to change the motors' output RPM through a gearbox and then connect each gearbox via chain. Instead, you may want to investigate, as has been mentioned, coupling each gearbox to a single output shaft. As an alternative to gears, you can use chain and sprockets to alter the RPM as needed and, again, couple the output to a single shaft. Gears would be much easier to deal with, however, as they won't change properties as much as chain might (i.e. stretching.)

You can eliminate chain from your design altogether by attaching a gearbox and motor to each driven wheel, even. Or, similarly, you can make driveshafts ( ;) ) There are many possibilities for driving the robots and they each offer advantages and disadvantages.

You're on the road to designing a basic gearbox. Remember, though, that harnessing that power may not be the best solution for this year's game. Always design with the game in mind, as an amazing drivetrain is certainly something to be proud, but it may not serve your need to effectively compete.

As stated above, you are on the right track. What you are looking at is something that is pretty heavy and the first question is "how is it going to steer?" With chain feeding both front and rear you can't turn either set of wheels. If you are going for tank drive, then the side friction of the wheels while turning skyrockets the motor current.

Would there be friction if we went for a spin or straight setup. The left side and the right side go in opposite directions to rotate us. They go in the same direction to move us foward and backward. Obviously, this would kill are ability to do gradual turns because as you said this would cause one side of the robot to drag putting strain on the motors. Can you give me some other steering alternatives or different gearbox setups? Thank you very much.

What several teams have started doing is either buying or designing/building their own wheels that grab in one direction and slip in the others. (We called ours BUPOD but I don't remember what the letters stand for at the moment. They were essentially small wheels mounted at the outer circumference of a larger wheel and at right angles to the driven axis. When driving the smaller wheels didn't move but when turning they did.)
Another alternative is to only drive one set of wheels and use casters (shopping cart) wheels for the other set.
Third and most difficult is to design a drive pair where the motors rotate as a module with the wheel and therefore drive and steer.
Good Luck,
Only two more days to go!

BUPOD=Biased Uni Planar Omni Directional.
Biased meaning they roll in only one direction.

This sounds like the most popular thoughts of a holonomic system, despite the fact that the amount of controllable degrees of freedom is not equal the the total amount of degrees of freedom (seeing as how you can be forced to strafe, and it's not controlled, as explained in a second). I believe I know what you're saying, and this sketch might be close.

It seems to me that if you were to integrate these omni-wheels (as they're commonly referred to) into a 4-wheel-drive (two sets of two chain-driven wheels), without the wheel assemblies themselves turning (thinking of the Wildstang 2002 robot), then you can easilly fall victim to being pushed perpendicular to your wheelbase, whereas a team without such a system would be much less susceptible to such a maneuver.

However, such a situation makes more than a few assumptions about next season's game, so much of this post can be disregarded. :rolleyes:

Interesting, I'm pretty sure I understand what you are saying. Would the wheel assembly look something like this. This is an overhead view with the I's being the big wheel and the -'s being the small wheel. Also, if I kept the robot fairly square in dimension, wouldn't I be able to rotate without friction problems in tank drive? Thank you very much.
II
II
II
II
II----------- (the smaller wheel can be more foward or more back)
II
II
II
II

Check out this thread for many pictures of 'omniwheels.' In the white papers, you can find this AutoCAD drawing of team 226's crab module. The wheel they used is an omniwheel.

Any system that uses skid steering wrestles against friction. Even if you're rotating about a point, with one side in forward and the other in reverse, the wheels are still sliding perpendicular to their intended motion (i.e., not forward or backward). This creates friction. Belted tank drives exhibit the same problem, but there's more surface sliding along the floor, potentially making it worse. (See this thread for a discussion on how surface contact could impact robot performance.)

Many teams choose to live with these losses. It's a balancing act, though, because by adding additional load to the motors while turning, the current draw increases, and you risk tripping a circuit breaker.

Teams choose to minimize these losses in a few different ways. Omniwheels are popular. Casters are popular also, but aren't powered, traditionally. There are some issues with simply strapping a gearbox onto a freely rotating caster. Crab modules are another answer. These are, essentially, powered, controlled casters. They're considerably complicated to build. Tanks can pivot on a single point if the system is designed propely.

Hope that helps.

D.
Using your drawing as looking down from above the small wheels would be the II viewed edge on with the axle parallel to the II and the - would be the drive shaft. If you look closely in the attached pic you can see the little white wheels with "o" rings for traction.
BUPOD=Biased Uni Planar Omni Directional.
Biased meaning they roll in only one direction.

Al, here is an even better picture of your wheels. We loved them and copied them on last years robot. However we were totally unable to keep the O-rings on the rollers with the swerve in full effect so we switched to aluminum rollers with a heavy knurl pattern on them instead and that proved very durable.

Very great wheels, I recomend that any team with a fixed tank drive setup uses them on the rear wheels.

I would've automatically assumed to put them in the front, as that's where cars steers and all.

But, then again, I've never driven these robots in competition.

Why would you recommend putting them as rear wheels over front wheels? Or, am I reading into it too much?

Well I guess we don't have a totally great answer for why except that when we used them on the front the robot steered 'about' the rear wheels which made it hard to grab the goals last year.

When they were on the rear wheels the robot spun about the front wheels similar to a fork truck.

We also tried them on all four wheels and the robot spun about its center but it didn't have as much pushing force as dedicated traction wheels on two of the four.

Oh, I think I get it now, those white roller thingys alleviate the side friction problem. How did you guys go about manufacturing this and what exact materials did you use.

Matt, thanks for the better picture. I am sure I have one some where but that was the best I had at work.
Construction... The large wheels consist of a sandwich of 2 aluminum pieces in which areas are relieved to hold a small axle for the white rollers to turn on. The rollers had slots cut in them for the o rings and then the o rings were glued in place. Each drive module had two assemblies because we found that the rollers were not in contact with the floor long enough to grab. Two assemblies next to each other but offset, allowed at least one roller to be in contact with the floor at all times. The rear drive set used normal wheels and performed the drive for steering. Note that a normal tank style drive with this arrangement allowed responsive steering without the side friction problems.
This robot was for the ramp competition and the drive was strong enough that we were able to drive around with another robot on our back and drive across the ramp.
We have discussed various designs to replace the roller/o-ring arrangement but have not used this design again. A roller made from aluminum with some kind of tooth cut in the surface would be ideal though.
I should mention that our mechanical engineer, Raul, is the one who is responsible for this design. It was in direct response to the electrical team's research on high current demands in tank drive systems.
Just a few more hours...

2001
 

Here is a design for a trick wheel that we used on our 2000 robot.

http://www.theforumisdown.com/uploadfiles/1102/trick%20wheel%201.jpg

(copy & paste the link)


edit: fixed link
edit#2:fixed url parse

Look in the white papers under team 226 crab drive for the plans on how to make the plates for the omni-wheels.

For what it's worth, I've 'adapted' those omniwheels into an Autodesk Inventor assembly (R5). I changed the bolt hole pattern around shaft so it would meet my preferences. Anyone with a little working knowledge of Inventor can change that easily enough.

Forgive me, Matt, if I bastardized your design. If I did, please let me know. I want to know the wheels will work if we decide to use them :)

(The file is a little too large to be an attachment. If you're interested in it, PM me and we'll figure out some way of getting it to you. It's really nothing all that exciting, though. It took me about 20 minutes to make.)

Not my design M ;) it was lifted from Wildstang and I think it is yours to do with as you desire.

Well, I lifted the design from your team's CAD drawings in the White Papers section. So, thanks for those, and thanks to Wildstang for making them in the first place, and thanks to cavemen for inventing the wheel :)

I managed to upload it to FTP.

http://www.magenet.com/~imagination/...Wheel_INV5.zip