The oddest error

So far this year we have been using Kevin’s basic 3.0 code and it has been working great. However, at the end of last week the team decided it wanted it control out arm with encoders and pots. So we download the 3.0 code with gryo/encoder. We add all of our functions, set up the encoder /analog input codes , the whole spiel.
We compile it and mplab has no problems with the code, it compiles fine. Next we load the code onto our practice bots to play with the pots/encoders in order to get a hang of them. Before that the norm 3.0 code was on the practice bot and the bot was working fine. So we load the code and everything looks normal. We have all greens on the RC except for rc mode and radio bc it is not tethered to the oi. Then we tether it to the oi and the rc flips out. The programming state is flashing green red and the bot will not do anything. The computer feedback is null and we are stumped. Testing to see if it is the bot we reloaded the norm 3.0 code and it worked fine. We reloaded the 3.0 gyro/encoder code and the bot flips out again. We are stumped. Any advice is helpful

Does the voltage readout on the OI happen to say 8.2 or 8.3?

I’m going to have to agree, sounds like a power on reset. Have you tried replacing the battery?

the battery was reading 13 point something volts with the multimeter (if that is what it is called) and it could not have been battery because we switched back the code to the plain 3.0 and it worked fine

The reason for saying the battery was because the motors might be pulling different numbers of amps with the different code. Some code may be putting a much greater strain on the motors since it is holding an arm in a particular position and this is much more likely to be the encoder code and not the original code.

However, since apparently the battery is fine, I can’t see a reason for this problem. We have had very similar things happen to us in the past but it has always been fixed with a simple battery change. One thing you might check is the resistance of the battery with your multimeter cause if the battery has a bad cell then when the battery has no load it looks fully charged but when put in the bot will drop very low very quick.

If that isn’t it then search me, I haven’t done a huge amount of programing and certainly don’t know the controller as well as I could.

There was a bug discovered with the PIC18F8722 based robot controllers used since 2006. One of the symptoms of the bug is that the voltage will read 8.2 or 8.3 volts regardless of the actual battery voltage. Can you please check to see if this is happening with your controller? Would it be possible for you to zip up your build directory and send it to me?


I have also been having odd errors. The ‘Program State’ light stays lit and the program doesn’t run. The voltage is NOT 8.2.

What is odd is that the only apparent difference between a project that works and the project that doesn’t is that I am using a new project name (Sensors2008 vs ifi_frc).

I have zipped the files and a diff.txt file I generated. There are actually 113 differences, but I can’t seem to see any consistency.

However, in the ifi_frc project, I am able to get the encoder, gyro, ultrasonic detector and Banner IR switch all playing nicely together!

Thank you Kevin.

The difference might be that the build options aren’t the same across the two projects.


I will check tomorrow when we meet Kevin and I can zip up the build directory then and send it to you. Thanks for the help

the two projects are using different lib subdirectories, but that didn’t make a difference.

I attached the zip file with the two projects and diff file.


The problem is that you didn’t add ifi_frc.c to the Sensors2008 project.

Edit: I forgot to mention that you also need to build using the large code and data model.


Thank you! It worked! Also, should we use multi-bank stacks?

actually we fixed the error, there was an interupt channel for the ADC code that we did not uncomment out.