Automatic Shifting Algorithm

[phrontist]

For the purposes of this thread we are assuming that the robot has a four speed transmission.

In 2005 I'd like to have a fully automatic transmission, but I've been struggling with how I'd actually implement this (from an algorithm standpoint).

This is the best I've come up with:

Find max speed robot is capable of in highest gear with full motor power. Call this x. Using banner sensors, the speed of the wheels will be used in the algorithm as a percentage of x. The percentage of joystick input would the correlate directly to the speed of the wheels. The algorithm would increase motor power until reaching the desired wheel speed unless it hits 255 first at which point it would shift up and decrease motor by some given amount calculated ahead of time.

I really have very little idea what I'm doing

How would you do it?

[Adam Y.]

*Warning this is coming from a person who also has a vague idea what he is doing* I would try and forgo providing any imput from the joysticks. The whole purpose of an automatic transmission is that you can jam the pedal all the way down without having to worry about destroying the motor. I would focus on the wheel speed only. At 0-X₁ the gearbox would be set to to the lowest gear. At x₁-x₂ the gearbox would shift up. At x₂-x₃ the gearbox would then again shift up. At x₃-max speed the gearbox would be at it's final speed. The x's represent the maximum speeds that the gear transmision would obtain. So in my eyes it would be a simple inequality.
If speed is greather than 0 but less than X₁ shift into lowest gear ratio.
If speed is greater than X₁ but less than X₂ shift up into second gear.
If speed is greather than X₂ but less than X₃ shift up into third gear.
If speed is greater than X₃ or equal to max speed shift into forth.

[phrontist]

The system you described is what I was thinking, sorry if my explanation indicated otherwise.

Ah, but the problem with this is that it almost defeats the purpose of a tranny! What if you go up a ramp or get into a shoving match? It seems more logical to have a system like the one described but also have it check the current draw on the motors. If the current draw is more then y (and y would have to be found through tinkering) don't shift up to go faster, shift down.

I think that would work...

[Adam Y.]

The system you described is what I was thinking, sorry if my explanation indicated otherwise.

No problem.

Ah, but the problem with this is that it almost defeats the purpose of a tranny! What if you go up a ramp or get into a shoving match? It seems more logical to have a system like the one described but also have it check the current draw on the motors. If the current draw is more then y (and y would have to be found through tinkering) don't shift up to go faster, shift down.

Good idea. I was thinking that the banner sensors wouldn't be reliable enough to use in an automatic transmission. Now you would have redundancy built into the system.

[Astronouth7303]

Why not measure the RPMs of the motor and up/downshift as necessary?
IE:

// Globals
long RPM;
#define MINRPM 10
#define MAXRPM 100
unsigned char Gear = 1;
#define MAXGEAR 4
#define MINGEAR 1

//...
// in some sub...

if (RPM < MINRPM) Gear--;
if (RPM > MAXRPM) Gear++;
if (Gear < MINGEAR) Gear = MINGEAR;
if (Gear > MAXGEAR) Gear = MAXGEAR;
// change gears, if necesary

[edit]This is all asuming the code can shift well and measure rpms acurately enough[/edit]

[Chris Hibner]

I would suggest shifting based upon the torque, not the speed. The problem is that torque is more difficult to measure than speed, but you can do a decent job using current sensors.

The algorithm would look something like:

if (torque > DownShiftThresh)
    Gear--;
else if (torque < UpShiftThresh)
    Gear++;

if (Gear > 4)
    Gear = 4;
if (Gear < 1)
    Gear = 1;

Shift(Gear);

[Paul H]

Originally Posted by phrontist

Ah, but the problem with this is that it almost defeats the purpose of a tranny! What if you go up a ramp or get into a shoving match?

Yes, but if you get into a pushing match, wouldn't you slow down anyways, causing it to shift down?

[Adam Y.]

Why not measure the RPMs of the motor and up/downshift as necessary?

I suggested that in the second post. The only problem is that you would need a fairly reliable sensor to accomplish this. Hmm... I have an idea. A really cool idea that might just work. Ill be on later.

[FizMan]

You might also want to include a sort of "buffer"... if for some reason your robot is fluctuating speeds from just above and below "x2", then it'll be constantly engaging the shift back and forth... probably not the healthiest thing.

[Greg Ross]

Originally Posted by FizMan

You might also want to include a sort of "buffer"... if for some reason your robot is fluctuating speeds from just above and below "x2", then it'll be constantly engaging the shift back and forth... probably not the healthiest thing.

This "buffer" is called hysteresis. Before shifting up, you should wait until the RPMs/speed is "a little" above your threshold, and before shifting down, you should wait until it is "a little" below.

[Paul H]

Originally Posted by Adam Y.

I suggested that in the second post. The only problem is that you would need a fairly reliable sensor to accomplish this. Hmm... I have an idea. A really cool idea that might just work. Ill be on later.

We used banner sensors for ours and they worked fine. We used four, two per tone wheel, one tone wheel per side. They doubled as encoders for autonomous and gave us the ability to make our robot go anywhere on the field within about an inch. Our design for next year actually uses a shaft encoder right in the gearbox. It'll be in the whitepaper, I posted a picture of the CAD drawing somewhere.

So....just use a shaft encoder.