"Automatic Transmission"

[Frank(Aflak)]

in any case, differentials can be heavy and at most, i see only a few teams using them as power (not to mention the input motors must have equal max-torques or else you loose major energy)

The major advantage of a differential (or planetary) link system is that you don't loose as much energy to motors fighting each other as you would with a fixed gear setup . . .


On topic: Personally, I would avoid using that type of clutch system where one motor does low speed and one high speed because at low speeds (as I understand your design) the chip would be nearly stalled (and therefore you have a possible breaker popper) and at high speeds and reverse your only power come from the chip. The main advantage is that it is automatic and you can forget about it. Still, If I'm going to put two motors in a gearbox I want them both to pull their weight. What would work instead could be a wheel-switching mechanism (one wheel geared highs than the other, lower it using pneumatics). You could even give the computer control over that and turn it into an automatic.

Using the original post's design, you would have a robot that is quite energetic until it hits 5 fps or so and then is fast but a little sluggish, and in reverse it would have a hard time moving at all (much less skid-turning)

if you could somehow make the drill take over lowspeed power in reverse also (maybe accomplish this with a clutch controlled by a governor?) , then you would have a great box.

[sanddrag]

Originally posted by Frank(Aflak)
What would work instead could be a wheel-switching mechanism (one wheel geared highs than the other, lower it using pneumatics).

Team 980 did this very successfully last year. It was amazing they got it all in there along with all that other stuff they have. Truly amazing.

[Madison]

What would work instead could be a wheel-switching mechanism (one wheel geared highs than the other, lower it using pneumatics). You could even give the computer control over that and turn it into an automatic.

Well, personally, I've only conquered that beast and am on V2.0. This was an attempt at something different.

For me, anyway, switching drivetrains is old hat.

[Frank(Aflak)]

Originally posted by M. Krass
Well, personally, I've only conquered that beast and am on V2.0. This was an attempt at something different.

For me, anyway, switching drivetrains is old hat.

True. I enjoy new things myself. This year, I am pushing for (and will probably get, seeing as I'm design lead) pretty standard drivetrain, cept its a four-wheel killough-style.

I personally think the future of this competition is in omnidirectional drivetrains. I mean, when it gets down to it, its all about speed and manuverability, and, to a lesser degree, power. nothing beats killough in manuverability. four wheel styl lets us distribute the motors more evenly. and make the math easier.

[ahecht]

Originally posted by Frank(Aflak)
What would work instead could be a wheel-switching mechanism (one wheel geared highs than the other, lower it using pneumatics).

Team 190 did this in 2001 and 2003 (although the two sets of wheels in 2k3 were at 90 degree angles to each other). The only problem with it is that is is much bulkier and heavier than a SotF transmission (which 190 had in 2000, IIRC). However, as we learned this past year, it can be really nice to have a backup driveline in case you pop a chain on your primary one.

Originally posted by Jnadke
Actually the coefficient of friction of Cast Iron on Steel is 0.4. This is compared to the coeficient of friction of Steel on Steel which is 0.8.

Exactly. The only reason 190 didn't use steel on steel in 2002 was that it wasn't allowed. The CVT we started in 2003 (but never used) was designed to be steel on steel.

[Paul Copioli]

jNadke,

OK, I was wrong about the differential not being like the CCT, but I know I am right about the torques NOT combining. The calculations are done in my whitepaper. Conservation of energy dictates that the torques DO NOT combine.

Put simply,

The second motor acts like the housing on the drill transmission: all it does is REACT the load of the input motor. To be exact, its reaction torque is (Torque of output carrier - torque of sun motor). The backdriving phenomenon you are describing is as if the housing breaks. If the ring gear motor does not have enough torque, then it can't react the load and is backdriven or put to stall and pops breakers.

The latter is exactly what happened to us at Great Lakes in 2002. I, like you, thought the motors combined torques and that got us in a lot of trouble. We popped breakers constantly. When we got home and I actualy sat down and did the calculations required (in the whitepaper), I discovered that the torques did not combine and the ring gear motor was merely a speed increaser. This is the biggest disadvantage of the CCT: add a motor and get speed, not torque.
However, the cool part is that you get more speed with the same output torque. In 2002 that was a big advantage, because we could move both goals at high speed.

If you are not convinced, you can e-mail me and I will discuss the details with you.

-Paul

[FotoPlasma]

Originally posted by Frank(Aflak)
What would work instead could be a wheel-switching mechanism (one wheel geared highs than the other, lower it using pneumatics). You could even give the computer control over that and turn it into an automatic.

Ahecht mentioned that 190 has done this, before, but I thought I'd add some pictures from 258's venture into this kind of system. This robot is from the 2002 season. The huge bolt through the 1x2" box aluminum acted as the pivot point, and the 2" bore, 4" (?) stroke pneumatic actuator did the shifting. If it's implemented properly, it can be a great method of shifting, but otherwise, it can be pretty bad. besides the driven wheels, we only used casters, and I must say, the casters didn't help. With a little off-the-cuff math ((550rpm/60s)*7in*pi), I calculate that we were going at, or a little under 16fps, in high-gear. Straight wheelchair wheels would have provided lots more control, I believe.

Also, speaking of a hybrid manual / automatic (for lack of a better way of putting it) shifting system, it sounds nicely challenging to develop a system (mechanical, electrical, and programming) which monitors current draw in the drive motors, and shifts accordingly. (I believe that 190 had this kind of system for their CVT, in 2001, but please correct me if I'm mistaken) Id est, starting in high-gear, get into a pushing match with someone, the system recognizes that you're drawing a lot of current on the drive motors, and shifts into low gear. You'd want to build in some hysteresis, so that it wouldn't go crazy at whatever you determined to be the threshold.

Just a couple thoughts, not sure if they're really applicable.

[maclaren]

Originally posted by M. Krass
As for your second question -- the only motor that's spinning constantly is the Chiaphua motor. Even then, it's spinning at low voltage with a low current draw when the robots at the low end of its operating range. The drill can be safely turned off entirely once the robot's moved beyond the useful speed of the drill motor.

Actually if you don't cut power to the chip motor at low RPM it will stall and will subsequently over heat and literally fry the motor.

If you do cut the power to the chip it will act like a magnetic brake because it will be generating electricity; due to the conductor, magnetic field and relative motion between the two. That's assuming that the chip motor has permanent magnets.

[Andy A.]

Motors only act as brakes if dynamic breaking is enabled on the Victor. It is selected by the position of a jumper between 3 pins on the base of the Victor it's self.

Check the Victor docs for more on that.

-Andy A.

[DanL]

Getting in on the action of this thread, albeit a week or so late, here are my thoughts....

First, I think someone mentioned this before, but I'll say it again: this monster's going to be loud when it's slipping/drill motor turned off to save power. I also can't help wonder how all this slippage and slamming of the plates will hold up. Mechanical things aren't my forte, but it seems that, especially at the CIM's higher RPMs, this is going to cause a lot of wear and breakage, not to mention heat. Rather than 'turning off' the drill motor when going fast, I'd use some more power and put the thing in low so the relative motion decreases and there's less slamming of the plates.


Now for my real problem with this design: from a programmer's point of view, this is a complete nightmare.

Originally posted by M. Krass
Well, during that time, so that it doesn't drag on the system, we also want the Chiaphua motor to be spinning -- but we don't want for it to see any load. To accomplish that, we have to employ our second "disconnect," but this time it's an electronic disconnect. By varying the voltage to the Chiaphua via PWM output, we can make it such that its free speed corresponds with the current drill motor speed while under load. This is our electronic clutch.

Something like this cannot easily be determined from motor curves alone. This is going to require testing, testing, and even more testing. You can't wait three, four weeks to build this gearbox and possibly expect the programmers to have the e-clutch figured out in a few days. I've begun thinking of several ways on how to calibrate this, but regardless, the programmers need a lot of trial-and-error time to get the e-clutch working at max efficiency. Another thing, it seems to me the 'golden values' would be different at 12 volts than at 10, 9volts (seeing as more voltage causes the motor to spin faster). Once your voltage begins dropping in those last 60, 45 seconds of the match, it seems to me like the efficiency of the e-clutch will be going down and down.

M, it's an interesting idea, but as I understand it, if anyone implements it, that person better hope he has very talented/patient programmers with plenty of time to find the magic values. Someone correct my ideas if I'm wrong, though - like I said, I'm an electrical guy, not a mechanical one...

[edit]
Thinking about it even more, there seem to be just so many variables to take into account to get it working at max efficiency - the voltage of your battery, the drill motor load rpm vs. the cim no-load rpm (is the relationship linear, or is it complicated?), the actual amount of load or resistance to motion being expierienced, the wear (and so, the changing coefficient of friction) on the clutch plates, differences in individual motors (you'll have to calibrate each side seperately), and probably more to be discovered. If even one of those changes, the programming is going to have to account for that. This idea is going to be like jamming an iron rod through your programmer's face.

[kmcclary]

Originally posted by SuperDanman
First, I think someone mentioned this before, but I'll say it again: this monster's going to be loud when it's slipping/drill motor turned off to save power.

Extremely! (whack whack whack... ) I was wondering about the wear and heating effects, too. That's a LOT of hammering while clutching. (I'd be tempted to add a pneumatic clutch just to reduce the noise and wear on the joint! )

Originally posted by SuperDanman
Now for my real problem with this design: from a programmer's point of view, this is a complete nightmare. Something like this cannot easily be determined from motor curves alone. This is going to require testing, testing, and even more testing. [...] Another thing, it seems to me the 'golden values' would be different at 12 volts than at 10, 9volts (seeing as more voltage causes the motor to spin faster).

Well, I'm not so sure. IMO, the solution to that will be in adding "appropriate feedback sensing" to make it a closed loop system.

The question then becomes: What data do you need to collect to determine the case, and appropriate control action? In some way, you'll need to know a loading factor per motor, and to sense an imminent motor stall condition.

Off the cuff, current monitoring of the motors may yield enough data to determine the case and close the loop, but you may also the true speed of the motor with either encoders or "PWM off phase generator speed sensing" as well.

Note that to prevent backdriving, you can always include some kind of a mechanical antibackdrive system in each motor's train (like worm gearing, or backdrive pins). Another option would be to wire the coast/brake jumper to switch the Victor into braking mode under program control. I'm just curious though how much back drive the Schottky kickback diodes within the Victor's MOSFETs can safely take before popping!

I agree with you, Dan. Dropping this one onto the programmers in week 5 (or 6!) without even a proof of concept prototype, and somehow expecting them to "figure it out" would NOT be a good idea (and possibly suicidal). This is definitely a case where "off season prototyping" experiments are in order before you even consider choosing it.

- Keith Mc.

[Matt Krass]

Originally posted by kmcclary

I agree with you, Dan. Dropping this one onto the programmers in week 5 (or 6!) without even a proof of concept prototype, and somehow expecting them to "figure it out" would NOT be a good idea (and possibly suicidal). This is definitely a case where "off season prototyping" experiments are in order before you even consider choosing it.

- Keith Mc.

You drop this on the programmers that late the only whack whack whacking you'll hear is them beating you with something blunt.

[Mr. Ivey]

Growing up in an auto shop I have learned some things about how transmissions work, and how gear ratios are figured, and how mechanics in general works. I think that the inital idea of having a sort of screw that connects the powered shaft from one motor is a good idea, but... Let's think how a real automatic transmission works, you have a ring gear, planet gears, and 1 or 2 sun gears. In an automatic transmission in a car there are 2 of these systems connected together to give the car multiple gear ratios. Now you can make a level of the gears, such as the planets stop moving, this gives you a different output gear and a different ratio. What if you could construct a planetary gearset that was somewhat like the one inside of a car. That when you lock one section of the the gearset you get a different ratio, but you can also allow another section of the gearset to spin freely. Thus allowing a drill to be powering the wheels via sun gear, and the whole apparatus rotating around the sun gear from the atwood, and then at a specific point, the atwood powers up, and a clutch of sorts is released and another engaged, and the drill motor is stopped, while the whole shabam is being powered off of the atwood. I'll get a copy of this idea up as soon as I can, I've been working on this concept for some time now.
But that's my two cents on the whole automatic transmission idea.
Ivey

[Madison]

I agree that there are different -- probably better -- ways of accomplishing the same task. This was just an idea I tossed out there for criticism and improvement.

What you described sounds a lot like 217's CCT (There's a whitepaper describing its design and function on this site), though, admittedly, I don't know much about how the CCT works -- so I could be far off base.

Thanks for taking the time to read through this thread -- especially since it had been dormant for so long.

[KenWittlief]

M.Krass

I finally found this thread - took a long time to read through all of it (i wish you would have PM'd me :^) ]

first off, I love what you have done with the idea - you've really taken the ball and run with it here.

second - I believe the idea is sound and very clean as you have implemented it. Ive taken note of some of the objections in the thread, but I dont think any of them are serious problems

third - I have only one suggestion to make the system better. In your first drawing you show the mating surfaces, the part that will catch and transfer power when the clutch locks, at 90° relative to the clutch face. Id recommend you put an angle in there, so that, when the clutch engages, the two halves pull themselves together - a little bit of the spiral, but in the opposite direction - then as soon as it starts to catch, it will pull itself together tight, not depending on the pressure of the spring to engage fully

and that brings us to one of the repeated objections - noise? clatter? I dont think so. When you ride a ten speed bike, and stop pedalling, is the clatter from the one way clutch in the back wheel deafening? No! does that clutch inside the gear assembly wear out frequently? have you EVER had one wear out on you?

no

With that little bit of back angle on the catching surfaces, the spring that pushes them together can be very soft - remember, this is only going to engage at very low rpms, and once the edge catches, they will 'screw' themselves together (if you angle that surface a little like I mentioned above).

As for the SW control problem, thats simple. You dont want to lean on the high speed motor when?

when the clutch is engaged

when is the clutch engaged?

when its pulled together!

it would be simple to ride a contact switch on the back side of the moving part of the clutch, and when its disengaged, the clutch is pushed back a little, the switch closed

and SW knows its time to allow serious power to be applied to the high speed motor, and if you want, to power off the low speed motor.

I think some people are interpreting the concept behind this wrong - dont think of it as a traditional automatic transmission, with each 'gear' covering half the operation range.

Design the high speed motor and gear ratio so the bot will drive the way you want, as if it were the only motor - dont gear it up so high that the bot cannot start without popping the 40A breakers

then design the low speed transmission geared down so low, that you can spin your tires if you want to - it might have a top speed of 1mph

which is what you want in a shoving match - kinetic friction has no knowledge of how fast a wheel is slipping on the carpet - once it starts to slip, the force you are able to apply is the same, no matter how fast you spin the wheels

so you could have a bot that drives 'normally' in both directions, is pretty quick on the playfield

but when you want to push, you have the all the torque you need (ie, once you start spinning your wheels, thats all you need)

Nicely done! I really like it. :c)