I was wondering if it better to have a drive that has each wheel independently motored or to have a drive in which all the wheels are motored together?
If you have more than one motor per side I think it would be a good idea to chain or gear them together. This way, if one or more wheels are off the ground, you will still be able to use all the motor power to drive the remaining wheel(s). I.E. If you have 2 motors for each side, and the robot tips slightly, you will be able to still use all 2 motors for each side to power the wheels, instead of just one.
Does this make sense? I can explain more if it doesn’t.
They each have their own benefits. If you decide to connect each wheel to one motor you can proceed to use mecanum wheels, a huge beneft compared to a regular tank drive. Also, the response time for any input from the controller will be shorter as the distance traveled from the motor to the wheel will probably be less.
But as Jij said, using tank will ensure each side fully uses the powor of two motors even if only one wheel is touching the floor.
Please explain this statement. Connecting a motor directly to a wheel and chaining a motor to a wheel will produce the exact same response time. Unless you’re looking at slippage, of which there is usually none in a high strength chain (and usually none in regular chain as well if you’re using it correctly), or the stretching of the plastic (which is pretty much immeasurable by our standards), then there is no delay between the motor moving and the wheel that it is chained to moving.
I did some analysis of drive lag, and found that the lag caused by acceleration (getting the vehicle up to speed) was more significant than anything I tested.
I added some linear drive ramping, and found that with a 5-cycle time constant (125ms to go from 0 to 127), I was significantly reducing the high-current spike on acceleration but not really changing the actual acceleration time by a noticeable amount. The forward-reverse slams, though, were slightly noticeable at a 250ms rise time, but that was OK.
To the OP, it is usually better to chain all wheels on a side together, as they will all share power in the event that one is lifted or slips.
I chained my wheels to a few shafts in the middle of the robot, driven by the 3 drive motors (per side) and geared to each other. This allowed me to have a final stage of chain reduction (12:6 up, in my case), something direct-driving does not allow.
As to the “huge” advantages to going mecanum, I disagree:
The option to use mecanum wheels should be driven by strategic analysis of advantages and disadvantages. The need to go sideways is almost always overestimated in vex design, especially if there isn’t a good driver and HMI (Human Machine Interface) to handle it. I’ve driven/built many robots with skid-steer drivetrains, two with slide drives, and one crab drive (not all in VRC). Of all of them, only one of the slide drives had nice strafe translation, and only with a certain HMI, and it only performed well with a certain driver (who plays many videogames). The HMI we ended up with was what our driver called a “Doom Drive” (It’s like Halo but better), which combined our Halo drive on the left Y and right X with a slide control on left X, for standard videogame controls.
Again on mecanum and holonomic motion, the VRC 33 teams built a total of 3 robots this year: 33A,33B,33C. 33A had a 5-wheel slide drive. The chassis that 33A used was also used in a local competition, OCCRA (non-VRC). The OCCRA driver (the one in the last paragraph) was able to correctly handle the slide drive while facing himself, which is a very hard skill to master, and scored many points. The VRC driver wasn’t as good, and never really mastered sliding while facing herself.
Skid steer drivers never have to master skills of strafing while facing themself, as they only turn and drive. With some of the HMI’s we’ve been working on (Cheesy and Halo drives), it’s really easy to drive, and all of the new drivers we’ve been training have loved it. The classic tank drive isn’t quite as easy, but it’s still a lot better than all of the holonomic HMI’s we’ve worked with, because of the strafing problem.
In addition, a mecanum inherits all of the downsides of a four wheel skid steer that isn’t chained together, except all of the issues are more dramatic. When one wheel on a mecanum is lifed, then some of the force vectors stop canceling, and suddenly the robot moves at a 45 degree angle.
So, the “huge” advantages of mecanum need to be analyzed more closely.
This is a great point for all teams to remember, and not just for the drive train. Make sure your design decisions are founded on how you want to play the game, not the other way around.
Being able to handle driving and turning in any orientation is not unique to holonomic/mecanum drives. I’ve mentored FRC and VRC drive teams for several years and found this usually comes down to good innate spatial awareness. It can be taught/learned, but takes a lot of practice.
My age may show hear, but what are Cheesy and Halo drives? Realize the last FPS video games I played were Wolfenstein 3D and DOOM when they were originally released nearly 2 decades ago.
This year one of my teams built their first holonomic drive, using the left joystick for x,y motion and the right joystick for rotation. To try to alleviate some of the orientation issues mentioned above, they implemented a driver-oriented control system. With the addition of a gyro and some programming the robot always move in the same direction regardless of its rotation. Moving the joystick up always causes the robot to move away from the driver and moving the joystick left causes the robot to more to the drivers left, etc. This has been very successful and would ease the learning curve for inexperienced drivers.
The effect of one wheel being raised is not nearly as bad as I had expected. I saw this quite a bit in the FRC Breakaway game a couple years ago when mecanum drives went over the hump. I was surprised how well they handled it.
I agree that the benefits of mecanum drives are being somewhat overstated, but like any other decision each team should weigh the pros and cons and then make a deliberate informed decision.
I like reasoning for decisions. A lot of things I’ve seen on the Vex forum seem to indicate that many decisions are trial and error, without a lot of thought before doing it.
We ran a similar drive style (left stick = translation, right stick = rotation) and that seemed to be the best for us. It wasn’t that hard to drive, but everyone who used it would always strafe the wrong way or stop before strafing when the robot wasn’t facing away from themself. We had one driver pick up the skills much faster, probably because he plays more videogames than the other holonomic drivers. It took the other drivers a very long time to pick that up. I am very aware of the skills that driving requires, and only tried to briefly address them in my post.
The Cheesy and Halo are essentially improved arcade algorithms (initially based on FRC 254’s Cheesy Drive). Instead of just mixing the two inputs (Throttle and Wheel), they multiply the rotational power by the forward speed and a gain, with logic to handle 0 throttle requests (“Quick Turn”), so the steering seems correct at varying speeds (to the driver). Due to the Cheesy Poof’s original use of a throttle stick and steering wheel, the software traditionally refers to the two inputs as “Throttle” and “Wheel”. Because Cheesy and Halo algorithms are for skid-steer drivetrains, our holonomic drives which use the Halo algorithm for the forward wheels and the left X for the slide wheel was coined to be a “Doom” drive by our driver.
In all of our analysis of FRC and VRC games, we’ve always looked at slide and swerve drives, and always talked ourselves out of it very quickly. The two years we talked ourselves into swerve, we hated it - one year we went to the effort of removing the swerve drive at our second regional to save weight, and replacing it with straight drive pods. I’ve seen many FRC teams try mecanums and fail, because they think the ability to strafe is so important for anti-defense or scoring that they forget or brush off all of the downsides it comes with. I hope that, if any team chooses to use holonomic drives, it is for the right reasons, not for the coolness factor.
This is caused because usually, though not always, when mounting wheels with chain, the motor is placed farther from the wheel, therefore the input placed on the motor has to overcome all of the distance until it can reach the wheel. When the central sprocket moved it tugs on the next link, which subsequently tugs on the next link and so on until it can lands on the sprocket for the wheel.
This detail only affects the acceleration of the robot and does not seem to relate to top speed and even in acceleration I believe this problem can be solved. Another minor detail to watch out for is for proper tensioning of the chain, if the chain is too loose it will allow movement of a wheel after you stop movement. A scene where you accelerate and after letting go of the forward input, the wheel will continue to spin until the chain no longer has links that can pass through the wheels sprocket.
As for the ability of using all of the motor’s strength for a wheel that has not been lifted in the air, I cannot imagine too many scenarios where a well balanced robot should take advantage of this. I can, however see it’s benefit when the lifting of any mechanism changes the center of gravity for the robot and then the back wheels (or any other wheels for that matter) receive more weight directly upon them.
In the end, I believe it’s more beneficial to use chain linked wheels on each side.
What distance does the motor have to overcome? If two sprockets are connected by a chain with the proper tension, as soon as I start to move one sprocket, the other one starts to move as well. The scenario you put fourth may be true if there is such a large slack in the chain that it would most likely fall off.
at the current config, we have 2 motors for the drive, 1 per side, and a 4 wheel drive, it is a mix of torque and speed, more torque, for the next competition we are going to buy more motors for better drive, but for gateway … gearing wheels together worked really well as long as when you were turning, you reverse the other drive at the same time
I agree with George (Jij), gearing together is better for the reasons he describes.
One thing to be careful of is that if you gear motors directly together, the vibrations and any differences in the motors will mean the motor gears tend to break. To help prevent this, linear filtering can be used to reduce the shock loading on the motors - that is, make it so that the power ramps up more gradually. If you do it right you won’t notice much difference in acceleration while driving but you will not break any gears.
Also, I would NEVER gear together a motor plugged into a 2-wire port and one plugged into a 3-wire port using a motor contoller since the responses are different (see this thread for info). This means that the shock loading on motors will be much greater (and at AURA we had many internal gears break before we realised this was the problem). For example, don’t gear together port 1 and 2, use 2 and 3 and put the port 1 motor on its own somewhere (e.g. intake).
I suppose it all depends on what you’re going for with your drivetrain. Gearing/chaining wheels together wouldn’t work for holonomic drives (except H-drive), but it is a very good thing for traditional tank drives. For Round-Up, we used a 4-motor tank drive with the motors connected directly to the wheels. It worked well enough for our purposes, but it overheated in pushing battles. For Gateway, we used a 4 motor drive with 6 wheels, all geared together, and its performance was much better.
For mecanum drives, there are ways to make sure your wheels don’t lift off the ground. If your weight distribution is good, and you put on a protective skirt to keep objects from going under your wheels, then you should be fine.
The image above is how we have geared our drive system, we have only used 2 (269 motors) it works well … but the only thing that we have to do is when you turn, make sure you reverse the other side as well … to stop it from shaking around too much …
Have you tested this drive base with the amount of weight you are likely to have with a full robot? My guess is that it will stop working well. If you can spare another two motors from anywhere, they would be good additions to your drive, either to give it more power or more speed (it looks to be quite slow right now). Also consider getting some omni wheels, that would stop the shaking.
alrite, thanks, we have some omni-wheels on order at the moment anyway … waiting for them to come … the current config on motors at the mo is 4 on lift, 2 on drive, and 2 on wrist … with 2 spare servos … depending on funds … may get 2 more motors … just depends, but hopefully for wrist, we can use 1 motor and 1 servo for our design (fingers crossed) meaning we only need to buy one more motor
You don’t seem to have any Delrin Blocks on you axles, at least not on the inside. Without them, friction between the axle and your metal frame is going to be a problem. The issue is going to become more prominent as the weight of your robot increases. At least two blocks per axle will greatly reduce friction, increase system efficiency, and take a load off of your motors. You should then be able to do point turns depending on your drive surface and weight. (Turning by only powering one side)
… i know we have a shortage … we are waiting for some more … will be done when we have some more …
I’m not trying to discourage you, just telling you what our team found from making this drive - http://2.bp.blogspot.com/-tsxboVcrdwo/T608J507fjI/AAAAAAAAABo/5lYURYJVeYE/s400/VEXCoastDrive2.jpg
Once we put some weight ontop of it, it didn’t perform nearly as well as we had hoped, and the ability to turn decreased significantly under load. We have now switched to a much more stable and common drive, seen on the robot in this blog post: http://vrc357.blogspot.com/2012/06/new-mechanisms.html
Those aren’t high-traction wheels, they’re the 5" wheels. They’re still not omnis, which explains the turning problem, but they also have a larger diameter, so they apply less torque than 4" wheels.