View Full Version : Holonomic + gyro/PID
I've been doing some research on holonomic drivetrains, and understand the physics behind it. I'm assuming that, of course, error will begin to mount up, which requires some additional programming to overcome.
I've heard people say they use a gyro and a PID loop, but I'm confused as to how the gyro is implemented. And, even if the gyro is used to control the angle, how can you control the velocity? Doesn't the gyro itself rack up some error over time?
I'd appreciate any advice and any good links. Thanks!
Usually, when a gyro is implemented, it is used for "field-centric" control. The robot is moved relative to the field, whatever direction it might be facing. This is usually implemented by converting the X/Y inputs from the joystick into a polar coordinate (magnitude and direction), and then add the gyro heading to that direction, then convert the polar coordinate into four motor outputs for either the omni wheels or mecanum wheels.
By itself, an omnidirectional drive has no control loop (or controls the speed of its wheels using P/PID and encoders), but there isn't much error to build up in the drive alone.
Possible sources of gyro error:
IF you boot up while moving, then the gyro accumulator will set the centerpoint to whatever it was when you booted up, and then when you stop moving it will think you are continuously spinning. I do not know if it is possible to set the centerpoint manually.
IF you somehow manage to max out the gyro's output (since it has a 5v or 0v limit), you will loose all of the data above that point. Which means you will be off.
The gyro does have a little bit of running error, which might or might not be negligible during a 2.5 minute match. I have only ever used it during auto, and the error in 15 seconds is negligible.
If you would like to experiment with new drivetrains (especially field-centric driving), I highly suggest that you prototype during the off-season.
Any more questions? feel free to ask.
Jeremy Germita
19-12-2010, 22:43
The gyro is used in allowing the robot to be controlled reletive to the driver(driver-centric) as opposed to the traditional robot-centric mode.
For example, if you push forward on the stick, the robot will move away from you, pulling it back will bring it closer to you.
A PID loop can be used to control this angle more precisely.
Gyros DO drift over time. This is measured by Degrees/minute. Check your model's datasheet for the exact rate.
I recommend you have your program "Zero" out the gyro reading at the beginning of autonomous and teleop(given that the angle should the same at the end of auton). In Arizona last year, our robot was left on during an especially long reset period and our autonomous program behaved strangely, almost incurring a penalty.
Perhaps you could use a complementary filter with an accelerometer and gyro. This will make your angle heading more accurate. Google is your friend.
A PID loop is can also be used to control the velocities of each wheel. You must use an encoder on each wheel.
I would use a gyro to make sure that when you want your robot to go straight, that it goes straight and does not turn. Encoders will help you keep your wheels spinning at the same speed which should keep you going straight but if your wheels have different amounts of traction then the gyro can be used to keep the robot going straight. For velocity you can try an accelerometer or just use the encoders, even though it'd be hard to get a good measurement, again because of traction.
I disagree. There is generally not enough slip to make a difference. I would argue that an accelerometer is an almost useless sensor for FRC robots, since we have access to encoders, which measure much more precisely than accelerometers.
I would actually argue that it is easier for a driver to drive the robot directly (robot-centric) than field-centricly, since 1. it is easier to drive, and 2. once you get used to driving, it is very nice to have direct control of where you want your robot go go.
Just because you have a holonomic drive, that does not mean it must use a gyro and be field-centric.
I've been doing some research on holonomic drivetrains, and understand the physics behind it. I'm assuming that, of course, error will begin to mount up, which requires some additional programming to overcome.
Could you please explain what error you are referring to, which will begin to mount up ?
theprgramerdude
19-12-2010, 23:24
I believe he may be referring to the error in all sensors which may deviate from the actual, true reality, like a gyro reading +/- .01 degrees per second turn when it's in fact stopped. It's the nearly unavoidable stuff in cheap electronic parts.
I believe he may be referring to the error in all sensors which may deviate from the actual, true reality, like a gyro reading +/- .01 degrees per second turn when it's in fact stopped. It's the nearly unavoidable stuff in cheap electronic parts.
Thank you, that's one possible interpretation... but I'd like to hear from the OP if that's what he meant... or if he had something else in mind.
He doesn't mention gyro in the first paragraph where he says he understands the physics but is concerned that "error will begin to mount up".
He mentions gyro in the second paragraph, but says he doesn't know how it is implemented. So I inferred that he wasn't referring to gyro error in the first paragraph.
AustinSchuh
20-12-2010, 00:02
I would argue that an accelerometer is an almost useless sensor for FRC robots, since we have access to encoders, which measure much more precisely than accelerometers.
We've seen wheelspin when accelerating quickly, and the wheels will slip when the robot gets hit hard. Both of those are relatively common in a match, so the encoders will no longer be at the correct position. This doesn't mean that encoders are useless sensors, but that they aren't a magic bullet. A clever algorithm would decide which one is more likely to be right, and use it to correct the other one based on the measured conditions.
We've seen wheelspin when accelerating quickly, and the wheels will slip when the robot gets hit hard. Both of those are relatively common in a match, so the encoders will no longer be at the correct position. This doesn't mean that encoders are useless sensors, but that they aren't a magic bullet. A clever algorithm would decide which one is more likely to be right, and use it to correct the other one based on the measured conditions.
Or, you could use follower wheels with encoders on them.
http://www.chiefdelphi.com/media/photos/32440
http://www.chiefdelphi.com/media/img/211/21129e741345c801f421fe70c9304589_m.jpg
AustinSchuh
20-12-2010, 01:43
Which work best on flat ground. Not a problem in 2009 when the ground was flat, but I wouldn't have been willing to put them on our robot this year.
EricS-Team180
20-12-2010, 09:02
Kris noted the simplest use of a yaw rate sensor and it's easiest implementation: driving straight. We have used this technique on most of our 'bots, holonomic, treaded & wheeled, since 2004. The algorithm is a simple multiplier on the yaw rate detected. We usually determine it empirically, This is added to the motor outputs to create an automatic, opposite spin to the measured yaw rate. When driving straight, the yaw rate is close to zero, so the effect is nil...easy and powerful. Add in a small deadband around zero yaw rate, if it wants to twitch when still. This also helps, if someone is trying push on a corner of your 'bot. Typically we give the driver a button or switch, to turn the effect on and off. We always want the driver to have the final decision on handling.
We've used the gyro for field-centric control, as well. Our results are mixed - a great implementation with our 2004 holonomic 'bot, and a rather disastrous implementation with our swerve drive, last year. Give yourself a lot of time for driver training and robot testing.
Eric
and a rather disastrous implementation with our swerve drive, last year.
What was disastrous about it?
Wow you guys are all really helpful! I think two separate issues are coming up here, mostly due to my ignorance.
1) Driver-centric vs. Robot-centric: It seems that this issue is not related to the type of drive train. For example, by turning the joystick into a polar coordinate, if I push the joystick to (0.5,pi/4), then I could see using a gyro to constantly PID to the angle even without holonomic wheels. Error in this case could be caused by the gyro, which if it mounts up might require the driver to zero the gyro midway through the match.
2) Holonomic vs….well, non-holonomic: Having never tried a holonomic drivetrain, I was wondering if error could mount up naturally. For example, pushing the joystick to (0.5, pi/4) might for some reason not move the robot at precisely this amount due to environmental factors. I was wondering if teams use a gyro or other sensors to deal with this, but maybe this isn’t a significant problem.
I'd appreciate any attempts to help clarify this stuff for me. Thanks :)
2) Holonomic vs….well, non-holonomic: Having never tried a holonomic drivetrain, I was wondering if error could mount up naturally. For example, pushing the joystick to (0.5, pi/4) might for some reason not move the robot at precisely this amount due to environmental factors. I was wondering if teams use a gyro or other sensors to deal with this, but maybe this isn’t a significant problem.
This isn't a holonomic vs non-holonomic question. You could ask the same question (or a similar question) about a simple tank drive: "If I push both joysticks forward by the same amount, will the robot go precisely straight ahead?". The answer is no, and it doesn't matter because the driver adjusts (within reason) the joystick position(s) to get the response he seeks.
The only reason holonomic is different is because it has three degrees of freedom, and it's annoying for the driver if, for example, he's got a Halo-style interface and he has to continuously hold a rotation command in order to keep the robot from rotating while he's busy working the fwd/rev and strafe joystick. That's when gyro feedback or a "calibrate" button on the joystick is nice to have.
Dillon Carey
20-12-2010, 13:58
Which work best on flat ground. Not a problem in 2009 when the ground was flat, but I wouldn't have been willing to put them on our robot this year.
We had a setup very similar to this (http://www.chiefdelphi.com/media/photos/32440) on our 2010 robot. It was only used during autonomous, but it could have been used during the match if we had reason to.
Because of this we used a servo to pick it up during teleop. The only thing that may have worried me a little is going the plywood bump, but the omni wheel seemed to handle it fine.
(the only time we really damaged it was due to people not paying attention when setting the bot on the cart)
Alright, I'm starting to understand. In the case of holonomic, there is usually joystick 1 (fow/rev and strafe), and joystick 2 (rotation). Would it be advisable to use a P/PID function that controls the rate of rotation of the robot? For example, if joystick 2 is at (0,0) but the gyro senses 5deg/sec, make some corrections. No reason to use P/ID on fow/rev and strafe?
Alright, I'm starting to understand. In the case of holonomic, there is usually joystick 1 (fow/rev and strafe), and joystick 2 (rotation).
That is one of four popular ways to do it. It's called Halo-style. See this link (http://www.chiefdelphi.com/forums/showpost.php?p=985901&postcount=23) for 2 other ways. A fourth way is to use a 3-axis joystick: X, Y, and Z (twist).
Would it be advisable to use a P/PID function that controls the rate of rotation of the robot? For example, if joystick 2 is at (0,0) but the gyro senses 5deg/sec, make some corrections.
If your drivetrain is well-designed and balanced, and your wheels are carefully aligned and the mec rollers spin freely, and you use PID to control the 4 wheel speeds, it shouldn't be necessary.
But you can if you want. Here's (http://www.chiefdelphi.com/media/papers/download/2796) one way.
No reason to use P/ID on fow/rev and strafe?
Right. Besides, how are you going to sense fwd/rev and strafe speeds for the PID process variable input? With a couple of idler wheels?
Cool, even if it isn't necessary during driver control, it would likely be for autonomous mode.
Thank you so much!
EricS-Team180
21-12-2010, 08:18
What was disastrous about it?
...insufficient testing to uncover errors in the steering motor's output logic coupled with a bad Cypress board and a hardware issue with our CAN bus. ::ouch:: Using the sensor to determine field orientation angle worked fine. We ditched the Cypress board, fixed the CAN issues and reverted back to robot-oriented control and what you are calling a halo-style driving scheme. We just did not have time to untangle the logic.
...insufficient testing to uncover errors in the turning motors' output logic. ::ouch::
Yeah, I was wondering if that's what you meant. I've been thinking about this problem for a while; it has many subtle nuances. For example, if a wheel is going in direction "theta", and the command says "go in direction theta+180", do you turn the wheel or reverse the wheel's rotation? What if the command is theta+175? Do you turn 175 degrees or do you reverse motor direction and turn 5 degrees? What about theta+100 or theta+95? How does the wheel's speed affect these decisions? What about wheel "wind up" (assuming you're not using slip rings), e.g., What if the wheel rotation is limited to +/- N turns? What if the wheel is limited to +/- 180 degrees, or +/- 90 degrees, or whatever... how does this affect the logic and where do you put the "discontinuity" for least impact on the driving? If the commands can change more rapidly than the motors can respond (both the turning motor and the driving motor), then it seems that every control iteration you would need to compare the process variables to the commands to determine the best course of action - your logic must have access to the process variables.
I'm not asking you to answer all those questions (unless you want to, which would be great). Those are just the questions I've been thinking about - if anybody wants to discuss.
I know in 2009, team 1983 Skunkworks used swerve drive. They didn't have continuous-turn potentiometers, and so when they needed to turn past a certain point, they would flip the module 180 degrees and reverse the direction of their drive motors. It worked surprisingly smoothly, but that may be in part due to the low coefficient of friction.
Here's a drawing of their drive base:
http://www.chiefdelphi.com/media/photos/32444
I know in 2009, team 1983 Skunkworks used swerve drive. They didn't have continuous-turn potentiometers, and so when they needed to turn past a certain point, they would flip the module 180 degrees and reverse the direction of their drive motors. It worked surprisingly smoothly, but that may be in part due to the low coefficient of friction.
Do you know where they positioned the discontinuity?
I'm certainly not recommending this, but suppose for example they located it at the 12 o'clock (straight-ahead) position. I can imagine a lot of weird wheel movement going on when trying to drive straight ahead with small directional changes. So I wonder where's the best place to put it. Perhaps it depends on the game played played.
Well, it was a 7/8ths turn potentiometer, so they definitely had some leeway.
I think they didn't switch it until they had to; instead of switching at 3 and 9, they switched at 5 when turning CW, and 7 when turning CCW.
Hi,
We used a field oriented drive system this year, it definitely made Breakaway SO much easier.
We originally used a compass to read the directions, but quickly realized that there was too much interference around the sensor. We then used a gyro to do it. The WPILib version of holonomic drive is NOT advised, we found many small errors in it, in addition to the fact that the code was labeled as "Experimental". The Error you are referring to is likely the walking of the gyro. We noticed little to no error after only the 2.5 mins of a match, even while crossing the bumps 3-5 times per match. Actually, using a holomonic drive system made this easier.
The field oriented drive system allows us to have many usefull features:
1) Easier control: Anyone can use it...point in a direction, and the bot goes that way!
2) Auto aligning features: Hit a button and line up for the bump automatically, while all you do it point in the direction of the bump.
3) Auto hang aligning: Again, hit a button and drive directly towards the tower; bot will align to it by itself
4) Drive in a direction: We refer to it as "the trigger". While we are driving towards a ball, regardless of if the bot is facing towards the ball, as we drive to it (using the shortest possible distance) the bot will turn in that direction, eliminating the need to stop, turn, then drive.
these are only a couple features that we had. This is a quick video we made while testing: http://www.youtube.com/watch?v=HT3WhTcQvw4 Not all features are noted here
I should also note we used a 3 axis joystick, so there was only one-easy to use-joystick for robot motion control. If you saw us in action at some later competitions (mostly off season) you can see us "having fun" on the field sometimes.
2) Auto aligning features: Hit a button and line up for the bump automatically, while all you do it point in the direction of the bump.
4) Drive in a direction: We refer to it as "the trigger". While we are driving towards a ball, regardless of if the bot is facing towards the ball, as we drive to it (using the shortest possible distance) the bot will turn in that direction, eliminating the need to stop, turn, then drive.
These are very innovative ideas. Nice work!
What type of drivetrain did you use?
Dillon Carey
21-12-2010, 18:34
For example, if a wheel is going in direction "theta", and the command says "go in direction theta+180", do you turn the wheel or reverse the wheel's rotation? What if the command is theta+175? Do you turn 175 degrees or do you reverse motor direction and turn 5 degrees? What about theta+100 or theta+95? How does the wheel's speed affect these decisions? What about wheel "wind up" (assuming you're not using slip rings), e.g., What if the wheel rotation is limited to +/- N turns? What if the wheel is limited to +/- 180 degrees, or +/- 90 degrees, or whatever... how does this affect the logic and where do you put the "discontinuity" for least impact on the driving? If the commands can change more rapidly than the motors can respond (both the turning motor and the driving motor), then it seems that every control iteration you would need to compare the process variables to the commands to determine the best course of action - your logic must have access to the process variables.
I'm not asking you to answer all those questions (unless you want to, which would be great). Those are just the questions I've been thinking about - if anybody wants to discuss.
For our swerve in 2010 we used an Ma3 encoder to track the position of the wheels. In you example of "direction theta+180" we did not reverse the drive motors. we decided against trying to make the drive motors reverse because we didn't want robot to move inconsistently if the driver told the modules to turn faster than they could. We made up for this by gearing the turning motors as fast as we could, although it didn't fix the problem entirely. If we were to do a swerve again we would consider either adding more motors, or using more powerful motors, and gearing up the turning speed even higher.
As for "wrap up", we have never had a problem with this since we use co-axial swerve modules.
AdamHeard
21-12-2010, 18:52
Yeah, I was wondering if that's what you meant. I've been thinking about this problem for a while; it has many subtle nuances. For example, if a wheel is going in direction "theta", and the command says "go in direction theta+180", do you turn the wheel or reverse the wheel's rotation? What if the command is theta+175? Do you turn 175 degrees or do you reverse motor direction and turn 5 degrees? What about theta+100 or theta+95? How does the wheel's speed affect these decisions? What about wheel "wind up" (assuming you're not using slip rings), e.g., What if the wheel rotation is limited to +/- N turns? What if the wheel is limited to +/- 180 degrees, or +/- 90 degrees, or whatever... how does this affect the logic and where do you put the "discontinuity" for least impact on the driving? If the commands can change more rapidly than the motors can respond (both the turning motor and the driving motor), then it seems that every control iteration you would need to compare the process variables to the commands to determine the best course of action - your logic must have access to the process variables.
I'm not asking you to answer all those questions (unless you want to, which would be great). Those are just the questions I've been thinking about - if anybody wants to discuss.
We had a coaxial crab drive which had no limits on rotations (mechanically or with sensors).
If we were moving, we would keep motor direction and go the long way (a full 180 degree turn if necessary). If we were not moving, we would never move more than 90 degrees, and set the motor direction as necessary.
The reasoning behind this was that we wanted to take it easy on the bevel gears.
In you example of "direction theta+180" we did not reverse the drive motors. we decided against trying to make the drive motors reverse because we didn't want robot to move inconsistently if the driver told the modules to turn faster than they could. We made up for this by gearing the turning motors as fast as we could, although it didn't fix the problem entirely. If we were to do a swerve again we would consider either adding more motors, or using more powerful motors, and gearing up the turning speed even higher.
Thanks Dillon. I need to ask a question to make sure I am properly understanding what you said. Consider this scenario:
- robot is slowly moving straight forward
- driver pulls joystick straight back (because he wants robot to stop and back up)
In the above scenario, are you saying your logic would not just reverse the motors to back up, but rather would turn the wheels 180 degrees?
Dillon Carey
21-12-2010, 21:06
Thanks Dillon. I need to ask a question to make sure I am properly understanding what you said. Consider this scenario:
- robot is slowly moving straight forward
- driver pulls joystick straight back (because he wants robot to stop and back up)
In the above scenario, are you saying your logic would not just reverse the motors to back up, but rather would turn the wheels 180 degrees?
Yes. The wheels would turn 180 degrees.
We did however have another mode that turned the wheels 90 degrees from forward and used only the x values from the joystick to determine drive direction.
This mode was made for the sole purpose of playing defense on 469. It would allow us to strafe back and forth as quickly as possible while keeping our accumulator pointed toward our side of the field.
Although it was developed for only that, it ended up being used more often than the "normal" swerve code.
4) Drive in a direction: We refer to it as "the trigger". While we are driving towards a ball, regardless of if the bot is facing towards the ball, as we drive to it (using the shortest possible distance) the bot will turn in that direction, eliminating the need to stop, turn, then drive.
I'm curious as to the theory of how this is accomplished. For example, we've done the same thing without holonomic wheels (called it 'Vector Drive'). However, this was accomplished using "skid" (speeding up one side of the robot, slowing down another). Is there a different principle involved for holonomic?
I'm curious as to the theory of how this is accomplished. For example, we've done the same thing without holonomic wheels (called it 'Vector Drive'). However, this was accomplished using "skid" (speeding up one side of the robot, slowing down another). Is there a different principle involved for holonomic?
A mecanum, or a full-swerve drive*, can rotate as it is translating. If you have field-oriented control, you can easily maintain a fixed heading as you rotate. The coordinate translation (http://www.chiefdelphi.com/forums/showpost.php?p=978072&postcount=25) keeps the robot going in the same direction while it is rotating. It's a beautiful thing to see - looks like an ice-skater.
So, as the robot is heading toward the target, it simultaneously rotates until its yaw angle is aligned with the heading angle.
*i.e. 4 independently controlled wheels
A mecanum, or a full-swerve drive*, can rotate as it is translating. If you have field-oriented control, you can easily maintain a fixed heading as you rotate. The coordinate translation (http://www.chiefdelphi.com/forums/showpost.php?p=978072&postcount=25) keeps the robot going in the same direction while it is rotating. It's a beautiful thing to see - looks like an ice-skater.
So, as the robot is heading toward the target, it simultaneously rotates until its yaw angle is aligned with the heading angle.
*i.e. 4 independently controlled wheels
Yes, by simply doing the normal field controls, and adding the turning code (increase one side's speed, decrease another's) you have a beautiful turning and driving bot.
Its important to remember, that in mechanum, each wheel operates individually, and can put its vectors in any of the 45 degree directions at a time.
Oh, and when using the trigger in an open area, it acts like a car the way it drives...no matter what direction it is driving in, the bot it facing frontwards!
EricS-Team180
22-12-2010, 09:36
Yeah, I was wondering if that's what you meant. ...
We used AnyMark swerves and had about 330deg of rotation before we would get wire wind-up and pull the connectors apart. So we calculated a "keepout" zone based on whether the wheels were commanded forward or reverse. If your current steering request put you in the keepout zone, then flip the wheel and reverse the wheel direction. We used a -180 < 0 < 180 compass for the steering calculations.
Hurdle #1 was getting the angle bookkeeping right.
However, this could produce a "shopping cart" shuck in the steering, as we tried to also use a field-centric stick, and the driver commanded forward and reverse near the keepout.
I finally concluded that you need to track the last pass steering command and bookkeep a 180deg reverse direction +/- a ...say...10deg band. If your current steering request put you in that band, then what you really wanted to do was reverse wheel direction. Then you could compare this new commanded steering angle and wheel direction to your keepout.
I never got to try this. After the Florida Regional, we reverted to robot-oriented sticks and finished the season with them.
We used AnyMark swerves and had about 330deg of rotation before we would get wire wind-up and pull the connectors apart. So we calculated a "keepout" zone based on whether the wheels were commanded forward or reverse. If your current steering request put you in the keepout zone, then flip the wheel and reverse the wheel direction. We used a -180 < 0 < 180 compass for the steering calculations.
Hurdle #1 was getting the angle bookkeeping right.
However, this could produce a "shopping cart" shuck in the steering, as we tried to also use a field-centric stick, and the driver commanded forward and reverse near the keepout.
I finally concluded that you need to track the last pass steering command and bookkeep a 180deg reverse direction +/- a ...say...10deg band. If your current steering request put you in that band, then what you really wanted to do was reverse wheel direction. Then you could compare this new commanded steering angle and wheel direction to your keepout.
I never got to try this. After the Florida Regional, we reverted to robot-oriented sticks and finished the season with them.
Thanks for the detailed explanation. What you described above largely parallels the thinking process I went through. I've got scribbled notes and had planned to write it up but haven't had a chance yet.
EricS-Team180
22-12-2010, 10:14
...changing directions a bit...heh...
A field-oriented driving scheme requires that a yaw rate sensor and a steering motor pot or encoder become primary sensors. I've given fault detection and accomodation lip-service over the years, but have never really implemented anything other than a switch that gives the driver tank or skid steering if the sensor feedback goes to heck in a hand-basket. I wonder if any teams out there have had the opportunity to advance FDA at all?
Thanks,
Eric
Dave McLaughlin
23-12-2010, 00:50
Do you know where they positioned the discontinuity?
I'm certainly not recommending this, but suppose for example they located it at the 12 o'clock (straight-ahead) position. I can imagine a lot of weird wheel movement going on when trying to drive straight ahead with small directional changes. So I wonder where's the best place to put it. Perhaps it depends on the game played played.
Seeing as no one else from Team 1983 has replied, I think I will speak up from the shadows as a Skunkworks alum.
We positioned the potentiometers such that the discontinuity was facing toward the rear of the robot as was mentioned by the team member from 3123. The pots we were using had a 20 degree dead band, so, to address the issue of having unlimited mechanical rotations possible but only about 340 degrees of sensing range we implemented the "wheel flip power change" also mentioned by the astutely informed member of 3123.
However, prior to competing in the World Championships that year, out team decided to make a switch to MA3 magnetic absolute encoders. As the driver that year, I can tell you that there was a noticeable change in performance and handling. In addition, I can also say with much certainty that had we been playing on a carpet field, the method we used with the potentiometers would not have yielded any positive success.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.