Issues with our code

[Richard McClellan]

We're moving to WPILib this year and are having a few issues getting our code working with the FRC controller. We tested it out quite a bit on the Vex robots last fall and it worked great, but we tried downloading to last year's FRC bot for the first time today and couldn't get it to work.

The code below compiles and downloads, but does nothing after that. We were trying to get basic drive working first with the Tank2 function (We have one CIM motor on each side, plugged into PWM ports 13 and 15). Then we commented out the Tank2 function to see if we could just get the motors to turn on at all with the SetPWM function, and that didn't work either. Any ideas what we're doing wrong?

We are using MPLab v8.00, the C18 Compiler v2.40, and IFILoader v1.10.

#include "BuiltIns.h"

void IO_Initialization(void) {
SetCompetitionMode(1);
}

void Initialize(void) {
DefineControllerIO(INPUT, INPUT, INPUT, INPUT, INPUT, INPUT, INPUT, INPUT, INPUT,
INPUT, INPUT, INPUT, INPUT, INPUT, INPUT, INPUT, INPUT, INPUT);
}

void Autonomous(void) {
printf("Autonomous\r");
while(1) {
printf("In Autonomous\r");
SetPWM(13, 50);
SetPWM(15, 50);
}
}

void OperatorControl(void) {
printf("OperatorControl\r");
while(1) {
printf("In OperatorControl\r");
SetPWM(13, 50);
SetPWM(15, 50);
//Tank2(1, Y_AXIS, 2, Y_AXIS, 13, 15, 0, 1);
}
}

void main(void){
}

[Branden Ghena]

Do you have your robot enabled on the operator interface? (done that WAY too many times)

Otherwise looks good. Are you getting your printf text?

[Richard McClellan]

Yes, our robot was not disabled, but we have make that mistake before too :rolleyes:

We tried it both with and without the autonomous switch on and it didn't work either way.

And, the printf's do work. They run continuously, inside our while(1) loops. It prints "In Autonomous" when the our auto switch is on, and prints "In OperatorControl" when the auto switch is off.

[Branden Ghena]

Are you sure it's not a physical problem?

i.e. are the fuses in, do the victors light up when the program is running, are your pwms plugged in all the way, do you have a fully charged battery?

I know, probably not your mistake, but I can't see anything wrong with the code.

[Richard McClellan]

Well, the Victors are flashing orange, so they're not getting any signal at all. Does WPILib initialize all the pwm's to zero like the default code does? Should these be getting any signal?

We also tried loading our code from last year (default FRC code) and it worked fine, so I'm thinking it's not a hardware problem.

[btgdaniel]

Did you ever get WPIlib to work? We are having the *exact* same problem. No outputs to PWMs, last year's code works fine. A little more info: (1) joystick input seems to work; (2) analog input works.

[Redneck]

We've been having the same problem. Using WPI Lib, we cannot get any output on PWMs 13-16. We tried using the SetPWM() function, along with Motor(), Motors() and Drive(), all to no effect. We also tried using WPI Lib with the IFI header files and setting the PWMs using the aliases from ifi_aliases.h, and again 13-16 are non-responsive. When using the default IFI code by itself, we can control them just fine.

[Richard McClellan]

Well, I'm not exactly sure what we did, but it is working now. Unfortunately, I don't know exactly what fixed it, but here's a few things to check:

Download the latest firmware to the RC, which can be found here:
http://www.ifirobotics.com/docs/frc-master-ver15.zip
Try tethering to the OI at least once first.
The OI needs to be on and communicating properly for the RC to output to anything.
Make sure you have your backup battery plugged in.

[BradAMiller]

There are issues with the PWM ports 13-16 since they are controller by the user processor. Try the program with ports 1-12 instead. I think the motors will start working.

Brad

[Richard McClellan]

That actually makes a lot of sense now! We got our code working on our new RC (using PWM 1&2), but the old one wasn't working (using PWM 13&15). We didn't originally change the old RC ports because on last year's robot it is very difficult to access and requires unscrewing a lot of electronic components. We're planning on making this year's much easier to access.

Does this mean that we will be limited to 12 PWM ports if we use WPILib? Or is there any way to use 13-16? Right now we're only planning on using 10 PWM ports, so we should be okay, but would we have room to expand to more than 12 ports?

[BradAMiller]

Kevin Watson wrote some code last year that allowed control of the extra PWMs in your user program. It works with easyC and WPILib and can be integrated easily into an existing program. You can find the explanation here (http://www.chiefdelphi.com/forums/showthread.php?t=53276).

[btgdaniel]

Thanks, Brad! That new pwm code fixed it! PWM's 13-16 are now good.

[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]

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]

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.