while programming the autonomous period with our holonomic robot, we find that it is very difficult to have the robot track straight. a simple feedback loop with encoders don’t seem to work. our code was originally as follows:
set a predetermined value for how far an encoder should travel per period of time, and make sure that value is less than 100% of motor power (i.e. 3 encoder ticks per 4ms)
increase motor power if encoder value is less than desired value, and vice versa.
this doesn’t seem to work no matter how we tweak the numbers, we did see compensation but in limited ways. and also, because of the nature of holonimic drives, any one motor can affect both the translation and rotation of the robot. i was wondering if there is a simple PID code that can be used with holonomic?
note: and it’s also extremely frustrating that robotc for vex does not support floating points.
You may be experiencing an issue with cumulative error. Lets say one motor is a bit faster than the others. Every time you change speeds, the algorithm will need a few encoder samples to correct the error, but your robot will get further off course each time. For instance, if the left wheel takes off a bit quicker than the right wheel, your robot will veer right at startup. If you then synchronize the left/right motors, you will travel in a straight line, but angled a bit left. If you then stop and start again, the error in your heading will grow.
Basically, your algorithm corrects the speed for imbalances, but doesn’t attempt to correct the position error caused by those imbalances. A simple tweak to your algorithm might be to remember how many cycles an encoder is out of balance, and then target a value that is off by the same amount in the other direction (for the same number of cycles). This won’t result in perfect tracking, but it should help reduce accumulated errors in heading angle.
A properly applied PID loop may help, but to make it really work, you’ll need to try and figure out where your robot actually is based on the encoder feedback and have it plot a course to where it wants to be from there. If you just correct each motor individually, you won’t get perfect positional accuracy for your robot. If you consider the whole drive system as a process to be managed by a PID loop, you can get fairly precise positioning.
The processor in the existing Vex microcontroller isn’t really up to doing floating point (at least not quickly). The upcoming new microcontrollers should be much more capable in this respect.
We had a similar problem when building our bot, holonomic does tend to drift slightly off course. What worked well for us is adding weight to make the weight distribution more even (even though you build your bot symmetrically, there are somethings you dont account for like the battery). We used a bevel gear box, 1 inch screws, and a ton of lock plates to match the weight of the battery. It helped a lot, and it gave our driver more control over the direction he decided to go in.
One way to get around the floating point issue is to use fractions… like in your constants for the proportions you may be using, its not perfect – and the more functions you run it through the more error you will get, but it does allow you to get a more accurate number (i.e. if you want pi use something like 355/113) though maybe a different strategy is in order. Using sonar or line following sensors may help (if this is for Clean Sweep).
would having two encoders for a holonomic drive be reliable? we would like to have 4 on the drive but we have a design that require 2 encoders off of the chassis, leaving us with 2 for the drive. we’re holding back on ordering parts as to save money for FRC.
we know which motor is causing the most swerve, if that’s any good. we are planning on putting encoders on two opposite wheels. would that be effective?
Insert a jumper into one of the Analog/digital I/O ports. Rotate a potentiometer to one of several specific angles. Put a rubber band around one of multiple limit switches. Block the light going into one of multiple light sensors. Let the computer pick one randomly based on a timer/counter’s value. Start with a line tracking sensor on or off of a line. Etc.
Actually, with some scouting data and a quick talk with your upcoming alliance partner in advance, you can manually change a variable in your code and get it on your robot before the match. Our jumpers vanished somewhere so that’s what we did at our last competition. We’re waiting for a larger list of parts to accumulate before we order them again.
We’ve found the easiest and most convienent way is to use a potentiometer.
We put tape over the pot and draw lines to make regions for each autonomous mode, then bend an axle 90 degrees and use it as a toggle.
It makes it very easy to change autonomous modes just before turning the robot on, but you have to make sure your drawn lines coincide with the programming.