Our programming team was discussing things we should do, and we were on the topic of better Drive, as the Drivetrain has just finished telling us what they were making. Thinking about how we had lost our best driver last year (senior), I thought of a Semi-Omni-Arcade Drive (SOAD) since we were not going to be using swerve/crab, mechanum,or omniwheels. You point the joystick in a direction, and the robot (using gyro or the like) then turns and goes in that direction.
Is there anyone who has done something similar, and if so, how did you do it?
There have been teams that have done something related, in that when using an omnidirectional drive they had the strafing be independent of robot orientation (and then spin was controlled separately): pushing the joystick in a direction would always make the robot move that direction with respect to the driver station. This sounds like essentially the same task you’re tackling.
The usual approach those teams used is to try to track the robot orientation using a gyro, but since you only get angular velocity from the gyro, you end up with accumulating error in your angular position measurement. Some people have tried using a digital compass, but the usual reported result is that there’s enough ferrous material in the field and the robots (not to mention magnetic fields from the motors) that these don’t work.
Something you might consider instead is having a set of buttons that would command the robot to turn predefined angles (90* 180* -90* etc) using the gyro, that way you wouldn’t have the problem of long term gyro drift.
–Ryan
If I’m not mistaken, I believe 1114 did that for their 2008 robot.
If I’m correct I would say try to contact them, because it obviously worked out pretty well for them. 
EDIT: I thought I had seen their '08 code, but it was their '07 code that I was thinking of.
Regardless, I don’t think that 1114 drove in this manner in 2008.
what would be the average gyro drift for a 2 minute match?
Next meeting we are going to test a basic form of this. I wrote up a basic drive:
(In Telop, gy is a gyro, drive is a RobotDrive, stick is a Joystick)
double offset=0;
double offset=0;
while (IsOperatorControl())
{
//(1+cos(pi*x))/2; speed function
//-xx+2x; turn function, graph these at http://www.walterzorn.com/grapher/grapher_e.htm
GetWatchdog().Feed();
float speed=0;
float turn=0;
if (stick.GetX()!=0&&stick.GetY()!=0)//UN Preliminary check for are we moving. this might be unnesecary?
{
//get the diff in the gyro and joystick, making sure no overflow occurs, and normalizing to 0 to 359
offset=((int)((int)(stick.GetDirectionDegrees()-(((int)(gy.GetAngle()*360))%360))+360)%360);
//Detect the location, and change speed/turn multipliers
switch ((int)(offset/90))
{
case 0: //top right
speed=1;
turn=1;
break;
case 1: //bottom right
speed=-1;
turn=1;
break;
case 2: //bottom left
speed=-1;
turn=-1;
break;
case 3: //top left
speed=1;
turn=-1;
break;
default: //should never occur, print error?
speed=1;
turn=1;
break;
}
if (offset>180)//start folding into 90 range
{
offset=fabs(offset-360);//escape greedy %
}
//bring into normalized values in 0-90 then 0-1
offset=((int)offset%90)/90;
speed*=((1+cos(Pi*offset))/2)*stick.GetMagnitude();//multiply turn (switch from above) times function, times speed
turn*=(-(offset*offset)+(2*offset))*offset;//multiply turn (switch from above) times function, times dir
}
drive.ArcadeDrive(speed,turn,false);//DRIVE!
Wait(0.01); // wait for a motor update time (using victors)
}
There is not a simple answer to this. It depends on:
- Whether you at any point saturate your sensor (turn faster than it can detect).
- The sampling frequency.
- The frequency profile of the turns your robot is making.
- How well you’ve calibrated the gyro.
- The gyro’s own thermomechanical noise properties.
- 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).
Yikes! A reset functionality would be essential!
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.
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?
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.
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…
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.
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?
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
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…
The robot was on blocks, not moving (visibly), all 5 modules were plugged in, and the wire went from the crio away from the cims, turning at about .2-.4
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.
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
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.