New C18 3.0+ Compatible FRC Code

[1jbinder]

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

[ldeffenb]

Originally Posted by 1jbinder

...They are Encoder_3_State, Encoder_4_State, Encoder_5_State, and Encoder_6_State. Do you know where these variables are declared.

Look at lines 70-86 (at least in my copy) of encoder.c. You'll see the declarations there.

Originally Posted by 1jbinder

.
Also why are the encoder 3-4 ISR's different from the encoder 5-6 ISR's.

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.

[amk]

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

Originally Posted by ayeckley

There seems to be something amiss when using the combination of MPLAB 8.0, C18 V2.4, the V2.4 beta code and the MPLAB SIM debugger. I think that's a "legal" combination, right? The simulator seems to be going off into the weeds when it hits line 373 (serial port enable) of serial_ports.c. The odd thing is that if you step through it it hangs up on that line, but if you let it run it instead hangs up on line 427 of ifi_frc.c, which is _do_cinit();

Is this just a question of the beta code not supporting MPLAB SIM? I don't think I've seen any _SIMULATOR definitions in either the 2.4 or the 3.1 beta code.

Edit: The same thing happens when I run the 3.1 beta code with C18 v3.1. Maybe I'm the only one trying to use MPLAB SIM? It worked like a champ with last year's code.

[mandrews281]

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.

[Kevin Watson]

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

[Kevin Watson]

Originally Posted by amk

Have you resolved this issue? We're having the same problem, but with the C18 V3.10 compiler & beta 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

[amk]

Originally Posted by Kevin Watson

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

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

Ann

[Joe Ross]

Originally Posted by mandrews281

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?

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.

[Joe Ross]

Originally Posted by amk

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

Ann

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

[ldeffenb]

Originally Posted by Kevin Watson

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?

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

[ldeffenb]

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!

[Dave Flowerday]

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

[Kevin Watson]

Originally Posted by Dave Flowerday

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

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

[Guy Davidson]

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.

[billbo911]

Originally Posted by sumadin

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.

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

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

FUNCTION:		Process_Gyro_Data()
*
*	PURPOSE:		Manages ADC data and does gyro rate integration
*
*	CALLED FROM:	ifi_frc.c/Disabled_Spin(),
*					ifi_frc.c/Autonomous_Spin(),
*					ifi_frc.c/Teleop_Spin()
*
*	PARAMETERS:		Unsigned char with a value of zero will prevent this
*					function from calling Reset_ADC_Result_Count() when
*					ADC data has been processed. If you do use this mode
*					of operation you must call Reset_ADC_Result_Count()
*					from your own code. Failure to do this will cause
*					the gyro to stop functioning.

Are you calling Reset_ADC_Result_Count() from your code?