Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

Yes I Did

Variables Change randomly
 

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.

Re: Variables Change randomly
 

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. :P

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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"
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.

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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.

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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!

Re: New C18 3.0+ Compatible FRC Code
 

Yes, that version will only work properly with the '8722. I'll be releasing a unified version soon that will work with both robot controllers and C18 2.4 & 3.0+. I'll release it when I'm finished with a major revision of the gyro code.

-Kevin

(If you can't wait and promise to report any bugs you find, here's a snapshot of the latest build without the gyro mods)

Re: New C18 3.0+ Compatible FRC Code
 

I've posted a snapshot of what I hope is the last build for a while. The changes are numerous and include improved gyro code. The documentation still needs some work, but the code should be complete. If you're willing to test it and provide feedback and/or bug report(s), you'll find it here: http://kevin.org/frc/ifi_frc_sensor.zip.

-Kevin

Get_Gyro_Rate() returns jumpy values
 

when I call Get_Gyro_Rate() it tends to give occasional outliers and data that doesn't make sense. When I turn the gyro constantly one direction, jumps back and forth between positive numbers. Get_Gyro_Angle() works fine and is accurate. I am testing with last year's kit gyro.

Re: Get_Gyro_Rate() returns jumpy values
 

You might be seeing the issue resolved here.

Re: Get_Gyro_Rate() returns jumpy values
 

I downloaded the Sensors code from Kevin's site just yesterday, was it not fixed then?

Re: Get_Gyro_Rate() returns jumpy values
 

The public version on the website still has the bug. I hope to replace that version with the new version (link a few messages back) tonight after you guys (hopefully) try it out and report any issues.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Just transferring the new code over to my dev. code.

Noticed that the Get_Gyro_Bias_Status() function looks like a bad cut/paste from another function. No return value.

Re: New C18 3.0+ Compatible FRC Code
 

Other than the Get_Gyro_Bias_Status Phil noted above, I haven't found any problems with the latest code. I only messed around with the relativly simple stuff today - I'll be doing some more intensive encoder and gyro (maybe) based testing tomorrow, so I'll let you know about those after I do that.

Re: New C18 3.0+ Compatible FRC Code - New Build
 

Great work Kevin

had running a gyro, a MatBotrix Ultrasonic ranger and an encoder!!!!

To get values from the MatBotrix, I needed to use Get_ADC_Result and then Convert_ADC_to_mV....the Get_Analog_Value didn't work.

Re: New C18 3.0+ Compatible FRC Code
 

Ouch. Let me see what happened...

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Thanks!

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I don't know what I did, but the correct version should be on the server. Thanks again for your help.

-Kevin

Re: New C18 3.0+ Compatible FRC Code - New Build
 

I'm pretty sure you'll get corrupted data if you try to use Get_Analog_Value() while the ADC code is running in the background.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I'm having a huge problem with the lastest code I just downloaded 2 hours ago. I'm using version 2.4 of the compiler. I followed all of the instructions in the readmes, but if I call Initialize_ADC(); and Initialize_Gyro(); in teleop/Initialization(), I'll get a blinking red and green light next to program state on the rc. On the output window, "IFI User Pr" shows up, making me think that it runs into an error in the middle of trying to print the printf:IFI User Processor Initialized ...\r\n. There are no problems when those 2 function calls are commented out(initialize gyro and adc). I've tried a combination of commenting and uncommenting the gyro code in teleop and the process_gyro_data function in teleop_spin. I don't get this problem with an earlier version of the 2.4 gyro beta code. I'm really not sure what to do. Any one else have this problem? Does this work for anyone using 2.4- the hex file builds and in ifi_frc.h I have USE_C18_24 #defined only. I'd really appreciate any suggestions. Thanks.

Re: New C18 3.0+ Compatible FRC Code
 

My guess is that you didn't enable the timer 4 ISR in ifi_frc.h.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

will the encoder code work with the US Digital E4P-250-250 encoder which is built-in on the Andy Mark Super Shifter transmission? also what kind of output should u expect from the encoder and the gyro?

Re: New C18 3.0+ Compatible FRC Code
 

The E4P is a standard quadrature encoder. I can assure you that it works perfectly with Kevin's encoder library for the standard IFI code, and I have very high confidence that it will work just as perfectly with his new framework.

Re: New C18 3.0+ Compatible FRC Code
 

Having the same problem with the new code as someone mentioned before.

When I build the project with Initialize_ADC() uncommented, it builds fine but encounters a code error.

When I build the project with ENABLE_TIMER_4 defined in timers.h, the linker encounters the error:

Error - symbol 'Timer_4_ISR' has multiple definitions.


I have tried commenting out the definition for Timer_4_ISR() in timers.c (because it does nothing) but we get back to the code error. Also, ENABLE_TIMER_4 is defined in ifi_frc.h.

Using a 2007 RC, MCC18 3.10;

Thanks!
-James

Re: New C18 3.0+ Compatible FRC Code
 

per Kevin's read-me

2) Enable the timer 4 interrupt service routine in ifi_frc.h
3) Make sure timer 4 is disabled at the top of timers.h.

Re: New C18 3.0+ Compatible FRC Code
 

I've written replacement code for IFI's Get_Analog_Value() function. It's now included with both builds of the new code on my website. You can also just grab the files and drop then into your project.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

So, per your documentation, to use your 'quickie' adc code, you shouldn't run them with the gyro code, right?

Re: New C18 3.0+ Compatible FRC Code
 

No, you shouldn't as they'll interfere with each other. You can always just increase the number of analog channels sampled by the adc.c code when using the gyro.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I have gotten Timer0 to work as a clock for the code. A few misadventures (like not putting the initialize function in the Initialization.c in Teleop.c), but actually is very easy to implement in the new code with the prescaling.

I have not gotten the encoder 3 and 4 to work. no error messages, but get_encoderX_count always comes back 0. any ideas?

Re: New C18 3.0+ Compatible FRC Code
 

If it builds with no error messages it's probably because you didn't enable the call to the encoder ISRs at the top of ifi_frc.h.

I'm thinking about password protecting the project zip files with a password that's something like read_the_readme.txt_file_before_doing_anything :).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Okay, I'm having a little more trouble... I'm trying to get some potentiometers working on our robot, so I read the readme and did everything it told me to do:
I think I have done everything I needed to do, but when I try to build, it says Here is where it is saying this...
I also tried the quick_adc, but I was having trouble, so I went back to this...

Update: I may have fixed it, but I'm unsure... Instead of Get_Analog_Value(rc_ana_in01), I used Get_ADC_Result(1). Will this work? I'm not going to be able to try this on our robot until Saturday as I'm going out of town for the next 2 days.

Re: New C18 3.0+ Compatible FRC Code
 

You just use a number from 1 to 16 to select the ADC channel. As an example:

liftpos = Get_Analog_Value(1); or liftpos = Quick_ADC(1);

Of course you'd probably want to #define these values in a header file and then the code would look like this:

// this goes at the top of the source file or in a header file like robot.h
#define ARM_ELBOW_POT 1 // analog input one
#define ARM_WRIST_POT 2 // analog input two

unsigned int elbow_pot;
unsigned int wrist_pot;

elbow_pot = quick_adc(ARM_ELBOW_POT);
wrist_pot = quick_adc(ARM_WRIST_POT);

Because it's simpler, I would use quick_adc() if you're only using potentiometers on your 'bot.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

We are using Kevin's code to read the gyro and control our steering. Our steering is connected to a 10K linear pot. We are reading the pot with get_ADC_value and feeding it to a PID function. The intent is to have servo controlled steering.

We are having a lot of trouble getting the servo to respond properly. We are working on tuning our PID loop and having some success.

Here is my question: We are calling the PID routine in Default_Routine so it executes very 26.2 ms. Should we be calling it in a fast loop?

Re: New C18 3.0+ Compatible FRC Code
 

Thanks again for the help. I found out why the quick_adc.c and quick_adc.h were not working... Even though I said add files to project, it never did copy them to the project folder, like I expected it would... Still getting used to MPLAB. It compiled without any error (just the way I like it :D) and I'm going to try it out hopefully Saturday.

Re: New C18 3.0+ Compatible FRC Code
 

We had the enables in the IFI_FRC.h. The problem was in the format of the print statement (note to others- output from encoders is a long integer). The encoders were working just fine. Sometimes it really is just dumb stuff. (Thank you Kevin for being patient)

Re: New C18 3.0+ Compatible FRC Code
 

I just tried to build the ifi_frc_sensor project with MPLAB IDE v7.20 and C18 2.4 (had to use the project wizard to create new mcp/mcw files, as I was unable to open the ones that came with). After updating the ifi_frc.h header file to define the proper compiler macro (USE_C18_24), I now am getting these errors:

timers.c:72:Error [1205] unknown member 'PSA' in '__tag_216'
timers.c:72:Error [1131] type mismatch in assignment

Apparently the header file mcc18\p18f8722.h defines T0CON bit 3 as T0PS3, but the timers.c file references it as 'PSA' instead. Should the code read:

#ifdef USE_C18_24
T0CONbits.T0PS3 = 1;
#else
T0CONbits.PSA = 1;
#endif

??

Re: New C18 3.0+ Compatible FRC Code
 

Looks like another bug in their header file. Your options are to replace the 2.4 p18f8722.h with the 2.44 version in the Documentation folder included with my code, or you can update your compiler to 2.44, which is the same version I use. Here's the link to the secret copy I keep on my website: http://kevin.org/frc/c18_244_update.zip.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

How many folks out there are using this code with MPLAB IDE v7.20 and MPLAB C18 2.4? I noticed a comment in encoder.h as follows:

This version is compatible with Microchip C18 3.0+ only

Is this still true?

Re: New C18 3.0+ Compatible FRC Code
 

Ugh. Um, I guess I was a knucklehead and forgot to delete that comment. The code works file with 2.4.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

That's what I had guessed, thanks for clarification. Note that this comment also appears in at least one other file as well (interrupts.h), possibly others, too.

Re: New C18 3.0+ Compatible FRC Code
 

Another ADC and Gyro question :)

We want to use the gyro as well as other analog sensors. It appears that using Process_Gyro_Data() in Teleop_Spin(), for example, will check for ADC result count, read the ADC gyro channel only and then reset the ADC result count without reading any other ADC channels. Is that a problem?

The 2007 Process_Gyro_Data() didn't check for ADC result count or do a reset inside the function, so we read our other channels just after Process_Gyro_Data() and before the reset.

Where should ADC channels for our other sensors be read? Do they need to be read in the fast loop at the same time as the gyro channel is read? (Should we insert more Get_Analog_Result()s in Process_Gyro_Data to read the other channels?)

We're using pots with a PID to control steering etc., and ultrasonic sensors.

Thanks...

Re: New C18 3.0+ Compatible FRC Code
 

Yes it is. I would modify Process_Gyro_Data() to not reset the the ADC result count, but make sure it does get reset after processing all your other sensor data. I think I'll modify Process_Gyro_Data() to accept a TRUE/FALSE parameter to determine how it behaves in this regard. Thanks for catching another knuckleheaded mistake on my part <grin>.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

We've already done this, but why the recommendation to "reset after processing...other...data"? We simply remember the last count and make sure it has changed before processing more data. That way we are sure to be processing fresh stuff and don't need to tie it all together to get a reset when everyone has had their chance at the latest readings....

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

And I've been remiss in sending "Thanks" to Kevin, but our software group is LOVING the new code format. It is much more understandable than the earlier default code.

One change we've made is to add a few "always" functions. We hooked them in to the main program and they're called "Always_Spin", "Always_Before", and "Always_After". They get called regardless of the current operating mode. The *_Before and *_After routine get called before and after the invocations of the mode's command packet processing routine.

We did this after we found ourselves adding the same invocations to Disabled_Spin, Teleop_Spin, and Autonomous_Spin for the third time. Always_Spin makes it easy.

Always_After is a handy place to get a last chance to reverse any PWM values for opposing drive motors without having to remember to do it everywhere else. Positive logic rules with the ability to override it for reality where necessary. (Robots shouldn't go forwards when you set PWMs to 0, but when mechanical mounts opposing motors and controls wants red to red to positive consistency, it falls to software to make it all work right).

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

Yes, this works too, but keep in mind that the value returned by ADC_Result_Count will roll over at some point, so make sure to use the != operator instead of > in your test (I know you know this Lynn; I'm just mentioning this so others won't make a mistake).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I'm having trouble with the Gyro bias calculation in the code posted on 2/2. If I use the previous code (without the circular buffer), I get a gyro bias of ~2080. With the newer code, I get a gyro bias of ~1660. This make the code think the gyro is spinning continuously. Is there an OBO (off by one) error lurking somewhere? Is anyone else having problems with the updated code?

Re: New C18 3.0+ Compatible FRC Code
 

btw
I had a problem, I was trying to declare a variable in "interrupts.c",
and use it also in "autonomous.c,"
no matter what i've tried, it didn't work
(nope, trying to redeclare it as an extern in the header didn't work either),

strangely enough, after wasting an hour like an idiot :D,
I've declared it in autonomous.c and it worked like a charm.

incredibly weird..

Re: New C18 3.0+ Compatible FRC Code
 

Kevin

What is the difference in master code from the 2007 controller and the 2008 controller... is there a procedure to update a 2007 controller to the current master code?? I understand that the hardware is 100% the same...

thanks...

Re: New C18 3.0+ Compatible FRC Code
 

There is no difference in the hardware or firmware between the 2007 and 2008 robot controllers. The latest revision of the master firmware is version 15, available here:

http://www.ifirobotics.com/docs/frc-master-ver15.zip

You use the IFI loader to send it to the robot controller (the boot loader intercepts it and sends it to the master).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

We just uncovered (and fixed) a potential gotcha in the invocation of Teleop_Init() from main. We tried to access the current state of the OI inputs from there and they weren't available!

We found that the Getdata() call was occurring AFTER the Teleop_Init(). We moved it BEFORE the if(teleop_init_flag) test and it corrected our problem.

On further inspection as I'm writing this, the same issue would plague the other two *_Init() invocations. Simply moving the Getdata call will make the current OI data available to those functions.

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

Hmmm... I'll have a look at it later tonight.

Edit: I'll change it when I make the changes mentioned above, but I don't see where this could cause a ploblem as the OI data from the previous Getdata() should be valid. What problem were you having?

-Kevin

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Hi Kevin,
Our robot this year is using four different omnis that need 4 different encoders. The problem is we need to use four encoders this year. We used the encoders 3-6. We noticed that 3-4 were working but 5-6 only gave 0's and 1's. After looking at the ISR's for the encoders 5 and 6 i realized that 3 and 4 only worked on rising edge interrupt but 5 and 6 worked on both. After i changed 5 and 6 to be like 3 and 4 they worked but i do not understand why. there are four variables that i am using, two of which you use that are not declared anywhere. They are Encoder_3_State, Encoder_4_State, Encoder_5_State, and Encoder_6_State. Do you know where these variables are declared. Also why are the encoder 3-4 ISR's different from the encoder 5-6 ISR's.
Thanks in advance,
Julian

Re: New C18 3.0+ Compatible FRC Code
 

Look at lines 70-86 (at least in my copy) of encoder.c. You'll see the declarations there.
From Kevin's encoder_readme.txt from 2 years ago:

Encoder channels one and two are optimized for velocity control
and will generate the least number of interrupts per encoder
count (one per encoder count). These channels may have problems
in position control applications because they can be fooled
into thinking that the encoder shaft is rotating if the shaft
happens to stop very near a phase-A transition and then wobbles
back and forth across that transition.

Encoder channels three and four are optimized for position
control. For these channels, software examines both transitions
of phase-A and can't be fooled into miscounting the number
of encoder counts. The downside to using these channels is that
for a given encoder, they will generate twice the number of
interrupts as channels one and two (two per encoder count).

Encoder channels five and six are just like channels three and
four, but offer the bonus of increasing the precision of your
encoder by a factor of two for free. Unlike channels one
through four, which will increment or decrement on each rising
(zero to one) transition, these two channels will increment or
decrement on both transitions of phase-A. In other words, if
you attach a 64 count-per-revolution encoder to one of these
two channels, you'll read 128 counts when you rotate the shaft
exactly one revolution.

Re: New C18 3.0+ Compatible FRC Code
 

Have you resolved this issue? We're having the same problem, but with the C18 V3.10 compiler & beta code.

Re: New C18 3.0+ Compatible FRC Code
 

First, I really like the new code organization (that seems to be a common theme). One suggestion though. I'd like to see the *_Init routines called whenever the mode switches. This probably won't affect the matches where things are always: disable->autonomous->teleop->disable. But we were chasing a bug in our autonomous because we were forgetting to reset the robot between runs, and the Autonomous_Init() routine wasn't getting called (we were continuously toggling between disabled and autonomous.

Anyway, back to autonomous programming.

Re: New C18 3.0+ Compatible FRC Code
 

Just FYI, I've updated the code to address these three minor issues:

http://www.chiefdelphi.com/forums/sh...&postcount=348

http://www.chiefdelphi.com/forums/sh...&postcount=351

http://www.chiefdelphi.com/forums/sh...&postcount=360

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

For some unknown reason (yes, I've checked the RCON register) the simulated processor is resetting when serial port one gets enabled. This causes the 32 entry call stack to overflow (which shouldn't happen in real hardware). This seems to be a problem with the simulator and not something I can fix.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Is there a workaround? Why is this happening this year and not last year? Thanks for your help.

Ann

Re: New C18 3.0+ Compatible FRC Code
 

I heavily modified the ADC code and was having issues with the data in the gyro bias buffer being corrupted. In the process of trying to figure that out, I looked at the bias calculation heavily and did not find any logic errors in it.

I never did solve my problem, though, so there might be a problem lurking in that code.

Re: New C18 3.0+ Compatible FRC Code
 

See if the solution in this thread helps: http://www.chiefdelphi.com/forums/sh...ad.php?t=62816

Re: New C18 3.0+ Compatible FRC Code
 

Here's the deal. When the robot powers up in teleop, as is normal outside of competition, the first routine of ours that gets called is teleop_init, before (at least originally) the first call to getdata (except for the getdata before initialization, which I suspect doesn't include OI data).

We were grabbing some switch values in teleop_init into a static variable to detect when/if the operator changes those switches during the normal teleop(). We do this to avoid moving some of our appendages on first power up until someone at the control panel asks them to move (safety considerations).

Since telop_init() was only invoked once, before the first (real) getdata, we didn't see the real OI switches and concluded that the operator had, in fact, moved them when teleop got called after the getdata invocation.

Thanks for considering the changes, and check out my next post. It's going to point out another 26.2msec issue in this same area of the code.

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

Given the structure of the code in main() surrounding the modal invocations and the position of the getdata() calls, it appears to me that the new code structure actually invokes the previous mode with the new mode's getdata() results immediately after a mode switch.

Consider: robot is in disable, rcdata has that fact recorded, hybrid begins. main() detects disabled mode, detects that new data is available, calls getdata() receiving the new autonomous flag but invokes disabled() anway. Autonomous_init() and Autonomous() doesn't get called until the NEXT command packet, 26.2msec later.

I've not done it yet, but I'm planning to restructure our main() to something like this (just pseudo code, not real code):

main loop:

if (new data available)
{ getdata();
set newdata flag;
}
if (...mode...)
{
all of the existing mode_init and mode() calls here, but no getdata or putdata() calls
}
if (newdata flag)
{ putdata();
}

goto main loop:

With this structure, the newly gotten mode is the one checked and invoked with the getdata() packet.

I hope to first prove this with a mode-checking printf in one (or all) of the _init() routine that check if the mode we're in is reflected in rcdata (hidden by the #defines for the mode flags). I suspect it is not.

Lynn (D) - Team Voltage 386 Software

PS. This also makes our new always_before(), always_after(), and always_spin MUCH easier to hook in, now that I've written it out! always_before() right after the getdata(), always_after() just before the putdata(), and always_spin, well, always in the loop!

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
We discovered a side effect of the new code setup that I thought I should point out. I've only read this thread sporadically, so maybe it's already been mentioned - if so apologies for bringing it up again.

We had some feedback code that we implemented in the _Spin() functions since we wanted it to execute faster than the 26.2ms rate. The side effect that we found was that if you do something which causes your Autonomous() code (for instance) to take longer than 26.2ms to execute, then Autonomous_Spin() will never execute. The problem this caused for us was that our feedback was obviously not running when this occurred.

Anyway, I don't consider this a flaw in the code or anything, merely a behavior that I wanted to make sure others were aware of. We will probably modify ifi_frc.c and remove the "else" blocks around the _Spin() functions, which will ensure that the _Spin() code gets executed at least once per main loop.

Maybe it would be worth a note in the comment blocks before each _Spin() function noting that those functions will only be called if there's extra time left over after processing the new command packet.

Dave

Re: New C18 3.0+ Compatible FRC Code
 

Dave,

Thanks for catching this. IFI's code behaves the way you describe, so I went ahead and removed the three surrounding else statements. I also added support for the MPLAB simulation tool. The code is up on my website now.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

What is the procedure for adding additional analog sensors with the gyro code? I changed the number of ADC channels, plugged the (pots, in my case) in to channels 2 and 3, and added the code to read them in the Process_Gyro_Data function.

While I've been able to read the values (by converting the number to milivolts, as otherwise I'm not exactly sure what I'm seeing), the gyro has since been going crazy. I wired the gyro to an oscilloscope, and it still works, but the code (after given time to initialize and computing the bias) sees crazy values. Any idea what I'm doing wrong? Is there any readme to using the gyro with other analog values I'm missing?

Thanks.

Re: New C18 3.0+ Compatible FRC Code
 

Just a thought, here is a quote from the header of the gyro.c/Process_Gyro_Data

Are you calling Reset_ADC_Result_Count() from your code?

Re: New C18 3.0+ Compatible FRC Code
 

Here's the code to my Process_Gyro_Data (it isn't the latest revision with the input character):

Re: New C18 3.0+ Compatible FRC Code
 

Yeah, I'm a knucklehead for changing how Process_Gyro_Data() works. I'll post some code to show you how to use the other ADC channels. While waiting, you should go grab a copy of the code Bill mentions above.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

This code works for me:

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

It looks like C18 3.16 has been released. The release notes claim to have fixed the ADC header file issue.

Re: New C18 3.0+ Compatible FRC Code
 

I haven't done much testing, but my code builds with 3.16.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Sub-Subject: Using PWM() for a 100Hz Control Loop

I'm trying to understand how to use the PWM() function in order to implement a 100Hz PID control loop (rather than the default ~38.2 Hz).

I believe I understand the previous postings, but I'm getting stuck on when (and how often) PWM() needs to be called in order to generate output values. I have five questions below, buried in the posting. Answers (or any help, for that matter) to these questions would greatly aid my understanding. Thanks!

The "pwm_readme.txt" file says the following:

Looking into the code in PWM.c, I see where the pulse is commenced near the end of PWM():

However, I don't see where the transition from high to low occurs. (I know nothing about "CCP".) Is the high-low transition performed automatically somehow at a later time? (Q#1) Is there an interrupt service routine associated with the timer being used (timer3) or is no ISR needed for this style of usage? (Q#2)

Assuming that the high-low transition is occurring automatically with the CCP hardware, when does the next low-high transition occur? (Q#3)

It sounds from the one line in the pwm_readme.txt that the next low-high transition will not occur until PWM() is again called. This implies that I need to call PWM() repeatedly, even if we aren't changing the pwm values. Could we just call PWM() as fast we possibly can? (i.e. in every loop in Teleop_Spin() or Autonomous_Spin()) (Q#4).

If it would be bad to call PWM() as fast as we possibly can (because something would break), then presumably we need to call PWM() from Teleop_Spin() and/or Autonomous_Spin() at no more than about a 100Hz rate. If so, then do we need to take out the calls to PWM() in ifi_frc.c so that we're not actually calling PWM() 138 times a second? (Q#5) (100 times from our 100Hz section of *_Spin() and an additional 38 times a second in the block of code in ifi_frc.c which calls Autonomous() or Teleop())

I realize that these are almost surely "newbie" questions for anybody experienced with CCP, but that's where I am in my understanding of this right now. I ask your forgiveness for the "newbie" questions but don't know where else to turn to help, as I'm having trouble finding these answers in the documentation.

Thanks,
--ken

Re: New C18 3.0+ Compatible FRC Code
 

In a previous message in this thread regarding the setup of a timer for a 100Hz loop, the following question was asked:

I looked through the thread for an answer to this question, but couldn't find one. Does anybody have a code snippet which configures a timer for 100Hz?

Thanks!
--ken

Re: New C18 3.0+ Compatible FRC Code
 

Yes, this is certainly possible. Set a timer to go off at 100Hz, but don't set the interrupt enable bit to one. Now craft a piece of code that will execute in one or more of the fast loops. In that code you should test to see if the timer interrupt flag gets raised, and if so, do your PID calculations and then call PWM() at the end. You'll need to comment out the call to PWM() in main() if you're using my code.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I've created drop-in replacement code for timer.c and timer.h that implements a millisecond system clock using timer 2. The code is available here: http://kevin.org/frc/ifi_clock.zip.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

We have been using the new code with great success, but whenever we set NUM_ADC_CHANNELS above 3, the analog input values including the gyro become unreliable. We also tried to adjust the sampling rates some, but this did not seem to help the problem. What have we missed?

Re: New C18 3.0+ Compatible FRC Code
 

We've been running into a similar issue - the gyro seems to drift way more when additional ADC channels are enabled. Is there any workaround?

Re: New C18 3.0+ Compatible FRC Code
 

I suspect the KOP gyro can't drive the sample-and-hold capacitor fast enough. If you have additional channels, those channels could drive the capacitor to very different voltages than what you gyro is sending out. When the ADC circuit switches to the gyro input, the gyro has very little time to push or pull charge into or out of the capacitor. The end result could be inaccurate gyro readings. As an experiment, sample the additional channels, but don't connect anything to those inputs. If the gyro works better, my theory starts looking good. Assuming my theory is correct, try using the adc_8520.c code instead as it should give the gyro additional time to charge the capacitor before the analog to digital conversion begins. If you're handy building circuits, you can also try using a very simple op-amp based voltage follower to better drive the capacitance. If you try these potential solutions, please report back here with your results.

EDIT: Another possibility is that you're not allowing enough time to calculate the bias. See my next message.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Hey Kevin, I'm testing the 2007 gyro with your latest code. It works great when NUM_ADC_CHANNELS is one. But when I set it to four, I get a gyro bias of like 1660 - instead of the usual 2080- and then a constant rate when it's not moving. I don't have anything besides the gyro connected to the RC i'm testing it with. Is it possible this has something to do with the calculation of the gyro bias?


Edit: Could it be because I'm using the default gyro testing code in teleop.c which does not have enough time to fill the Gyro_Queue. I plan to test this theory tomorrow, and is there any reason why I shouldn't make the ADC_SAMPLE_RATE 3200HZ?

Re: New C18 3.0+ Compatible FRC Code
 

Possibly. What may be happening is that you've added four channels, which means it takes four times longer to acquire the 64 updates (remember update rate = sample rate/samples per update) necessary to calculate the bias. Use the Get_Gyro_Bias_Status()
function to determine when it's safe to call Stop_Gyro_Bias_Calc() function. Here's info from the header:

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I think that's it because I just did the calculations for a 800hz sampling rate and 16 samples per update. It takes 5.12 seconds to fill the gyro queue and the testing code only calculates the bias for 4 seconds. If I'm just reading some pots during the 26.2 ms loop, is there any reason I should reset adc result count in my own code as opposed to doing in the gyro code?

Edit:
Would the bias be any more accurate if the gyro_queue replaced some of it's first values it got from start up?

Re: New C18 3.0+ Compatible FRC Code
 

I'm in a bit of a bind...I'm having a bit of a problem integrating the PID code available at http://www.kevin.org/frc/2005/ with this new code. I've been looking through the PID code and I have absolutely no idea where to start trying to make them work with one another. I'd greatly appreciate any help I can get here....

Re: New C18 3.0+ Compatible FRC Code
 

Kevin.
I'm trying to get the camera code going with the new 3.0 code. I'm not receiving ACKs or NCKs so it fails at init state 3 return value 131. serial_ports.h/c looks ready to go for port2 9600 baud and interrupts.

Integrated camera.c terminal.c and tracking.c without any issues.

Anything obvious come to mind reagrding serial port initialization?

Chad

Re: New C18 3.0+ Compatible FRC Code
 

Chad,

Try setting serial port 2 to 115200 baud.

Dave

Re: New C18 3.0+ Compatible FRC Code
 

I've been running into an odd problem with encoders.

Encoder 1 works perfectly fine during the teleop period, but does not give me anything during the autonomous one. Encoder 2 works in both teleop and autonomous. The initialization functions is called during both the autonomous and disabled initialization routines.

I am running your latest code build, as far I as know, with MPLAB 8 and C18 3.10. While the robot is shipped already, I'd love to hear if you have any suggestions for what to try.

It could be that the encoder is working, and is giving the correct signals, but is always printing a zero in my debug statement, and the code that is executing makes me believe that it is seeing a zero (as the count). But when I print out the count in the teleop mode, I get numbers that make sense.

New C18 3.0+ Compatible FRC Code
 

Kevin

Do you have access to an Explorer 16 board from Microchip??

Re: New C18 3.0+ Compatible FRC Code
 

I had the same issue in autonomous, except with both encoder 1 and encoder 2. I never had the chance to check in teleop mode, though.

I'll try with last year's board, if I can get the time (we removed our encoders from the bot for this reason).

Re: New C18 3.0+ Compatible FRC Code
 

I haven't done it, but I can't think of any reason it wouldn't work.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

A common reason for this is the wrong printf() format parameter is used. Use %ld instead of %d.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

No, most of my experience is with x86, PPC, Cell BE, TI DSP plus lots of FPGA work. My only real experience with PIC is side work using IFI hardware. Why do you ask?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

That would make sense, I guess. The DEBUG I use in the teleoperated code casts the variables to integers in the DEBUG, while the one I have in autonomous does not. But something's still lacking. In this case, why would encoder channel 2 print out properly, while one was not? I also tried connection the two encoders to the opposite channels (i.e. the left one was previously connected to 1, and I moved it to 2, and vice versa with the right encoder). When I did that, the signs flipped, but encoder 2 still changed and 1 still remained constant, while both worked in teleop, I believe.

Another weird thing with my autonomous code, is that unless I have a DEBUG in the PWM() function body, the robot doesn't move. I'm updating the PWM function every main loop, and I noticed that unless I have that DEBUG statement there, the robot doesn't move. Once I added it, or commented it in (when testing), the robot started moving again. Any ideas?

Thanks.