Something to be aware of is that during testing my team found that in order to control the robot at low speeds the motors must be given 40% of maximum voltage (to overcome the robots moment of inertia) and then once the robot is moving the power can lower slightly.
Other issues that could impact fine control is the lag time between control system and robot.
My Team’s robot uses a near identical setup, 8in andymark Mechanums wheels(with black mini wheels), andy mark toughboxes, chains connecting them with andymark wheel tensioners (Fiddly to the extreme to get right, but once right they havent failed through 13+ matches)
all done open loop with no feedback, with jaguars on PWMs, and joystick mapping for fine control
Yes. It could definitely make a difference, depending on other factors of course.
Sorry I don’t have all the information… all of this is from memory.
I understand. But if I may ask without being too much of a pest, would you be willing to ask your lead engineer whether you have encoders on the wheels/gearboxes, and what the other details of your drivetrain are (gear ratio of transmission and tooth count on sprockets if using chain drive).
The holonomic drivebases that we have used (in 2007 and 2008) had similar kinematics to mecanum drives, and we were also dissatisfied (at first) with the controllability of the drive at all speeds, and especially at low speeds.
The following solutions helped to get us under control, and each of the aforementioned robots managed to win a regional:
Make absolutely sure that all wheels are always touching the ground. Ideally, you should have some sort of suspension or at least a non-rigid frame that lets you deal with non-flat carpet.
Use a gyro to help the robot drive straight. We used a proportional-only controller with a feed forward component (meaning we did the holonomic drive kinematics to generate the command, and then added the output of a P controller with “yaw command” as setpoint and gyro rate as input). In general, we found that encoders on the wheels did help, but not nearly as much as the gyro (because of wheel slip, non-level surfaces, etc.) Also, this was back in the IFI era, so CAN speed control was not an option.
Limit each joystick to a maximum of two axes. We tried using a 3 axis (X,Y,Twist) joystick with our holonomic drive, but despite plenty of practice our drivers always seemed to do better with a two stick setup without a twist axis (one stick for X/Y and another that just uses the X axis for twist, or one stick for Y and twist - e.g. tank drive - and the other for strafing). Simply put, we found that too often the driver would accidentally use the twist axis when they didn’t mean to.
Making sure that weight is distributed evenly! The vector math assumes all wheels have equal normal force - if your robot is far off from this assumption, your mileage will vary.
Weight distribution! Yes, I can see where that might be a factor with our design.
Gyro. Interesting. How difficult was this to implement (develop and tune the algorithm)? Were all your gyro implementations on bots with closed-loop wheelspeed? Or did you try it without closed-loop?
Using the gyro was very simple - the algorithm was just:
for each motor
motorCommand = <result of holonomic drive calculations>;
if we are trying to go straight (e.g. yaw command is zero)
motorCommand += Kp * getGyroRate();
end if
Tell motor to go "motorCommand"
end for
As you can see, we didn’t need encoders for this to work well for us. We determined “Kp” by having it read from a potentiometer (the throttle on our joystick) - we played with it until it seemed like there was a good balance between staying straight and being smooth (if Kp is too high, the robot will oscillate wildly). You can also use integral or derivative terms (e.g. PI, PD, or PID) in your controller if you aren’t satisfied that this is fixing things for you.
We put encoders on our drive, but ended up only using them for distance tracking in autonomous mode rather than for velocity control (the gyro by itself was fine and was 4 less things that could fail).
Am I reading the above code correctly: you use the gyro only to make the robot drive straight when so commanded? You don’t use it to control turning or strafing?
I’ll echo Jared341 on all points. We don’t have so much experience with the holonomic platform as they do, but our experience matches exactly with respect to what has to be considered, and our solution ended up remarkably similar.
We understood the importance of keeping uniform load on all wheels at all times and chose the simplest way to do that: use three wheels and keep the CG in the middle. Low-tech, and very effective.
Unless all your drivetrains are perfectly linear the thing won’t drive straight, since the motors are almost always running different speeds, and hence at different spots on the input vs speed curve… In principle, it should be possible to get linearity with individual feedback loops on each wheel, but we weren’t able to make that work. It helped, but it wasn’t sufficient. Possible or not, it isn’t easy. We ended up taking it out entirely for other reasons.
Gyro-based correction, in the other hand, is simple. Our feedback code looks almost exactly like the posted snippet. For driver control, rotation feedback isn’t terribly important except when trying to go straight, since the driver can’t distinguish, for instance, between rotating 47 degrees per second and rotating 52 d/s. But there’s a big difference between driving straight and drifting 5 d/s.
Correct - for those two games (Rack N Roll and Overdrive), pointing our scoring mechanism in a consistent direction was the biggest obstacle to overcome in order to be effective. For strafing or turning, we let things run open loop - with a little practice, the driver is able to compensate for translation errors without even thinking about it.
There is no reason why you couldn’t use the gyro to control your turns, but in general, 0 degrees per second is by far the most important turn rate setpoint. As buchanan pointed out, 47 deg/s and 52 deg/s doesn’t make a lot of difference to a driver, but 0 deg/s and 5 deg/s does.
Team 241 has 8" mecanum, direct drive toughboxes,
voltage control CAN interface
We are considering adding and tuning a speed control based on encoders that are already mounted.
There have been many factors that we have found seem to affect “the lack of fine control of robot movements…”
consistent CIM free run speed - (some CIMs are outliers)
consistent gearbox efficiency -
consistency of mecanum roller turn resistance- keeping these even have been a constant maintenance task for our mechanics
the designed lack of roundness in the 8" mecanums - at very low power, this non-linearity is noticeable.
weight distribution - get 4 scales one for each wheel.
suspension to keep all wheels firmly on the ground (we added this early based on academic research- so we really don’t know how important it is to this game/surface… Are some teams with mecanums but without suspensions satisfied with the handling for the Breakaway arena?)
and probably most important-
+++ giving the driver enough practice time to truly have a chance of learning to predict the behavior of the robot based on the commands sent to it.
we locked in on using a single driver almost exclusively due to the lack of enough practice time available.
Our original optimistic plans were to have speed control (not voltage control) completed at least two week before the robot had to ship so the drivers would have substantial time to learn the machine.
We have portions of a second bot but we did not get to a cloned drivetrain (no mecanums, only 2 CIMs on it).
The teams with fields to practice on and have cloned second bots to practice with are strongly advantaged both in getting the control right and more importantly, in training the drivers to play the game well and making the most of the control that they have.
I am bit amazed on how well some drivers have done with so little driving practice especially with new mecanum drive systems.
IMO, the most important control system to tune is the one between the drivers ears…
Can you adjust each motor’s signal based on the ratio of normal forces? That is, if you know the percentages of robot weight borne by each of the corners, can you compensate for that by varying the command to each? This might also be useful for bump-climbing when the weight distribution on even a perfectly centered CG 'bot gets totally skewed.
We were able to improve driveability to an acceptable level by going back to tank drive (to take advantage of our driver’s previous tank-drive experience) and using one joystick’s X-axis (not used for standard tank drive) for strafe. We developed an algorithm to encode the 3 joystick commands (leftY rightY rightX) into commands for forward/reverse, turn, and strafe, which could be tuned independently (see link above). With a bit of tuning, it behaves just like the familiar tank drive, except it has the ability to strafe by using the joystick X-axis when necessary.
This would work in principle, but because of the dynamics of how a robot moves (e.g. the weight gets shifted towards the rear wheels when accelerating), you would need a very fast strain gauge or other type of force sensor to detect how these quantities vary over time. I’m not sure how much this would help in practice.
As long as each wheel has enough normal force to provide enough friction so that it is not slipping, you want the same command applied to each wheel. The torque on each wheel gets transferred from the wheel to the ground, regardless of the normal force on the wheel, as long as the wheel is not slipping.
If a lightly loaded wheel is being given a command higher than the friction provided by the normal force on that wheel can support, and the wheel starts slipping, then what are your options? If you reduce the command to that wheel without reducing commands to the other wheels you will mess up the behavior of the bot (we’re talking about a mecanum bot here). If you don’t do anything, and let the one wheel slip, that will also mess up the behavior of the bot. Bottom line: you must have enough normal force on each wheel at all times in order for mecanum behavior not to be affected. That’s why suspensions are used on mecanum bots: to distribute the normal load on each wheel more evenly.
As I said before, 868 is using mecanum wheels with no wheel feedback.
We are using 6" wheels. We’ve also geared our robot down significantly, I doubt our max speed is faster than 6 feet per second. This is probably why our robot is so controlled.
Sorry I couldn’t help much; best of luck at your competitions.
