View Single Post
  #34   Spotlight this post!  
Unread 10-06-2014, 19:53
asid61's Avatar
asid61 asid61 is offline
Registered User
AKA: Anand Rajamani
FRC #1072 (MVRT)
Team Role: Mechanical
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Cupertino, CA
Posts: 2,229
asid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond repute
Re: The in-wheel swerve shifter!

Quote:
Originally Posted by Chris is me View Post
This is what I was trying to talk about earlier. As the dog oscillates during slow down / direction changes, the gears are being alternately loaded almost all of the time, though the duration of each individual load condition might not be that high. This is going to resolve as inertia that prevents the CIM from fully slowing down as quickly as a CIM under no load, unless there's a very significant delay between shifting halves.

Another condition that might behave oddly is what happens if you shift under load, i.e. to begin a pushing match. While the dog is "in between" gears, your wheels offer essentially no rolling resistance. What if a wheel is spinning the opposite direction you're trying to drive it? It seems like no matter how long the shift window is, you're going to be dealing with either or both of these problems to varying degrees.

I ain't trying to hate on your design, just trying to figure out if there are ways around these issues.
The dog is never "in between"; it can technically be in both gears at once. However, in that position, there will always be a force that will shift it one way or another into drive.

Hm. I'm looking at the cad again, and I'm seeing something interesting. The dog will actually very quickly "get stuck" in both gears if the dog is moving slower than the gear/hub it is driving. That means that the speed will instantly drop to whatever lower speed the dog is moving at. This would occur once every 1/3 of a rotation maximum, so at ~1400rpm shaft speed there would be 70 of said speed collisions each second. I would want to include part wear in loaded tests to see how much this affects driving. Code would have to allow for taking more time to decelerate, or I could just live with the collisions; that's what shifters and gears do usually when stopping.
Thinking about it some more, and looking at the cad again, it looks like the dog would just shift into the original gear whenever it reached the intermediate position.

Because the cim is putting force in the opposite direction when you shift (reverse cim direction), it will actually shift into the other gear because there is much less resistance that way instead of locking up. I wouldn't go into low gear unless I was in a pushing match anyway or had no load on the robot.

Or a stupid solution: Turn the excess speed into weird snake turns so that you don't have to deal with decelerating at all! Just keep all cims at 100% or -100% constantly. And when you're sitting in place, you can just turn in place!
I don't even want to think about the battery load that would entail.

In the pushing match situation you describe, there would be no pushing match. It would be another robot pushing you in the direction you wish to go, only faster than what the swerve can go at. If the wheel is actually spinning in the opposite direction for some reason, then I would flip the wheel around. More interesting code situiations.

No, I appreciate the input. It would suck to make this, then see it fail horribly and explode when I try to stop.

This swerve would have to have an onboard controller like an XMOS to do all this detection.

Something that's really similar to this is the zeroshift for F-1 racers, but it uses manual shifting with multiple dogs. The angled teeth are the same though.

Last edited by asid61 : 10-06-2014 at 19:58.