|
|
|
![]() |
|
|||||||
|
||||||||
In pondering silly and fun FRC mechanisms, I thought about putting omniwheels on a swerve drive. After I put more thought into it there are some very practical advantages, and some debilitating disadvantages.
Advantages:
You can get away with 1 pivot motor for all wheels (3 in this case) because there is no turning scrub
Significantly easier programming because of that
The theoretical max speed is 1.414 times what the bot is geared to (because you can add the velocity vectors of X and Y travel after a fast turn, ideal hypotenuse is 2^0.5)
No t-bones in any direction
All motor power goes into the same direction (as opposed to regular omni)
Pure silliness
Disadvantages:
Standard disadvantages of swerve (weight, complexity)
The minimum skill required to effectively drive it is probably insane
Lack of traction
So, What are your thoughts on the concept of OmniSwerve? (comments about my Implementation should go to "OmniSwerve chassis Bottom View" I guess, so we don't have 2 discussions at the same time)
If there is anyone experienced with swerve that has the time to test this concept I would love to see the results.
17-06-2016 19:38
Scott KozutskySorry, double posted the pictures.
17-06-2016 20:07
ctt956Good concept IMO. This would probably also be advantageous if a motor/gearbox/drive module failed, as it seems like it could be pulled along by just one wheel. All of the gears should probably be protected better so debris doesn't get in them.
17-06-2016 20:35
The other Gabethis is ridiculous, a complete waste of time, and probably not particularly effective. I love it!
17-06-2016 20:48
Chak
| The theoretical max speed is 1.414 times what the bot is geared to (because you can add the velocity vectors of X and Y travel after a fast turn, ideal hypotenuse is 2^0.5) |
17-06-2016 21:03
Scott Kozutsky|
It would be a very interesting math problem to calculate the theoretical max speed. I don't think it's 1.414, because that either assumes the motor can get up to max speed immediately after a fast turn, or it assumes that omniwheels have no friction laterally. Instead, as the robot turns, it decelerates in one direction and accelerates in the other. With the omniwheels, the net acceleration will probably increase the speed. But to what maximum?
|
17-06-2016 21:07
Chris is meI'm really having trouble seeing what this gains over a normal kiwi drive setup.
If you have six motors on it, you're going to have plenty of torque in any direction of travel even if all wheels aren't pointing in the same direction. You'll be able to do advanced maneuvers (simultaneous rotation + translation) with a kiwi drive, but not with this drive.
17-06-2016 21:30
Scott Kozutsky|
I'm really having trouble seeing what this gains over a normal kiwi drive setup.
If you have six motors on it, you're going to have plenty of torque in any direction of travel even if all wheels aren't pointing in the same direction. You'll be able to do advanced maneuvers (simultaneous rotation + translation) with a kiwi drive, but not with this drive. |
17-06-2016 22:35
Chak
|
I'm really having trouble seeing what this gains over a normal kiwi drive setup.
If you have six motors on it, you're going to have plenty of torque in any direction of travel even if all wheels aren't pointing in the same direction. You'll be able to do advanced maneuvers (simultaneous rotation + translation) with a kiwi drive, but not with this drive. |
|
You'd have one and a half times as much power in any direction ,assuming a power if 1 unit per wheel you'd get 2*cos(30)+1*cos(90)=1.73 to 1*cos(0)+2*cos(60)=2 for kiwi and 3*1=3 for omniswerve. If you have the motors mounted you might as well use them.
You are able to do advanced maneuvers with this because you can just tank turn at any time, there's no scrub from the omni wheels so even with the sub optimal platform it would still work. |
17-06-2016 23:27
Dan_KarolMaybe i'm missing something, but how does it turn?
If all pods are ganged together then you have no control over what your heading is or you have no ability to strafe.
17-06-2016 23:56
GeeTwo
TL;DR Trying to wrap my brain around what this does and why you'd want to do it.
If all the wheels steer in unison, you have crab drive - with the inherent [crab] inability to rotate the chassis (not good for a triangular chassis in most conceivable games) and the additional [omni] weakness of being highly vulnerable to cross-drive forces. I don't see any way to get anything faster than geared speed in this scenario, either.
If only the wheel near the steering motor is steered, I can imagine a scenario where you can get up some extra speed, though I haven't done the math to convince myself it's viable. If this is the case, why are the two non-steered wheels built up so they appear to be swerve modules?
Or is something else going on (e.g. one of the wheels steers counter to the other two, or something even more arcane)?
Edit:
|
drive straight to max speed, turn left at 90 degrees and accelerate in that direction to max speed. Because of the omni wheels, you actually (ideally) don't lose your forward momentum after turning and, as such, move in both directions at your maximum geared speed, hypotenuse of that vector triangle is 1.414 times the side length.
|
17-06-2016 23:59
Scott Kozutsky|
Maybe i'm missing something, but how does it turn?
If all pods are ganged together then you have no control over what your heading is or you have no ability to strafe. |
18-06-2016 00:48
Aren Siekmeier
18-06-2016 01:17
asid61How are you getting above max speed? You might get more power in a direction (like with a kiwi), but not more max speed.
The major advantage I can see to this is being able to run a crab drive without worrying about turning scrub, but at that point one might as well run mecanum or pure swerve. I think this would be usable for a team with low programming resources that wants to get into swerve (say during the build season) but wants a good backup plan for if it doesn't work out. Crab is significantly easier to program than full swerve.
18-06-2016 07:06
Scott Kozutsky|
How are you getting above max speed? You might get more power in a direction (like with a kiwi), but not more max speed.
The major advantage I can see to this is being able to run a crab drive without worrying about turning scrub, but at that point one might as well run mecanum or pure swerve. I think this would be usable for a team with low programming resources that wants to get into swerve (say during the build season) but wants a good backup plan for if it doesn't work out. Crab is significantly easier to program than full swerve. |
18-06-2016 07:20
GdeaverIt's summer. No pressure. No time constraints. Why waste your time on this project. Isn't there something your team needs to work on to improve it's skill set? Something that could actually be used in the future?
18-06-2016 07:52
Scott Kozutsky|
It's summer. No pressure. No time constraints. Why waste your time on this project. Isn't there something your team needs to work on to improve it's skill set? Something that could actually be used in the future?
|
18-06-2016 12:37
Aren SiekmeierThe sqrt(2) speed increase is certainly a different way to think about things. I imagine it wouldn't coast terribly far on the rollers, and it's not powered through any obstacle in that direction. And sounds like you've considered how it would mess with the driver to be in a constant uncontrollable powerslide.
Put in a traction wheel and you've got a decent crab drive. Two more turning motors for unicorn.
18-06-2016 12:44
nuclearnerd|
This was entirely my own project and an excellent opportunity to brush up on CAD. I figured Chief Delphi posters in general would also enjoy this kind of thought exercise but apparently not.
|
18-06-2016 15:25
GeeTwo
|
This was entirely my own project and an excellent opportunity to brush up on CAD. I figured Chief Delphi posters in general would also enjoy this kind of thought exercise but apparently not.
|
18-06-2016 19:20
Cothron Theiss|
This was entirely my own project and an excellent opportunity to brush up on CAD. I figured Chief Delphi posters in general would also enjoy this kind of thought exercise but apparently not.
|
19-06-2016 21:44
MoskowapplepiI am curious how well this would work in practice as well as how the triangle design came to be.
19-06-2016 22:03
EmileH
|
I am curious how well this would work in practice as well as how the triangle design came to be.
|
19-06-2016 22:41
Scott Kozutsky|
I am curious how well this would work in practice as well as how the triangle design came to be.
|
22-06-2016 23:53
Hitchhiker 42With the max speed thing, here was the way I though you could possibly do it:
Have one wheel face one way, another face 90* from it, and the third point right in between. If you power the two at 90* to each other, you'd get sqrt(2) the speed.
23-06-2016 00:48
asid61|
With the max speed thing, here was the way I though you could possibly do it:
Have one wheel face one way, another face 90* from it, and the third point right in between. If you power the two at 90* to each other, you'd get sqrt(2) the speed. |
23-06-2016 08:46
GeeTwo
|
The velocity vectors don't add like that I think. You would get sqrt(2) + 1 times the torque of the single cim pointing in the right direction, but the max speed is still only the speed of that cim.
|
23-06-2016 15:02
asid61|
The velocity vectors can add up so that the speed of the robot is greater than the speed that any individual wheel is driven. The issue is that with the number of rollers providing resistance to this motion, I find it unlikely that those two motors could achieve a significantly greater speed than one in which all three motors are providing drive force in the desired direction. The only way to know for sure is to build it.
|
23-06-2016 16:02
Aren SiekmeierForce vectors add. Velocity vectors do not. Rather they are constrained by slip conditions and the relative motion of bodies.
It's sort of a continuously variable transmission.
Say you are constrained to go in a direction 0 (by a wall or omnis opposing each other, etc.), but an omni wheel is pointed in a direction theta relative to your heading, and spinning at speed w about its axis. The overall translation velocity vector v is identically the velocity of the center of the wheel relative to the ground, which can be broken into the rotation of the wheel (w), and the rotation of the rollers (s), assuming no slippage. Then v must project onto the wheel speed w, as w=v*cos(theta). The roller speed is s=v*sin(theta) and has no limit. The overall speed is v = w/cos(theta), resulting in a higher speed.
To do this, you could have a four wheel drive with steerable omnis in each corner. Start with them directed forward, (theta=0), and spin the wheels at speed w. Then v = w / cos(0) = w. Then turn the left and right wheels toward the middle by an angle theta. Now v = w / cos(theta) will give an increase in top speed.
However, the force available in the forward direction drops. Each wheel supplies F in its own direction. When theta = 0 then the total force is 4*F, all straight forward with no sideways component. When theta is increased, the sideways components cancel, but at each wheel, the sideways component must add with the forward component to get F in the direction theta. So the forward component from each wheel is F*cos(theta), and the overall force available is 4F*cos(theta).
In this way, steering the wheels toward the middle by an angle theta acts as another stage of reduction, increasing the speed and decreasing the force by a factor of cos(theta), assuming no wheel slippage.
Vector diagram to help

23-06-2016 18:28
bkahl|
The velocity vectors can add up so that the speed of the robot is greater than the speed that any individual wheel is driven.
|