We noticed this while repeatedly running autonomous on a tether. The first phase of our auton. is a timed run for about 5.5 seconds. After running two or three times properly, we again reset the controller (press the reset button on the RC) and throw the “Autonomous” switch on the competition port, but this time it runs for about 11 seconds before going to the next phase. Note that 11 = 5.5 * 2.
It does this occasionally, every now and then.
What’s more, when it does this, the trackers scan much more slowly (my own tracker code, but see below).
We have special LED blinkers on the robot (for telemetry) and they blink about half as fast when it does this.
Then we reset, unplug the tether and plug it back in, turn around two times and throw salt over our shoulders and try again. And then it runs normally (5.5 second run, normal tracker scan speed and blinker speed.) But I have seen it run in “slow mode” more than once in a row.
I remember when I had Kevin’s tracker code and there was no beacon to see, the trackers would just scan and scan (as expected). Then, by themselves, they would start scanning at half speed. I think it was the same problem I am seeing now.
My guess is that the RC is missing every other 26 ms cycle, but I don’t know why. If the code didn’t run in less than 26 ms it might do this, but I would expect it to do this the same way every time, not just sometimes, nor run fine for awhile and then start running half speed. This behavior seems to appear randomly – I can’t correlate it to anything else.
Has anyone else seen this? Any ideas? Seems like a half-fast controller!
im not sure what your trackers are, but if they involve interrupts based on outside effects, then you may get varying amounts of interrupts thereby causing your code to take longer. Also, the radio modem’s interrupts may cause some discrepancies but i think this is handled by a seperate computer so i dont know…
The radio interrupts are handled by the Master processors, so that shouldn’t actually be interrupting you, and I really doubt you have enough interrupt code to stall you that much. Further, if you don’t call putdata() often enough (the normal 40hz or faster, I believe) the Master assumes the User is faulty/off and shuts it all down.
A red flag for me is that this is happening under tether…we had a lot of problems working with the tether when we were at Sacramento. The RC would keep resetting itself for no real discernable reason, and values were coming in really screwy-like. We solved most of the issues by ignoring the first few radio packets coming in, but I doubt that’s what’s going to help you…so weird.
Try printing out the packet number after every Getdata. It’s rxdata.packet_num or rxdata.packetnum or something like that (you want the packet number in rxdata, not txdata). If your packet number keep incrementing by 2, you’re missing packets.
If you are missing packets, I don’t know what to say other than I wish IFI would reveal more about their communication structure rather than packing everything useful into a library. We’ve run into several strange errors where more knowledge about the whole setup would have greatly speed up the debug process.
If you are catching every packet and it’s still running at 1/2 speed, then I’d definately say it’s an issue with how the master processor handles communication over the tether. The rxdata packet number is controlled by the master. Once again, it’s hard to investigate these problems without the master code…
Though I would suggest you try to run everything off of timers rather than program counts. It’s more accurate and more reliable that way.
Try printing out the packet number after every Getdata. It’s rxdata.packet_num or rxdata.packetnum or something like that (you want the packet number in rxdata, not txdata). If your packet number keep incrementing by 2, you’re missing packets.
Aha! Finally, a test I can do. Thanks, that’s very helpful!
im not sure what your trackers are, but if they involve interrupts based on outside effects, then you may get varying amounts of interrupts thereby causing your code to take longer.
Yeah, that occured to me, too, but I don’t know how to test for it.
Any chance your code is taking too long?
Always a chance. But I tested it way back in January with a scope and found the non-auton code taking less than 5 ms. I kind of think the auton code is not 5 times longer. I thought of taking my scope on the plane to Atlanta, but the thought passed (Tek 475 – about the size of another carry on, but much more fragile than my socks). Besides, I think Kevin Watson’s unmodified tracker.hex code had this same behavior, too. I think, but I might not swear to it.
do you have printf statements in your code?
Yes. Turning off printf is a good thing to try. I may write a dummyPrintf() function and #define printf dummyPrintf
void
dummyPrintf( char *s, ... ) // note the var arg "..."
{
return;
}
// and later:
#define printf dummyPrintf
Do you think that will do what I want (shut down all printfs at once)?
I think printf’s are always suspect since I found a strange behavior: I would upload the code, it would start running, flooding the screen with printf output, so much that when I stopped the RC the screen kept going for a second or so. Then the program would not run again after a reset. I had to download the code each time to run it once. I got rid of most of the printfs, and that self-destructive behavior went away. Beware printfs!
If you call printf() before the Initialize_Serial_Comms() call in user_initialization() you’ll see this exact behavior.
I agree that printf() is a big resource hog and should be used sparingly. I’m working on an implementation of printf() that uses a circular buffer and the Tx interrupt to ease the problem a bit. If it works pretty well, I’ll release it when I’m done.
on thing thats really useful for debugging your code is to use the user_mode variable on the OI - you only get to see one byte of data, but its there all the time
when we used printf’s in our code it would lag about 10 seconds from when the data changed in the RC - I dont know why
Man, I have fold memories of my old 475. Looks like they can be found on ebay pretty cheaply. You know you’re a middle aged EE geek when you dream of oscilloscopes past :D.
The tracker code is pretty efficient; I can’t imagine it taking more than a millisecond to execute each pass.
Ya, we had the same problem as well. The lag was actually in the terminal program not being able to refresh quickly enough, due to our slow PC.
We simply modified the printf() function to only spit out less frequently.
We’ve seen the lag as well, and (for us anyway) it’s in the IFI terminal program. Switch to a better terminal program (even Hyperterm will do) and the problem should go away.
