We had recently been working on programming skills for our bot, and so have been downloading code multiple times a day. We are using the most recent version of robotc.
Here’s the problem: sometimes, when we download code we encounter some strange issues. Sometimes, our arm doesn’t move up or down, sometimes our automated hang doesn’t work… these problems cannot be solved by restarting the robot. Redownloading the code doesn’t help, instead we have to make a change to the code file. Even if we don’t change the code itself (such as adding a comment or and extra space in a random location) the problem is fixed.
These problems seem to occur randomly, and seem to only be solvable by forcing robotc to recompile the code.
We know the problem is not an error in our code, nor is a problem with sending the code to the robot, so we believe it to be an issue with the robotc compiler itself. Our code is large (1400 lines in three files)… could that be the problem?
Any solutions or work around would be appreciated as soon as possible.
To be honest it sounds more like a code issue. I would imagine maybe it has to do with pre_auton being run or some other condition that is only properly run once per boot.
Just like Jpearman asked in the official version of this. Post your code and I will take a look.
All of our problems seem to occur within the “doAutoArm” task (line 497), which admittedly points to the problem being with my code.
If it helps, here’s an account of one of the problems we had.
I tweaked our skills routine (in the autonomous file) recompiled and downloaded the code - I did not change the main “starstruck code” file before downloading.
When we tried to use the automatic throw (which had worked fine the time before, found on line 612) throwMode, our variable for cycling through the phases of the throw, was set instantly to 20 (seen in the debugger).
I checked and double checked my code, and could not find anything that would set throwMode to 20, and could find nothing that could increment it out of control (throwMode++;). In fact, on line 652 I set throwMode to 0 if it exceeds 5.
I restarted the robot several times, but the problem persisted. I tried redownloading the code, but the problem was still occurring.
When I recompiled the code, and then redownloaded it (with identical code) the problem disappeared.
Similar problems have happened, but only after we have recompiled and redownloaded it; the only way to fix these problems is to recompile and redownload the code, and hope for the best.
Thanks for your help,
Team 224 224 Code.zip (14.5 KB)
I can’t see your code - and as a novice programmer that coaches my team your problem sounds like it may be due to sensors not resetting properly between runs. So, for example, if you tell the sensor to run until it hits a value of 100, it will not go to the next step until 100 is reached. However, if the sensor starts at -50 it would only hit 50 and your code will be “stuck.” What I recommend to my kids is to watch the sensor values in the sensor window to make sure they are initialized properly and getting to the required values. Lots of times intermittent problems like the one you describe above are due to that problem.
Sensors were the first thing we checked, they all work fine, and read the correct value when we move the arm by hand. Also, when restarting the robot the problem persists… only recompiling the code and then redownloading it fixes the problem
The problem isn’t fatal, and we can work around it by recompiling and redownloading, but it is a pain to have to redownload the code when it goes wrong.
The only factor that affects the outcome is the compiler, so we don’t know what to do to stop the problem from occurring.
I’m pretty experienced with coding, we won the think award at worlds, and I’ve published 5 apps to the AppStore. If it is a problem with my code, then I expect it will be nuanced and to do with how the compiler reads the file.
If anyone else has this problem it would be great to know we’re not alone.
Oh, I didn’t realize you were such an experienced coder. It is hard to tell on here - some people are very novice and some are very experienced. Good luck. Hopefully, one of the “experts” on here can help.
I would like to caution against using statements such as: "We know the problem is not an error in our code, nor is a problem with sending the code to the robot, so we believe it to be an issue with the robotc compiler itself.
Methodical troubleshooting is something I’ve also been teaching the kids and unless you absolutely prove that something isn’t an issue, you can’t say with certainty that it isn’t your problem. With 1400 lines of code, you really don’t know if it’s the code or not. It very well could be, but you are cutting off solution space by eliminating that option with fully proving it out. My kids want to blame everything from the battery to the man on the moon when things go wrong. Mostly, the problems are caused by things they did.
Intermittent problems are the worst type of troubleshoot. Key to the solution is finding the condition that causes the problem. Test your “too many lines of code” theory by cutting your code in half. Do you still have the problem?
RobotC can handle 1400 lines, that’s not the problem. The only problems I can think of relating to the compiler or RobotC internally would be either your arrays (they are big, but not big enough for RobotC to complain so I think it’s fine), or some compiler options. Make sure that you have checked “Debugger” in the “Code Generation” tab for the compiler preferences.
We checked the compiler settings, debugger is set.
Gear Geeks: sorry if we sounded arrogant, we were just trying to explain that we could find no problem with the code. The problem isn’t intermittent, but persists until we recompile the code. That’s why we found the problem to be the compiler.
Here’s our trouble shooting so far:
We checked the sensors - worked fine
We checked the code - values we saw on the debugger should have been impossible… no one on our team could figure them out
We restarted the robot - problem still occurred
Redownloading the code - still had same problem
Recompiled and then redownloaded - problem stopped
That’s why we think it’s the compiler… nothing else makes sense (at least to us)
I’ve assumed that downloading the code, having not changed it or reopened the code file does not recompile it. If this is not the case please let me know. It may then be an issue with downloading over vexnet.
@224 Sharks Are you at the Riverside competition on Saturday? I see 224S will be there, if so you can perhaps show me what’s happening, I can bring a spare cortex so we can try downloading to that with your PC.
I think we recompile every time, we do use a pre-compiled header (that means we only compile the robotc header files once) but changing code would not cause those to recompile anyway, you would have to restart RobotC for that to happen.
How old is your cortex?
I won’t be there, but I’ll send another member of our team to show you (224s is our second team)
just to verify: downloading the code will or will not recompile? Also: does clicking the compile button in the top right recompile the code?
Our cortex is kinda old, but we haven’t bee been using it for very long. Could a faulty cortex explain the problem?
As @kypyro was showing you (before deleting the post ? ) there are two options available. “Compile” which does as it says, just compiles the code, that’s useful when writing the code and you want to check for errors etc. and “Compile and Download” which does both. We don’t have a button that only downloads.
A faulty cortex could explain this behavior, but it’s one of those low probability possibilities, I would need to get hold of the cortex and do some tests. If you have access to another one it would be worth trying and see if the problem persists.
Well, I didn’t intend to delete it. However, after initially posting it, I made an edit. (Added whitespace around the screen shots.) Then, the post showed up twice. So, I refreshed a couple of times to make sure it wasn’t an artifact. When I was sure, I deleted one of the posts. Upon refresh, ** both ** copies were gone.
I’ve very, very occasionally experienced issues similar to this. I haven’t been able to tie it down exactly, but I’ve never had it happen over the USB cable, only over the joystick/controller link. And it seems to be correlated with low joystick/controller batteries.
That correlation doesn’t seem very likely; it seems barely more likely than cosmic rays flipping a bit. But it has the advantage of giving the illusion of control. We can change the joystick/controller batteries, resync everything, and compile/download again. Problem solved. No way to tell, of course, which thing might have made the difference: the battery change, the joystick/controller reboot, the VEXNet reconnect, the compile/download cycle. Or even just the time it takes.
Thanks for that explanation, we do often have issues when downloading the code over the vexnet keys… we often get an issue like ‘flash corrupt, redownload’ which seems to happen more often when the controller is farther away from the cortex
These weird problems have happened before, but never as often as it has been the past few days
If the download button also compiles then I guess the issue must be to do with either transmitting/receiving the code over the vexnet keys, or with the cortex itself
I know you mentioned that the code size doesn’t matter, but could it if we are transmitting wirelessly? Our second team also transferres wirelessly with the same pc (but with newer keys and cortex) and a much smaller code file and had never had this issue
