Chief Delphi - encoder vs. motor

Page 2 of 4

Show 100 post(s) from this thread on one page

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

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

- - encoder vs. motor (http://www.chiefdelphi.com/forums/showthread.php?t=31681)

stephenthe1

09-12-2004 19:38

Re: encoder vs. motor

Quote:

Originally Posted by Mike Betts

Steve,

What you have is not a mechanical encoder. It is an optical encoder made by CUI.

Here is a spec sheet: EC202A050A2(S or T)D. As you can see, it comes in two flavors a horizontal or vertical mount.

More importantly, it has a quadrature output so that you can determine direction in your code.

Team 177 used a very similar device last year. I very, very strongly suggest that you download Kevin Watson's example code for optical encoders at http://kevin.org/frc/ and download the file edu_encoder.zip open it up and examine his code very carefully.

What Kevin did is for the edubot. You will have to do the same stuff to the RC code. However, over 50% of the work has been done for you.

It works like a charm. Trust me...

sweet. what a relief.

Mike Betts

09-12-2004 19:41

Re: encoder vs. motor

Postscript:

Go to Optical Encoder Tutorial and read the sections "Introduction To Encoders" and "Technical Overview".

I'm sure you will have questions... Post 'em here...

Mark McLeod

09-12-2004 21:03

Re: encoder vs. motor

Continue in the direction Mike is sending you. I just want to address some of the previous outstanding questions.

Quote:

Originally Posted by stephenthe1

I assigned a value of zero to encoder, however, every time the code is reread (every 30 milliseconds or something?), the value for encoder will be set back to zero, making its function useless. wish there was a way to make it so the thing didn't reread the code every amount of time, but rather go over it once and remember everything, and do everything from there. that's the way it is in most programming languages isn't it. anyway, do you see what I mean? or will it only assign the value of zero to it once and then when it reanalyzes the code, it will use the last assigned value. I don't think it works that way though.

That is the way "static" works.

The statement “static unsigned int encoder = 0;” will only take effect at compile time, not while the code is running. It sort of nails the variable in place and sets it’s initial value only once.
The statement “unsigned int encoder = 0;” will take effect while the code is running. Every time the routine is entered the variable encoder will be “created” and assigned the value of 0.

Referring back to Sean’s comment earlier about only counting rc_dig_06 when it changes, not every pass through the code that it happens to equal 1…
The following is an example of only counting changes in rc_dig_06. This particular method actually doubles the resolution of your encoder as it counts both when it changes to 1 and when it changes to 0.

Code:

static char toggle=1;  // Start as TRUE

 

if (toggle == rc_dig_in06) // Encoder has changed

{

           toggle = !toggle;

           encoder = encoder + 1;

}

This method that we’ve been discussing is called polling the input and works fine for slow changes like your arm movement. If the changes occur faster, such as an encoder on a wheel or motor shaft, then you should use interrupts. Interrupts basically are like a good poke in the controller whenever the encoder state changes, and will be discussed in Kevin’s paper.

Kevin Watson

10-12-2004 01:35

Re: encoder vs. motor

Quote:

Originally Posted by Mike Betts

Here is a spec sheet: EC202A050A2(S or T)D. As you can see, it comes in two flavors a horizontal or vertical mount.

More importantly, it has a quadrature output so that you can determine direction in your code.

Yes, this looks like a nice encoder.

Quote:

Originally Posted by Mike Betts

Team 177 used a very similar device last year. I very, very strongly suggest that you download Kevin Watson's example code for optical encoders at http://kevin.org/frc/ and download the file edu_encoder.zip open it up and examine his code very carefully.

As the company that hosts my web server decided to change the IP on me, you may or may not be able to get a copy of the code at this time. It should start working soon as I just updated the DNS record on my end. If you need the code in the mean time, feel free to drop me a note and I'll send it to you.

Quote:

Originally Posted by Mike Betts

What Kevin did is for the edubot. You will have to do the same stuff to the RC code. However, over 50% of the work has been done for you.

Yeah, I've been a real knuckle-head for not modifying the EDU-RC code to run on the FRC-RC. It's been on my to-do list for some time, but I just haven't had the time. I will, however, get it done before the kick-off.

-Kevin

Mr. Lim

10-12-2004 02:36

Re: encoder vs. motor

I also highly recommend Kevin's code.

We used it on our FRC last year and it worked PERFECTLY. We also used it with a relatively low-resolution encoder, about 64 ticks per revolution.

Some advantages:
- Uses interrupts, so that you don't have to worry about missing your encoder ticks.
- Reads two quadrature outputs, so that you can detect which direction your encoder is spinning (increment your encoder variable when spun in one direction, decrement it in the other)

Things to look out for:
- The version I used had one interrupt per encoder, and interrupted only on rising edges
- This meant my encoder variable would only increase or decrease after about 4 encoder state changes, dividing my effective encoder resolution by 4
- This wasn't a BAD thing, in fact it was a very good exercise in learning, and implementing two interrupts per encoder, which interrupted on rising AND falling edges, and gave me back full encoder resolution

*hint: don't use two interrupts per encoder... to me external interrupts are more expensive than getting a higher resolution encoder. Last year, we had an interrupt or two to spare after we removed our IR after Pittsburgh. Next year, I know we WON'T have any spare external interrupts. I know it sounds crazy, maybe this advice comes a bit late, but buy an encoder with twice the resolution you expect to require.

It gave me a great opportunity to teach students about interrupts vs. polling, and the concepts of rising edges, falling edges and such. Even the whole concept of quadrature was quite interesting to them. Most didn't think it was that easy to figure out which way an encoder was spinning. In addition, we purchased an inexpensive mechanical encoder where we opened up the back, and you could physically see how the quadrature signal was generated with just a sweeping arm, and a few contacts.

I definitely learned a lot, and so did the students on 188.

Thanks Kevin for your code! We used your IR code too =), and were very successful in our empty gymnasium, but weren't so successful on the actual playing field.

-Shawn...

Mike Betts

10-12-2004 10:08

Re: encoder vs. motor

Quote:

Originally Posted by Kevin Watson

...
As the company that hosts my web server decided to change the IP on me, you may or may not be able to get a copy of the code at this time. It should start working soon as I just updated the DNS record on my end
...

Your web site worked fine. The only thing I noticed is that I did not see a link to your FAQ.

Quote:

Originally Posted by Kevin Watson

...
Yeah, I've been a real knuckle-head for not modifying the EDU-RC code to run on the FRC-RC. It's been on my to-do list for some time, but I just haven't had the time. I will, however, get it done before the kick-off
...

IMHO, having a little work left for the student is a good thing. If they encounter problems in porting the code, they can always post here.

Thank you for your help.

Alan Anderson

10-12-2004 10:46

Re: encoder vs. motor

Everybody has been focusing on the programming, but nobody has answered the other question:

Quote:

Originally Posted by stephenthe1

...does the operator interface controller provide a way to simply shut everything down immediately in the event of a disaster?

If you don't already have a "competition dongle" to plug into the top port of your OI, make one now. One of the pins on the competition port will disable the robot, shutting off all its outputs. See the Competition Port Pinout Guide on the Innovation First web site.

A couple of weeks ago I put together a mini-dongle, with the "disable" toggle switch built into a plastic DB-15 connector housing (the extra channel access is wired to be permanently active, and autonomous control is not available). It's mostly going to be used when someone is working on the robot and doesn't want it to bite them if a joystick gets bumped. It'll also come in handy when we want to have multiple robots running at the same time.

Mike Betts

10-12-2004 11:06

Re: encoder vs. motor

Alan,

Thank you for catching that.

I teach my team to pull the power plug or the tether (depending on how it is powered) to the OI to disable the robot. Also, when loading untested code, one team member is to have their hand on the 120 amp circuit breaker disconnect button until the code is verified.

The reason I do not have them use the dongle is that the connection is normally enabled (a broken wire enables the robot).

We use the dongle for autonomous mode testing only.

Kevin Watson

10-12-2004 16:01

Re: encoder vs. motor

Shawn,

Quote:

Originally Posted by SlimBoJones

*hint: don't use two interrupts per encoder... to me external interrupts are more expensive than getting a higher resolution encoder. Last year, we had an interrupt or two to spare after we removed our IR after Pittsburgh. Next year, I know we WON'T have any spare external interrupts.

Actually, the code only generates one interrupt per "tick". This is the desired behavior. If you want to count two edges per "tick" (which is a cool idea), you can modify the interrupt service routine to toggle the edge the interrupt is sensitive to. You could also just use interrupts 3-6, which are sensitive to both edges.

Quote:

Originally Posted by SlimBoJones

I know it sounds crazy, maybe this advice comes a bit late, but buy an encoder with twice the resolution you expect to require.

I'm not sure I would do this. You should do the math beforehand and get an encoder that isn't overkill. You should optimize in the direction of lower counts per revolution.

Quote:

Originally Posted by SlimBoJones

It gave me a great opportunity to teach students about interrupts vs. polling, and the concepts of rising edges, falling edges and such. Even the whole concept of quadrature was quite interesting to them. Most didn't think it was that easy to figure out which way an encoder was spinning. In addition, we purchased an inexpensive mechanical encoder where we opened up the back, and you could physically see how the quadrature signal was generated with just a sweeping arm, and a few contacts.
I definitely learned a lot, and so did the students on 188.

Thanks. It really made my day reading this.

Quote:

Originally Posted by SlimBoJones

Thanks Kevin for your code! We used your IR code too =), and were very successful in our empty gymnasium, but weren't so successful on the actual playing field.

Yeah, I've heard this more than a few times over the last eleven months <grin!>.

-Kevin

Kevin Watson

10-12-2004 16:14

Re: encoder vs. motor

Quote:

Originally Posted by Mike Betts

Your web site worked fine. The only thing I noticed is that I did not see a link to your FAQ.

It's at the top of this page: http://kevin.org/frc/2004

Quote:

Originally Posted by Mike Betts

IMHO, having a little work left for the student is a good thing. If they encounter problems in porting the code, they can always post here.

Unfortunatly, the interrupts I used in the code for the EDU-RC map to digital I/Os one and two on the FRC-RC, which overlap with the digital I/Os I used on the EDU-RC <DOH!>. This may not be obvious and may cause some confusion.

-Kevin

Mike Betts

10-12-2004 19:26

Re: encoder vs. motor

Quote:

Originally Posted by Kevin Watson

...
Unfortunatly, the interrupts I used in the code for the EDU-RC map to digital I/Os one and two on the FRC-RC, which overlap with the digital I/Os I used on the EDU-RC <DOH!>. This may not be obvious and may cause some confusion...

Kevin,

Teams will have lots of I/O and interrupt requirements. They need to understand that there is not "one size fits all" and that different timers. interrupts, et cetera, act differently (eventually, you have to read the manual).

As to your previous statement, I can't get to your website at all now... Please let us know when everything is resolved. Your's is much to precious of a resource to be lost.

Once again, thank you for your guidance and support...

Kevin Watson

11-12-2004 13:21

Re: encoder vs. motor

Quote:

Originally Posted by Kevin Watson

Turns out that I had done a FRC-RC version of the encoder software last February, but didn't post it for some reason. If you'd like to test it before I can get a FRC-RC setup here at home, I've posted it here:

http://kevin.org/frc/frc_encoder.zip

and here:

http://robotics.jpl.nasa.gov/~kevinw/frc_encoder.zip

As I won't get a chance to test it for a few days, please let me know if you have problems with the code.

-Kevin

Kautz

15-12-2004 19:18

Re: encoder vs. motor

Where do you wire the 5v and ground to pin 1 and 2 of the encoder. Pin 3&4 to the digital input /output?

Thanks I searched but do not fine anything.

Kevin Watson

15-12-2004 19:30

Re: encoder vs. motor

Quote:

Originally Posted by Kautz

Where do you wire the 5v and ground to pin 1 and 2 of the encoder. Pin 3&4 to the digital input /output?

Thanks I searched but do not fine anything.

Which encoder are you using?

-Kevin

Kautz

15-12-2004 19:49

Re: encoder vs. motor

Quote:

Originally Posted by Kevin Watson

Which encoder are you using?

-Kevin

It is an optical encoder made by CUI.

EC202A050A2(S or T)D

Sorry about that

All times are GMT -5. The time now is 22:26.

Page 2 of 4

Show 100 post(s) from this thread on one page