Chief Delphi - Penalizing mecanum wheeled robots durring alliance selection.

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)

- - Penalizing mecanum wheeled robots durring alliance selection. (http://www.chiefdelphi.com/forums/showthread.php?t=130348)

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by Jared Russell (Post 1398750)

In my experience, a degree or two of position drift per minute is more achievable (as long as you don't spin too fast and stay on a flat and level field).

If you observed drifting of more than 10 degrees per minute and the robot wasn't saturating or shaking the gyro, what would you think? Would that be typical of the FRC gyro, or would that indicate a bad sensor?

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by efoote868 (Post 1398771)

We have not seen any of the recent kit provided gyros net that bad of a drift. I think bullet point #1 in Jared's list is the biggest culprit to gyro drift in a typical FRC match. Competitions are usually held in cold arenas and your robot won't start moving until a minute or two after you turn it on. We map a button on our operator console to reset the gyro calibration, and print out the current integrated angle so the driver can assess if they need to reset it. Ideally this is something we do automatically next year.

Re: Penalizing mecanum wheeled robots durring alliance selection.

One thing I would like to test is driving a field centric drive with a very large gyro drift (say +/-10 degrees).

If the driver can see the robot, I don't think a drift that large will matter (in tele-op). An interesting question would be, "How long can someone drive a field centric drive before performance suffers from gyro drift?"

I'd hypothesize that you wouldn't see a big difference in performance until drift reached ~15 degrees.

Coming back around to my questions, if performance doesn't suffer with 10 degrees of drift, I don't think gyro drift should be a concern preventing teams from using field centric drives.

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by efoote868 (Post 1398775)

One thing I would like to test is driving a field centric drive with a very large gyro drift (say +/-10 degrees).

I tried. Its impossible. Also, its not even the problem of a set drift. Its when it starts to drift several degrees per second. then, when robot not moving (to inbound, shoot, whatever) and you try to drive again you can not tell where is forward.

Once you realize the problem exists things don't get much better. Your robot will start driving in ever shrinking circles when you press forward.

Quote:

Originally Posted by efoote868 (Post 1398775)

If the driver can see the robot, I don't think a drift that large will matter (in tele-op). An interesting question would be, "How long can someone drive a field centric drive before performance suffers from gyro drift?"

2 degrees fixed is noticeable. 10 feels very weird. 2 degrees per second is enough to make a robot impossible to drive.

Quote:

Originally Posted by efoote868 (Post 1398775)

Coming back around to my questions, if performance doesn't suffer with 10 degrees of drift, I don't think gyro drift should be a concern preventing teams from using field-centric drives.

The main reason I think field-centric control it is not used more is fear of a delicate piece electronics being trusted to control a drive train. In addition, robot-centric is not that hard to understand.

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by Max Boord (Post 1398799)

Gyro drift occurs when the gyro has very small errors in the rotation value it is reading (turning at 1 degree / second versus reading 1.001 degree / second).

When you integrate the error of rotation, you get an error in position.

What was discussed was that after the gyro runs for sixty seconds, the cumulative error is about 2-3 degrees, not 120 to 180 degrees.

Yes, a field centric robot that is off by 2-3 degrees per second is going to be difficult to drive, but I'd say something is fundamentally wrong with the system you're referencing (gyro not calibrated, pin out is wrong, code is wrong).

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by Tom Bottiglieri (Post 1398772)

We have not seen any of the recent kit provided gyros net that bad of a drift. I think bullet point #1 in Jared's list is the biggest culprit to gyro drift in a typical FRC match.

I agree with this assessment. We always throw out the WPI library and do our own bias calculation and integration. Our method is simple: big moving average for the bias calculation up until the instant the FMS switches from disabled to auto - then we freeze the bias and start integrating.

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by efoote868 (Post 1398804)

Interesting. with the KOP gyro my setup would accelerate up to 20 degrees per second in some cases while in others would only move 1-2 degrees per minute. The drift would also change direction so I do not think it was a calibration issue. I even tried it on a spare CRIO and got similar results to one encased inside a driving competition robot.

Re: Penalizing mecanum wheeled robots durring alliance selection.

My team had mecanum drive train for Ultimate Ascent and that was the season that our team actually performed the best. We were alliance captains and made it to semi-finals at our regional. We also won the quality award. In my opinion mecanum is a valid choice for a drive chain and when used on the right robot, can be very effective.

Re: Penalizing mecanum wheeled robots durring alliance selection.

Allot of post on this subject. My take on it is that going forward any team that is considering a omnidirectional drive system should evaluate the performance of that system compared to the six cim tank drive. The new standard. The power of 2 additional cims changes the game. Low resource teams can purchase Cots 3 cim gear boxes and have a very good powerful drive train easy now. This year with swerve we found that when we went up against the best we were too slow and at the same time did not have enough traction. We as a team realize that our current 4 cim swerve is not enough going forward. We as a team are working on taking swerve to the next level by adding more power and easier driver control. We've built a tribot and have been testing it. We have a 6 cim swerve module designed but not built for it . There are allot of positives on the drive ability of it but also negatives for the shape. For a 4 swerve module we have built a quasi cvt 1 cim module and are designing a 4 cim 4 mini cim drive. At the same time we're working on methods to make an omni directional robot easier to drive. Yes, there is a drive train arms race. Keep up or get nuked next year. Mecanums may have been relevant in the past . There utility in the future is very questionable. In my opinion.

Re: Penalizing mecanum wheeled robots durring alliance selection.

About the gyros:
In our swerve drive, sometimes I'll turn on the robot and the gyro might start drifting at 3 deg/sec at times. Even when it doesn't drift this bad, it accumulated quite a bit of error in a match. This seems inevitable; we've replaced the gyro many times.

We have a gyro reset button, and I end up calibrating the gyro many times in match. Even with the reset, I sometimes find myself driving with 25+ degrees of error.
Somebody above said that this was impossibly disorienting, but I find it manageable.
I got used to gyro inaccuracies after some practice.

Nevertheless, we're determined to improve the system. We are going to try using two gyros, one mounted upside down. 1717 does this and says it helps a lot.

Even if I had to deal with gyro drift forever, if still greatly prefer field centric over robot centric

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by cjl2625 (Post 1398979)

I don't think you need two gyros or non-kit gyros. We have seen similar problems with the WPI gyro code, which is why we do our own bias calculation and integration - see my above post. If you need more details, let me know.

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by Chris Hibner (Post 1398981)

Hmm, that's interesting.
Yeah, I'd love to know the details of how you guys calculate that.

Re: Penalizing mecanum wheeled robots durring alliance selection.

Quote:

Originally Posted by cjl2625 (Post 1398983)

Hmm, that's interesting.
Yeah, I'd love to know the details of how you guys calculate that.

This is going to be a long post. I'm trying to target this post at relative newbies, so if any of this is old news feel free to skip to the good parts.

(Since this got long, I'll break it into two posts: the first will be explanation (the "why), and the second will be the "how" part.)

The vast majority of gyro "drift" is usually due to a poor voltage bias calculation.

What is this "bias" that you speak of? The sensor outputs a voltage relative to the angular rate (these devices are angular rate (speed) sensors, not heading sensors). The voltage when still (angular rate = 0) is typically around 2.5V for a 5V sensor, but in reality that can vary for many reasons. Therefore, the software always needs to calculate the voltage bias before using the angular rate to compute a heading. The bias is used by subtracting it from each sample before computing the heading. Thus, after the "bias subtraction", the sensor output is transformed from 0 - 5V to approximately -2.5 - +2.5V.

How is the bias typically calculated? The bias is calculated by averaging a number of samples when the software thinks the gyro is still. The WPI gyro software performs this calculation as soon as the software begins to run. Any movement of the robot just after power-on until the bias calculation is finished will cause your bias to be bad, and you will get a large gyro drift. "When is the WPI code finished calculating it's bias so we know it's safe to move the robot?" you ask. Good question. I don't really know, which is one of the reasons we don't use it. Another reason we don't use it is because we find it nearly impossible to keep the robot perfectly still immediately after power on.

Can the bias of the gyro drift? The short answer is yes. If you calculate a good bias, and then the bias changes, your heading will drift over time. That's not good.

What causes the bias to drift I don't want to repeat a good post: see Jared Russell's post above. One important I'll repeat: the bias is likely to drift as the gyro warms up. Therefore, in an ideal world you would like gyro to be at its steady-state before calculating the bias. The WPI code does this immediately after power-on so the likelihood of bias drift is much higher than if you could wait.

Ok, then in your opinion when should the bias be calculated There are 3 main criteria for me: 1) The robot MUST be PERFECTLY STILL; 2) The gyro should be at steady state; and 3) The bias calculation should be performed as close as possible to the time your are going to start using it (in other words, a bias calculation from 5 minutes ago is much less likely to be accurate than a bias calculated 1 second ago).

So when do YOU calculate the bias? Simple answer: the instant before the match begins. This ensures it satisfies all three criteria: 1) the robot will be perfectly still since all humans have to be off the field or someone is getting DQ'd; 2) The gyro should be at steady state since it has been a few minutes since power-on; and 3) the instant before the match starts is as close as you can get to when you start using the bias.

What are the disadvantages of your method? The WPI gyro code can't be used, and you have to write all of your own software.

Re: Penalizing mecanum wheeled robots durring alliance selection.

So, how do you actually do it?

First, we throw out the WPI gyro library and just use the analog input library. You'll need to know the sensitivity of your gyro (in deg/s/V), but if you don't know that you can make a guess and figure it out with some testing. We always do the tests anyway to characterize the sensor we're using.

You need a few things in your code:

1) An array of gyro voltage readings so you can calculate a moving average. This moving average will be stopped once the match begins and this average will become your gyro bias.

2) A variable to indicate that your robot has become enabled once during this power cycle. Why is this important? Because you don't want to resume calculating the bias in that short disabled period between auto and teleop. You may say, "but you said a bias calculated as close to the the current time possible is better, so wouldn't it be good to calculate it again just before teleop?" The answer is no, because then you have a good chance of violating the most important criteria: the robot MUST be still. There is a decent chance that either your robot was still in motion as power was cut to end autonomous, or some other robot runs into you at the end of autonomous. Either way, the safe bet is to just use the bias from just before auto mode starts.

3) An integral to calculate the heading from the angular rate samples. (If you don't know what that is, it's a fancy term for area under a curve, which is a big sum. Look it up on wikipedia.)

So here it goes with the code:

(note: caveats apply. a) I'm doing this by the seat of my pants, so there may be a bug or two; b) this is more intended to be pseudo-code rather than copy-and-paste C code; c) this is intended to provide a general idea - not a final solution - see (a) and (b))

(note 2: I'm going to assume you have a typedef.h file and use descriptive types. f32 = 32-bit float, u8 = unsigned 8-bit integer, s16 = signed 16-bit integer, etc.)

defines and global variables

Code:

#define GYRO_BIAS_SIZE 32

#define GYRO_ANALOG_CHAN 1

#define GYRO_SENSITIVITY 0.025 /* in deg/s/V */



f64 gyroBiasArray[GYRO_BIAS_SIZE];

f64 gyroBiasSum;

u8 gyroBiasIdx;

bool visitedEnabled;

f64 gyroHeading;

f64 currentTime;

f64 previousTime;

In your "init" function

Code:

gyroBiasSum = 0;

gyroBiasIdx = 0;

visitedEnabled = FALSE;

gyroHeading = 0;



for (u8 i = 0; i < GYRO_BIAS_SIZE; i++)

{

   gyroBiasArray[i] = 0;

}

In your fastest periodic loop

Code:



f64 gyroV;

f64 gyroDPS;   /* in deg/sec */

static f64 gyroDPS_prev = 0;  /* deg/sec previous sample - used for trapezoidal integration */



if ((getFMSMode() == AUTO) || (getFMSMode() == TELEOP))

{

    visitedEnabled = TRUE;

}



previousTime = currentTime;

currentTime = getTickCnt_ms() / 1000;



/* sample the gyro voltage */

gyroV = getAnalogVoltage(GYRO_ANALOG_CHAN);





/* calculate the bias if we have not yet been enabled */

if (FALSE == visitedEnabled)

{

    /* compute the moving average by first calculating a moving sum

       the moving sum is computed by first subtracting the oldest

       sample in the bias array, then add the current sample.  Then

       replace the oldest sample in the bias array with the newest sample. */

    gyroBiasSum -= gyroBiasArray[gyroBiasIdx];

    gyroBiasSum += gyroV;

    gyroBiasArray[gyroBiasIdx] = gyroV;

    gyroBiasIdx++;

    if (gyroBiasIdx >= GYRO_BIAS_SIZE)

    {

        gyroBiasIdx = 0;

    }

}

else

{

    /* if we're here, it means we've been enabled.  Therefore, we need to

       be calculating the heading instead of the bias. */



    /* first, subtract bias voltage and convert to degrees/sec */

    gyroDPS = (gyroV - (gyroBiasSum / GYRO_BIAS_SIZE)) * GYRO_SENSITIVITY;

    /* Now, compute heading using trapezoidal integration */

    gyroHeading += ((gyroDPS + gyroDPS_prev)/2) * (currentTime - previousTime);

    gyroDPS_prev = gyroDPS;

}

And there you have it.

I would highly recommend characterizing the sensor you're using rather than just using the sensitivity from the data sheet. Not only can the sensitivity vary from part to part, but the sensitivity can be reduced if the gyro isn't mounted perfectly flat. Here's how we do it:

1) make your best guess at the gyro sensitivity (use the nominal sensitivity in the data sheet if you have it).

2) Place the robot flat up against a wall and start your code.

3) After sufficient time to allow a good bias calculation, enable your robot into teleop mode.

4) Rotate your robot 180 degrees and place the robot flat against the wall again (so you ensure your robot rotated as close to exactly 180 degrees as possible).

5) Write down the computed heading.

6) adjust your gyro sensitivity in your code using the following calculation: NewGyroSensitivity = OldGyroSensitivity * ActualRecordedHeading / 180

7) Repeat the procedure until your recorded heading is VERY close to 180 deg.

Last note: we actually use LabVIEW. I can post that as well if you don't do textual programming.

If there are any questions, let me know.

Re: Penalizing mecanum wheeled robots durring alliance selection.

Wow, thanks for posting this!
I'll share this it my team.

What exactly do you mean by the "init function"? Do you mean to put that in Begin.vi? (We use LabVIEW too)
How fast do you run that periodic loop?
And you just reference the gyro heading in tele/auto by using a global variable, right?