[FTC]: Motor encoders Love'em? or leave'em?

[DocMartin]

My fellow Mentor and I are at odds on using encoders or not.

I want to hear from you.

Does your team use them or not? and why?

Go!

[MattRain]

We love them. With the right code, they work wonders. We have code that allows us to move all the way up to a .001 of an inch, not that we need.. haha.

[DocMartin]

Can you provide some examples of what scenario you had the need to use them and what problem it solved?

[ksafin]

I don't think this question can be asked so broadly.

They're hugely necessary in some instances, useless and redundant in others.

You should analyze your situations and decide what's best for it.

[Nemo]

I just wish the things weren't so insanely expensive and fragile.

[ftcTeam6389]

We've never had good luck with them, they are not accurate. Program it to go to the same spot every time, but it rarely does. I also agree they are too delicate. I just don't understand why Tetrix can't come out with a DC motor with a good encoder built in.

[MattRain]

Originally Posted by DocMartin

Can you provide some examples of what scenario you had the need to use them and what problem it solved?

For example for last years FTC. The robot sits in the corner of the field. Autonomous starts. IR turns on, finds out which column the IR is on, then picks out of three programs, which one to run to make it to the IR. Ok, say its the left column, robot makes a left 45 degree turn, goes 15 inches, right 45 degree turn, 20 or so inches forward, stops, lift goes up, which also has an encoder to tell it how many turns, to make it to that height, then 5 inches in, placing the ring on the peg, lift goes down a few inches, robot backs up 10 inches, does a 135 degree turn to face the ring dispenser. Ready for teleop.

With our code as well, I could move the robot to tile, carpet, concrete, asphalt, etc. And it would still do the same exact thing the program tells it to. Other than a few teams that I have seen with advanced code, most teams run off time, which with time, just with the wear and tear of some foam tiles, or brand new tiles, along with battery powered, wither fully charged, or somewhat charged, can change the autonomous sooooooo much.

If you write your code right, it works. With what we have written, it takes us less than a few minutes to write a code, or 30 minutes to write a very precise code. (and extremely easy once written. One of our new programmers, never seen code before, is writing the autonomous this year,(one day of teaching the basics) only having to list down how many inches,degrees turned,and lifting height)

How did you verify that your positioning was accurate to within .001"?

The code is written in such a way, that it tells me on the NXT brick and computer screen, how far its traveled for each step it does, granted, there is no reason for that precision, especially this year, so we changed only go to the .1 of an inch really.

[Ether]

Originally Posted by MattRain

The code is written in such a way, that it tells me on the NXT brick and computer screen, how far its traveled for each step it does

I don't think that answered the question Madison was asking.

There's a difference between what the sensor on your robot says and how far the vehicle actually moved.

[MattRain]

Originally Posted by Ether

I don't think that answered the question Madison was asking.

There's a difference between what the sensor on your robot says and how far the vehicle actually moved.

Ok, yes there is that fact of that robot could have gone a little under or over that number. Again, there really is no reason for programming that far, and hard to even get that measurement in real time, without looking at the computer. I was just stating the fact that the program could do it if it really wanted to. Right now in our programming, we do give a tolerance area for the code to decided if its in the right place without it getting stuck on a certain step. Its just stupid not to have your program run through all the steps because of a small.1 of an inch. I think right now, our programmer has it to a .1 or .15 of a tolerance, as there is really no need for huge precision this year, unlike last year with the pegs and such.

[Ether]

Originally Posted by MattRain

Ok, yes there is that fact of that robot could have gone a little under or over that number [ed: 0.001 inch]

As a pre-kickoff project, you might want to try this:

1) Command your robot to move exactly 20 feet forward and stop.

2) Using a tape measure, determine how far it actually traveled.

3) I think you may find the results surprising.

[MattRain]

I will have to students try that out today. I shall post the results tonight.

[Ether]

Originally Posted by MattRain 15Nov2013 11:00

I will have to students try that out today. I shall post the results tonight.

Did you forget?

[aakerberg]

Well, accurate distance isn't all that important. Presumably you should have some opportunity to tune your program to account for any inaccuracy in the encoder. However, consistent results ARE important. A better experiment would be:

1. Mark a very specific start point
2. Program the robot to go any distance
3. Mark where it finishes moving.
4. Repeat several times - preferably with different loads (add/subtract weight) and/or different levels of battery charge.

How close does it get to your original finish mark each time? if the encoders are reasonably consistent, you should end up in the same spot (or very close) each time, regardless of load or battery condition.

The problem with using encoders for measuring robot position in autonomous mode is they offer no defense against the things that are most likely to trip you up - getting bumped off course by another robot, wheels slipping on the edge of the board, etc.. I would argue that provided you don't make radical changes to the robot during the course of a single competition and manage your battery pack properly, you can get equally effective results using time for judging distances driven.

If they are consistent, I can see them being more useful for measuring things like precision arm movements, or maybe feedback for a sophisticated driving control system...

We have been also been unhappy with they way they are mounted to the outside of the motor. We are experimenting this year with other ways to give us the information we need.

[Ether]

Originally Posted by aakerberg

Well, accurate distance isn't all that important.

That may well be true in many cases, but the specific point of posts 7, 11, 12, 13, 14, and 15 was to think through the statement in post 2.

[Sasha]

We do use encoders for autonomous. They work fine for straight motion (of course, not to 0.01 inch - but it is not necessary). However, we found them rather unreliable for measuring turns (when turning, both wheels slip), so we use gyro sensor for this. Works much better for us. Your mileage may vary.