One completed transmission was weighed and c-channel was calculated. The whole drive system should only weigh about 27 lbs.
What led you to choose this over something like a mechanum setup? Or even a standard 6wd?
Agility, and profile mostly. Notice how the footprint of the drive components is very small and delegated into the corners. leaves almost all of the footprint profile available for anything else. But the main factor is agility. With this design, we can go in any direction, at any time, in any orientation, while spinning. Also instantaneously change both heading and orientation at any time in any other direction/orientation. For example heres a video demonstrating these advantages: https://www.youtube.com/watch?v=irf7pGiCru8 This years system should be an order of magnitude better than what you see in that video.
Your execution and driving of the system is really well done.
thanks though last year it wasn’t as good as we wanted it to be. However that should be remedied this year. This year’s system should be perfect. It should be perfect mechanically, software wise, and driver experience wise since they should have plenty of time to get used to the new updated system. But that video should give a demonstration of why we chose such a system, when properly executed it’s very powerful(in terms of the advantage it gives)
Is this programmed like a mechanum drive train? If you program in java, can you send me your example code? Thanks!
-mcchev
There is no “h” in mecanum.
not at all. the programming is actually a little tricky and requires a sensor to give you an off robot reference like a gyro or compass. We’ve used a compass and that seems to work pretty well but there’s room for improvement so we’re looking into different IMU/AHRS platforms. I also did it in labview but I can explain my approach.
Step 0: robot boots up and takes a heading reading, this will be the “forward” direction for robot
Step1: take the x and y axis values from joystick and convert those into a magnitude and angle
Step2: Add the joystick angle to the robot’s angle(the current minus the start up reference) and an offsets if required. For example one offset for our robot was 45* since that’s how the wheels were mounted from “forward” and another offset depending how you calculated the joystick angle(you may be off by 90* +/- depending how you did the math. Break that back down into x and y components of the triangle and multiply by joystick magnitude to give you the motor values for the two sets of omnis(each set are two parallel wheels, so you have an X value for motors and Y value). For rotation it’s very simply just turning all motor in same direction and we used a second analog stick to rotate. We used a 360 controller so the left stick was direction and speed while the right stick was rotation
What kind of load can this handle? Not pushing power, but how much weight can it move on top of it?
Agility
Is it more agile than a mecanum drive? I can definitely see the weight advantages of omni and the corner setup, but I’m just wondering if and how it’s more maneuverable than a mecanum drive. Can you prove some numbers? Like traverse speed in degrees per second or seconds per 360 degrees, straight (meaning moving parallel to one of the frame pieces) speed, and diagonal (moving at 45 degrees to the frame pieces) speed?
I’ve always thought that:
Mec Straight Speed > Omni Straight speed
Mec Diagonal speed < Omni Diagonal Speed
Mec Strafe Speed = Omni Straight Speed
Mec Straight Speed < Omni Straight speed
Mec Diagonal speed < Omni Diagonal Speed
Mec Strafe Speed < Omni Straight Speed
See this chart.
I’m missing something, with the omni’s at 45* if the wheel diameters are the same and the rpm at the wheel shaft is the same for the both, wouldn’t the mecanum be faster?
No. In the forward direction mecanums will go the same speed as a standard wheel (neglecting parasitic losses due to roller axial free play and carpet stretching which causes the rollers to spin). Omni will go sqrt(2) faster due to the 45 degree angle.
See attachment. The blue arrow indicates how far the omni wheel would travel for one rev if not constrained to move in the forward direction. The red arrow indicates the motion contributed by the (spinning) rollers when the wheel is constrained. The black arrow shows the net motion, which is sqrt(2) greater than the length of the blue arrow.
*
*
Interesting, I had never considered this. Makes sense.
Do mecanums correspondingly have sqrt(2) more torque than an omni setup with the same mechanical advantage? Or are mecanums that much less efficient?
If it’s just a matter of mecanums essentially having more mechanical advantage, then this doesn’t answer the question of one being more agile, as the same characteristics could be got by changing the gear ratio of one or the other. (not a criticism against your answer, just saying there’s more discussion to be had)
Read the statement in blue italic at the bottom of the pink section in the chart linked in post 11 in this thread (but see note1 below).
If it’s just a matter of mecanums essentially having more mechanical advantage, then this doesn’t answer the question of one being more agile…
Correct, but my post was not addressing the “agile” comment.
…as the same characteristics could be got by changing the gear ratio of one or the other.
Theoretically yes (see note1 below). See this document.
note1: The affordable mecs and omnis used by most FRC teams tend to have significant parasitic losses (mainly roller friction and roller axial free play) that affect real-world behavior noticeably (especially on a compliant surface such as carpet). This is especially noticeable for mecs in the strafe direction.
*
*
Ah nevermind the chart didn’t load completely for me. Some things the phone isn’t good for.
Thanks for the clarification