Holonomic + gyro/PID

[apalrd]

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.

[AustinSchuh]

Originally Posted by apalrd

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.

[biojae]

Originally Posted by AustinSchuh

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

[AustinSchuh]

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]

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

[Ether]

Originally Posted by EricS-Team180

and a rather disastrous implementation with our swerve drive, last year.

What was disastrous about it?

[Jogo]

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

[Ether]

Originally Posted by Jogo

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.

[Jogo]

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?

[Ether]

Originally Posted by Jogo

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 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 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?

[Jogo]

Cool, even if it isn't necessary during driver control, it would likely be for autonomous mode.

Thank you so much!

[EricS-Team180]

Originally Posted by Ether

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. 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.

[Ether]

Originally Posted by EricS-Team180

...insufficient testing to uncover errors in the turning motors' output logic.

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.

[kamocat]

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

[Ether]

Originally Posted by kamocat

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.