|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: Encoder Code
Are you guys using the p18f8722.h header file included with the KOP compiler?
-Kevin |
|
#2
|
||||
|
||||
|
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 Last edited by PICgnosis : 20-01-2006 at 11:30. |
|
#3
|
||||
|
||||
|
Re: Encoder Code
Quote:
-Kevin |
|
#4
|
||||||
|
||||||
|
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. |
|
#5
|
|||
|
|||
|
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. |
|
#6
|
|||||
|
|||||
|
Re: Encoder Code
Quote:
|
|
#7
|
||||
|
||||
|
Re: Encoder Code
Quote:
-Kevin |
|
#8
|
||||
|
||||
|
Re: Encoder Code
Quote:
Jon Mittelman Team236 |
|
#9
|
|||||
|
|||||
|
Re: Encoder Code
Quote:
|
|
#10
|
|||
|
|||
|
Re: Encoder Code
Quote:
|
|
#11
|
||||
|
||||
|
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?
|
|
#12
|
||||
|
||||
|
Re: Encoder Code
Quote:
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. |
|
#13
|
||||
|
||||
|
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? Last edited by tseres : 23-05-2007 at 20:16. |
|
#14
|
||||
|
||||
|
Re: Encoder Code
Quote:
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. |
|
#15
|
|||||
|
|||||
|
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. Last edited by AdamHeard : 13-08-2007 at 13:09. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Out of the Box Camera Code | russell | Programming | 9 | 21-10-2009 05:28 |
| Kevin Watson's encoder code with RPM output | MaxM | Programming | 2 | 05-02-2005 00:06 |
| Team THRUST - Kevin's Code and Camera Code Combine | Chris_Elston | Programming | 3 | 31-01-2005 22:28 |
| Updated Encoder Code Available | Kevin Watson | Programming | 2 | 04-01-2005 01:00 |
| heres the code. y this not working | omega | Programming | 16 | 31-03-2004 15:18 |