New C18 3.0+ Compatible FRC Code

[Kevin Watson]

Originally Posted by Jon236

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

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

[Jon236]

Kevin,

I re-installed 3.10 and it worked just fine!

Thanks for all your work!

Jon

[Lafleur]

Originally Posted by Kevin Watson

I just made this change (thanks Mike) and added some additional documentattion to the ADC and gyro code. Link is in message #1 of this thread.

-Kevin

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

[comphappy]

Originally Posted by Kevin Watson

I just made this change (thanks Mike) and added some additional documentattion to the ADC and gyro code. Link is in message #1 of this thread.

-Kevin

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?

[Nathans]

Originally Posted by Mike Mahar

The simple answer is don't use Get_Analog_value. The new code in adc.c should replace it. Instead you should call Get_ADC_Result. Make sure you set NUM_ADC_CHANNELS to the number of analog inputs you are using and allocate them starting with first one and go up from there.

The analog inputs are not instantaneous. You have to start them, then wait a certain amount of time and then read them. The code in adc.c will do that for you and uses a timer to wait. Calls to Get_ADC_Result will simply fetch the result that the library has already captured for you.

The function Get_Analog_value does the start/wait/read operation in-place and takes longer and consumes valuable cycles that could be put to better use doing something else.

How do you allocate the analog inputs with Get_ADC_Result? I found where to set NUM_ADC_CHANNELS, but I haven't found anything about allocating specific inputs. Furthermore, what is used as the argument of Get_ADC_Result?

[Joe Ross]

Originally Posted by neutrino15

I am currently in the process of testing the old configure.py makefile with this new code. Has anybody had success?

I use a mac, and seriously do not want to try and update mplab in vmware.. painful memories..

There have been at least two makefiles posted in this thread.

[comphappy]

I am trying to figure out the encoder code, and do not understand how the code knows what way the shaft is turning,
void Int_1_ISR(void)
{
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}

What really is ENCODER_1_PHASE_B_PIN?
And what port is this interrupt running one Input 1 or 2?

[billbo911]

Originally Posted by comphappy

I am trying to figure out the encoder code, and do not understand how the code knows what way the shaft is turning,
void Int_1_ISR(void)
{
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}

What really is ENCODER_1_PHASE_B_PIN?
And what port is this interrupt running one Input 1 or 2?

When using a "Quadrature" encoder, there are two signals generated, Phase A and Phase B. Both are square waves with "B" 180 degrees out of phase from "A". When triggered by "A" going high, the ISR looks at "B", if it is low, you are going forward, if "B" is high you are going backward.
In the code it explains how to attach the A and B phases.

Now, if you are not using a quadrature encoder but one with a single output, like the GTS in the kit, then determining direction is a much bigger challenge although, not impossible.

[Kevin Watson]

Originally Posted by comphappy

I am trying to figure out the encoder code, and do not understand how the code knows what way the shaft is turning,
void Int_1_ISR(void)
{
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}

What really is ENCODER_1_PHASE_B_PIN?
And what port is this interrupt running one Input 1 or 2?

Open up encoder.h and have a look at the comments for the answer to what ENCODER_1_PHASE_B_PIN is. Rotation direction is determined by the logic state of phase b on the rising edge of phase a. Have a look at this illustration for a diagram showing what the waveform looks like. If the encoder were spinning in the opposite direction, the phase b waveform in the illustration would be flipped top to bottom.

-Kevin

[comphappy]

Originally Posted by Kevin Watson

Open up encoder.h and have a look at the comments for the answer to what ENCODER_1_PHASE_B_PIN is. Rotation direction is determined by the logic state of phase b on the rising edge of phase a. Have a look at this illustration for a diagram showing what the waveform looks like. If the encoder were spinning in the opposit direction, the phase b waveform in the illustration would be flipped top to bottom.

-Kevin

I got what port it was hooked up to, I was just trying to figure out what phase b was, as the GTS does not have one, I will just modify the code so that instead of looking at phase b it will look at the PWM > or < 127 to determine the correct operand. I just need to determine the distance travailed on the linear drive.
Thank you for the diagram it was really useful. (BTW I like your code, it is clean and well organized)

[billbo911]

Originally Posted by comphappy

.... as the GTS does not have one, I will just modify the code so that instead of looking at phase b it will look at the PWM > or < 127 to determine the correct operand. I just need to determine the distance travailed on the linear drive....

I have used this method in the past on my Vex bot. It works fairly well but is not perfect. For use in straight line driving, as in Hybrid mode, it should be sufficient. BTW, make sure you account for the dead-band associated with the Victor.

[comphappy]

Originally Posted by billbo911

I have used this method in the past on my Vex bot. It works fairly well but is not perfect. For use in straight line driving, as in Hybrid mode, it should be sufficient. BTW, make sure you account for the dead-band associated with the Victor.

Yes, I am aware of that, but in this case the PWM is being driven with out any user input, should be ether 0 or 255, nothing in the middle.

[billbo911]

Originally Posted by comphappy

Yes, I am aware of that, but in this case the PWM is being driven with out any user input, should be ether 0 or 255, nothing in the middle.

I'm not sure I am following what the question is. If you have a PWM value that is going to be only one of two states, 0 or 255, then just test for one state. For example:

if (pwm03 > 127)
    {
      accumulator ++;
    }
else
    {
     accumulator --;
    }

I chose 127 just for simplicity.

Just as easily, you could test for the actual value.

if (pwm03 == 255)
    {
      accumulator ++;
    }
else
    {
     accumulator --;
    }

[comphappy]

Originally Posted by billbo911

I'm not sure I am following what the question is. If you have a PWM value that is going to be only one of two states, 0 or 255, then just test for one state. For example:

if (pwm03 > 127)
    {
      accumulator ++;
    }
else
    {
     accumulator --;
    }

I chose 127 just for simplicity.

Just as easily, you could test for the actual value.

if (pwm03 == 255)
    {
      accumulator ++;
    }
else
    {
     accumulator --;
    }

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.

[billbo911]

Originally Posted by comphappy

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.

It's nice to know that great minds think alike

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 )