FTC: Using the Hitechnic SuperPro Prototype Board

[TRWSHSHLX]

In all my years of coaching ftc, the tetrix encoders could give accurate readings in some matches and completely wring the next match.

"Completely wrong" as in no pattern at all or +/- a few inches up to a feet?

One suggestion is don't draw too much power from the motor controllers at once (like putting full throttle on a six motor drivetrain instantaneously) since that does in fact mess up the encoder count.

[Andrew Lobos]

Originally Posted by TRWSHSHLX

One suggestion is don't draw too much power from the motor controllers at once (like putting full throttle on a six motor drivetrain instantaneously) since that does in fact mess up the encoder count.

This happens because the encoder counts are stored and read from the motor controllers - if they loose power (or brownout), the count will reset.

My FTC team used encoders to achieve infinite rotation on our swerve drive last year, and we had no issues with the encoders returning the wrong position.

A few more questions -
How old are the encoders you're using? Some of the older packages they made used adhesive backing, which I've seen come loose.

When deciding the encoders are returning incorrect values, are you looking at the value itself, or just seeing the results of an action using the encoders? If you are observing the robot driving different distances, but the encoder values are consistant, your issue may be rooted in how your code decides it is "there".

[Mr. 1033]

Can you guys show some sample code?

When I say "its random" I mean when they enter autonomous mode sometimes the robot moves correctly, other times it never stops moving, sometimes it moves the opposite direction, and sometimes it barely moves.

Many of my teams use LabView and they always include a "reset encoder" module block before and after every move forward segment of code.

I'd love to iron out these issues and be able to communicate them back to other coaches who are also frustrated about it.

Has anyone used the IR sensors attached to the prototype board rather than the IR sensor from hitechnic?

[TRWSHSHLX]

I don't have access to LabView or RobotC currently but the pseudo-code should be:

reset encoder;
while (encoder<some_value) //assuming positive is forward
{
  motors go forward;
}
motors stop;

sometimes the robot moves correctly, other times it never stops moving, sometimes it moves the opposite direction, and sometimes it barely moves.

All of the possibilities above might be related to an encoder problem except moving in the opposite direction. Referring to the pseudo-code above, the motors only go one way (forward). If your teams and other teams are using built-in functions or blocks, then it might be possible that the "block" is not setup correctly (like negative encoder count is forward but a positive encoder count is used hence never reaching the value).

The code above has no feedback control and with a reliable reasonable drivetrain, it should consistently be +/- 1 in. per 2 feet.

[Mr. 1033]

Ok. I'll see if the robot c team have the same in their code.

Is there any way to get more precise/repetitive than +/- 1in per 2 feet?

[TRWSHSHLX]

Is there any way to get more precise/repetitive than +/- 1in per 2 feet?

Yes. Usually with the aid of software feedback control with the famous example being PID. However, just tuning and maximizing the consistency of the drivetrain, battery power, and having a ramping up / down function (to minimize slippage / skid) will be significantly easier and beneficial overall as it will help not only autonomous but also tele-op performances.

Also, in most scenarios +/- 1 in. is more than enough since the field usually have different elements (such as taped lines / walls / IR sensor) to "reset" the robot. With "advanced" implementation techniques (such as mounting the IR sensor on a servo, having multiple IR sensor from different angles, etc.) the IR sensor can be extremely beneficial; even just directly polling from the IR sensor and drive till a certain value is reached is accurate, as long as there is a shield to block out ambient light.