Semi-Omni-Arcade Drive

[Jared Russell]

Originally Posted by byteit101

what would be the average gyro drift for a 2 minute match?

There is not a simple answer to this. It depends on:

1) Whether you at any point saturate your sensor (turn faster than it can detect).
2) The sampling frequency.
3) The frequency profile of the turns your robot is making.
4) How well you've calibrated the gyro.
5) The gyro's own thermomechanical noise properties.
6) Any filtering that you do.

In other words, a gyro that is sitting still for 2 minutes may not drift that much, but one that is on a "twitchy" robot slamming into things for 2 minutes may drift by quite a bit (I have seen ours drift > 180 degrees in match).

[byteit101]

Originally Posted by Jared341

(I have seen ours drift > 180 degrees in match).

Yikes! A reset functionality would be essential!

[buchanan]

I worked with #1988 doing this two years ago. It's a great concept in that it doesn't require drivers to mentally put themselves "in the robot" to operate the controls. People are amazingly good at this, but it's a coordinate system transform that consumes a fair amount of the brain's "cpu cycles". Our experience was IMO sufficient to validate the concept but the real-life results were severely limited by several factors.

The biggest of these was dealing with the practical constraints of the robot drive system. We used a diamond configuration with differentially steered drive wheels on the side and undriven (slightly raised) omni wheels front and back for balance. The robot was relatively small and essentially round. Though we tried to optimize for manuverability (spin in place, etc) this sort of drive (as do most) requires that the body of the robot be rotated in order to change direction. You don't want to stop to make small course corrections, but you have to stop (or very nearly so) to make large ones. So making it work without slowing down too much means some fairly sophisticated balancing of deceleration/rotation/acceleration rules.

In practical tems the hardest part of this turned out to be dealing with rotational inertia/momentum issues. Going, for example, from high speed at 0 degrees to high speed at 90 degrees means stopping (or almost), rotating exactly the required amount, and taking off again, all as quickly as possible. Linear deceleration/acceleration are not to hard to get right, but making a quick rotation to exactly the right heading without overshoot, undershoot, or time-consuming fine adjustment is not so easy: you have to account for stuff like polar moment of inertia, drivetrain backlash, etc. All possible, but not trivial. We got it working reasonably well on our practice robot, but when the real hardware was done (night before ship, natch) enough things were different that the tuning didn't work well. We didn't have time to readjust the software and the robot turned out to be troublesome in competion.

We used a gyro to track position, and gyro drift was not a big problem. We did relatively straightforward smoothing/averaging and got a system that would stay within a few degrees if you spun the robot through several rotations and back, more than you'd likely ever do in a match. There's also a simple and effective low-tech way to handle drift if it does happen: if you find that "straight downfield" is really going a few degrees to the left, just grab the base of the joystick and rotate it a bit to the right. We replaced the handle on the stick with a straight round handle to keep this from bothering the driver.

My takeaways from the experience were that 1) it's a killer concept if effectively executed 2) it's really hard to effectively execute on a robot without some kind of omnidirectional drive. I want to try this again sometime on a holonomic drive robot, but wouldn't particularly recommend it on more conventional platform.

[Chris is me]

This seems "cool" and all, but is it that much more intuitive over a standard arcade or tank drive to warrant so much time being spent coding and debugging such a control algorithm?

[virtuald]

We did it last year with a swerve drive. It works reasonably well. Did not have any problems with gyro drift, it was mostly irrelevant.

Implementation for an omnidrive robot is pretty trivial, its just a little bit of trig. Our code release (see http://www.virtualroadside.com/FRC/) for last year has an implementation by one of our students, he called it 'CompassDrive'. He implemented it for a 2-motor prototype also, and that was a little bit more involved due to trying to correct for drift and such.

What we found is that some people like it, and some people don't. So just make sure you implement both methods of control and see which one works best for your drivers.

[thefro526]

Originally Posted by Chris is me

This seems "cool" and all, but is it that much more intuitive over a standard arcade or tank drive to warrant so much time being spent coding and debugging such a control algorithm?

Chris, I worked with a local team back in 2007 on a similar concept and found that it's an excellent system to have once it's working properly, because it lets less experienced drivers pick up the controls and drive more effectively because they don't have to think as much. At the same time, I didn't like how the system felt, mainly because it was arcade, but also because I felt like there was a layer of sorts between me and the robot.

I personally feel that such a system is only worth spending time on if you have the programming resources though. If your programming resources aren't the greatest then you're time may be better spent elsewhere....

[Adam.garcia]

Yes, team 1388, Eagle Robotics used a gyro for their steering mechanism. I was so impressed as to how it worked. They had a bike tire, with pegs on each side to show the concept.

[Jared Russell]

Originally Posted by Adam.garcia

Yes, team 1388, Eagle Robotics used a gyro for their steering mechanism. I was so impressed as to how it worked. They had a bike tire, with pegs on each side to show the concept.

This is an active gyroscope with a rotating mass. The original poster was referring to a MEMS sensing gyroscope.

But yes, Eagles Robotics' gyro system was very cool.

[byteit101]

Figured out our problem, we thought the gyro was using 0-1, so we were multiplying the results by 360. actual drift was only 0.01 degrees a second.
We also had driver testing, and decided to not use this drive system. They liked Twist joystick Arcade better

[buchanan]

In "real life" I do a lot of work in human-hardware interaction and measuring effectiveness of different ways of doing things. Without reading too much into it with respect to the particular merits of one control paradigm over another, consider some general thoughts:

What seems (or what they say is) easier or more intuitive to people isn't necessarily. When you want to evaluate the effectiveness of alternatives, measure their actual performance on tasks similar to the ones you care about. "Intuitive" often is used simply as a synonym for "familiar", and people with hard-won skills in a difficult task are prone to describing what they do as "easy".

Subjective evaluations like these are notoriously untrustworthy. If you want to find out what works best, measure how well things work. If you want to give people what they like, ask them what they like. Be careful about confusing the two.

[Greg McKaskle]

If you want to give people what they like, ask them what they like. Be careful about confusing the two.

And then give them feedback in the form of a side-by-side test, as blind as can be -- placebo effect doesn't only affect drug tests. Sometimes it takes a skill test and measured data to convince someone of their own performance numbers.

Greg McKaskle

[virtuald]

Originally Posted by byteit101

Yikes! A reset functionality would be essential!

Yes, having the ability to reset is definitely a good thing to have.

The one thing to keep in mind too is you need a way to indicate to the robot its starting position relative to the field (and it should be on the robot so it can read it during autonomous mode). Otherwise when your driver starts trying to drive it he'll get confused *really* fast. We had that happen once when someone didn't set the switches correctly...

[Delian]

Our team tried this drive last year and then tested our drivers on an obstacle course filled with Orbit balls and goals. We found that it was far more intuitive to leave out the gyro-relative code. Most drivers found it easier to "throw" their orientation to them being on the robot, rather than relying on a gyro.

[byteit101]

We tested it out last night, and the 2010 KOP Gyro (and Accel) drifts about 1.5-2 degrees a second, ever increasing.
our sensitivity is set to gyro->SetSensitivity(0.007);
Is everyone experiencing this? if so, how do you fix it?

[Greg McKaskle]

If that is with the robot standing still, that sounds too high. I'd suggest repeating the test and make sure that the robot isn't moved while being calibrated, and make sure the modules are plugged in when the cRIO is turned on, and make sure that your wires aren't picking up noise from motors and such.

Greg McKaskle