View Single Post
  #9   Spotlight this post!  
Unread 15-03-2008, 08:45
Shue Shue is offline
Programming Subteam
AKA: Mike Gushue
FRC #2228 (Cougar Tech)
Team Role: Mentor
 
Join Date: Mar 2008
Rookie Year: 2007
Location: Honeoye Falls, NY
Posts: 3
Shue is an unknown quantity at this point
Re: Autonomous / Hybrid - Tethered versus Radio?

Hi Ken,

Thanks for your insight! I definitely agree with you about not eliminating possibilities too early in the analysis of a problem. It's not so much eliminating possibilities as much as narrowing the investigations into higher probability causes. You need to keep revisiting the bigger picture...

Of the three candidates you mentioned as causes of our problem, 1 or 3 are the more likely ones (I certainly have had my eye on the gyro, as it was a problem throughout build season but seemed to be behaving towards the end). The geartooth sensors were less likely for us, as we use them exclusively for determining when to shift our two-speed transmissions (which are locked into low for hybrid) and distance traveled. In our case, if one failed for the distance calculations, it would make us go further than we wanted (since we average the distances from both wheels to get the centerline-distance traveled). Haven't eliminated the going-short possibility, but it's less likely to be caused by the geartooth sensors misbehaving...

The only datapoint that doesn't fit with the gyro being the cause is the fact that when we removed the gyro from the equation entirely (by doing "programmed straight" with hard values being written to the drive motor pwm's), we still saw the turn left, just at a 45 degree angle (into the center wall). We looked at some video of one of those instances, and noted that there seemed to be a difference in the starting time of each wheel (the left seemed to be slow off-the-line compared to the right). So, it may be a different cause for the "programmed straight" not behaving...

Your suggestions about the data logger possibilities are excellent! We had considered investigating this during the off-season this year, as the "tether to get debug output" approach gets old realy quick (especially when the problems only occur when the robot has been running for a while). The picture someone has of "forever chasing the 'bot" while carrying a laptop is very apt! Not sure about the ability to put a laptop on our robot (as it's pretty exposed on the top and no "inside" room), but I'll bring it up to the team today at our team meeting. Definitely will purchase a data logger, however!

My suspicion about the gyro goes beyond the gyro bias calculation. I'm sure that the calculation was totally disabled (the only trace output we generate when ready for going out for competition is that for the bias calculation, just to be sure that we look "normal"; this didn't print before the matches where we had the hard-coded bias value). My real issue is that when the bias value fails to get real values (gyro reports bad values used to generate the bias), it's likely the same thing can occur after the bias is calculated. If this happens, no matter how good the bias value is, the gyro will be reporting inaccurate/false angles of turn and, hence, we'll be attempt to correct for a non-existent turn... Haven't proved this is the case yet, but have been brainstorming with the team to put in OI indicators (LED's) to indicate to the drive team that a problem with the gyro has occurred...

The point you brought up about the compiler differences from ANSI-standard is something that all teams should be aware of. We discovered this about two weeks from the end of the build season, in exactly the way you stated: we had two seemingly simple values that when multipled together, were being used to bound an input value (12 * 54). The check kept failing, and when we printed the value 12*54, it was being computed as -120! The fact that the compiler by default doesn't promote to an integer before doing math is definitely not what I was used to, and enabling the option to have it do that and recompiling the code didn't help either. The resulting code also didn't work, just in different ways, so we reverted to the original options and just fixed all instances of the byte values so the math worked (our mini-autonomous is where we saw it: with no distance being executed, the robot just did a spin in-place!).

Thanks again for your (and everyones) insight! We'll keep working the problem and report what we find.

-Mike