I am posting this question, late. What we are seeing with our robot controller and operater interface is that at times the OI will get bad data from the RC, and the RC will get bad data from the OI.
When we turn the robot on, sometimes it will give us a random RLOD, this is normally fixed with a simple power off and on.
The other time is when everything seems fine, but randomly the belts on our robot will start running, or it will start running in circles, even when on the OI the FlightSticks are unplugged, and thus it can’t be the fact that the joysticks are sending data. Also, on the OI all the lights will go on, as in all the extra LED’s under the Robot Feedback header, when not all of them should be lit up. If I am connected to the programming port, I will see that the output appears all scrambled, and I get random crap thrown to my terminal window.
I am thinking there might be a problem with the interrupt that it is not saving enough data personally, but I don’t understand why this would cause it to die upon startup. luckily for us it is immediatly evident, according to the CMUcam thread there are others with the same problem, so my team is not the only one fighting with the code at the moment trying to get it to work without any problems.
Kevin Watson, you posted elsewhere something else to add to save in the pragma before the InterruptHandlerLow, maybe that could help us?
Any other things I should do? I am going to email IFIrobotics and see what they have to say about this problem, besides that I am wondering how we are going to go through the competition if our robot is malfunctioning.
No such luck for us, same problem. It will sporadically go in to chain fire mode, jsut keep hammering the piston til the air tanks empty, our battery indicators freeze at 8.2 and a joystick completely unrelated to drive becomes controller of the left PWMs. The pragma is right, so that wasn’t it…
That is what I am seeing as well. Thing is, once one unplugs the OI, and plugs it back in, everything is back to normal, sometimes.
Edit: Forgot to mention, I am allready using the different PRAGMA than the standard, I am allready getting it to save section(“.tmpdata”). Kevin Watson in another thread suggested saving MATH or something like it as well.
Recompile your code with either one of these libraries and verify if you see any difference. We made a simple change to the way that the high priority interrupt saves data according to the PIC18F8722 errata sheet. If this helps you let us know.
Regards,
Mark Lambert
I will reply asking if I can attach the new beta code he sent me for all others to try out as well.
We saw this as well with our robot when we were testing it out just prior to shipping. The voltage registered as 8.2 and the robot went crazy. It had been working prior to this and worked just fine later.
We have the pragma set up for .tmpdata and our code looks OK as far
as we can tell. We would like to hear about other peoples experiences so
we can make sure this does not happen in competition.
Also, I’ve heard some less than nice comments about IFI on this one, and I won’t name names, but people, be nice, they do serious tailbreaking every year for this, and it was a new chip this year, between IFI and FIRST I think we’ve had one of the most bug free years so far and I’d be willing to be those griping programmers have made a mistake or too themselves. They’re only human and I applaud them for getting us a fix as soon as they realized what was going on. Thanks IFI.
To go a bit further, this is not an IFI bug. This is a Microchip bug in the actual design of the processor in the RC. Since replacing all those processors is not practical, IFI implemented a software workaround for the problem. So, anyone making disparaging comments about IFI is really misguided.
