Re: Holonomic + gyro/PID
 

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)

Re: Holonomic + gyro/PID
 

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?

Re: Holonomic + gyro/PID
 

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

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.

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?

Re: Holonomic + gyro/PID
 

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

Thank you so much!

Re: Holonomic + gyro/PID
 

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

Re: Holonomic + gyro/PID
 

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.

Re: Holonomic + gyro/PID
 

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

Re: Holonomic + gyro/PID
 

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.

Re: Holonomic + gyro/PID
 

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.

Re: Holonomic + gyro/PID
 

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.

Re: Holonomic + gyro/PID
 

These are very innovative ideas. Nice work!

What type of drivetrain did you use?

Re: Holonomic + gyro/PID
 

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.

Re: Holonomic + gyro/PID
 

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.

Re: Holonomic + gyro/PID
 

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?

Re: Holonomic + gyro/PID
 

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.