Vex Pro Ball Shifter Questions

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

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

[Gregor]

Originally Posted by yash101

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

??!!!???

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

[yash101]

Originally Posted by Gregor

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.

??!!!???

Yeah. Precisely!

Originally Posted by MichaelBick

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]

Originally Posted by yash101

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.