Quote:
|
Originally Posted by Al Skierkiewicz
Gene and Mark,
Does the OI report normal battery when not running the code? This is very interesting since the RC is on the hairy edge of reset at 8.2 due to the dropout restrictions of the internal regulator. Are you running the IFI backup battery charger circuit as well? When you measure the main battery are you at the battery or at the RC terminals?
|
We measured our main battery voltage during one of these events and it was 12.6 volts at the power terminals of the RC.
We are not running the IFI backup charger circuit, we just keep our backup batteries swapped every match. It could very well be the backup battery voltage that is appearing on the user display, but this line of code is not in our program, we are using the user mode display to provide height information from the camera and rpm information, not the backup battery voltage.
As noted by others above, the problem seems related to some memory stomping that is going on and small changes to the code that move things around in memory cause the problem to come and go. We have seen wierdness on this front even when using a non-interrupt open loop code
for all controls. We have a "static int counter" in our main loop, used
to control printing every 40 trips. When we used
if(counter % 40 == 2) { printf(...); }
we lost our prints. When the counter was explicitly initialized
as "static int counter = 0;" the prints came back. The prints would
come and go with the "= 0" in the code to initialize the counter. Either
the compiler is not correctly initializing the static variables that are
not explicitly initialized, or the memory movement that might be caused
by the variable landing in a different segment, the one with explicit inits,
caused a memory stomping problem to go away. Remember, this
was with the new default code and simple open loop feedback control,
no use of timers or interrupts, beyond what is in the default code.
Given this experience, we went through the Kevin's camera code and
explicitly initialized all of the non-array static variables, and the resulting
binary locked up our RC with a programming light on, but it would not
load a program. Holding down the program button for the time period that
is normally takes to get the programming light allowed us to get a
the non-interrupt code back in place.
So, either the compiler or RC is not properly initializing implicitly
initialized static memory, or memory stomping is occuring even
with the default code... We are pretty skittish at changing the
code at this point, given that we need the robot working for matches
at the Portland regional, but given the fault that has appeared with the
static counter in the default code we may spend some time exploring
how this fault is affected by adding more variables before and after
the counter, to move it around in memory.
I would really like to be using the 2005 controller. We have some really
nice automatic aiming and ranging code that uses the camera, but we
can't trust that it will run reliably enough to use it in a match. The interrupt
based code on the 2006 controller would
have to get through an entire Thursday, while making code changes, without any of this kind of faults for us to trust it for a competition match.
Eugene