Motor declarations break analog module

[nathanww]

In which team 1678 continues our saga of stumbling across every frustrating bug that exists:

Today I finished tracking down an error that was causing the analog module on our robot to not function correctly(about 90% of the time when you booted the robot, the analog inputs would be unreadable and it would spew "invalid parameter" errors from low-level analog functions). After replacing the hardware(didn't help), testing with sample code(made the errors go away), cutting out various functions(didn't help), reimaging the cRIO(didn't help), and finally going through and commenting/uncommenting everything line-by-line, I discovered that the cause was actually the declarations of the speed controller classes(victors and jaguars) that we were using to control our kicker and climbing mechanisms.


I really have no idea how this could be causing low-level errors in the analog code, but tests confirmed that this is indeed the case. Even more bizzarrely, the RobotDrive class that we have configured for 4-motor tank drive doesn't interfere with the analog system at all!

Does anyone know what might be going on? Right now, we have to choose between using sensors and using motors.

[Alan Anderson]

Which slots do you have the cRIO modules installed in?

Show us the part of the code that makes things break. Try to isolate it to something simple so we aren't too distracted by anything irrelevant.

[Greg McKaskle]

Without viewing the code I'm just guessing, but in my experience, when commenting out code which initializes something and noting bizarre side-effects, it is often useful to look at your compiler warnings or at the code directly for uninitialized variables. The compiler tends to allocate stack variables one after the other except that the optimizer may scramble the order or double up variable declarations. Anyway, if you have an uninitialized variable, these allocations can give your code different behaviors based upon the value that other function calls leave on the stack.

Greg McKaskle

[nathanww]

Our compiler doesn't give us any warnings about uninitiialized variables, do you think it would be worth tracking everything down just to make sure?

Our robot has an analog module on slot 1, a digital module hooked to the sidecar on slot 4, and a relay module and pneumatics bumper on slot 8.

The code we're using(without the irrelevant things that don't make it break) is :

class testRobot : public IterativeRobot
{
	
	//set up roller
	Victor *rollerMotor;
	RobotDrive *testDrive;
	Victor *kickerWinch;
	Jaguar *armWinch;
	AnalogChannel *pot;
        Gyro *angle;
	
public:

	testRobot(void)	{
	
		kickerWinch=new Victor(3);	
		armWinch=new Jaguar(1); //TODO:Fix this so we're using both motorz
		rollerMotor=new Victor(4);
		testDrive=new RobotDrive(5,6,7,8);
		angle=new Gyro(1);
		pot=new AnalogChannel(3);
		

	}
...
void RobotInit(void) {
		testDrive->SetInvertedMotor(RobotDrive::kFrontLeftMotor,true);
		testDrive->SetInvertedMotor(RobotDrive::kFrontLeftMotor,true);
		pot->SetAverageBits(30);
		
	}
...
void DisabledPeriodic(void)  {
		GetWatchdog().Feed();
		printf(" pot=%f\n ",pot->GetAverageVoltage());
	
	}

[Joe Ross]

Why did you choose to set the average bits to 30? By my calculations, you'll get a new value every 4 hours or so (if the FPGA even supports a value that large). A more reasonable value is 10, which will get you updates at about 50hz.

If you actually wanted it to average 30 samples, you should set the average bits to 5, since 2^5 is 32.

[nathanww]

I beleieve the person who put that in thought that 30 bits=30 samples, or she might have just been testing an extreme amount because we were having problems with noise on the input. I have to check with her, though. In any case, the FPGA seems to be limiting it to a more reasonable number since the update rate is at least 10 hz.

[nathanww]

And it is fixed!

What happened, we believe, was that the 30-bit averaging, combined with the motor stuff, was using too much FPGA memory and the errors that we were getting were the result of an out-of-memory condition. The system now works after we reduced the averaging bits to 10.