Re: Consistent encoder rate
 

I posted this in another thread, but if you use the wpi's getRate function, I've been told it looks at rate in the following way.

1count / (current time - time of last count)


the way we helped limit this noise is using the sum of the counts

encoder counts / (current time - time of last loop)

then reset the encoder.

this will give you a much steadier reading. Just try to limit the function to being called one time per loop. For example, only our PID calculates speed, where everything else reads from a variable it stores the speed in after the calculation. Thus ensuring that is only called once every PID loop.

Re: Consistent encoder rate
 

360. I put tape on the wheel and made one rotation.

In the original post I used the sampling in WPI's encoder settings, but now I don't. As per lineskier, I believe it samples it much quicker than 2½ seconds though, though.


1x. Encoder class.

I placed code that is like "read count, subtract previous count, divide by measured elapsed time since previous sample" in the 100ms loop in the Periodic Tasks VI, so it's assumed. Indeed, during my work with the magnetic encoder, I found that the actual time does vary. I could try to use a Timed Loop to make the time more consistent.

Sorry, I meant braid.

Re: Consistent encoder rate
 

Make sure that the shaft is well centered relative to the encoder sensor. We had an encoder problem where the distance was reading correctly, but the rate was varying. The problem turned out to be that the shaft and disk were eccentric relative to the sensor. You could see the disk move up/down/side to side relative to the sensor. After correcting the centering, our readings improved dramatically.

Re: Consistent encoder rate
 

How do you braid with a hand drill?

Re: Consistent encoder rate
 

Team 358's "Timing Is Everything" paper is worth reading:

http://team358.org/files/programming...Everything.PDF

Re: Consistent encoder rate
 

My terminology is terrible. :rolleyes: By twist I thought slijin meant twisting each individual wire. I did this.

I should try to implement that and see if that makes an improvement.

I noticed this was a problem with one of the encoders when Ether reminded me to make sure they were properly mounted, but one was properly mounted. Unfortunately, I could not correct it before the robot was bagged.

Re: Consistent encoder rate
 

Just for clarification, braids resemble these:
.

Light braiding will work for wire management (you don't want to braid stuff very tightly either), because all you're doing is flexing the wire. In the link you gave, though, there's a lot of tension on that wire - an absolute no-no in a moving application subject to vibration, especially on signal wires.

Re: Consistent encoder rate
 

Why is that so bad?

Re: Consistent encoder rate
 

Especially when you consider that most instrumentation cable used in industry is in twisted/paired form. Clearly installing a twisted pair without any kind of slack would be bad, and twisting it by hand (drill) raises the possibility of excessive strain on the strands if it's "overtwisted", but I'm not sure why it should be considered bad practice in the context of the FRC.

In simple terms, the advantage to twisting the wires is that voltages induced in the conductors by external, changing magnetic fields (a type of EMI) in accordance with Faraday's Law are made self-cancelling due to the twist. The ideal twist pitch is a function of the characteristics of the shape of the magnetic field. In most instrumentation cable you'll encounter pitches between 1 and 8 twists per inch. In FRC, the major source of changing magnetic fields is the brushed DC motors we use.

Re: Consistent encoder rate
 

The way I see it, putting tension like that on a wire is liable to either stress it past its breaking point or make it particularly brittle. Once that wire gets tied down to the frame of a robot, chassis vibrations (from driving, turning - any movement) then propagate into the wire, which is liable to break it. Given that the E4P's wires are so fragile already (you can actually rip these wires by hand), I'd be wary of putting any undue stress on them.

Alex, I am aware that twisting wire is a common practice in industry for the very reason you mention; my position is that the undue stress placed on the wire by twisting it with a hand drill, especially to the extent of the link, is likely to do more damage than good, especially in this particular example.

That being said, don't focus too much on the physical aspect; wire twisting could be the issue, but it won't necessarily be the issue. If you can, get some testing done; prepare a bench test (or a test setup on another bot) to see if you can troubleshoot your encoder problem. Use a similar wire setup (twisted wires and all) and see what you can do to isolate your problem. Although conditions won't be exactly the same, you probably will find issues that you didn't even originally notice, and then find a solution before competition.

Re: Consistent encoder rate
 

It turns out that inconsistent elapsed time between loops was the main culprit. I fixed the variation in our speed readings with a Timed Loop.

Thanks again for the help.