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?