New C18 3.0+ Compatible FRC Code

[Jon236]

Julan,

Did you define the number of channels in the adc.h file?

Kevin,

The code runs fine if called ifi_frc.hex.....if I change the project in the same subdirectory with all the same files, I get a stuck programming mode light.

So I won't every change the name, but I'd still like to know why this hapens!!

Jon

[1jbinder]

Yes I Did

[sparrowkc]

PLEASE I CANNOT TAKE THIS ANYMORE

Any functions I create return seemingly random numbers

for example I put the function

unsigned int Motor_Limit (int motor)
{
static unsigned int lmnewmotor;
if(motor >= 254)
{
lmnewmotor = 254;
}
if(motor <= 0)
{
lmnewmotor = 0;
}
}

In ifi_code.c and a prototype in ifi_code.h. I call it with
motor1 = Motor_Limit((int) motor1);
where motor1 is a pwm value that may be invalid.


IT ALWAYS RETURNS 1919!!!!


WHYYYYYYYYYY

Is this a bug, I have the sensors version and kevin's site said that it was relatively bug free.


We have a demo tomorrow and whenever I try to run my code the robot goes int a spasm.

[Alan Anderson]

Originally Posted by sparrowkc

IT ALWAYS RETURNS 1919!!!!

How do you know what the return value is? I once spent hours trying to debug a routine that seemed to be returning the wrong value, only to discover that the error was in the line of code that prints the value.

But upon further inspection, the problem with your code is rather obvious to someone who hasn't been staring at it for hours. You merely forgot to return the newly computed value.

[sparrowkc]

I cannot adequately express my frustration with myself and the people here who I asked to check this for error. Thank you for pointing out that I DIDNT HAVE IT RETURN ANYTHING AAAAAAAAAAAAA

[Boku-Ni]

I looked at the link that was provided for a version of C18 other than 3.15 but couldn't find it. Can someone point to me where it is? >.< Any help appreciated.

-- Hank

[Joe Ross]

Originally Posted by Boku-Ni

I looked at the link that was provided for a version of C18 other than 3.15 but couldn't find it. Can someone point to me where it is? >.< Any help appreciated.

-- Hank

The link in the first post for C18 has both 3.10 and 3.15.

[Joe Ross]

Originally Posted by PhilBot

And finally I have

long Get_Gyro_Angle(void)
{
// Return the calculated gyro angle to the caller.
return(((gyro_angle * GYRO_SENSITIVITY * 5L) / (ADC_RANGE * ADC_UPDATE_RATE)) * GYRO_CAL_FACTOR);
}

So, since I've been caught before on this one.. I calculated the value of the divisor of this expression. ADC_RANGE * ADC_UPDATE_RATE = 2048 * 100 = 204800. So I'm dividing a "Long" by this number.... I should be able to calculate the maximum result I can get...

Max Long is 2147483648 so if I divide this by 204800 I get 10485 ... Which, in theory is the maximum result I can get...
But wait, this is millirads so the maximum angle I can measue is... just over 1.6 full rotations...

Oops... Either I did my math wrong, or I have to reduce my update rate.
In fact, this does reflect what I see in my log data... after getting to 10485 mRad, the angle starts counting down again...

So I need to reduce my ADC range/rate, or reduce my measurement accuracy (like changing to tenth of a degree.)

No wonder my bot corrected in the wrong direction on evey second lap

If you move the multiply by 5L to the end of the expression, it should give you 5 times longer before it roles over.

[Kevin Watson]

Originally Posted by PhilBot

No wonder my bot corrected in the wrong direction on evey second lap

So I spent some time working on this yesterday, mostly just understanding how everything works (I wrote this code a few years ago). First, a bit of history: My first cut of the gyro code was included in the scripting code Rich Petras and I released in 2005 and the intent was to reset the gyro angle to zero, have the robot perform a turn, drive straight, reset the gyro angle to zero, execute another turn, etc. In this way, all turns are relative and I didn't need to worry about rollover.

Okay, so yesterday I modified the code to gain more headroom (ADXRS150 w/ default settings rolls over in just over five revolutions) and implemented a scheme where complete revolutions are detected, counted, and then subtracted from the total angle. In this way the number of revolutions is accounted for separately from the angle. The downside is that the code is somewhat bloated and convoluted. I guess I'd like to keep the status quo with additonal headroom and dump the loop counting code, but I'd like to get some feedback on what teams want.

-Kevin

[billbo911]

Originally Posted by Kevin Watson

...Okay, so yesterday I modified the code to gain more headroom (ADXRS150 w/ default settings rolls over in just over five revolutions) and implemented a scheme where complete revolutions are detected, counted, and then subtracted from the total angle. In this way the number of revolutions is accounted for separately from the angle. The downside is that the code is somewhat bloated and convoluted. I guess I'd like to keep the status quo with additional headroom and dump the loop counting code, but I'd like to get some feedback on what teams want.

-Kevin

Thanks for the background description. It helps in understanding how and why the code operates the way it does.

As for feedback;
Honestly, currently we don't have a need to keep track of heading for up to five revolutions. In fact, this year we will really only be expecting the code to track up to one and a half revolutions. So, as it is now, it will work just fine. On another note, I am curious as to the outcome of the question/observation PhilBot had when he posted this"

I think the problem is that GYRO_CAL_FACTOR is defined as 1000/1000, but the multiplication is being done AFTER the prior expression is cast to an integer... Therefore if ((((long)gyro_rate * GYRO_SENSITIVITY * 5L) / ADC_RANGE)) calculates to anything above 32 or below -32, then multiplying it by 1000 will cause the number to exceed the valid range of an integer.

I think the second to last bracket is misplaced... I think it should be:

return((int)((((long)gyro_rate * GYRO_SENSITIVITY * 5L) / ADC_RANGE) * GYRO_CAL_FACTOR));

Is there a problem with the Get_Gyro_Rate() function? We will be depending on it heavily this year, and need it to function correctly.

[Kevin Watson]

Originally Posted by billbo911

Is there a problem with the Get_Gyro_Rate() function? We will be depending on it heavily this year, and need it to function correctly.

Yes, Phil caught an error that would cause the function to overflow if you rotated your gyro fast enough. This is what the fixed code currently looks like:

return((int)(((((long)gyro_rate * GYRO_SENSITIVITY * 5L) / ADC_RANGE)) * GYRO_CAL_FACTOR));

-Kevin

[billbo911]

Originally Posted by Kevin Watson

Yes, Phil caught an error that would cause the function to overflow if you rotated your gyro fast enough. This is what the fixed code currently looks like:

return((int)(((((long)gyro_rate * GYRO_SENSITIVITY * 5L) / ADC_RANGE)) * GYRO_CAL_FACTOR));

-Kevin

Excellent!! We will modify the code accordingly until an updated version comes out!

Thanks again Kevin. Your work is appreciated more than I can express.

[Jon236]

And here is some code to remap gyro values to the standard format


rev = temp_gyro_angle/3600;
if (temp_gyro_angle < 0)
{
gyro = temp_gyro_angle - (3600*(rev));
if (gyro < 1800)
{
gyro+= 3600;
}
}
if (temp_gyro_angle > 0)
{
gyro = temp_gyro_angle - (3600*(rev));
if (gyro > 1800)
{
gyro-= 3600;
}
}
if (gyro > 1800)
{
gyro -= 3600;
}

[TimeOut]

We are trying to compile and down load the base 3.0 code using MPLab IDE 7.62 and the Upgrade version of C18 compiler to 3.10. We tried downloading to the 2006 and 2007 controllers (8722). However, we are getting a code error and the program light is flashing rapidly.

My question is a) can the 3.0 code work in the 2006/2007 controllers? If so, then what other situation may cause the program error to light and program light to blink rapidly?

Edited:
Found the problem. I had forgotten to uncomment the defines in ifi_frc.h; but I had uncommented everything else in the rest of the code. No error messages during the build, but immediately after the the download the controller was crashing.

Also, Kevin, thanks for the great work on the code this year.

D. Sean Kelly
Toltechs #499

MPLab IDE 7.62 C18-Compiler 3.10

[wcarr]

Originally Posted by Kevin Watson

Just FYI, I believe that I have a single version of the code that will work with all robot controllers from 2004 on and can be built with C18 2.4 or 3.1. After seeing if I can improve the gyro integration code (per Philbot's posting above), doing some additional testing, and writing a bit more documentation, I should be able to release the code in the next few days.

-Kevin

Hi Kevin,

I'd like to add my thanks for the great work on the new framework.

We use the 8520 for small groups prototyping code. I know you are working on a set of code that will work for all controllers, but I was wondering if the message you have in adc.c:

* This version will only work with PIC18F8722 based robot
* controllers. You should use version 0.3 of this software
* with a PIC18F8520 based robot controller.

is still valid. And if so, how would I go about getting version 0.3 of the adc.[ch]?

Thanks!