Issues with our code

[Ryan O]

Hi,

We are also having problems with our gyro. I plug it in to port one, as init, start it, ect. It gives zero for awhile, then starts increasing and doesn't stop, even if the gyro isn't moving. Any help would be great.

[BradAMiller]

Originally Posted by Ryan O

Hi,

We are also having problems with our gyro. I plug it in to port one, as init, start it, ect. It gives zero for awhile, then starts increasing and doesn't stop, even if the gyro isn't moving. Any help would be great.

Make sure it's plugged into an analog port rather than a digital port.

The gyro returns the rate of rotation as an analog value - where no rotation is will return a value around 512 (center).

You can easily test if the gyro is working by running easyC and opening the Online Window. Load the Online code into the robot and look on the screen at analog port 1. Now you should be able to twist the gyro (or robot if it's attached) and see the analog values jump from a centered value around 512 to either smaller or larger numbers for left and right twists. Remember, the value will only change while the robot is moving since it is measuring rate of rotation, not the heading.

[Ryan O]

Thank you. It is in an analog port, and we are using the WPILib function GetGyroangle(port), whcih is supposed to give us a heading through integration. Have you had any problems with that?

[BradAMiller]

Originally Posted by Ryan O

Thank you. It is in an analog port, and we are using the WPILib function GetGyroangle(port), whcih is supposed to give us a heading through integration. Have you had any problems with that?

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?

[Ryan O]

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);

[Kingofl337]

Did you call initialize gyro and start gyro?

[Ryan O]

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.

[BradAMiller]

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.

[Ryan O]

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!

[Ryan O]

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.

[lukevanoort]

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.