Vex Pro Ball Shifter Questions

[magnets]

I've been working on an off-season gearbox project, and I have a few questions about the vex pro ball shifter.

For my project, I'm designing a 2 speed, 3 CIM gearbox, with power takeoff. I've designed a few in the past, but they're all too heavy, so I decided to try with parts from a vex pro ball shifter. The three CIMs are set up to drive two separate ball shifter shafts. The first operates like it would in the normal gearbox, shifting the drive motors from high to low, and the second is only driven by one input gear, so the output from the shaft will only be connected when that input gear is selected.

I have three questions

1. Can I use the ball shifter shaft with 3 CIMs without it breaking?

2. We bought some ball shifters in the past, and I'm pretty sure that you can (by hand) move the shifting rod in between the two gears and get to a "neutral" gear, where no output happens. Is this correct, and would it be possible to spring load the shifting mechanism so that when there is no air the system, it returns to "neutral"?

3. Has anybody done something like this before with positive or negative results?

[T^2]

1. Can I use the ball shifter shaft with 3 CIMs without it breaking?

2. We bought some ball shifters in the past, and I'm pretty sure that you can (by hand) move the shifting rod in between the two gears and get to a "neutral" gear, where no output happens. Is this correct, and would it be possible to spring load the shifting mechanism so that when there is no air the system, it returns to "neutral"?

3. Has anybody done something like this before with positive or negative results?

1. Yes.

2. Yes, and no. If you want to have a neutral, you'll have to buy a 3-position pneumatic cylinder with strokes of 0.25in and 0.5in.

3. We're doing something similar right now. I'll keep you posted when we're done.

[DonRotolo]

2. The neutral position is in-between high and low (full in and full out)

[R.C.]

What T^2 said above, for the neutral you can't easily get it with springs.

But FabCo and Bimba sell a 3 POS cylinder. The hole pattern matches with the current mounting and the cylinders are basically interchangeable with the SMC cylinder used on the ball lock. So you can easily get the neutral position.

-RC

[yash101]

If you can get a servo to act as the cylinder, you could accurately position the shifter stuff.
You may like checking this out: http://www.andymark.com/product-p/am-2297.htm
(http://www.andymark.com/product-p/am-2297.htm)
Something similar may be what you want!

[T^2]

If you can get a servo to act as the cylinder, you could accurately position the shifter stuff.
You may like checking this out: http://www.andymark.com/product-p/am-2297.htm
(http://www.andymark.com/product-p/am-2297.htm)
Something similar may be what you want!

No team has accomplished this on the ballshifter as of yet; see 67's attempts last season. If you're going into this project blind, don't do this.

[EricH]

No team has accomplished this on the ballshifter as of yet; see 67's attempts last season. If you're going into this project blind, don't do this.

I'll also note that with dog shifters, those folks that use servos tend to switch to pneumatics as soon as practical. The legal FRC servos tend not to have enough power to shift on the fly, or so I hear (and I've heard it from enough sources to figure there's some truth to it). No comment on the linear servo, though; I don't think anybody's tried it in a competition yet.

[Adam Freeman]

If you can get a servo to act as the cylinder, you could accurately position the shifter stuff.
You may like checking this out: http://www.andymark.com/product-p/am-2297.htm
(http://www.andymark.com/product-p/am-2297.htm)
Something similar may be what you want!

No team has accomplished this on the ballshifter as of yet; see 67's attempts last season. If you're going into this project blind, don't do this.

I have yet to try the linear servo shifter. It appears that something like that would solve the issues I was having with the other servos setups, trying to get the rotatary motion lined up with the "slop" in the shift rod.

[yash101]

With a linear servo setup, the problem is that you need to be at a complete stop to shift, which rids you of the point in having a shifter. You would typically use the shifters to accelerate quickly, and then accelerate slowly, to a higher max speed!

[EricH]

With a linear servo setup, the problem is that you need to be at a complete stop to shift, which rids you of the point in having a shifter. You would typically use the shifters to accelerate quickly, and then accelerate slowly, to a higher max speed!

That's actually the problem with ANY servo setup, or so I hear. I think 330 tried servos on a shifter back when I was a student, but never on a competition robot; we used pneumatics on EVERY shifter we had (drill motor trannies and AM Gen2s).

[MichaelBick]

With a linear servo setup, the problem is that you need to be at a complete stop to shift, which rids you of the point in having a shifter. You would typically use the shifters to accelerate quickly, and then accelerate slowly, to a higher max speed!

The only team that I know that had used shifter to accelerate more quickly is 33. Everybody else generally uses shifter so that they have a higher top speed and a good pushing gear.

[yash101]

Yeah, I guess, but if used properly, shifters can be used to accelerate to a moderate speed faster, and then increase the top speed! Geared down with speed reduction, you will get tons of torque, what you need to accelerate faster. Geared down high, you can increase the top speed by a lot!

[AlecS]

Yeah, I guess, but if used properly, shifters can be used to accelerate to a moderate speed faster, and then increase the top speed! Geared down with speed reduction, you will get tons of torque, what you need to accelerate faster. Geared down high, you can increase the top speed by a lot!

A careful analysis of the factors at work in drivetrain will show that with typical FRC top speeds, this is not the case. Even in cases where battery voltage drop limits acceleration, the acceleration difference between a low gear 8fps and high gear 18fps, for the first 8fps is minimal. You would be talking about less than .3 - .1 seconds here, over a distance of 50 feet. Of course, gearing for absurdly high speeds, say 30fps, would yield a greater acceleration difference. However, at these speeds, you wouldn't even be able to accelerate to top speed in 50 ft, not to mention the currents you would be drawing.

When you consider the time and air it takes to shift each time, any small benefit gained would be a drop in the pond when driving in a match.

[MichaelBick]

This doesn't even start to mention the complexity of correctly writing auto shifting code. For the small benefit is it really worth all that time?

[sanddrag]

When I drove 3476's auto-shifting Vex pro ball shifter robot, it was rather seamless, and it seemed worth it.

[yash101]

This doesn't even start to mention the complexity of correctly writing auto shifting code. For the small benefit is it really worth all that time?

Couldn't you use PID, running inside the FPGA to: If encoders on the motor see that the motor is running at a high RPM, and the power is high, switch to high gear, to reduce the RPM. If the motor RPM is low, and the power is low, switch to low gear. That could possibly automatically shift for you. Otherwise, you could use an accelerometer! If nothing works, you could also just have a button on the operator console, like in our 2012 robot. (Supershifters were bad for it because they would flip the robot over :()

[FrankJ]

PIDs aren't really useful here. Ball shifters are a discrete change. PID need a variable to control in small steps. Not just one big one.

[Andrew Lawrence]

I'm no programmer, but I understand enough software to know this is possible with encoders:

if rpm > x amount
shift up

if rpm < x amount
shift down

Looks pretty easy to me.

[Brandon_L]

I'm no programmer, but I understand enough software to know this is possible with encoders:

if rpm > x amount
shift up

if rpm < x amount
shift down

Looks pretty easy to me.

I'd say a little more involved but at its core I can't see it being anything more then that.

[Joe Ross]

I'm no programmer, but I understand enough software to know this is possible with encoders:

There are quite a few more conditions, because it depends on both the current speed and the desired speed, and because you need hysteresis to keep it from continually shifting when you're near the shift point. You also probably don't want it to shift if you're only slowly accelerating or decelerating, so you need a third input.

See here for more details: http://www.chiefdelphi.com/forums/showpost.php?p=1205172&postcount=3

[MichaelBick]

Otherwise, you could use an accelerometer! If nothing works, you could also just have a button on the operator console, like in our 2012 robot. (Supershifters were bad for it because they would flip the robot over :()

Accelerometers don't measure velocity, they measure change in velocity. Also, having drivers constantly switch gears would distract them from driving well and would be much slower because drivers cannot respond as quickly as a computer can.

[yash101]

But you can uses that change in velocity to find out your actual velocity! Also, that is the reason why our shifter idea was a flop!

[Jared]

Couldn't you use PID, running inside the FPGA

No. You can't change the FPGA image and be competition legal, and there is no provided PID for the FPGA. Also, why PID? PID is used when you have a variable output.

I've played with auto shifting in the past, and it wasn't that great. Our test robot could accelerate in the fast gear to high speed faster than it could by starting in slow gear and switching to high gear. The only time it's useful is if you have it kickdown to the pushing gear if it detects a huge change in acceleration without the driver telling it to slow down (like running into another robot).

The problem is that it shifts when you don't want it to. It shifts when you turn, it shifts when you hit a wall, it shifts in that one moment where you need to keep going, it shifts as the chain falls off... Then, you have to write a bunch of code telling it not to shift if it shifted in the last 2 seconds, if you're turning sharper than a certain amount, if the deceleration is too huge....

Using the accelerometer to measure velocity isn't really feasible with the technology we have. It is possible to integrate the acceleration, but you always end up off. It's like the gyro drift where you integrate the angular rate to find your heading, but much, much worse.

[DampRobot]

IMO 33 is autoshifting as far as I am concerned.

However, 971's p-bot shifting setup at Madtown was pretty cool, if I do say so myself.

[Gregor]

(Supershifters were bad for it because they would flip the robot over :()

Could that of been a center of gravity issue and not specifically a Super Shifter issue?

Not really sure how shifting could cause your robot to flip over. Stopping and starting must of been next to impossible if shifting caused problems.

??!!!??? :confused: :confused: :( ::rtm::

[MichaelBick]

But you can uses that change in velocity to find out your actual velocity! Also, that is the reason why our shifter idea was a flop!

If everything was perfect you could use accelerometers to calculate velocity. However you would need a perfectly accurate accelerometer and no lag. There is no system capable of this, and so because of that using an accelerometer to find out your velocity would be incredibly inaccurate. Encoders provide a much more accurate reading of the velocity of your robot.

[T^2]

If everything was perfect you could use accelerometers to calculate velocity.

I'm struggling to see how this is possible. You'd have to know your initial velocity for this to work, which sort of defeats the whole purpose.



We did an acceleration/velocity test with our robot (ballshifters) earlier this year. In high gear, from a standstill, the robot catches up (position-wise) to itself in low gear within four feet. If you shift, you'll also lose energy during it. Automatic shifters are not worth it.

[MichaelBick]

I'm struggling to see how this is possible. You'd have to know your initial velocity for this to work, which sort of defeats the whole purpose.


If you know your acceleration and how long you've been accelerating, you can calculate velocity(based off of an initial velocity of zero at the beginning of the match). As you well know, there are so many ways this becomes inaccurate which is why it is a completely unreliable and nonviable method for figuring out your velocity and an encoder(which was made for this purpose) makes so much more sense.

[yash101]

Could that of been a center of gravity issue and not specifically a Super Shifter issue?

Not really sure how shifting could cause your robot to flip over. Stopping and starting must of been next to impossible if shifting caused problems.

??!!!??? :confused: :confused: :( ::rtm::

Yeah. Precisely!


If everything was perfect you could use accelerometers to calculate velocity. However you would need a perfectly accurate accelerometer and no lag. There is no system capable of this, and so because of that using an accelerometer to find out your velocity would be incredibly inaccurate. Encoders provide a much more accurate reading of the velocity of your robot.

In this case, you do not need to be on-the-dot. (+-).5 fps won't be a big deal when you want to find out when to shift.

[MichaelBick]

In this case, you do not need to be on-the-dot. (+-).5 fps won't be a big deal when you want to find out when to shift.

You will be way more off than .5 fps because the error VERY quickly adds up.

[Jared]

you can't use an accelerometer to measure speed. You will be off by way more than 0.5 fps. If your robot gets bumped, expect the value to be offset by about 20 feet per second.

[JorgeReyes]

Couldn't you use an encoder and use this to set up auto-shifting? And you could use this together with measuring voltage to detect when to shift.

[Rauhul Varma]

Couldn't you use an encoder and use this to set up auto-shifting? And you could use this together with measuring voltage to detect when to shift.

I would use encoders plus the built in ammeter functionality in the new PDB to autoshift.

[asid61]

Couldn't you use an encoder and use this to set up auto-shifting? And you could use this together with measuring voltage to detect when to shift.

Detecting current, right? Detecting voltage wouldn't help much.

[JorgeReyes]

Yeah you are right. My bad