This is a crude drawing , we are still working on the cad file. A top view of the idea I posted before. We hope to use steel tubes to suport the drives so they can move up and down with the ramps. The bolt of the bumpers will slide into the tubes and a cotter pin will hold it together. More drawings at http://www.team1322.org/ideas.htm
I might be totally wrong here, but i think there is a huge problem with this design.
The chains going to the omni wheels in the center should not be there. Imagine what happens if two mechanums on the same are rotating in different directions in order to create a strafe movement, what happens is that the sprocket on the center omni wheel is getting pulled by one chain forwards, and by the other one backwards, thus, assuming the powers are equal it will not rotate at all, and the mechanums will not rotate either, and therefore you will never be able to strafe.
If i am correct, you have to consider removing those chains, and leaving the center omni wheel unpowered, or powered by a different motor.
Can someone more experienced tell me if i am correct here?
If that’s a top view, I think your mecanum wheels are in the wrong orientation. From what I’m looking at, it looks like the drivebase will have low rotational stability. The omnis will mask the problem, but the underlying issue will still be there.
This drawing does not give enough detail to show the differential on the omniwheel drive shaft.
Very logical assumption and good observation! however, in a previous thread discussing the same design, it was revealed that the chains tie into a ball differential for the center Omniwheel… this way if the robot is going forwards or back, the chains are going in the same direction, and the Omniwheel will roll. If they are strafing, then the chains will be going in opposite directions, canceling each other out, so the sprockets will free-spin and the Omniwheel will not turn. If it is going at an angle, the Omniwheel will move slightly back or front.
While I am having a little trouble understanding how the ball differential physically looks, I LOVE this idea! Well done!
In a top view, you want the axis of the rollers on each wheel to form an X so that the rollers form an O or a diamon on a bottom view.
If this were a bottom view, it would be fine. If this is the top view, all you need to do is swap each wheel with it’s counter-part.
Still don’t see why the Mecanums can’t be directly driven from the banebots shaft, rather than through Helical gears, but looks like a very interesting concept. Please keep us updated on any prototyping efforts.
The reason we do not drive the wheels straight off the Bainbot shaft is to allow for straight driving. You know that the motors drive faster one direction than the other direction. Using them on helical gears the way we are make the motors go the same direction when the robot is going forward thus the motors are running at the same speed. So when we program for autonomous we will not have any problems with it pulling to the right or left… Also note that when the robot goes sideways one set of motors will reverse so they will be going the same direction again allowing for straight travel.
That’s much less of an issue than you might think. The CIM motors in particular have negligible directional bias. What I’ve discovered is that the Victor bias is the real troublemaker. With factory calibration, the neutral point on the Victor corresponds to about 132 on the IFI PWM scale. If you treat 128 as the neutral, you end up with a tendency for the motor to run faster in reverse than in forward.
We had a robot a few years ago that would unexpectedly turn slightly under autonomous control. Calibrating the Victors to the RC output fixed the problem completely. We’ve made it a point to calibrate them ever since, even including a special function in the robot code to sweep a selected PWM output from full forward to full reverse and back to neutral. (Last year, we defined full forward as 228 and full reverse as 28, and we did a similar calibration for our joysticks. It made working with the code a tiny bit easier to have the valid range of both control and output values be +/- 100.)
I can’t imagine helical gears are cheap. You’re willing to pay the extra money to solve a problem that can easily be fixed in the code?
okay, so ive been trying to understand how ball differentials work, and i think i have the basic idea down. they have the same function as a normal differential, but can be more compact. i rendered this to help myself understand how it works. i was trying to get it animated, to show the different directions, but the constraints just werent working.
we used a drive train like that in class once
I assume that with mecanum drive you will be using encoders on all wheels. If so, you can fix any lingering bias issues in programing, using feedback from the encoders.
One thing to note here. If your pivoting the “modules” about the steel tubes (that’s my assumption) then whenever your suspension moves the distance between the steel tubes is going to change. Seem like it could be hard to mount other robot pieces on a dive base that keeps changing size.
I can see why you might use the helical gears just to save space in the chassis but it would seem like the price wouldn’t justify the cost. Although if you had some of the old helical gears from 2004 and previous season lying around I would definitively see the benefit.
Pasting from the other thread:
You may be correct, but from what I have observed from the ball differential it should work. The omni wheels will be attached to the shaft that is attached to the disc holding the balls. The balls will be pressed on each side by the sprockets. If the sprockets are going the same direction than the wheels must be moving the same speed. If the sprockets are going in opposite directions (equal full speed) than the omni should be stationary. Correct? Now if one sprocket is not moving while the other is moving at full speed than the omni wheel should be moving one direction at half speed. Thus allowing for a 45% angle run of the robot. Any other difference should be also of the same ratio. On paper the ratios work out but in practice I may be wrong. We will be building a test system this fall to find out.
The problem lies in the direction of the force vectors that the omni wheels add when they spin. When you’re trying to lateral at 45 degrees off of forward motion, I see now that the omni will only spin at half speed. However, the omni wheel still spins forward therefore your 45 degree angle of velocity is cut down to (ideal physics here…) 45/2 or 22.5 degrees.
You should be able to account for this in code by adding a small backspin to the front mecanum wheel, yet there may be a bit of tweaking to make it smooth from zero to 90 degrees in each quadrant. Good luck and keep us posted!
Nice rendering, I see you have groves in the side plates, you don’t need them the balls are trapped and will not go anywhere. You also need a way of adjusting the tension on the plates that are against the ball to adjust for slippage. The design we have come up with is at http://www.team1322.org/ideas.htm under ball differential. We are going to have to test our design to se if it is strong enough.
Four encoders and a few dozen lines of code are a lot lighter and cheaper than four sets of helical gears.
Especially with our new processor, there should be no problems keeping up with all the data.
We have some helical gears from 2004 but if the cost is too high we may have to change the set up. It would be nice to keep the space though.
And what was your experience with it?
i like this design a lot. Its very intuitive.