Omni-wheels and driver-centric drive

[efoote868]

Question. Have any teams successfully made and coded a robot that drove in relation to the driver? (i.e. driver pushes joy to left, robot goes to the driver's left, instead of left in relation to itself)?

The programming guys on our team this year wants our robot to do that, so right now we're trying to figure out how to do that.

another question:
How difficult was it to program, and what sensors did you use?
Can I see your source code ?

[Astronouth7303]

We have not done this, I know of teams that have.

67 (2005), 190 (2005), and a few others have done full-joystick holonomic drives with turning.

The thing you need is a gyro and a lot of trig. Do a lot of theory before-hand and try to simplify it as much as possible.

Do lots of testing. A co-processor may not be out of the question for this.

[edit]I believe both 67 and 190 (I know 190) used mecanum wheels, which are slightly different than omni-wheels.[/edit]

[AdamHeard]

If you have sort of drive base that can be driven by a vector input it is relatively easy.

Take the vector output from the joystick, rotate it based on your onboard gyro, and then apply it to your wheels.

This requires knowledge of a holomonic drive platform beforehand though.

[Andrew Blair]

Originally Posted by Astronouth7303

We have not done this, I know of teams that have.

67 (2005), 190 (2005), and a few others have done full-joystick holonomic drives with turning.

The thing you need is a gyro and a lot of trig. Do a lot of theory before-hand and try to simplify it as much as possible.

Do lots of testing. A co-processor may not be out of the question for this.

[edit]I believe both 67 and 190 (I know 190) used mecanum wheels, which are slightly different than omni-wheels.[/edit]

67 has actually never used mechanum that I know of, but they did build a crab in 2005. Not sure if that was driver-centric, but I do know that they almost filled all the code space with drive code, so I would imagine it was...

I would think that you'd run into problems with drift after awhile, but not sure if it would be < 3 minutes.

[seanwitte]

Read this entire thread: http://www.chiefdelphi.com/forums/sh...5&page=1&pp=15

[efoote868]

How effective would it be using 3 or 4 non-powered omni wheels with optical encoders on them as directional feedback, instead of using a gyro? Would that be more precise (unless theres a ramp of course)?

[AdamHeard]

Originally Posted by efoote868

How effective would it be using 3 or 4 non-powered omni wheels with optical encoders on them as directional feedback, instead of using a gyro? Would that be more precise (unless theres a ramp of course)?

For angle a gyro would be most accurate. For more consistent drive encoders would be nice, but are not necessary for the effect that is desired.

However, a gyro to keep a constant front and encoders to maintain even speeds would result in a very nice and friendly base to the driver.

EDIT: Hmm... I didn't see where you said nonpowered... I'm not sure how well that works for angles, I bet it works well for distance/ location but I doubt it would give more precise angle readings than a gyro.

[Eko]

Team 868 toyed with this last year, and our experience was mixed.

We used the mecanum wheel system, which allowed for arbitrary translational vectors with arbitrary rotation vectors to describe the movement. Adding the yaw rate gyro offset was easy enough, but the gyro could only report angular velocity values up to a certain speed, something like 80 degrees per second. This was not a valid option for us, as our robot could spin around almost one full revolution per second. That aside however, the code for it was very simple. It turned out to only require a minimum of trigonometry as well, as a lot of the trigonometry falls away when you realize the relationships between the various pairs of wheels. Unfortunately, I don't have the code at hand right now, but I'm sure if you sent an email or PM to one the Team 868'ers on the forum, they could get this year's programmers to dig it up for you.

~Kyle

[AdamHeard]

Originally Posted by Eko

Team 868 toyed with this last year, and our experience was mixed.

We used the mecanum wheel system, which allowed for arbitrary translational vectors with arbitrary rotation vectors to describe the movement. Adding the yaw rate gyro offset was easy enough, but the gyro could only report angular velocity values up to a certain speed, something like 80 degrees per second. This was not a valid option for us, as our robot could spin around almost one full revolution per second. That aside however, the code for it was very simple. It turned out to only require a minimum of trigonometry as well, as a lot of the trigonometry falls away when you realize the relationships between the various pairs of wheels. Unfortunately, I don't have the code at hand right now, but I'm sure if you sent an email or PM to one the Team 868'ers on the forum, they could get this year's programmers to dig it up for you.

~Kyle

That's good to hear. That means all you have to do is buy a gyro with a higher angular velocity (i've seen 300 something). Or... I've seen magnetic compasses w/ analog ouputs. Does anyone know how well those work? they could accomplish the same thing probably.

[Andrew Blair]

The magnetic compass could work, but I doubt you could get one with high enough resolution that still wouldn't be affected by that giant mass of electrical components we call a robot. Or maybe you could...

[efoote868]

Originally Posted by Eko

Team 868 toyed with this last year, and our experience was mixed.
....
I don't have the code at hand right now, but I'm sure if you sent an email or PM to one the Team 868'ers on the forum, they could get this year's programmers to dig it up for you.

Yeah, i know that.

thanks for making me look slow, eko . I haven't found the source code from last year, and as you know the laptop with the source is dead.

Any teams other than my own that have done this?