Go to Post ...it takes a very special kind of person to equate bagpipes with harps. - Kevin Sevcik [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 12-03-2008, 17:02
eugenebrooks eugenebrooks is offline
Team Role: Engineer
AKA: Dr. Brooks
no team (WRRF)
 
Join Date: Jan 2004
Rookie Year: 2001
Location: Livermore, CA
Posts: 601
eugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond repute
Re: Autonomous / Hybrid - Tethered versus Radio?

One thing to note is that on the field, the enable comes quite
quickly after autonomous, and on your manual box it may not
be so quick. This can foul any timer that is not checking for
both autonomous and enabled. I can't think of anything else
that I would expect to be different, other than potential radio
modem trouble. By measuring the time between packet loops
you can detect missed packets and show them with a counter
on the user display.

We have had trouble, during testing with our sensor test mule,
with measured run lengths being short, and long. Our test mule
used a shaved sprocket to trigger the sensor and the gap had
a lot of variation in it. We straightened it, and closed the gap
as much as possible. After that the measured distances seemed
much more repeatable, but not totally flawless. The wheel counters
in our competiton robot are different, running directly on the output
gear in the toughbox. The gap to the gear in this case is critical
because the teeth are small. I suppose that the next time we run
into this we should try the tether and see if it makes a difference.

There is always the possibility of residual gremlins in the 8722.
We have had more than our fair share of problems with it.
If the rules allowed the 2005 controller, upgraded with the latest
firmware, we would be using it. We have never had gremlins
appear on the prior controller.

Eugene
  #2   Spotlight this post!  
Unread 13-03-2008, 07:32
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!

We do use the gyro during teleop mode (and hence do process the gyro data in the teleop_spin), and it seems to be working ok there. The bias calculation (we are using Kevin's default code) occurs during the disable-mode handling. One of our experiments was to assure we weren't losing the bias value by calculating it just before a match and hard-coding it in the gyro initialization. Not a perfect solution, but it showed that the bias value calc (or lack of it) wasn't causing the bad robot behavior...

The IR commands were suspected early, as one of our IR commands was "turn left 30 degrees". We disabled the IR handling (disabled the sensor in hardware, as well as removing the code that looked for the IR and processed the commands). We ran that way for a couple of matches, and the hard left turn was still there...

As for distance calculations, as I mentioned, we use geartooth sensors on both our wheels. Our autonomous is implemented as a state-machine that runs discrete functions used to "play the game". These are things like "go straight", "turn 90 right", "turn 90 left", "delay X seconds", "raise lift", etc. These are called in a specific order and with lane-specific values to traverse the track. The straight function sets up the distance and heading desired, starts the wheels at the desired speed, and polls in the 26.2ms loop for completion. Part of setting up the distance is the resetting of the distance counters. We suspected this early as well, so we did a lot of tracing on this (but of course, it works on the practice floor ).

The suggestion to put out the distance in the user bytes to display on the OI is an excellent suggestion! We will implement that for testing during the practice rounds at the Buckeye Regional. That should give us enough info to either identify it as the culprit or remove it from suspicion...

We even went so far as to discuss the issue with the IFI representative at the FLR. They went back and looked through the data they keep, and noted no dropped/corrupted packets to our radio modem. I didn't really suspect that as a cause, but needed to cover all bases looking for clues.

-Mike
  #3   Spotlight this post!  
Unread 13-03-2008, 10:27
TubaMorg TubaMorg is offline
Programmermechanicalelect ricalcoach
AKA: Dan
FRC #1480 (Robatos Locos)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2005
Location: Houston
Posts: 450
TubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond reputeTubaMorg has a reputation beyond repute
Re: Autonomous / Hybrid - Tethered versus Radio?

Mike,
Thanks for the update. Please keep us posted. The last two years our team has had a similar problem where autonomous behavior while tethered was far different than what happened on the competition field. We had other, more important, demons to extricate from our machines, however, so we weren't able to pursue the matter. It's a frustrating problem, though, because it can only be tested during real competition.
  #4   Spotlight this post!  
Unread 13-03-2008, 10:56
Ken Streeter's Avatar
Ken Streeter Ken Streeter is offline
Let the MAYHEM begin!
FRC #1519 (Mechanical Mayhem)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 2005
Location: Team: Milford, NH; Me: Bedford, NH
Posts: 475
Ken Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond reputeKen Streeter has a reputation beyond repute
Re: Autonomous / Hybrid - Tethered versus Radio?

Shue,

At our regional, we had been encountering similar problems in autonomous mode with the robot not behaving as expected. We had a very difficult time debugging the problem. The fundamental difficulty we had in identifying the problem was that our assumptions about where the problem was occurring were fundamentally wrong, so we were looking in the wrong place(s) for the problem, which made it very hard to find! Taking a step back and asking others on CD for advice is a great approach to get a fresh perspective. Hopefully one of the myriad of replies you get here will help you identify the real problem. I would caution you to consider all the suggestions, even if you "already tried" one of them -- on our team quick conclusions arrived at while debugging "under the gun" during the little time in between matches are sometimes incorrect due to being based upon incorrect data.

I think that the key issue is that you need to determine what the robot is doing when it goes astray. It sounds like the three most likely candidates are either (1) that the robot is trying to drive straight, guided by the gyro, but has an incorrect bias due to a problem with the bias calculation not being invoked as expected due to differences in the disabled -> autonomous transition sequence between your practice field testing and the real field, or (2) that the robot is trying to drive straight, but has suddenly started receiving incorrect sensor data causing it think that one wheel has suddenly stopped turning and that it then remedies the situation by turning sharply in the other direction, or (3) that the robot thinks it has finished driving straight and is prematurely performing the left turn planned for at the other end of the field. Determining which of these is actually occurring (or if even a fourth event is taking place) should be a priority.

We grappled with the same issue (identifying what the robot is trying to do without telemetry information) at our regional this year. We ended up locating the problem by testing in the pits (our problem turned out to be a flaky sensor) when we could use "printf()" output to our laptop to identify what the robot was trying to do at the time the problem occurred. However, in a real match, you don't have the luxury of live "printf()" output from the controller.

Having learned a few things since our regional, though, I can now suggest to you two ways to be able to get "printf()" output during operation on the real field:

1 - Use a "serial port logging device" on the robot to record serial port information. Phil Malone of Team 1629 wrote a white paper on doing this using the SparkFun Logomatic Serial Datalogger. His white paper explaining how to use this product is published as a PDF file on the SparkFun site. We have since ordered one of these from SparkFun but haven't yet received it to play with it. This device has the advantage of being fully FIRST legal for competition rounds.

2 - If you have a practice round (this wouldn't be legal for a real round) and you don't have time to order and receive the above datalogger, we learned of another approach to getting "live data" from Team 1307 who used a similar approach when testing their autonomous modes... You can strap a laptop to the robot, and have it connected to the programming port of the controller. I'd suggest using Hyperterminal (or your favorite terminal emulation program) to log all the output data to a file. By adding a lot of "debugging output" to your autonomous program, this will enable you to determine exactly what the controller thinks it is doing (and what sensor input it is seeing) when the problem occurs during the actual practice match. If you try this, make sure that the laptop is extremely well attached to the robot, and preferably in a highly protected spot, as you really don't want it to come loose during the match or have another robot's arm stuck through it!

Now that I've spoken my piece on trying to figure out what the robot is actually doing when the problem occurs, I'll add a few specific suggestions on some of the possibilities that you and others have mentioned.

Quote:
Originally Posted by Shue View Post
We do use the gyro during teleop mode (and hence do process the gyro data in the teleop_spin), and it seems to be working ok there. The bias calculation (we are using Kevin's default code) occurs during the disable-mode handling. One of our experiments was to assure we weren't losing the bias value by calculating it just before a match and hard-coding it in the gyro initialization. Not a perfect solution, but it showed that the bias value calc (or lack of it) wasn't causing the bad robot behavior...
When you made this fix are you sure that you completely turned off the bias calculation code so that if and when the bias calculation code did run, it didn't simply overwrite the hardcoded initial value? (I know that sounds like a stupid error, but I made that exact mistake during the build season when trying to debug the gyro bias calculation...) A possible way to see what would happen if the gyro bias is not calculated would be to turn off the calculation of the gyro bias and then run (on the practice field) the resulting code. When we do this with our robot (i.e. simulating a failed gyro bias calculation), we get a hard turn to one side (I forget which) when trying to drive straight, as the program thinks the robot is spinning quickly due to the gyro bias being radically incorrect.

Quote:
Originally Posted by Shue View Post
As for distance calculations, as I mentioned, we use geartooth sensors on both our wheels. Our autonomous is implemented as a state-machine that runs discrete functions used to "play the game". These are things like "go straight", "turn 90 right", "turn 90 left", "delay X seconds", "raise lift", etc.
This sounds like exactly how our autonomous software works, except that we used absolute magnetic encoders on our driven axles, rather than geartooth sensors. We ended up having multiple contributory causes to our problem. One of the root causes was that we were sometimes getting flaky values from one of our magnetic encoders. The symptoms we would see were that the robot would drive beautifully for a somewhat random distance, and then turn sharply to the right. This ended up being because the left encoder would stop reporting new values, which led to the program thinking that the robot was turning sharply to the left, which resulted in an immediate decrease in right motor power, which caused a sharp turn to the right. Thus, even though our robot was trying to "drive straight," the bad encoder input caused the robot to turn sharply to the right since the incorrect sensor information led to the (incorrect) conclusion that the robot needed to compensate for stoppage of the left wheel.

The other likely scenario is that the robot thinks it has completed traveling the desired distance to make the left turn. You mentioned that the turn works correctly on a practice field, but is that with the robot driving the entire 40 feet and making a left turn, or a shorter "test distance?" The reason I ask is that depending upon the resolution of your encoders, the precision of the variables you are using, and the order of operations in your assignments, you may be seeing overflow on your "40 feet" distance. This problem could manifest itself as the code thinking it only needs to go a much smaller distance to go 40 feet. We've been bitten many times by mathematical operations like the following:

Code:
#define DRIVE_STRAIGHT_DIST_IN FEET 40
#define TICKS_PER_FOOT 12

int dist_to_travel;

dist_to_travel = DRIVE_STRAIGHT_DIST_IN_FEET * TICKS_PER_FOOT;
At first glance, and with most compilers, the above looks perfectly fine. dist_to_travel is a 16-bit signed integer, and 40*12 = 480 which fits very easily into a 16-bit signed integer. However, the microchip compiler, when generating the code for the above, looks at the 40 and 12 and notes that they both fit nicely into 8-bit math, and thus performs the calculation of 40 * 12 in 8-bits, which overflows and gives a very unexpected value. However, if you were to test this code by setting DRIVE_STRAIGHT_DIST_IN_FEET to 6 feet in order to have enough room to test the code out in the practice area, you would have 6 * 12 = 72, which fits nicely in 8-bit math and will work perfectly. Only when trying to drive the full 40 feet does the problem occur, resulting in mayhem during the real round, even though everything worked great on the practice field!

The above, which looks a lot like a bug for those (like myself) accustomed to ANSI-standard C compilers, is actually a documented feature of the microchip compiler:

Quote:
2.7 ISO DIVERGENCES
2.7.1 Integer Promotions
ISO mandates that all arithmetic be performed at int precision or greater. By default, MPLAB C18 will perform arithmetic at the size of the largest operand, even if both operands are smaller than an int. The ISO mandated behavior can be instated via the -Oi command-line option.
For example:
Code:
unsigned char a, b;
unsigned i;
a = b = 0x80;
i = a + b; /* ISO requires that i == 0x100, but in C18 i == 0 */
Note that this divergence also applies to constant literals. The chosen type for constant literals is the first one from the appropriate group that can represent the value of the constant without overflow.

For example:
Code:
#define A 0x10 /* A will be considered a char unless -Oi
specified */
#define B 0x10 /* B will be considered a char unless -Oi
specified */
#define C (A) * (B)
unsigned i;
i = C; /* ISO requires that i == 0x100, but in C18 i == 0 */
Hopefully at least one of these suggestions will pan out for you!
__________________
Ken Streeter - Team 1519 - Mechanical Mayhem (Milford Area Youth Homeschoolers Enriching Minds)
2015 NE District Winners with 195 & 2067, 125 & 1786, 230 & 4908, and 95 & 1307
2013 World Finalists & Archimedes Division Winners with 33 & 469
2013 & 2012 North Carolina Regional Winners with teams 435 & 4828 and 1311 & 2642
2011, 2010, 2006 Granite State Regional Winners with teams 175 & 176, 1073 & 1058, and 1276 & 133
Team 1519 Video Gallery - including Chairman's Video, and the infamous "Speed Racer!"
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
whos doing what in Autonomous/Hybrid? seanl General Forum 16 17-02-2008 20:04
Radio breaks in autonomous mode?? MrHero Control System 4 17-02-2008 01:57
Help needed in autonomous programming for hybrid mode Team_STORM Programming 3 21-01-2008 19:11
Backup autonomous code if a Radio Dropout Occurs patTeam241 Programming 8 03-02-2005 00:12
Autonomous workking differently tethered in pits, than from feed during competition. Elgin Clock Programming 12 24-03-2003 17:00


All times are GMT -5. The time now is 01:50.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi