Chief Delphi - Encoder Code

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Encoder Code (http://www.chiefdelphi.com/forums/showthread.php?t=41815)

For those encoder fans out there, I've uploaded new-and-improved encoder interface software for your robot controller. The major change is that I've added four additional channels optimized for position control. The code can be found here: http://kevin.org/frc. As always, if you find a bug in the code or a problem with the documentation, please let me know.

Here's the readme file:

Code:

This source code in this file implements an interface up to

six quadrature output encoders. Used with suitable PID control 

software, encoders can be used to control the position and 

velocity of of your robot. In general, for velocity control

with low count rates (~100/s), the encoder channels are 

interchangeable and it's anticipated that teams won't need 

all six inputs and will cut and paste the code as needed. For 

high count rates or position control, the channels are

optimized for specific applications and are not interchangable.

 

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.

 

This software was tested with Grayhill 63R256 and 61K128 

quadrature output optical encoders. Data sheets for these 

devices are included.

 

This source code will work with the PIC18F8520-based FIRST 

Robotics robot controller, the PIC18F8722-based FIRST Robotics

robot controller, and the Robovation/EDU robot controller.

 

                                 ** IMPORTANT **

On a 40MHz PIC18Fxxx, this software can track peak encoder 

count rates as high as a few thousand counts per second, which

should be more than adequate for most applications. To meet

your performance expectations, selecting the proper Counts Per 

Revolution (CPR) parameter of your encoder is very important.

If the CPR is too high, the robot controller will spend too

much time counting encoder "ticks" and not enough time on

other tasks. At the extreme, you will see very wacky behavior

in your robot controller including corrupted data, the red-

light-of-death or the controller may even think the robot is

traveling in a direction that it isn't. Selecting a CPR that

is too low will not give you the resolution you desire. The

CPR should be optimized to minimize the number of interrupts

your robot controller will have to service yet meet your

resolution expectations (yes, millimeter position resolution

to too much to ask for).

 

Another potential problem with high count rates is that

your encoder probably won't have enough drive capability

to send the phase-A and phase-B signals though your cables

without signal degradation, which can cause all kinds of

problems. If you notice that your encoder counts just fine

at low count rates, but exhibits wacky behavior at higher

count rates, you'll probably need to build a line driver

circuit to provide more current drive. An integrated circuit

that can provide this added drive is the 74ACT244 octal

line driver. Mount the circuit close to the encoder.

 

The included project files were built with MPLAB version 7.20.

If your version of MPLAB complains about the project version, 

the best thing to do is just create a new project with MPLAB's 

project wizard. Include every file except: FRC_alltimers.lib 

and ifi_alltimers.lib and you should be able to build the code.

This file is best viewed with tabs set to four characters.

 

****************************************************************

Here's a description of the functions in encoder.c:

 

Initialize_Encoders()

This function initializes the encoder software. It should be

called from user_routines.c/User_Initialization().

 

Get_Encoder_n_Count()

These functions will return the current number of encoder

counts or "ticks" for encoder number n, where n is a number

between one and six.

 

Reset_Encoder_n_Count()

This function can be used to reset individual encoder counts

to zero.

 

Encoder_n_Int_Handler()

This function is automatically called by the microcontroller

when the phase-A signal of an encoder transitions from zero to 

one, and in the case of encoders three through six, one to a 

zero. You shouldn't have to call these functions yourself.

****************************************************************

Nine things must be done before this software will work 

correctly on the FRC-RC:

 

1) Each encoder's phase-A output is wired to one of the six

available interrupt inputs on digital inputs one through six.

Encoder one is wired to digital input one, encoder two is

wired to digital input two, etc.

 

2) Each encoder's phase-B output is wired to any free digital

input. By default, encoder one is wired to digital input

eleven, encoder two is wired to digital input twelve, ...,

encoder six is wired to digital input sixteen. These default

assignments can be changed by editing encoder.h

 

3) You must add the encoder.c/.h source files to your MPLAB 

project.

 

4) Disable encoders not needed for your design by following 

the instructions in encoder.h. By default, all six encoders

are enabled.

 

5) Digital I/O pins used in step 2 above must be declared as

an input in user_routines.c/User_Initialization(). If you 

notice an encoder that only counts in one direction, you 

forgot to do this step.

 

6) The encoder interrupt handlers must be installed in

User_Routines_Fast.c/InterruptHandlerLow(). See the included 

copy of User_Routines_Fast.c to see how this is done.

 

7) A #include statement for the encoder.h header file must be 

included at the beginning of each source file that calls the 

encoder functions. The statement should look like this: 

#include "encoder.h".

 

8) If you're compiling this code for the 2004/2005 FRC-RC, 

you'll need to comment out the #include <p18f8722.h> line 

near the top of encoder.c and then uncomment the #include 

<p18f8520.h> line below it.

 

9) Initialize_Encoders() must be called from user_routines.c/

User_Initialization().

 

Nine things must be done before this software will work 

correctly on the EDU-RC:

 

1) Each encoder's phase-A output is wired to one of the six

available interrupt inputs. Encoder one is wired to interrupt

one, encoder two is wired to interrupt two, etc.

 

2) Each encoder's phase-B output is wired to any free digital

input. By default, encoder one is wired to digital input

eleven, encoder two is wired to digital input twelve, ...,

encoder six is wired to digital input sixteen. These default

assignments can be changed by editing encoder.h.

 

3) You must add the encoder.c/.h source files to your MPLAB 

project.

 

4) Disable encoders not needed for your design by following 

the instructions in encoder.h. By default, all six encoders

are enabled.

 

5) Digital I/O pins used in step 2 above must be declared as

an input in user_routines.c/User_Initialization(). If you 

notice an encoder that only counts in one direction, you 

forgot to do this step.

 

6) The encoder interrupt handlers must be installed in

User_Routines_Fast.c/InterruptHandlerLow(). See the included 

copy of User_Routines_Fast.c to see how this is done.

 

7) A #include statement for the encoder.h header file must be 

included at the beginning of each source file that calls the 

encoder functions. The statement should look like this: 

#include "encoder.h".

 

8) You'll need to comment out the #include <p18f8722.h> line 

near the top of encoder.c and then uncomment the #include 

<p18f8520.h> line below it.

 

9) Initialize_Encoders() must be called from user_routines.c/

User_Initialization().

Re: Encoder Code

Ha! I was just about to implement this today, because I saw you hadn't put the code up yet. Good thing I procrastinated... :D

Re: Encoder Code

I can't believe I am going to be one of the first to get this, I just happened to be downloading everything I will need, and then I found this! cool! Thank kevin!

Re: Encoder Code

I'm getting the following errors when compiling under a brand new MPLAB install. The default code compiles cleanly under it...

Code:

C:\RobotCode\frc_encoder\encoder.c:131:Error [1205] unknown member 'INT3IP' in '__tag_223'

C:\RobotCode\frc_encoder\encoder.c:131:Error [1131] type mismatch in assignment

Re: Encoder Code

Quote:

Originally Posted by phrontist

I'm getting the following errors when compiling under a brand new MPLAB install. The default code compiles cleanly under it...

Code:

C:\RobotCode\frc_encoder\encoder.c:131:Error [1205] unknown member 'INT3IP' in '__tag_223'

C:\RobotCode\frc_encoder\encoder.c:131:Error [1131] type mismatch in assignment

I don't get this message when I build the code. Have you made any modifications to the code? Is p18f8722.h or p18f8520.h (not both) included at the top of encoder.h.

-Kevin

Re: Encoder Code

here is an though of google the error thats what i did which i found an online doc for mp lad latest verison of which i am using.
team 1388
2004 curie divison winners

Re: Encoder Code

the p18f8722.h file i have (mcc 2.40) says:

Code:

extern volatile near unsigned char       INTCON2;

extern volatile near union {

  struct {

    unsigned RBIP:1;

    unsigned INT3P:1;

    unsigned T0IP:1;

    unsigned INTEDG3:1;

    unsigned INTEDG2:1;

    unsigned INTEDG1:1;

    unsigned INTEDG0:1;

    unsigned NOT_RBPU:1;

  };

  struct {

    unsigned :2;

    unsigned TMR0IP:1;

    unsigned :4;

    unsigned RBPU:1;

  };

} INTCON2bits;

i'm a noob, but
shouldn't the second struct be
unsigned :1;
unsigned INT3IP:1;
and does INT3P = INT3IP ?

Re: Encoder Code

I "fixed" (eliminated compiler error) the problem by hacking up that structure declaration.

Re: Encoder Code

offtopic but i was trying to gear sensors working
i think that fixed it...it counts. i dont know about accuracy.

Code:

  struct {

    unsigned :1;

    unsigned INT3IP:1;

    unsigned TMR0IP:1;

    unsigned :4;

    unsigned RBPU:1;

  };

Re: Encoder Code

Are you guys using the p18f8722.h header file included with the KOP compiler?

-Kevin

Re: Encoder Code

Hi.

I had the same problem and also traced it back to the mismatch between the mcc18/h/p18f8722.h and encoder.c aliases for the INT3 external interrupt priority bit.

In encoder.c, bit #1 is aliased as INT3IP but in mcc18/h/p18f8722.h it's called INT3P. If you want the <p18f8722.h> header file to be consistent with the PIC18F8722 datasheet, you should change the alias in p18f8722.h (Ln 1712) to INT3IP. If you're not a stickler for details, as long as you change one of them to match the other, it will compile correctly.

:)
Karen

Re: Encoder Code

Quote:

Originally Posted by PICgnosis

Just FYI, I updated the encoder software with a fixed p18f8722.h header file and workaround instructions.

-Kevin

Re: Encoder Code

Both today's code and the earlier code have a mismatch in function names and prototypes.

the encoder.c has the functions Reset_Encoder_X_Count while encoder.h has the prototypes Set_Encoder_X_Count.

Re: Encoder Code

Kevin,
Does your encoder code work with the GTS provided this year (seeing you don't have specific GTS code posted yet). Reading thru your encoder code it sounds like you have programmed several of the things we wanted to do this year. Thanks for your help as always.

Re: Encoder Code

Quote:

Originally Posted by farmer

That's what I used as a base for my GTS code. Striped off the quadrature stuff, and I'm cool. (Off course, I had problems using that number, but that's another discussion.)

Re: Encoder Code

Quote:

Originally Posted by farmer

Yes, just use interrupts one and two and remove the phase-b sensing code.

-Kevin

Re: Encoder Code

Quote:

Originally Posted by Kevin Watson

Yes, just use interrupts one and two and remove the phase-b sensing code.

-Kevin

So, so much for the GTS sensing reverse direction.......we're using Hall effect sensors (paired with one slightly offset for phase-b) and they're working great

Jon Mittelman
Team236

Re: Encoder Code

Quote:

Originally Posted by Jon236

So, so much for the GTS sensing reverse direction.......we're using Hall effect sensors (paired with one slightly offset for phase-b) and they're working great

The kit GTSs can do direction (different size pulse in each direction), it's just that the pulse is so short that I don't bother. Plus, we never expect our motors to go the wrong way. (Meaning: If they were, we'd have larger issues.)

Re: Encoder Code

Quote:

Originally Posted by Kevin Watson

Yes, just use interrupts one and two and remove the phase-b sensing code.

-Kevin

Thanks a bunch! We will give it a try.

Re: Encoder Code

question: in the encoder code, how can it tell velocity? do i have to count the ticks over a certain time? an example is if i have an encoder on my two drive wheels and i want them to go the same speed. i would know how to adjust the motor speed, but how do i get the actual wheel velocity from the encoder?

Re: Encoder Code

Quote:

Originally Posted by tseres (Post 628855)

ticks/time is the way to go. The velocity is a translation of ticks to wheel
circumference. It helps if you have a fair number of ticks/rev so you can keep the time interval short. Otherwise, it is hard to differentiate stopped (0 velocity) from very slow. A short interval also reduces issues raised by velocity change during the counting interval. The problem with large # of ticks though is you get flooded with interrupts if the robot is moving quickly.

You need to optimize based on what you want to accomplish. Understanding what you are using the velocity value for (and how accurate you need it to be) should be a driving factor in setting up your encoder code.

Re: Encoder Code

also, do i have to use kevin's code with all of the initialization? or could i make my own based upon the phase a and b on the digital inputs?

*EDIT*
is there also a way i could have the encoder counting in the background of my code? or does it do that already....if not, how (if possible).

from looking at the code, do i also have to reset the encoder count? do i also have to manually make the ENCODER_x_COUNT increment every time the encoder ticks?

Re: Encoder Code

Quote:

Originally Posted by tseres (Post 628869)

You really want to use the interrupt capability (Digio 1, 2) for the Phase A.
I suppose you could do it without interrupts, but you would have a lot of overhead and I don't think you would be able to get the accurate counting that you need.

If you are not familiar with interrupt service processing, I would say use Kevin's code with as few modifications as possible. As you understand more about how it works, then experiment with changes.

Kevins code has the encoder tick counting handled at interrupt level, so it is done effectively "in the back ground". Note that the encoder count is incremented (of decremented) in the ISR. (Interrupt Service Routine)

The question about resetting the encoder count depends on what you want to do, and how many ticks you are expecting. I generally find that using a "long" to store the count will let me count for way more than the amount of ticks I could get during a match time. This does mean that you need to store copies in routines that are measuring an elapsed distance.

Note also that I use "long" and not "unsigned long" since the code counts backwards when (negative) when the drive is reversed. If you have a system with encoders where you can not detect rotation direction, you may want to zero the count whenever you stop.

To compute velocity, one of the timers can be used to provide accurate interval info. Based on the timer, you can run a routine periodically that computes the velocity over the time interval.

Re: Encoder Code

I know it's been a while, but I'm designing the ratios for our prototype base now....

how many interrupts per second can the processor handle?

Our highest gear puts the encoder shaft at about 1500 rpm. We're using the grayhill 128's that Kevin reccomends (because we already have them) and that puts out a lot of counts per second , 1486.6 [rpm] / 60 [seconds/min] * 128 [counts/rev] = 3172 counts per second!!!, and that's only one side. That seems like way too much to me.

can anyone confirm this?

Just saw grayhill offers lower res in the same package. Both the 32/25 look good with 793 and 620 interrupts per second at full speed in high.

Still, I would like to know what the processor can handle.

Re: Encoder Code

Quote:

Originally Posted by AdamHeard (Post 638583)

how many interrupts per second can the processor handle?

As I recall, it can handle somewhere in the 5000-7000 range. Keep in mind though, that your encoders will probably not be your only interrupt events. Serial communication (i.e. to the camera) & ADC conversions both also count as interrupts. You may also just have a clock running for other timing.

Quote:

Originally Posted by AdamHeard (Post 638583)

Our highest gear puts the encoder shaft at about 1500 rpm. We're using the grayhill 128's that Kevin reccomends (because we already have them) and that puts out a lot of counts per second , 1486.6 [rpm] / 60 [seconds/min] * 128 [counts/rev] = 3172 counts per second!!!, and that's only one side. That seems like way too much to me.

Something else to consider: where are you putting your encoder, relative to the motor, gearbox & wheel? I would suggest putting it close to the wheel.

Let's suppose you have 10" diameter wheels (fairly large by FIRST standards). That means you have a 31.4" circumference. If that's in a 1:1 ratio with your encoder at 128 ticks per revolution, that means you get an encoder tick every 1/4" of linear movement. That should be sufficient. (I usually aim for 1/4"-1/2" per tick, which has always been more than enough.)

Suppose instead, you have very small wheel - 12" circumference (about 4" dia), and a very fast robot - 20 ft/sec. That means you get 128 ticks per linear foot, and 2560 ticks per second (and 0.1" per tick) at full speed. Double that to count both sides, and you're only at 5k interrupts per second, assuming you're traveling at full speed with both wheels.

If your robot is at a more reasonable speed in the 10-14 ft/sec range, and your wheels are typical FIRST wheels in the 4"-8" dia range, and you have a 1:1 ratio between the encoder and the wheels, at 128 ticks/rev you'll have a good balance among ticks/second, ticks/inch and total interrupts.

Re: Encoder Code

We're using all dead axles so It's far easier to mount it on the gearbox output shaft. There is a either a 12/28 or 16/28 (depending on how many motors were using in the drive) reduction. The stats above are for the 16/28. Also, the res for above is .33 and .43 inches. [also, the sprocket ratio only effects the resolution]

I think we'll go with 64 counts. That gives us about 1586 ticks per second (per side) and a res of .17 inches. That leaves plenty of interrupts open for possible future addons.

Does that sound good?

Re: Encoder Code

We used the 64 Grayhill encoder back in '06 with the speed of our shooters (~1300 rpm) and they worked pretty well for us. We stayed away from the 128 model, way too much resolution at that speed, expecially for that application where all we needed was velocity, not position.

Re: Encoder Code

I read the encoder_readme.txt and encoder.h files but I didn't find out how to disable unused counters. I tried commenting out the ENABLE_ENCODER_X entries in encoder.h but that didn't work.

Any details on how to disable unused encoder channels?

Thanks again Kevin. I'm really looking forward to using this.:)

Re: Encoder Code

Quote:

Originally Posted by AdamHeard (Post 638607)

I think we'll go with 64 counts. That gives us about 1586 ticks per second (per side) and a res of .17 inches. That leaves plenty of interrupts open for possible future addons.

Does that sound good?

You could cut the number of interrupts you are handling down by about a factor of 4 or 5 and see absolutely no change in performance. I would bet my shiny new iPhone that no FIRST robot ever has, or ever will, be accurate to 0.17". You may want to shoot for a resolution of .5 or 1 inch. It will drop the the cost of your hardware solution and save your programmers a whole bunch of headache. While the amount of interrupts you are looking at are in the theoretical limits of what the PIC can handle, your program will have to be very robust and optimized to not crash the system.

Re: Encoder Code

Quote:

Originally Posted by emersont49 (Post 646593)

It seems the encoder_readme.txt file directs you to instructions in the encoder.h file that I forgot to include :rolleyes:. Until I get around to fixing this, you should be able to disable individual channels by commenting out the associated #define ENABLE_ENCODER_n line in the encoder.h file.

-Kevin

Re: Encoder Code

Thanks Kevin. That works great.

I'm also using your "No Jitter" PWM code to run my drive motors on channels 13 and 15.

My bot will only be using 3 or 4 PWM channels total. Should I use channels 13 through 16 if I am using interrupts for encoders? The reasons for using (or not using) PWMs 13 through 16 have never been clear.

Tim

Re: Encoder Code

Quote:

Originally Posted by emersont49 (Post 646668)

The reasons for using (or not using) PWMs 13 through 16 have never been clear.

The twelve "master-generated" PWM signals can only be changed when the regular communication happens between the two CPUs every 26.2 milliseconds. The original reason to use the four "user-generated" PWM signals was to be able to update them more often than that if necessary. The reason not to use them was that they were prone to jittery operation if the user program had interrupts enabled, including turning on Victor speed controllers when the code requested they be off. You can see why it might not be good to use them for drivetrain motors.

With Kevin's new stable PWM code, there's a new reason to use them: it's possible to get better resolution than the standard PWM outputs. If you want extra-precise control of servo position, you can essentially concentrate the 255 discrete steps into a smaller range of travel. This works great for controlling the CMUCam tilt/pan assembly and getting much better information on exactly which direction the green target light is from the robot.

Re: Encoder Code

Kevin - during the season you worked a bit on new full-blown camera code with the improved resolution (which I believe you can still download off the link here in the forums, but not on your FRC page). Any chance you'll post the the streamlined version with the same improvements? We had it working at one point but we got rid of it in favor of the old version when we had to reprogram some other portions of our code.

Re: Encoder Code- help !!!

hi,
I try to use kevin's encoder
I opend the project :'encoder.mcw'
but I get en errors :
'encoder.c:130:Error [1205] unknown member 'INT3IP' in '___tag_223'
'encoder.c:130:Error [1131] type mismatch in assignment'

what can I do ??? :ahh:

thanks.

Re: Encoder Code- help !!!

Quote:

Originally Posted by avitzur (Post 653621)

You can do two things. First, read the documentation that came with the code you're using.

Quote:

Originally Posted by EncoderReadme

The p18f8722.h header file included with the C18 2.4
compiler may have an error that will prevent you from
compiling this software. If you get an error like:

...Error [1205] unknown member 'INT3IP'...

You'll need to replace your copy of p18f8722.h with the
version included with this project. If you installed your
compiler using the default path, this file should be located
at c:\mcc18\h.

Second, learn about the wonderful search facility here on the Chief Delphi forums. Searching for the keyword INT3IP provides plenty of information that explains the problem and its solution.

Re: Encoder Code

Alan, I think you forgot the most important:

Welcome to Chief Delphi! (first post of Avi):D

Re: Encoder Code

I've been programming for over 25 years, including some fairly heavy scientific programming and hobby programming on PIC microprocessors, and I have found this entire process of mentoring in FIRST to be quite confusing.

I think that those who make obnoxious remarks have probably forgotten what it was like to be completely new at this, on a rookie team, and working with new tools.

I agreed to mentor. Little did I know that I would be directed to read hundreds of pages of tedious documentation, when instead a simple example might seem to be in order.

Oh, I know: search the forum for "simple example" ... sorry, no hits.

Re: Encoder Code

Quote:

Originally Posted by John Hooper (Post 682400)

I don't think the obnoxious remarks are made on purpose. Sometimes people are kidding and the written English language is tricky when it comes to expressing emotions. ( I used to be a writer.)
One basic problem is that brilliant design engineers, software engineers, electrical engineers do not always make good online teachers. A teacher is someone TRAINED to break down ideas for the expressed intent of explaining to someone who needs a very basic explanation with simple, concrete examples. (Teachers deserve a LOT more respect!) Half the stuff I read in here would be impossible to understand if I hadn't studied PIC programming and read a thick book on the chips that solved all my insomnia problems!
This stuff is darned confusing and C is a fairly hostile language when it comes to humans. It's highly unintuitive and I can hardly wait for the next fad language, or a decent C translator to come along and make some sense out of it all. (Oh I CAN do it... but it takes more time and effort than it should and goes against my philosophy that computers should make things easy for people and not the other way around.)
In the end, I can hardly disagree that there are a profound lack of SIMPLE examples and explanations of concepts. That's one reason mentors are important. If you understand it, then you can translate for the kids on the team in a way they can understand. Still I agree with you, it's all too cryptic and tedious. Mentoring s tough (and sometimes thankless) and I doubt we'll ever see someone get a Nobel prize out of their involvement with a FIRST team, but it's important if not rewarding.
And by the way, if no one else has said it, Thanks for being a mentor.

Best wishes

Steve

Re: Encoder Code

Quote:

Originally Posted by John Hooper (Post 682400)

Oh, I know: search the forum for "simple example" ... sorry, no hits.

The default code is a simple example. The documentation for the default code explains it well.

Re: Encoder Code

Quote:

Originally Posted by Alan Anderson (Post 682719)

The default code is a simple example. The documentation for the default code explains it well.

Maybe I just never found this "default code" ... are you talking about the EasyC, Kevin Watson's JPL code, or the regular MPLab code? Where is the documentation? The only documentation I have seen is for EasyC, which wasn't really recommended at our kickoff meeting, so I only looked at it because the Juggernaut team helping us uses EasyC.

Everything I've seen in MPLab doesn't look documented at all. Just a bunch of empty functions with no explanation.

Re: Encoder Code

Hey wait, I think I finally found it. It was in a logical place, sort of, but the first links for "default code" are all dead links. That's because they are from previous years. The actual active links are five pages into the thread.

This is great, only three weeks and I have the default code! Actually, I think I downloaded it before along with a million other things as I was looking for code. OK, so sometimes you just look at the 2004 documentation. I should have been able to guess that.

Somtimes information from previous years is good, sometimes not. Got it.

Re: Encoder Code

Quote:

Originally Posted by John Hooper (Post 684413)

Everything I've seen in MPLab doesn't look documented at all. Just a bunch of empty functions with no explanation.

Just out of curiousity, are you referring to my code or IFI's? If it's my code, what can be done better?

-Kevin

Re: Encoder Code

Quote:

Originally Posted by Kevin Watson (Post 684427)

Just out of curiousity, are you referring to my code or IFI's? If it's my code, what can be done better?

-Kevin

It wasn't a criticism of any code. I couldn't criticize any code, because I can't tell what it is doing. It looks to me like a shell that is filled with functions that I should code. Unfortunately, I don't really know what to do with them, and even if I did, being a mentor for a rookie team, we don't have a robot to download to and most likely won't have one for a while.

I have borrowed a Vex robot, and I have ordered parts to build my own small toy robot, just to have a chance to work on the software. One of the kids is going to put the Vex robot together in the next few days.

Specifically, I don't understand how the software system is supposed to work. Apparently I missed out on the thorough documentation that Mr. Anderson has alluded to, but I might have it now, I hope.

The EasyC system (which we did not really look at) seems to be well documented and has explanations of how you do things. I can program in C, so I didn't look at it, as I usually find code generators to be tedious, limited, and just basically in the way.

I'm sure that once I can actually download the code into a robot and experiment, it will all make sense.

Re: Encoder Code

Ouch! That's rough! 3 weeks! You probably already know all this but just in case. Everything is overhead except for:
user_routines.h
user_routines.c
user_routines_fast.c

user_routines_fast executes once every 26.2ms (approx) and doesn't wait for the operator interface to send data. You can run the robot from this routine and in fact this is where you'd put code for the autonomous period, or any fast calculations from on board sensors without Operator Interface input.

user_routines Processes input (like joystick positions or pushbuttons or scaling the joysticks so they are not so sensitive on the low end) from the Operator Interface. most of the coding for actually operating the robot is in here, while the automatic stuff (an algorithm for keeping the robot running straight perhaps) Happens in user_routines_fast

user_routines.h describes itself:

Code:

* USAGE:

*  If you add your own routines to those files, this is a good place to add

*  your custom macros (aliases), type definitions, and function prototypes.

I am not a programming guru so I stay out of this one.

If you're looking for Encoder routines, Kevin Watson's is a quite elegant place to start. Downloading his code in the robot gives you on screen output of 6 encoders that use A & B phase direction/count inputs that are connected to the digital in/out on 1,11 2,12, 3,13, 4,14, 5,15, 6,16 positions.
You also get his interrupt driven serial port drivers. I didn't realize this at first, so I got confused until I finally figured it out. You disable unused encoders in encoder.h (I commented out the enable lines for the unused encoders).
I compared the encoder user_routines.c file with the default user_routines.c program to find out what I needed to leave in to allow the encoders to run and ended up adding my own joystick programs to the encoder user_routines.c and got it to work.
Really cool stuff and I have to thank Kevin for demystifying it. I'll be happy to send you MY files and you can see if they'll work on your VEX setup.

Best wishes
Steve

Re: Encoder Code

Thanks Steve. No, I didn't know any of that. That is some really invaluable information to have.

A real working example is exactly what I wanted, so if you can share that would be great. I have MPLAB 8.1, compiler 3.1 set up with Kevin Watson's FRC code, which does compile. I also have EasyC set up and running the default code. I know that EasyC will work with the VEX, but I'm not really sure about MPLAB.

It will be great next year when we have an extra FRC robot.

I'm sure anything you send will be very instructive for me.

Thanks again!

Re: Encoder Code

Quote:

Originally Posted by John Hooper (Post 684562)

I have MPLAB 8.1, compiler 3.1 set up with Kevin Watson's FRC code, which does compile.

Open up teleop.c in your editor. The one function you really need to know about is Teleop(). During teleoperation mode this function is called when new data has been received from the operator (i.e., robot driver) interface, which has a bunch of joysticks attached. This happens every ~26ms. The idea is to take the driver's input and use it to control a motor. The simplest case would be something like:

pwm07 = p1_y;

This maps the y-axis of the joystick attached to port one of the operator interface to the motor controlled by PMW output seven. The variables are unsigned chars where neutral is 127, full reverse is 0, and full forward is 255. pwm07 and p1_y are #defined in ifi_frc.h. The default mapping that has been used in the past can be found in ifi_code.c/Default_Routine().

-Kevin

I am using the 'frc_encoder' from 2006 as a base project and C18 2.4

I wont to use your new 'clock' file from 2008 but it looks for 'ifi_frc.h'
what can i do ??????

avi:ahh:

Quote:

Originally Posted by avitzur (Post 701487)

I am using the 'frc_encoder' from 2006 as a base project and C18 2.4

I wont to use your new 'clock' file from 2008 but it looks for 'ifi_frc.h'
what can i do ??????

avi:ahh:

Replace that #include statement with this one: #include <p18cxxx.h>. If you're using 2006 code, it's important to make sure you follow the steps in this document too.

-Kevin