Re: Issues with our code
 

We use those functions all the time. Can you use some print statements or the easyC online window to verify that the gyro is working properly?

Re: Issues with our code
 

Our code currently uses the following to output in an infinite loop in operator control:

printf("Gyro Heading: %d",heading);

Where heading is an int assigned:

heading = GetGyroAngle(GYRO_PORT);

Re: Issues with our code
 

Did you call initialize gyro and start gyro?

Re: Issues with our code
 

Here is the code so far:

Our file, ConstantsandControl.h:

#ifndef Constants_Control
#define Constants_Control

//Constants
#define AUTO_FIELD 1
#define INFINITE 1

//Ports
#define GYRO_PORT 1

//Controls

#endif


The run file, main.c:

//Define robot type(FRC vs. VEX) (Done only once)
#ifndef _FRC_BOARD
#define _FRC_BOARD
#endif

//Include features
#include "BuiltIns.h"
#include "Constants_Control.h"

//Setup competition mode, called first
void IO_Initialization(void)
{
//Set to automatic competition mode handling
SetCompetitionMode(AUTO_FIELD);
}

//Initialize: run at robot startup regradless of mode
void Initialize(void)
{
//Initailize Sensors
SetGyroType(1,80);
InitGyro(GYRO_PORT);
}

//Note: will switch between auto and operator automatically,
//even if the code is currently in an infinite loop

//Autonomous: run at field control enable
void Autonomous(void)
{
int heading;
StartGyro(GYRO_PORT);

while(INFINITE)
{
heading = GetGyroAngle(GYRO_PORT);
//Print
printf("Gyro Angle: %d\r",heading);
}
}

//OperatorControl: Teleoperated period
void OperatorControl(void)
{
int heading;
StartGyro(GYRO_PORT);

while(INFINITE)
{
heading = GetGyroAngle(GYRO_PORT);
//Print
printf("Gyro Angle: %d\r",heading);

if(heading < 0)
{
heading = heading * -1;
}

SetPWM(1,heading);
}
}

//Main: Satifies call requiremen only, unused
void main(void)
{
}


Thats the code.

The only warning we get on compile are qualifier mismatch in assignment, and we get two of them on the line that assigns GetGyroAngle to heading.


EDIT: That Setpwm thing was our way of testing if the printf was the problem. We just hooked a servo up to it ans tested to see if it moved t all when we moved the gyro.

Re: Issues with our code
 

I was able to test the code quickly on a Vex controller (changed _FRC_ROBOT) and it works as it should. It printed gyro angles for both autonomous and operator control and the motor started going once it hit operator control.

You mentioned that you're getting an warning about a type qualifier mismatch on the GetGyroAngle calls. I'm not sure why you're getting that and I don't see it here.

I'll see if I can put something together with an FRC controller, but I might not be able to do that for a while.

Re: Issues with our code
 

Is it possible I accessed something VEX specific? The output we get sometimes cuts itself off (Gyro AngGyro Angle: 0). It usually does all zeros, but the second time we tried it it just started incrementing and wouldn't stop. Also, I know that this year it is a different gyro. Is there something different in it that doesn't like WPILib? The papers for it said everythingis the same except the resolution, whch is down to 80 deg/sec from 150 deg/sec. I tried using the SetGyroType function, inputing 80, seeing as the WPILib papers said that the input number is the resolution.

Thanks for all the help!

Re: Issues with our code
 

I will be making a thread on this in programming, but we believe we have found the problem. THIS IS VERY IMPORTANT FOR GYRO USERS THIS YEAR!

While trying to help me figure out what was going on, one of our team members made the very interesting observation that there were many more paths leading to what we believed to be the temperature read port (with a T over teh white wire instead of an R) than to the port we thought was the Rotational Acceleration port. he then remarked that thee have been times when a board has been mislabeled. So, for the heck of it, and for lack of anythign else to try, we plugged the T port into the port we were using for the R port, with the code above. Low and behold, it started behaving like we thought the R port should have. It got larger to right, smaller to left, and held a value when it wasn't moving. Also, the numbers were roughly tenths of a degree counts from the starting point (90 degrees was about 900 counts).

So, we think that at least a few if not all of the new gyros this year (They are different from last year) could have been labeled wrong or with different conventions than last year (t doesn't stand for temp anymore, but Twist?) Either way, if you are experiencing problems similar to those we had described previously, give it a shot, it won't hurt the board if the controller doesn't know what to do with the signal it sends.

Re: Issues with our code
 

They aren't mislabeled, they are just confusingly labeled, which is effectively the same thing. IIRC, the "T" stands for "Twist" and the "R" stands for "Relative Temperature." Personally, I think A for rotation (standing for angular velocity) and T for temperature would make the most sense, and cause the least confusion.