Shifting while not going straight

[SoftwareBug2.0]

I have a couple related questions:

1) How much of a problem is it to shift in the middle of a turn? I know that at least some teams write their code so that if shifting won't happen if you're in a tight enough turn.

2) Has anyone built a shifting mecanum, rather than an octocanum? I've seen a design, here: http://www.chiefdelphi.com/media/photos/38068. I'd be interested in knowing what the shifting logic was and why. I'd especially be interested in knowing whether or not it's allowed when moving in directions other than straight ahead.

[Joe G.]

1. Depends on how quick the shift is. For the most part though, I can't imagine it being that much of an issue with any pneumatic-based shifter.

2. I would not want to build a shifting mecanum. The idea of a mecanum drive is to avoid pushing matches rather than to win them, which negates nearly every situation in which one would use low gear. Additionally, four seperate shifters add up in weight real quick.

[SoftwareBug2.0]

Originally Posted by Joe G.

1. Depends on how quick the shift is. For the most part though, I can't imagine it being that much of an issue with any pneumatic-based shifter.

2. I would not want to build a shifting mecanum. The idea of a mecanum drive is to avoid pushing matches rather than to win them, which negates nearly every situation in which one would use low gear. Additionally, four seperate shifters add up in weight real quick.

I guess one question I have is how long the shifts typically are. I know that with some of the teams at the championship I could watch them and tell when they were shifting as they drove, which suggests to me that they aren't super quick.

I don't intend to build a two-speed mecanum, but I'm interested in hearing how it worked because it might be more sensitive to what the dynamics of the shifters are.

I don't know if there's anyplace that does this, but it would be cool if there was some data about what output you can get about what the dynamics are. For example you might get something like:

t=0 is when a shift command is given
The original gear remains engaged until t=a
The wheel is free until t=a+b
When t=a+b the new gear is engaged

a=50ms, b=100ms

Or you might get: a=75ms with a stddev of 25, and b=100ms with a stddev of 50ms

Does anyone have data that could allow you to say something like: Supershifters take 150ms +/- 75 while the vexpro ball shifters take exactly 200ms every time. Then if you had some application where you needed things better synchronized you would know which one to pick.

I guess another good question to ask is: Is the output shaft being totally free a good model for what's happening during a shift in the sort of gearboxes that FIRST teams are using?

[MichaelBick]

Originally Posted by SoftwareBug2.0

I guess one question I have is how long the shifts typically are. I know that with some of the teams at the championship I could watch them and tell when they were shifting as they drove, which suggests to me that they aren't super quick.

I don't intend to build a two-speed mecanum, but I'm interested in hearing how it worked because it might be more sensitive to what the dynamics of the shifters are.

I don't know if there's anyplace that does this, but it would be cool if there was some data about what output you can get about what the dynamics are. For example you might get something like:

t=0 is when a shift command is given
The original gear remains engaged until t=a
The wheel is free until t=a+b
When t=a+b the new gear is engaged

a=50ms, b=100ms

Or you might get: a=75ms with a stddev of 25, and b=100ms with a stddev of 50ms

Does anyone have data that could allow you to say something like: Supershifters take 150ms +/- 75 while the vexpro ball shifters take exactly 200ms every time. Then if you had some application where you needed things better synchronized you would know which one to pick.

I guess another good question to ask is: Is the output shaft being totally free a good model for what's happening during a shift in the sort of gearboxes that FIRST teams are using?

The time it takes to shift is based on luck and how fast the robot is moving

[PVCpirate]

For logomotion, my team had a shifting and braking mecanum drivetrain. We used AM Supershifters with 1 cim on each wheel, and went for the pneumatic option to shift. I don't remember having any issues with shifting while the robot was rotating or doing anything else. The lower gear was mostly used for fine control while hanging game pieces. A student on our team also made brake pads for each wheel out of extra mecanum wheel plates, which immobilized the rollers to increase traction, and were also engaged by small air cylinders. Lots of pneumatics, but it did what it was supposed to do, and we won a Creativity Award for it.

[BEEKMAN]

Originally Posted by PVCpirate

For logomotion, my team had a shifting and braking mecanum drivetrain. We used AM Supershifters with 1 cim on each wheel, and went for the pneumatic option to shift. I don't remember having any issues with shifting while the robot was rotating or doing anything else. The lower gear was mostly used for fine control while hanging game pieces. A student on our team also made brake pads for each wheel out of extra mecanum wheel plates, which immobilized the rollers to increase traction, and were also engaged by small air cylinders. Lots of pneumatics, but it did what it was supposed to do, and we won a Creativity Award for it.

With regards to the robot Anthony is talking about: We had a lot of problems with shifting while going straight because you only shift on specific point with a DOG shifter. This means that some wheels will shift before others. This isn't an issue with a gyro stabilized drive, but most teams do not have that. With mecanum, shifting can really mess things up for small moments (driving straight + shift could cause a slight rotation, or translation unintentionally). Most drivers won't notice these at high speeds, but in auto its a killer.

[Gregor]

Why would you shift in auto?

[craigboez]

We had a shifting Mecanum this year, but it was for PTO purposes instead of two speeds. We played the whole match with the wheels engaged, then went to hang at the end. Once we were lined up under the bar we hit the climb button, which shifted all the wheels into PTO mode. The shaft in the middle of the chassis and the spools powered our climbing mechanism.

[PVCpirate]

I had meant to add that I didn't work very closely with the robot when I said I didn't remember any problems shifting. I did remember that all the wheels would shift at slightly different times.

[ErvinI]

Originally Posted by Gregor

Why would you shift in auto?

We shifted in autonomous because low gear was great for tight, accurate spins while high gear was required to allow us to complete our autonomous in 15 seconds. Also, because of the way the battery was positioned (our intake required a lot of empty space on the right half of the chassis), the robot drifted heavily towards one side when driving in high gear, but not at all in low gear. I have a feeling there was also some unwanted friction on one of the shafts, but I'll have to run a test to check it out. Shifting into low gear for the last 15 inches of a high-gear run gave us a very fast stop without any drifting towards one side.

I was a bit worried that the dogs will be worn out big time by the end of champs, however they held up admiringly, along with the solenoids moving them. While they occasionally broke while practicing at home (I'll have to ask the mechanical guys to see what exactly broke), it was never more than just one dog shifting a split second later than usual. Other than that, the shifting occurred almost simultaneously on both sides. When it didn't, I had some code written that automatically spun the robot to the original bearing that it was at before it shifted.