Vex Pro Ball Shifter Questions

[MichaelBick]

Originally Posted by 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!

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]

Originally Posted by 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!

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]

Originally Posted by 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?

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.

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]

Originally Posted by 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.

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

[Joe Ross]

Originally Posted by Andrew Lawrence

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/sh...72&postcount=3

[MichaelBick]

Originally Posted by yash101

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!

[MichaelBick]

Originally Posted by 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!

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]

Originally Posted by MichaelBick

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]

Originally Posted by T^2

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.