Go to Post Never allow your students to get away with an answer that amounts to "because it's better". Have them prove it to the best of their ability, and when they're wrong, ask them to figure out why they're wrong. - Tom Line [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 24-05-2007, 14:19
ericand's Avatar
ericand ericand is offline
Registered User
AKA: Eric Anderson
FRC #3765 (Terrabots)
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2004
Location: St. Paul, MN
Posts: 148
ericand is a jewel in the roughericand is a jewel in the roughericand is a jewel in the rough
Re: Encoder Code

Quote:
Originally Posted by tseres View Post
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?
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.
  #2   Spotlight this post!  
Unread 13-08-2007, 12:57
AdamHeard's Avatar
AdamHeard AdamHeard is offline
Lead Mentor
FRC #0973 (Greybots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Atascadero
Posts: 5,526
AdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond repute
Send a message via AIM to AdamHeard
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.
  #3   Spotlight this post!  
Unread 13-08-2007, 15:08
ay2b's Avatar
ay2b ay2b is offline
Registered User
AKA: Andy
FRC #2928
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 1994
Location: Seattle, WA
Posts: 211
ay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant futureay2b has a brilliant future
Re: Encoder Code

Quote:
Originally Posted by AdamHeard View Post
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 View Post
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.
__________________

2011 - SD Quarterfinalists (980), LA Quarterfinalists (980)
2010 - LA (2404) Finalists (980), AZ Motorola Quality (980)
2009 - LA Semifinalists (980); Las Vegas Quarterfinalists (980); SD (2404); IRI #1 Seed, Finalist (980)
2008 - SD Quarterfinalists (980), LA Champions (980), LA Rookie Inspiration Award (2404); CalGames Finalists
2007 - So.Cal Finalists (980), SD Quarterfinalists (980); CalGames Finalists
2006 - So.Cal Regional Champion (4), Toronto Judge's Award Day 1 (4)
2005 - SVR Champions, Delphi "Driving Tomorrow's Technology" (980); AZ Xerox Creativity (980); So.Cal Finalists, RadioShack Innovation in Control (980); Championship Archimedes Division Semifinalists; IRI Finalists (980)
2004 - So.Cal Regional Champions, Leadership in Controls (980); AZ GM Industrial Design (980); Championship Galileo Division #2 Seed; IRI Champions
2003 - PNW Semi-finalists (488)
2002 - PNW Finalists (488)
2000 - X-bot / 488 - Mentor / Founder
1994 - Sunny Delight - Driver - champion
  #4   Spotlight this post!  
Unread 13-08-2007, 15:56
AdamHeard's Avatar
AdamHeard AdamHeard is offline
Lead Mentor
FRC #0973 (Greybots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Atascadero
Posts: 5,526
AdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond repute
Send a message via AIM to AdamHeard
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?

Last edited by AdamHeard : 13-08-2007 at 19:23.
  #5   Spotlight this post!  
Unread 14-08-2007, 08:41
Doug G's Avatar
Doug G Doug G is offline
Coach / Teacher
FRC #0701 (Robovikes)
Team Role: Coach
 
Join Date: Dec 2002
Rookie Year: 2001
Location: Fairfield, CA
Posts: 880
Doug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond reputeDoug G has a reputation beyond repute
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.
__________________
Work Hard, Have Fun, Make a Difference!

  #6   Spotlight this post!  
Unread 17-10-2007, 22:12
emersont49 emersont49 is offline
Mentor
#1098
 
Join Date: Sep 2004
Location: Fenton, Missouri
Posts: 34
emersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of light
Red face 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.
__________________
Tim Emerson
  #7   Spotlight this post!  
Unread 18-10-2007, 02:51
Kevin Watson's Avatar
Kevin Watson Kevin Watson is offline
La Caņada High School
FRC #2429
Team Role: Mentor
 
Join Date: Jan 2002
Rookie Year: 2001
Location: La Caņada, California
Posts: 1,335
Kevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond reputeKevin Watson has a reputation beyond repute
Re: Encoder Code

Quote:
Originally Posted by emersont49 View Post
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.
It seems the encoder_readme.txt file directs you to instructions in the encoder.h file that I forgot to include . 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
__________________
Kevin Watson
Engineer at stealth-mode startup
http://kevin.org
  #8   Spotlight this post!  
Unread 18-10-2007, 14:52
emersont49 emersont49 is offline
Mentor
#1098
 
Join Date: Sep 2004
Location: Fenton, Missouri
Posts: 34
emersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of lightemersont49 is a glorious beacon of light
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
__________________
Tim Emerson
  #9   Spotlight this post!  
Unread 18-10-2007, 15:16
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,113
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Encoder Code

Quote:
Originally Posted by emersont49 View Post
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.
  #10   Spotlight this post!  
Unread 18-10-2007, 22:15
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,554
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
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.
  #11   Spotlight this post!  
Unread 17-10-2007, 23:28
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,188
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: Encoder Code

Quote:
Originally Posted by AdamHeard View Post
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.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT -5. The time now is 02:13.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi