|
|
|
![]() |
|
|||||||
|
||||||||
| View Poll Results: How mecanum drive effects a teams position on your pick list | |||
| Automatic DNP |
|
34 | 11.07% |
| Moved lower |
|
84 | 27.36% |
| Depends on performance |
|
161 | 52.44% |
| Nothing (does not effect position) |
|
22 | 7.17% |
| Other (please explain in thread) |
|
6 | 1.95% |
| Voters: 307. You may not vote on this poll | |||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#151
|
|||
|
|||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
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?
|
|
#152
|
|||
|
|||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
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.
|
|
#153
|
|||
|
|||
|
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. |
|
#154
|
|||
|
|||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
Quote:
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:
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. |
|
#155
|
|||
|
|||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
Quote:
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). |
|
#156
|
||||||
|
||||||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
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.
|
|
#157
|
|||
|
|||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
Quote:
|
|
#158
|
||||
|
||||
|
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.
|
|
#159
|
|||
|
|||
|
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.
|
|
#160
|
||||
|
||||
|
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 |
|
#161
|
||||||
|
||||||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
Quote:
|
|
#162
|
||||
|
||||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
Quote:
Yeah, I'd love to know the details of how you guys calculate that. |
|
#163
|
||||||
|
||||||
|
Re: Penalizing mecanum wheeled robots durring alliance selection.
Quote:
(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. |
|
#164
|
||||||
|
||||||
|
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; Code:
gyroBiasSum = 0;
gyroBiasIdx = 0;
visitedEnabled = FALSE;
gyroHeading = 0;
for (u8 i = 0; i < GYRO_BIAS_SIZE; i++)
{
gyroBiasArray[i] = 0;
}
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;
}
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. Last edited by Chris Hibner : 05-09-2014 at 13:09. |
|
#165
|
||||
|
||||
|
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? |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|