Alright, so basically our robot has 6 wheels, the four corner wheels are omni wheels, and the middle wheels are traction wheels that are connected to motors. In the programming I have it set up to use 2 joysticks on a tank-drive. Now that is all good and well, I like tank drive, but you barely move the joystick and the robot increases speed alot, but from there on the joystick, there is little more acceleration out of the robot. This creates a problem in turning, once it starts turning it doesn’t stop. I am also the driver and this touchiness of the robot is annoying me.
The way I came up with to fix it is to find the function relating the joystick movement to the robot’s speed, and then modify it in the code so that there is a direct correlation of joystick movement to speed. I figured out that:
Robot Movement = 42(Joystick Movement)^(1/5), this is only approximate though. I’m not sure what to do from there though. If anyone can help me out with this, or give me a better way to do it, please help!
Thank you! =)
Maybe you may want switch out one of your sets of omni-wheels for another set of traction wheels. That may make your turning more predictable.
One thing our team is doing that seems to help a ton is using a cubic function: motor = (input - 127)^3/127^2 + 127
The real nice thing about this method is that when the joystick is at either extrema (0 or 255), your motor is at the extrema too… But moving the joystick a little moves the motors even less near the center. For example, plugging in 157 (only 30 ‘ticks’ forward of the center of the joystick) gives you a motor output of something like 130. Basically, you make the robot less responsive to the joystick near the center, but gradually “ramp up” the responsiveness as you move the joystick out.
Mmmm, that’s something like what I’m looking for, the graph of that looks nice. I will have to test that tomorrow, assuming we have school… big snowstorm. Also, I will mention it to my mentor to change two to traction wheels, which two though? Front or back?
One more thing to add… if you’re using the cubic function, make sure all your variable types are longs - 127^3 will overflow an int.
As for which wheels to look into changing, you’ll want that to be the ones that hold the most weight. Also, do you have your wheels offset so the traction wheels in the middle are slightly lower than the ones on either end? You need to do that (and introduce a slight rocking in your robot) to ensure your traction wheels are always on the ground.
Finally, no one’s asked yet if you’re test driving on carpet or not… We use the same wheel setup as you, and it does slide a bit on hard flooring, but on carpet it works just fine!
We have the traction wheels in the middle lowered slightly, and have been testing on carpet. I’ll go back in the code and change things to long, I completely overlooked that fact 
thanks!
are your motors in coast? because that could be a problem for not stopping after turning
Somewhat similar to what was mentioned above but here is what we do…
We have the exact same setup you do (4 omni, two traction), and what we do is have a “deadzone” around the base of the joysticks, and I believe we also do some acceleration in our code (so that when you push the joystick out of the centered 128 position it doesnt start until something like 150, and then actually outputs a slower ramp 150 on the joystick outputs 129 for the motors, 152 might output 130, etc…). If you want to implement this in your code, email me and I can have our programmers send you some code. Im not exactly certain what formulas they use, but thats the basic concept.
This provides for a much smoother drive system, but allows you to take advantage of the power and manueverability of the drivetrain design you have.