|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||
|
|||
|
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
|
|||||
|
|||||
|
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:
Quote:
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; 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:
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
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 |