FTC: Using the Hitechnic SuperPro Prototype Board

[Mr. 1033]

Does anyone have any experience with the Hitechnic SuperPro Prototype board?

http://www.hitechnic.com/cgi-bin/com...on&key=SPR2010

My 5 FTC teams have always had inconsistency issues with the encoders from Tetrix and the IR sensor.

My understanding from what I've read is that we can use this prototyping board and attach sensors to it. Then its just a matter of programming it in LabView or Robot C.

Thoughts?

[Rainydaymaker]

We used it last year to read limit switches.

[Andrew Lobos]

We have used the protoboard in the past to read potentiometers for position of arms and swerve pods.

We have had no issues with the encoders being read by the motor controllers in the past. What issues did you encounter?

If you are thinking of using the protoboard to read encoders, I would be careful. Since there is no way to catch interrupts on the protoboard, you would have to constantly poll the protoboard; this creates the potential for missing pulses. The TETRIX motor controllers use interrupts on the encoder ports to prevent missing pulses.

[Mr. 1033]

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

I've observed and heard this from over 20 other teams in addition to my 5 or 6 teams.

We mount encoders per the instructions using white cloth gloves and everything.

The program produces clean build and will run correctly up until the randomness ten or more attempts later.

Regardless I think were going to use the prototype boards for limit switches, leds etc.

Anyone have any tips or ideas for encoders?

[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.