Encoder Code

[emersont49]

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

[Alan Anderson]

Originally Posted by emersont49

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.

[Tom Line]

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.

[avitzur]

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

thanks.

[Alan Anderson]

Originally Posted by avitzur

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

thanks.

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

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.

[Bomberofdoom]

Alan, I think you forgot the most important:

Welcome to Chief Delphi! (first post of Avi)

[John Hooper]

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.

[Steve_Alaniz]

Originally Posted by John Hooper

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.

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

[Alan Anderson]

Originally Posted by John Hooper

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.

[John Hooper]

Originally Posted by Alan Anderson

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.

[John Hooper]

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.

[Kevin Watson]

Originally Posted by John Hooper

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

[John Hooper]

Originally Posted by Kevin Watson

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.

[Steve_Alaniz]

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:

* 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

[John Hooper]

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!