Hello! Our team has been using tank drive for the last three years or so, but next year we’ll hopefully be switching to Mecanum wheels. I was wondering if it is possible to program a robot so that one joystick controls forward/backward/strafeleft/straferight and another joystick controls rotation. I’ve looked at the classes provided (we’re programming in C++), and I’m not sure what to think of them. I’m pretty sure we’ll need to implement the gyro. Can this be done?
Hopefully I can help you out by giving a simple answer yes it is possible in fact that is exactly how we controlled out robot in 2011 with mecanums. And you don’t need a gyro (though you can if you want)
Now time for what I say every time this comes up on Delphi. I am a huge supporter of nontraditional drive systems (not tankdrive), and am glad that I was able to work with them as a student and continue to work with them as a mentor and in my place of work that being said here are somethings to really think about before making the switch to mecanum.
-
Do you want to regulate 4 CIMS to drive the wheels?
This year with the increase to 6 CIMS, and the addition of the MiniCIMS it was not an issue but if this changes it can mean limits in your designs. -
Do you have the programming support to handle the switch?
Unfortunately this is sometimes over looked but it takes a lot of fine tuning on the programming side to make a great mecanum drive, without it they can be a nightmare. -
Is your robot better at the game for having mecanums?
This may seem weird coming from a member of a team who is on its third straight year using the wheels but not all games is it a good idea to use mecanums or all strategies. This year if your robot was designed as a 30 point climber who played defense for most of the match you wouldn’t want mecanums you would want the power from a tank drive. Another example of previous games where mecanum drives would not have made your robot better would be 2005 or 2002 where the field was either impeded by a lot of obstacles or where pushing power was the real game changer.
What i am trying to get at is the part of your post where you say next year you are switching, don’t assume that till you see next years game.
It’s definitely possible. Your direction and magnitude come from one stick, and the rotation comes from the other.
I’d like to remind people stumbling in here that this is the Programming subforum and not an appropriate place to start a mecanum debate
We did this in 2011, I’ll ask our head programmer from that year to reply in this thread.
See the MecanumDrive_Cartesian() function in the RobotDrive class:
void RobotDrive::MecanumDrive_Cartesian(float x,
float y,
float rotation,
float gyroAngle = 0.0
)
Pass in the X and Y coordinates of one stick, and pass the X coordinate of another stick to serve as the “rotation” rate, and then finally pass in an angle from the gyro to the gyroAngle field to rotate your cartesian x/y inputs relative to your robot’s orientation. That way, pushing “forward” on your x/y joystick will always translate to the direction that your robot absolutely considers true 0 degrees based on your gyro feedback, no matter which direction the robot is actually facing.
You will only need to use the gyro if you want your controls to be “field-oriented,” such that pushing forward on your joystick means the robot always heads directly away from you, no matter which way it is pointing. If you want it to be “robot-oriented,” such that forward on the joystick always means the robot travels in the direction that its front face is pointing, just pass a 0 to the gyroAngle field of the function.
We’ve used mecanum (and then octocanum) for quite a few years now, but this was the first year we decided to add the gyro and try to do some fancy things…
And we got a lot of drift on the gyro, so we ended up disabling it. Any ideas on how to prevent this?
How much drift? Can you quantify it in degrees/time?
Please give specifics on the gyro, how it is mounted, how it is used in the code, how the robot moves, and when the error accumulates.
Greg McKaskle
Our team began using mecanum this year. We found it impossible to use without a gyro. Nearly every time we drove, it careened in an arc. Adding a gyro fixed all problems. And with the rotation aspect, we set a constant value to rotate at with the top left and right buttons on the joystick (about 50%) and it worked like a charm
It was negligible throughout the build season and practice day, but went wonky during our first qualification match, with a drift pushing 5-10 degrees per second, easy.
Kit gyro, mounted to the frame (isolated, of course) near the CM, and we can watch the error accumulate by printing the values even when we strip all gyro-related everything from the code (besides getting the value we’re printing, of course) and have the robot up on blocks so that it can’t turn.
I’m sure you checked for broken wires, but that sort of “drift” is one symptom of the gyro not actually providing a voltage to be measured. That can happen if the gyro output isn’t connected to the analog input, or if the gyro isn’t getting power.
We controlled our mecanums in 2011 and 2012 with a single joystick. It has to have the extra degree of freedom (twist) in addition to the normal x/y capability. I think it was the Attack 3D joy stick.
We also used a gyro in 2011. To deal with gyro drift, we had a gyro reset button and a gyro disable button. To reset, you spun the bot until it faces what ought to be 0 degrees, and the press the button. I think we had to reset once or twice per match…
Not sure why we didn’t have a gyro in 2012, but depending upon driver, it was often disable in 2011 base on driver preference.
Right. We checked for that, and the powered gyro was drifting at that speed.
So it’s really that easy to drive like that? I assume that you must need encoders to ensure that the motors are spinning at exactly the same speed. How would that be done? How about field-centric steering? Is that particularly difficult to program? Like I said, we don’t exactly have any Mecanum wheels to test out with (yet), so this is purely for the sake of learning.
Yes, it’s really easy to drive like that. One of the nice things about mecanum driving is that your robot is controlled just like a first-person shooter! This is the first year we’ve ever used encoders on our drive, and we only have one on a single wheel…
In 2011 we experimented with speed-controlled mecanum wheels. If you can devise a method to tune your wheel speed feedback loop perfectly, then you will probably see better performance than with open-loop voltage control. We also found it necessary to introduce weight gain constants for each wheel, because the weight distribution of our robot affected mecanum control.
Our team’s retrospective analysis of mecanum performance in 2011 is unfortunately more qualitative than it is quantitative – which is to say some of us would say that there was a noticeable improvement in control, whereas others would say that both our tuned and un-tuned mecanum control was relatively imperfect, perhaps because we did not tune well enough.
I forgot to answer your other questions!
I assume that you must need encoders to ensure that the motors are spinning at exactly the same speed. How would that be done?
The state-of-the-art solution would be to implement a PID feedback control loop. What motor controller are you using? Jaguars provide an easy-to-use speed controller, whereby you plug your encoder into your jaguar and set your PID constants in code. There is also a program through which you can quickly update Jaguar PID constants for tuning. With Victors, you must implement your own speed control feedback loop, but this is still made easier by the fact that WPIlib provides us with a plug-and-play PID loop. What programming language are you using? You can see an example implementation here. For more on PID in the FRC world, searching ChiefDelphi would probably yield good results.
How about field-centric steering? Is that particularly difficult to program?
I already answered this in a prior post in this thread. But ask away for further clarification!
I assume you meant “each motor is spinning at the correct speed”.
How about field-centric steering? Is that particularly difficult to program?
That’s what a gyro is for.
The WPILib RoboDrive methods have an input for gyro angle.
/**
* Drive method for Mecanum wheeled robots.
*
* A method for driving with Mecanum wheeled robots. There are 4 wheels
* on the robot, arranged so that the front and back wheels are toed in 45 degrees.
* When looking at the wheels from the top, the roller axles should form an X across the robot.
*
* This is designed to be directly driven by joystick axes.
*
* @param x The speed that the robot should drive in the X direction. -1.0..1.0]
* @param y The speed that the robot should drive in the Y direction.
* This input is inverted to match the forward == -1.0 that joysticks produce. -1.0..1.0]
* @param rotation The rate of rotation for the robot that is completely independent of
* the translation. -1.0..1.0]
* @param gyroAngle The current angle reading from the gyro. Use this to implement field-oriented controls.
*/
public void mecanumDrive_Cartesian(double x, double y, double rotation, double gyroAngle)
any more information on what happened here? I’m hoping to take a look at an issue that was reportedly like what you are describing. We used the gyro in 2011 with no issues, but I’ve never personally worked on it.
To anyone, how does the gyro temp feedback work in the code? (I don’t usually get into the programming so you should talk to me like I’m 6) I’m poking through the java API and didn’t notice temp anywhere in the gyro class. Since the temp is obviously going to a different channel than the gyro, it seems i would need to also set temp up as a separate sensor, but that too i didn’t see in the sensorbase class. ??
Also to add 2 cents on the general mecanum talk: We’ve used mecanum since 2011 and never seen the “forward command equals horrible spin result” described all the time on CD. This is without gyro or encoder feedback. We have never been accused of having really fantastically designed and constructed drivetrains and have never given much (or any) time to weight distribution. This year a test drivebase was made which exhibited something kinda like the “forward command equals spin”, but it was very minor and the driver was able to compensate for it without much trouble. Just looking at it everyone figured the problem was the fact that the electronics board thrown on top had the battery cantilevered outside of the frame. At this point the battery had to be 25-50% of the total weight. :eek: THEN it was discovered that the 8020 frame was assembled incorrectly causing the frame to be warped. :eek: :eek: The combination of the 2 had one wheel taking almost none of weight. And still the driving behavior was not that bad. This leads me to the hypothesis that “forward command equals horrible spin result” behavior reported frequently is almost always caused by incorrect use or poor functionality of the gyro…
No, no additional information. Our driver is nails without it, and we don’t need it for autonomous, so it’s something we plan on investigating further in the off season.