Re: The 8.2 (or 8.3) Battery Voltage Bug
 

That bug hit us once and disabled us for a round at PNW, but we have found a way to avoid it. When we turn our robot on at the beginning of the round we have someone at the OI looking at the battery voltage to give us a thumbs up or down depending on whether it is showing ~12 or 8.2. If we get 8.2 we just power cycle (not just reset, because that screws up the camera). It saved us at least once later on.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Thank you for the information. Outside of the interupt driven code you wrote we did not use any interupts this year. I am trying to debug the issue to save teams from having this happen to them but all i have is info from debugging today, the last day of our regional, the code we used, and some video of the bot. IFI has recognized a problem with the interupts and that was why i was quick to jump to that conclusion. I wish i had the RC with me to test more but i dont. I havent been able to find out why this would just start happening. The code we were running when we got this error was your camera code with a modified default routine. Sachiel7 can confirm that for us. Sachiel7, if you have any more info please tell us.

EDIT: gobeavs, we have had that work also. That is a temporary solution. It doesnt solve the root of the issue which is what we would really like to happen. Can you supply more info on what the code you were running was.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I will continue to be a "Graciuos Professionalist" and not make any comments. Chief Delphi is a great community and flaming rarely occurs. Please do not make comments like that to me and others that spend our time trying to help others.

EDIT: D.J. Fluck, thank you for removing his post.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I was just lucky (or unlucky) enough that this bug kicked in while I was bench testing. It seems that the 8.2 battery voltage is really the reading of the p4_wheel. As you move the joystick 4 wheel, the OI battery voltage changes. The p3_wheel is mapped to the backup battery voltage (as shown from the data in the dashboard). the p1_x axis now maps to the joystick #3 switches. I can't say exactly what works and what doesn't as I was just reading what I was sending back from the RC to the OI from the dashboard and didn't really map all the joystick data to the user_bytes/pwm values. A reset doesn't work, but a full power down did (although I know that it doesn't always from previous testing). I do know that one of the joystick ports seemed to be mapped to the "disable" flag (not sure which one), so it's quite likely that the "autonomous" flag was also messed up.

Mike

Correction - Rather than the p3_wheel & p4_wheel, it is actually the p3_aux and p4_aux.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Interesting, Ill have a look. We decided early today to use are port 4 wheel for launcher wheel PWM. This could be part of the problem. Ill try and have that check out.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Maybe im just a little stressed from competition today, but you just joined today and made 5 rude posts that are bettering the community in anyway. If you dont stop i exspect to see an IP ban soon.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

To get back on topic real quick, has anyone had this error with the v2 Camera code?
Just wondering....
We used v1 because for some reason were having a few issues getting v2 going at comps, and reverted to the streamlined v1, because that's what we had working.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We are running code based off of Kevin's camera code, I think v1.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

What issues did you have with version two?

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

The problem appears to be some form of memory stomping, in the IFI default
code, or in the controller chip itself. I don't believe that it is a bug in the
camera code per-se, although the use of the camera code increases the
severity of the problem. We backed out of all of our interrupt/timer based
control at the Portland regional in response to this problem as there was
no way we could keep our robot running otherwise. We have seen problems
in very simple code. Below are the only lines of custom code, using
the recently published default code.

At one point whether or not the periodic printf statements appeared on
he download console depended upon whether or not we had
static int counter;
or
static int counter = 0;
for the declaration of "counter". This problem comes and goes over
a day, in the morning it is consistent but when attempting to reproduce
it with the same code in the afternoon one can't after several tries.
I am presuming that the memory location
of "counter" moves between the implicitly initialized segment, from the
explicitly initialized segment, with the declaration change and this changed
the arrangement of memory. Whether or not memory is actually getting
stomped is something a little more random in the controller.

An option question is, given the problems with the 2006 controller,
whether or not FIRST would be willing to allow the use of the 2005
controller at regional events. We have not seen any of these problems
on the 2005 controller.

Eugene



/************************************************** *****************************
* FUNCTION NAME: Process_Data_From_Master_uP
* PURPOSE: Executes every 26.2ms when it gets new data from the master
* microprocessor.
* CALLED FROM: main.c
* ARGUMENTS: none
* RETURNS: void
************************************************** *****************************/

struct rpmpower {
int rpm;
int power;
};
/* This table is constructed by using the manual RPM control to set
RPM values manually and then reading off the required power for that RPM.
*/
#define RPMPOWERTABLESIZE 9
struct rpmpower rpmpowertable[RPMPOWERTABLESIZE] = {
1300, 160,
1400, 161,
1500, 167,
1600, 168,
1700, 170,
1800, 177,
1900, 181,
2000, 189,
2100, 193
};
int RPM2Power(int rpm) {
int RetPower;
int i;
if(rpm <= rpmpowertable[0].rpm) return rpmpowertable[0].power;
if(rpm >= rpmpowertable[RPMPOWERTABLESIZE-1].rpm) return rpmpowertable[RPMPOWERTABLESIZE-1].power;
for(i=0; i<(RPMPOWERTABLESIZE-1); i+=1){
if(rpmpowertable[i].rpm < rpm && rpmpowertable[i+1].rpm >= rpm){
RetPower = rpmpowertable[i].power + ((rpm - rpmpowertable[i].rpm) * (rpmpowertable[i+1].power - rpmpowertable[i].power)) / (rpmpowertable[i+1].rpm - rpmpowertable[i].rpm);
break;
}
}
return RetPower;
}


void Process_Data_From_Master_uP(void)
{
int Target;
int BallWheelPower;
static int counter; /* Does not work if not initialized to zero! */

Getdata(&rxdata);

/* Control of the drive motors.
*/
if(rc_dig_in08 == 1) {
pwm01 = p1_y;
pwm02 = p3_y;
pwm03 = p1_y;
pwm04 = p3_y;
}
else {
pwm01 = STOP;
pwm02 = STOP;
pwm03 = STOP;
pwm04 = STOP;
}

/* Pan Control
*/
if(p3_sw_trig == 1 && rc_dig_in12 == 0) {
pwm06 = STOP + 20;
}
else if(p2_sw_aux2 == 1 && rc_dig_in11 == 0){
pwm06 = STOP - 12;
}
else{
pwm06 = STOP;
}
if(rc_dig_in06 == 0){
pwm06 = STOP;
}

/* Ball lift control.
*/
if(p2_sw_top == 1 && rc_dig_in07 == 1) {
pwm05 = 254;
}
else if (p2_sw_trig == 1 && rc_dig_in07 == 1){
pwm05 = 1;
}
else {
pwm05 = STOP;
}

/* Ball wheel speed control.
*/
Target = (int)1200 + (int)3 * (int)p4_x;
BallWheelPower = RPM2Power(Target);
if(rc_dig_in10 == 0) {
pwm07 = STOP;
}
else {
pwm07 = BallWheelPower;
}

/* Ball shooter fire control
*/
if(p2_sw_aux1 == 1 && rc_dig_in09 == 1) {
pwm08 = 254;
}
else {
pwm08 = STOP;
}


if(counter % 40 == 2) {
printf("p1_y = %d, p3_y = %d, BWP = %d, TargetRPM = %d, p4_x = %d\r",
(int)p1_y, (int)p3_y, (int)BallWheelPower, (int)Target, (int)p4_x);
}

counter += 1;

if (user_display_mode == 0) {
if(rc_dig_in12 == 1) { /* Right pan limit. */
Switch1_LED = 1;
}
else {
Switch1_LED = 0;
}
if(rc_dig_in11 == 1) { /* Left pan limit. */
Switch2_LED = 1;
}
else {
Switch2_LED = 0;
}
}
else {
User_Mode_byte = backup_voltage * 10;
}

Generate_Pwms(pwm13,pwm14,pwm15,pwm16);

Putdata(&txdata); /* DO NOT CHANGE! */
}

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Not really any issues. v2 is only for the bells and whistles. Which as it names syas has alot of features and we were using teh features so the code was a waste and took awhile to put on the RC. So we just went back to useing the streamline version.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

What happens if you move the "static int counter" outside of the Process_Data function?

Also, you may want to add the "rom" keyword to the rpmpowertable statement. It then becomes one less thing that could be overwriting other variables (As it would be stored with the actual program, rather then other variables)

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Our robot died three times during autonomous at BAE, and this was one of the symptoms at the time (main battery voltage reading as 7.75 volts on the OI). Eventually, the IFI rep requested that we (a) double-check our code (see other thread), and (b) use a loaner RC.

Interestingly, when I was double-checking the code after the first autonomous failure (still on our original 2006 RC), one of the first things I did is revert to a code version that doesn't use any of the camera code (but does use Kevin's ADC code), and we still had this problem. We also saw it on one of the loaner RC's (an upgraded 2004) as well, using both our code and the most recent default code to which we had added a single printf() reporting the battery voltages. The final loaner RC didn't show any problems .

So I've seen this problem on both our original 2006 RC *without* the camera code (using a fresh copy of Kevin's Gyro code with our default routine and autonomous added), and even on one loaner RC with default code (although other teams had reported problems with this loaner RC). So I'm guessing it's something with the interrupt handler (since we're using Timer 2, and the two sets of serials interrupts)? The serial code is common between the camera code and the gyro code.

I'm wondering if there is some sort of memory stomping happening, because I've also seen some random bits flicking on the OI status leds (the pwm and relay leds; we had disabled the default routine LED feedback on these to make a little bar graph showing how good the camera lock was, but after we pulled the camera I pulled the code for this as well, and we still would see random bits flicker in there).

I'm interested in solving this, since we had three matches that we lost basically since we died during autonomous (and were non-functional the rest of the match), and a fourth in which we competed with a 100% dead bot (since we pulled the RC to replace it with a loaner, but the first loaner was DOA, and we didn't have time to put the original RC back in). We still got five points with our bot that round (an alliance bot pushed us up on the platform...), but considering that we have a really good ball launcher, it rather stank that we couldn't run most of the time.

Unlike most teams, I now actually have the 2006 RC in my possession (a replacement is coming from IFI), although it's going to IFI this week once I get an RMA. Anything I should try checking with it?

In any case, if someone would like a copy of our code (that showed the voltage bug on two different RCs), or has some ideas, I'd like to know.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

When you say "default code", do you mean the default code from IFI's website or do you mean code from my website?

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

A fresh copy that I downloaded from IFI's website during the competition (http://www.ifirobotics.com/docs/frc-code-2-28-2006.zip). However, that RC was suspect (every once in a while the printf's would produce garbage).