Omni-wheel accuracy

I am currently using Robot C to program with a tetrix kit. We have a base drive train with omniwheels and is setup like so:
/------
| |
| |
------/

I already have the code for telop written but in testing the motors have a big problem with rolling. When the bot goes diagonally, the motors slow to a stop at random (not every time) rather than just stopping. Also, occasionally, when the train is rotated, two motors stop and two motors roll to make it roll about an extra 45 degrees. Note that this occurs with different motors every time. Does anyone have any ideas on how to compensate for this?

Message me if you want to see the code, I don’t want it leaking out everywhere.
Note: this is an FTC robot.

*Lift the bot off the ground and tell us what the wheels do when you command forward, reverse, rotate clockwise, rotate counterclockwise, strafe left, and strafe right.

I would suggest ensuring that you have feedback on each of the wheels. On our 3 wheel omni platform we drove it with and without velocity feedback (RobotC has this built in) and the difference was night and day. http://www.youtube.com/watch?v=qobHqf45SLc is before we put feedback on… but here is the one with feedback. http://www.youtube.com/watch?v=Qwg2cgNTAZE

In both cases, disregard the audio tracks they don’t really add anything…

Can you give me an example line of how to enable the feedback?(Too lazy to go dive around for it) I’m assuming encoders are not needed for this…

Thanks!

If you set the motors to brake instead of coast when your controller axes are within your dead band, that should solve your problem.

I agree that putting encoder feedback on the wheels is nice, but it’s expensive ($56 per encoder), the encoders are touchy to get mounted properly, and it takes extra expertise to figure out how to program them once you have the instruments setup.

I disagree, there is only about 20 lines of code running on that robot in the video and it was all done by our student programmers with only minimal pushing from our mentors for what to search for in the documentation. We also had no problems mounting the encoders, we simply followed the instructions. I will say they are bloody expensive. Encoders were the single biggest expense in that robot.

Encoders ARE needed for this. As for how to enable it http://www.robotc.net/teachingmindstorms/reference/hp_PID.pdf If you’re still struggling with it by Friday I’ll pull our code and get it to you as an example. I know when I told our students that’s what I wanted them to do it took them all of 20 minutes to get it working.

Our team has built 4 wheel omni drives like OP is describing on several occasions, and our experience is that they drive pretty nicely without encoder feedback. Maybe the 3 wheel version is touchier.

Encoders could solve the problem described by the OP. Setting the motors to brake instead of coast can solve it faster and cheaper. Adding encoders has additional benefits such as making the robot drive in a straight line and enabling more accurate autonomous driving.

I like instrument feedback. I just don’t think it’s worth $200 in this case.

How do you set a Tetrix motor to Brake?

I only know how to do it in LabView. The control Tetrix motor VI has a brake option that’s pretty easy to find if you drop it into a piece of code. When I wrote omni drive code, I made a case structure that set all four drive motors to brake when all three drive axes were within a dead band.

Edit: my memory is poor. There is a separate VI provided in the FTC Toolkit called “Stop Motors”. It’s not an option in the run motors VI.

Some friendly advice? This is not the way to ask for help.

I’m not sure whether the 3WD platform is touchier. My gut feeling tells me that it would spin a little easier and would show this problem a little more but I do not have data to back this up. I’m open for suggestions on how to collect this data.

I would disagree that simply placing it in brake mode would fix the core problem of motors moving at different speeds. It may fix the majority of it but for our team it was worth the $150 it cost to actually address the issue and to give us accurate autonomous navigation. It was also worth it to teach the lesson of the importance of feedback systems to my students.

I guess, my suggestion to OP would be to try the cheap and fast solution and if it meets your needs cool if not move on to using feedback.

I completely agree that using encoders is better overall and that it’s a great thing for the students to learn how to do that.

In this specific situation, I don’t think the core problem is best described as “motors are moving at different speeds.” According to the quote below, sometimes the motors are continuing to run after the driver stops telling the robot to drive, while other times the motors stop right away. That problem as described would go away if the motor was told to stop instead of letting it coast.

We’ve had this exact problem with the same style of omni drive, and it drove a whole lot better after we incorporated the “stop motor” command when we weren’t commanding the robot to drive.

No philosophical disagreements here… like I said, I agree that using encoders is better.

Try calibrating the joysticks or adding some joystick deadband. Sometimes, even when the joysticks appear to be centred, they may not be giving an output of 0, which causes the motors to slowly turn. We had this problem in Vex, after linearizing the motor speed controller output, and adding some deadband really helped.

I added a deadband from -10 to 10 on both the X and Y axis and now it is perfect! Now I am trying to figure out configurable speeds with motors via buttons. Ex: Pressing button 1 sets a boolean value to true or false which dictates a variable to be set to 1 or 10 which is used to divide the motor power. However, switching the boolean values is not working. Suggestions?

Great post and advice, thanks! Per my experience last year, encoders have a large amount of unreliability that scares me. We had 2 out of our four 4 just stop working in the middle of our autonomous period that really screwed us over. Because of this I am extremely wary of messing with encoders during tel-op but will definitely be using them for autonomous as the accuracy is needed. I fixed the initial problem by setting the motor power to 0 within a deadband of -10 and 10. Again, thank you all for all of your advice and help.