Hi, we are implementing a swerve drive this year and I was curious to see how other teams are dealing with the wheel rotation issues that ensue, such as only a certain rotation can be made before hitting a mechanical (e.g. wire) constraint, the difference between you want to rotate your wheels all the way through or just invert the wheel direction instead, that kind of thing.
Our initial implementation was probably the most common and simple method, just take the angle of the joystick and command the rotation to that angle, and also to put a deadband in the vertical axis so that if the driver moves the joystick forward and backward sharply the wheels won’t have to rotate all the way through 180 degrees, just the wheel direction is inverted. (It should be noted that with our system, we are capable of rotating through around 400 degrees by design). The problem with this though is that if the driver were to move the joystick back and then to the left, the rotation would command would have sharp changes that, although wouldn’t be mechanically a problem would require a finite amount of time to transition.
The next idea is to map out the transition zones on the joystick, determine which path would require a normal rotation or reverse rotation and reverse wheel direction. Attached is a chart describing these transition areas. A transition across the red arrow would result in a rotation inversion and wheel speed inversion, whereas a transition across the blue arrow would not. No code yet, it is still an idea.
But both these “solutions” still have to deal with working with the finite rotation available (sinceslip ringsaren’t so good anymore). I don’t see how there could be a quick fix to this issue, since this constraint will exist no matter what. You could design this maximum rotation at an angle where a driver wouldn’t necessarily be crossing often, so that you don’t have the wheels rotating 360 degrees just to move a couple, which is what I’m planning on doing.
First off, its all related to how you design your swerve drive.
Second, Why not just have your wheels designed to travel through 180 degrees? Then you map joystick full left to 90deg left of centre, joystick full right to 90 deg right of centre, and then use the Y axis of the joystick to control wheel speed?
This is essentially what 1075 has done in the past, with some fancy code to give us extra steering modes.
Why do you need to be able to rotate 360 deg? The motors and gear ratios you would use to steer a swerve drive are more than fast enough to spin the wheels ~180 deg in very little time.
I have never tried to code a swerve drive as it makes my brain hurt, but one way you could do it with all four wheels ganged would be to make one stick drive the robot in a traditional “arcade” style" and then use a pot / z-axis to control module rotation, making the extremes of motion completely sideways to the left or right. This passes on a lot of the tricky controls issues to the driver, who’d better be smart This is what I did with Vex a few years back.
David,
We have used a hollow, vertical shaft that is the turning point of our crab drive. The motor is mounted inside the module and the wiring passes up through the hollow shaft. With a loop above the module, 400 degrees will not damage the wire. I can’t tell you anything about the programming but we have used +/-200 degrees in the past with this arrangement. BTW, our design has allowed the crab modules to be removed for service or replacement without tearing apart the robot. The module (motor, transmission, housing and bottom bearing) mounts to a rotating plate that is part of the upper bearing assy and vertical shaft. The upper bearing contains a surface for normal loading and a thrust surface for carrying the weight of the robot. Four screws and a quick disconnect of the power and any sensors and the module is out. A complete replacement can be made in two or three minutes.
Al - A lot of teams could learn a lot by just going through and reading your posts, I know that I do! This is exactly what we are doing. Our swerve drive is designed to support swappable modules using cannon plugs for power/data. Our goal is be able to replace any complete module in around 2 minutes, they are attached to our frame on 80/20 slides. We are actually only using 3 modules, in a triangular design. Did you guys do something like this before? I seem to recall that you have.
Chris - We are sticking (so far…) with the normal joysticks but control it exactly how you are saying, the main joystick controls the strafing and the magnitude of that movement, and the second joystick controls rotation about the robot’s center, and probably gyro assisted in the near future. We were going to explore more advanced driving methods besides the standard crab/rotate way when we had 4 modules, but since going to 3 it would be interesting but I don’t think that feasible, at least for now.
We might try limiting the travel to 180 degrees if we can’t get a successful implementation of the other way, but I don’t know if our modules will be rotating that fast that it won’t be something to worry about. Plus, you run into the problem if you go left and up or down (outside whatever deadband you have) you are reversing your wheel direction and your rotation, probably not that bad in 2:15 but still it’s something to worry about.
NO we have never gone to a triangle. I think Hot 67 used that one year when robots were able to tilt over at the stat of the match. Their robot had a modified crab.