Vex Pro Ball Shifter Questions

[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.

[Jared]

Originally Posted by yash101

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.