Re: New C18 3.0+ Compatible FRC Code
 

It's the ifi_frc_encoder_beta oput of the box....using the 3.10 compiler and 8.0 MpLab

Re: New C18 3.0+ Compatible FRC Code
 

It builds just fine for me. Make sure the tool suite is set correctly and then use the project wizard to rebuild your project.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

I re-installed 3.10 and it worked just fine!

Thanks for all your work!

Jon

Re: New C18 3.0+ Compatible FRC Code
 

Interesting. You're suggesting I run another timer at 100hz, and use one to time the calls on PWM() and the other one for timing the calculations, right?
I think I might have a simpler solution. I have the ISR that calls on PWM() to set another flag high (not the interrupt flag), and check that flag in the _Spin() functions. As a result, assuming the calculation runs fast enough, I'll be one cycle behind, which would probably be the case either way. Does that sounds like it could work?

Thanks.

Re: New C18 3.0+ Compatible FRC Code
 

In testing the code on my test system, this change to the ADC.c code made about 1% saving it time...

Re: New C18 3.0+ Compatible FRC Code
 

I really appreciate what you are doing, and i don't mean to ask for more, but would it be possible for you to create diff/patch files when you release a new version, to make updating our code easier?

Re: New C18 3.0+ Compatible FRC Code
 

I was attempting to understand what the PHASE B was, i now know, and was just expressing how i was going to do it with out it in my specialized case. That code you wrote is exactly what i had described, and what has been in our code for a while now.

Re: New C18 3.0+ Compatible FRC Code
 

It's nice to know that great minds think alike :yikes:

I can, with 90% certainty, say that this year we will be using both of the GTS's and one quadrature encoder on our bot. Two for the drive, one for the "ball handler". Now, if the budget allows, we may go with three quadratures. (I hope, I hope, I hope :) )

Re: New C18 3.0+ Compatible FRC Code
 

My thought was to not even have an ISR and just keep an eye on your 100Hz timer interrupt flag with code located in teleop_spin() and/or autonomous_spin(). Just setup and start a timer, but don't set the interrupt enable bit to one, which will prevent the processor from calling the low priority ISR. Then with code like this in *_spin():

if(INTCONbits.TMR0IF)
{
// Get encoder counts

// Calculate position/velocity

// Do PID calculations

// Update PWM values

//reset interrupt flag
INTCONbits.TMR0IF = 0;
}

...you can implement your 100Hz contol algorithm.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

thank you kevin! i compiled, and everything checks out!

Re: New C18 3.0+ Compatible FRC Code
 

Ahh. I understand. No ISR at all. That would make it run slightly slower than 100hz, but will probably help performance slightly (due to the lack of the ISR). Thank you very much.

EDIT: Actually, I am not sure if it will run any more slowly at all. This looks great.

EDIT 2: Timer 0 does not seem to have the support to run to a predetermined value like timers 2,3,4. Should we use timer 2 instead? Another question. None of these timers actually allow us to run a 100hz cycle, even with 1:16 pre- and post-scalers. The slowest we can do is 150hz. Am I missing a way to do it, without using a second flag, or should we just use 150hz (or a double flag)?

EDIT 3: I just ran into another potential obstacle. Our calculations say that we will get at most 15 ticks from the encoder per cycle. That does not seem like a very high resolution. We're currently trying to see if this will actually be an issue, and if so, what we could do about it.

Re: New C18 3.0+ Compatible FRC Code
 

I see the linker problem when enabling some but not all of the encoders in the 3 to 6 range.

Chad

Re: New C18 3.0+ Compatible FRC Code
 

The ISR linker issue occurs if encoders_3 and beyond are enabled because...

ENABLE_INT_3_6 must be defined in ifi_frc.h, in order to use encoders in the range 3_6

This causes 'calls' to the ISR routines from ifi_frc.c lines 326 to 338.

But if this code block is enabled, all the interrupt code must exists in encoder.c.

That only happens if ENABLE_ENCODER_3 through ENABLE_ENCODER_6 are ALL defined in encoder.h which compiles in ALL the ISRs in encoder.c.

The define hierarchy needs to be fixed, or use all of 3_6 ISRs or none of them.

Chad

Re: New C18 3.0+ Compatible FRC Code
 

Yep, it doesn't quite work correctly. Thanks for catching my gaff. I'll have an update probably tomorrow.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
First I would like to say, Thank you in advance.


Is it possible that once you make this modification to the project files and post them, that you could also list the files that were modified so we would be able to just copy the modified files into our already customized projects and then just rebuild. It would save quite a bit of time if we didn't have to make all the customizations again. If not, no sweat, we could always use the practice. :cool:

Re: New C18 3.0+ Compatible FRC Code
 

Does it give anyone heartburn if I just release one build for each of the two compiler versions that has support for the ADC, gyro and encoders already built in? You'd be able to remove funtionality by commenting out a few #defines.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I have no problem with that.

Re: New C18 3.0+ Compatible FRC Code
 

IMHO, that would be ideal!!!

I don't mind hacking together various functions, in fact, I have learned a lot by doing this in the last couple years. But, if it is together already, it would be VERY convenient! ;)

Re: New C18 3.0+ Compatible FRC Code
 

I know this might be kinda random, but does anyone know if we are allowed to use any kind of gps system in our robot sense it's location on the field?

Re: New C18 3.0+ Compatible FRC Code
 

This seems like a more efficient approach for both you and people using the code.

Re: New C18 3.0+ Compatible FRC Code
 

This post is irrelevant to this topic, but in any case GPS is too inaccurate for this use. Also, it involves receiving external communications, which I understand is against the rules.

Re: New C18 3.0+ Compatible FRC Code
 

Excellent idea!

BTW, would you think that using 4 interrupts,INT's 3-6, at 128 ints/sec (every ~8ms) would be overstressing the processor? My students want to control our mecanum drive with an encoder on each wheel; I favor the gyro approach.

Thanks again for your work for the teams!

Re: New C18 3.0+ Compatible FRC Code
 

How are people implementing these updates?

Re: New C18 3.0+ Compatible FRC Code
 

We would definitely prefer it that way.

Re: New C18 3.0+ Compatible FRC Code
 

That sounds good. Doing code management through a one way CVS or some such code repository arrangement where our work can be locally merged but we can stay up to date with you would be nice :)

Chad

Re: New C18 3.0+ Compatible FRC Code
 

We're testing the new gyro code, but it overrides all of our commands and sets our pwm outs to 0. Once we put anything referencing the pwm outs we're using, it messes them up. We searched through the code, but we can't find anything that might be causing this. Has anyone else come across this problem?

Re: New C18 3.0+ Compatible FRC Code
 

Assuming you're referring to my code, what makes you think the gyro code is causing this? Can you use the "Find in files" search tool to find all instances of the PWM variable that's getting fragged?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

We tried that on Monday. I don't have the results in front of me now, but they were all just definitions. I suspect it has something to do with the gyro code (as downloaded from this thread, not added in by us), as the plain C18 3.0 code doesn't cause this problem. We got this bug on 2 occasions, each time starting from scratch, adding only a few lines for straight joystick-to-PWM drive code, as well as removing the gyro calibration in one instance.

Serial Ports
 

Kevin:

Is there a hard limit at 128 bytes in the Serial Queue's??

RX_1_QUEUE_SIZE 128 // Must be a power of two (i.e.,8,16,32,64,128)

Re: New C18 3.0+ Compatible FRC Code
 

(This may be a little bit of a tangent.)

I'd like to report to anyone who's interested that the C18 3.10 compiler works just fine under Wine (on Linux), after fixing one minor issue.

I had v 2.4 working under Wine. I ran the upgrade, and then things did not work. I don't remember the exact error, but it did not compile successfully. I copied my mcc18 directory from one machine (where I'd run the upgrade) to a different machine, and it worked fine on the new machine. I then copied my ~/.wine directory from the new machine back to the old machine, and the compiler worked fine.

If you plan on using v 3.10 under Wine, my recommendation is to do one of the following:
- Run the upgrade on a Windows machine, and then copy over the mcc18 directory to run it under Wine
- Make a backup of ~/.wine, then run the upgrade program under Wine, then restore ~/.wine.

Re: Serial Ports
 

Unless you want to hack the linker script, I suspect the upper limit would be 256. Just out of curiosity, why do you need such a large buffer?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I can't think of anything in the gyro or ADC code that would cause this, but I'd be very interested in finding out if it's something knuckle-headed I'm doing in my code. Which compiler are you using and which robot controller are you using (i.e., what year is it from)? Can you zip up your code and send it to me?

-Kevin

Re: Serial Ports
 

I don't, just wanting to know the limits of your code...

thanks...

Re: New C18 3.0+ Compatible FRC Code
 

I vote for the "All in one" solution..... saves me from having to combine them (which I have a high probability of screwing up).

Phil.

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
This is just a thought and should be implemented by teams as they feel their needs require.
In the teleop.c file, you currently have the gyro bias calculation process happen in the Teleop function.

This may be fine in some instances, but in competition, the robot is powered up in disabled mode, then transitions into autonomous(Hybrid) then back to disabled and finally into teleop. The gyro bias would never be calculated until well after it may be needed.
Wouldn't it be better if this code were placed in the disabled.c file in the Disabled function. An additional flag could be set to prevent the bias calc process from running during any additional disabled periods.

Re: New C18 3.0+ Compatible FRC Code
 

I had a look at your code and it looks like the problem is your limit() function, which is returning a 16-bit integer when it should return an unsigned 8-bit byte. You also had semicolons immediatly after your if statments:

Your code should probably look like this:

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I've already made this change and provided a sample calibration routine in Disabled(). You're waiting because I'm deep in procrastination mode and haven't finished the first cut of the documentation yet <grin>.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin, I think you forgot to remove the semicolons after the IFs in your reply. I think you meant it to be

Re: New C18 3.0+ Compatible FRC Code
 

Thank you. I thought it was probably something stupid I did.

Re: New C18 3.0+ Compatible FRC Code
 

Ahh, my devious little plan succeeded and I verified that at least one person is awake and actually reading the programming forum.

Dave, thanks for catching my gaff <grin>.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

This is probably one of the big things to watch for, even for experienced programmers. The MPLAB/PIC18 platform (and embedded platforms in general) are a lot less tolerant of type mismatches than your usual programming.

Re: New C18 3.0+ Compatible FRC Code
 

I think someone needs to pull a high priority interrupt and put everything else you are doing on hold! This should be your top priority, cuz I said so.:p

"Procrastination mode" I wonder if FIRST will use that to replace Hybrid mode next year?

Re: New C18 3.0+ Compatible FRC Code
 

Well, in the past, the difference wouldn't be very noticeable...

Re: New C18 3.0+ Compatible FRC Code
 

I depends on what else is executing on the processor, but in general you shouldn't have a problem.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Okay, here is a snapshot of the current build that includes support for encoders and gyro:

http://kevin.org/frc/ifi_frc_beta_4.zip

*Please* help me out and have a look at the code and documentation (start with readme.txt) and provide feedback before I go public with the code on my website, which I'd like to do on Friday or early Saturday. If you can, follow the directions in readme.txt to build the code and test with your encoder(s) and/or gyro and report any problems here. Thanks.

-Kevin


Edit: Code has been released and is available here: http://kevin.org/frc.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
In your gyro initialization code in teleop.c, you have two static ints that you use as counters. (i, j) You increment both every time through the function. When you wish to print out the gyro you have the following:
Since i has been incrementing all along, it will be equal to j. The next time i == 35 j will also be equal to 35. Putting i = 0 into the body should fix that. You also need to put i = 0 into the body of the statement if you aren't using the encoder code.

Re: New C18 3.0+ Compatible FRC Code
 

Thanks, I'll have a look to see if I can clean it up a bit.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

In the README.TXT, in the section to enable the ISR's in ifi_frc.h, (bullet # 3)the description is misleading, or the file is incorrect.

When looking at the file, the lines do not indicate that you are enabling an ISR.
Documentation error, code error, reader misunderstanding error???

Re: New C18 3.0+ Compatible FRC Code
 

Given the comments above and alongside those #defines, I don't see how a user wouldn't be able to figure it out:

I'd be happy to change it, but I don't fully understand the problem...

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I just saw the answer in encoder.c.
Sorry for the confusion. My bad.:mad:
I hate it when I misinterpret instructions like that. Oh well, blame it on sleep deprivation.;)

Re: New C18 3.0+ Compatible FRC Code
 

Is it recommended to use this code over the default, or should teams wait to use until it's out of its beta stages?

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

what changes should be made to the Vex C templates to run under 3.10? I'm getting library errors.

Re: New C18 3.0+ Compatible FRC Code
 

The library needs to be built with the new compiler. Until then we're stuck with C18 2.4.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Can we use MPlab 8.0 to use 3.10 to compile? I need to know Because I cant find 7.21

Re: New C18 3.0+ Compatible FRC Code
 

Yes. That's the exact setup I'm using.

Re: New C18 3.0+ Compatible FRC Code
 

Ok, I have a question (more of a comment really), but I was hoping someone could either verify my understanding, or explain what I'm missing.

It seems the current gyro code as well as some things others have mentioned depend on putting processing code inside one of the Spin functions.

Generally speaking, the spin function will be executed at a very high rate (essentially only processor-limited). However, at roughly 38Hz, the spin function is going to get delayed by however long it takes to run your general execution code, e.g., Teleop(). If this code is simple and runs quickly, this isn't likely to be too much of a problem.

However, there is still going to be some delay associated with this code, let's call it T_d. Now, the frequency, 1/T_d is going to be important because it's actually the maximum frequency we can count on our spin function to run at over any arbitrary time interval.

Right now it looks like we are processing our Gyro at 50Hz? (800Hz / 16 samples per update). This means we need to make sure that T_d < 20ms or else we will occasionally miss gyro samples.

I agree that if T_d is pushing 20ms, you're probably going to have other problems since that's a lot of computation going on. I mostly wanted to clarify this in the case someone was thinking about trying to sample an analog signal at a data rate higher than 1/T_d (probably somewhere in the 800Hz - 6400Hz range), and still do the processing in the spin loop. In this case they might start seeing data go missing every once in a while.

I guess my question then is why do we count on the spin code to do our processing since it's timing seems potentially sporadic. Wouldn't it be better to just do the gyro processing in the ISR alongside the analog-to-digital conversion? Then we would have high-frequency reliable processing of the gyro (or whatever other analog sensor we are processing), without having to worry about anything other than keeping our Teleop() execution time a decent amount under the theoretical limit of 26 ms.

Re: New C18 3.0+ Compatible FRC Code
 

Your average does need to be less than 20ms over time, but it's 40ms before you actually miss data. Agreed. If the execution rate is somewhere between five and ten million instructions per second, you can, on average, execute somewhere between 100,000 and 200,000 instructions per Teleop() loop even with the ISR overhead. If you're trying to execute 100,000 instructions in the Teleop() loop, missing an occasional ADC update is the least of your problems. I didn't point this out in the documentation, but you can determine if you're dropping data by testing the value returned by Get_ADC_Result_Count(). If it's two or greater, you're dropping data.

As I've stated elsewhere, I test the code with the ADC running at 6400Hz/4 samples per update, one encoder generating several hundred interrupts per second, several printfs generating a lot of telemetry in the Teleop() loop and as far as I can tell, everything works just fine (with the old 2.4 compiler I do see an occasional corrupted telemetry packet for reasons I don't fully understand; code generated with the 3.1 compiler doesn't have this problem).

Like I said above, I think (er, hope :) ) it's a non-problem.

This is how my code worked originally. The downside is that it's a lot of code to execute in a ISR and the ADC was dedicated to the gyro and nothing else could be sampled. After getting many requests, I split the ADC code away from the gyro code and provided a API to the ADC so that other sensors can be used alongside the gyro.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Thanks for the response Kevin. Sounds like my fear (and interpretation of the code) was mostly right, but as I was hoping, also completely unjustified :)

This looks like a great set of code and I'm very excited about getting a chance to play with it soon -- things have come a long ways from where they were in 2002... I think we were screwing around with PBASIC back then.

I'm missing most of the competition, but I'll be hanging around my old team for their last week and a half or so. Plenty of time for last-minute debugging of the software.

Kind of funny... doesn't seem to matter what robotics project I'm helping out with: DARPA Grand Challenge, or FIRST robotics... Kevin Watson manages to be involved and giving advice :)

Re: New C18 3.0+ Compatible FRC Code
 

After a bit of tuning, you can get fairly spectacular results with the robot controller. As an example, I have a Silicon Sensing Systems' CRS03-02 gyro attached to a servo which is programmed to rotate such that the gyro will always point in the same direction (here's a low quality movie of it in action). Anyway, the cool part is that it ran for nearly two hours today and the gyro only drifted a maximum of two degrees over that period. It's kinda neat.

Hey, say hi to your Dad for me. We had a nice discussion at the San Jose regional a few years ago <grin>.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

Upgraded to the final 3.0 version....now I get a RLOD with just 1 encoder enabled.....what can produce this condition?

Re: New C18 3.0+ Compatible FRC Code
 

Did you enable the ISR in ifi_frc.h?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Nope.....I knew we were missing something!

Thanx!

Re: New C18 3.0+ Compatible FRC Code
 

Yeah, we got this same issue today when enabling another encoder. Maybe a comment next to the #define ENABLE_ENCODER_# is in order to remind people to enable the ISR in ifi_frc.h?

Re: New C18 3.0+ Compatible FRC Code
 

I must be missing something simple. I am using your code that is a couple of versions back, and when i enable the gyro code, all i get is this:

Gyro Bias=-1
Gyro Rate=0
Gyro Angle=0

after it has initialized
I then pulled your most recent code enabled the adc and the gyro in both spin and teleop the code compiles correctly, but soon as i load it, i get a code error.

Re: New C18 3.0+ Compatible FRC Code
 

Did you follow the instructions in readme.txt step by step?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I got my code to work, there was an ifdef that i had written that blocked out part of the init, but the new code still fails to load.

Re: New C18 3.0+ Compatible FRC Code
 

Can you send me your code?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

The code that I cannot get to load is the code off of your webpage 1/20/08 both with and without the gyro enabled
My code based off of the older version is working fine.

Re: New C18 3.0+ Compatible FRC Code
 

When you say "I cannot get to load is the code..." are you getting the red-light-of-death, the LEDs are green, but nothing happens, or is it just not compiling?

Make sure you're performing all the steps documented in readme.txt.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Red light of death. Code compiles fine. I then go into programming mode open the loader give it the hex file and it attempts of load. The file is loaded in, but the code error light stays solid, reset, same thing. It is not really an issue for me, as I am sticking with the old code (early version of the v3 compiler), but I do not quite get what is going on. Do you want the hex file that i generate?

Re: New C18 3.0+ Compatible FRC Code
 

Make sure you have enabled the timer 4 interrupt in ifi_frc.h. Not doing this will cause the RLOD. Can you zip up your code and send it to me?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

The link is broken. I'll be happy to test beta 4 once I can get my hands on it.

-Guy Davidson

Re: New C18 3.0+ Compatible FRC Code
 

New and edited link on the first page. Or, go to his web site. The full and simple versions are up.

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

Now that I enabled the ISR's (grin) everything works fine. No need to include sonar code this year as the MaxBotix sensors have an analog output.

Re: New C18 3.0+ Compatible FRC Code
 

Hmmm i dont know what the issue was, (i did have ISR enabled) I just now recompiled the code and loaded it, no issues. Serial communications issue on the load... I dont know.

Re: New C18 3.0+ Compatible FRC Code
 

Hello, this is my first year doing the programming on my team and we are having a very confusing problem. We are using an unmodified version of Kevin’s 2008 beta code with mplab v8 and c18 v3.1 and the code compiles fine and loads onto the robot fine, and it seems run on the robot, but the robot doesn't react at all. Its equally frustrating because when we load a copy of the 2007 code it works fine. It seems that no one else has had this problem (that I saw), though it seemed that Kevin referenced it in one of his posts.

Any help we could get would be much appreciated.

Re: New C18 3.0+ Compatible FRC Code
 

With out any code that is going to be hard to help you with, are you in teleop mode? What code do you have in your teleop function?

Re: New C18 3.0+ Compatible FRC Code
 

Because I don't know how you have your robot configured, you need to write this code yourself. Just open up teleop.c and scroll down to the teleop() function. Once there, you can map joystick inputs to motor outputs like this:

You can also use IFI's default robot code by uncommenting (remove the double slashes) in front of the call to Default_Routine() at the bottom of Teleop(). The code for Default_Routine() is located in ifi_code.c.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I'm having a variety of problems, with the new code(http://www.kevin.org/frc/ifi_frc_sensor_30.zip), and the old encoder code (http://www.kevin.org/frc/frc_encoder.zip).

First off, I'll talk about the problems we were having with frc_encoder. When I had MPLAB 7.20 installed and was using v2.4 of the C18 compiler, everything compiled, and the encoders worked great on the robot. Here was the problem... there seemed to be about a 1/2 second delay between the robot receiving data from the OI, so I would move a joystick, then it would take 1/2 a second for the motors to start moving. I would release the joystick, and it would take 1/2 a second to stop (I almost had a bad incident with our new 80lb robot running me over).

Okay, now for the 3.0 compatible code.
I have MPLAB 8.00 installed and version 3.10 of the C18 compiler.
I can compile the code as it is downloaded no problem, but when I try to initialize encoder 1 and encoder 2 using the code where i take out the //, it fails at the link step:

MPLINK 4.1, Linker
Copyright (c) 2006 Microchip Technology Inc.
Error - could not find definition of symbol 'Initialize_Encoder_2' in file 'C:\Robot Code\2008\ifi_frc_sensor_30\teleop.o'.
Errors : 1

If I comment out "Initialize_Encoder_2" it will say the same thing about encoder 1.

Is my MPLINK out of date, since it says 2006?

Here are some snapshots of MPLAB with my horrible hand-eye coordination with my trackpad: :D

Attachment 6102

Attachment 6107

The other 4 errors are with this part of code:
Hopefully this gives you enough information to solve my problem.

Re: New C18 3.0+ Compatible FRC Code
 

I'm not sure what you want me to do about this.

Yep, it appears you didn't follow the detailed instructions in readme.txt :rolleyes:.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Oops, I never saw the pesky README. :D I already see what I did wrong, and I will edit this post a bit later to tell you if I got it working.

Also, the link to the beta4 software doesn't want to work.

Thanks for the quick response though... I was hectically trying to get this code working because our programming mentor is about to go to Indonesia on business.

EDIT: I got it working! Thanks a bunch!

Re: New C18 3.0+ Compatible FRC Code
 

We'll be using ultrasonic sensors as well as a gear count. Though, I don't think that teams that are already modifying your code should have too much of a problem reading data from the digital inputs.

Thanks a lot for the code, saves a great deal of time.

Re: New C18 3.0+ Compatible FRC Code
 

I think I've found a bug in the Gyro code....

I know... it seems unlikely considering how long it's been in service, but this problem has been bugging me for a while and I finally got the clues I needed to locate it. Here is the function.

I was calling this function and displaying the return value, but it never got above 32 or below -32, and it seemed to flip signs at the oddest times.

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

I'm going to try it tomorrow...

I'm just greatful I didn't have to write this code....
Thankyou Kevin... really.

Phil.

Re: New C18 3.0+ Compatible FRC Code
 

Okay, I'll have a look at it. I'm working on what I hope is the final release, so now is a good time to fix any bugs. Assuming it's a real bug, thanks for finding it.

It's not too suprising. I think most, if not all, people are using the the Get_Gyro_Angle() function, which wouldn't be effected by a bug in the Get_Gyro_Rate function.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

Would it be too much to ask for an updated library for the EDU-RC? ;)

Re: New C18 3.0+ Compatible FRC Code
 

I just discovered something else interesting about the gyro code... specifically the way the angle resolution relates to the analog input scaling.
I detected this as I was logging heading data as I was driving around and around our track.

On my system I have 4 Analog inputs, that I'm running 4 amples per update at 1600 Hz... This give me a Gyro update rate of 100 updates per second, and an ADC Range of 2048 and

In the Gyro code... for an ADXRS150 I have

And finally I have

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

Re: New C18 3.0+ Compatible FRC Code
 

Just to make sure we didn't have odd problems like this, our code looked something like

Re: New C18 3.0+ Compatible FRC Code
 

Well, you have to assume something is gonna break if you do enough loop de loops :).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Sorry if this has been addressed before I don’t have time to go through all 288 posts but we are having an issue when we compile. Here is what our output looks like, if anyone can help it would be greatly appreciated. Thank you

Re: New C18 3.0+ Compatible FRC Code
 

You need to go to the project menu then build options then project
On the directory tab select Header Search Path (i dont have mplab infront of me right now but it is the header one), create a new one that points to the mcc18\include folder where ever that may be, it might be in C:\Program Files\ or just under C:\
Seeing as that variable is off you may also need to set the Library Search Path to mcc18\lib folder

Re: New C18 3.0+ Compatible FRC Code
 

It looks like MPLAB doesn't know where to find the C18 header files (it seems to me that if you just sneeze while MPLAB is running, it'll forget all kinds of vital information <grin>). Anyway, go to Project > Build Options > Directories tab > Include Search Path and then point it to c:\mcc18\h.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Yes, at some point I'll port code to the EDU-RC (and maybe Vex too).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

well my first errors are gone but now i get these...

Re: New C18 3.0+ Compatible FRC Code
 

The first warning can be eliminated by changing the memory model to large: Project > Build Options > MPLAB C18 tab > Catagories: Memory Model > select large model for code and data.

The clib.lib error is due to MPLAB not knowing where your compiler libraries are installed: Project > Build Options > Directories tab > Library Search Path

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

cool, it all works now, thank you very much :)

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
You truly are an example that all FIRSTers can look to, including myself. Thank you for your incredible efforts!!

Re: New C18 3.0+ Compatible FRC Code
 

I do like the new code layout. I would like to see the code for C18 2.4. We do prototyping on previous years' robots and having both 3.15 and 2.4 on our machines seems a bit difficult to manage.

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

Now finding that the RC is stuck in Programming Mode at the end of download if adc is initialized.......any suggestions? (I did read the readmes!!!)

Jon Mittelman

Re: New C18 3.0+ Compatible FRC Code
 

Hi Kevin,
We keep on getting a error that ADC_CH0 is not defined. This happens when we try to use rc_ana_in_01. We looked in all of the header files including the complier file and could not find the definition but it is clearly used in ifi_frc.h.This might be a stupid error but please can someone help us.
Thanks,
Julan