Want to speculate on what we've missed about rio/amt 103 encoder?

Technical Electrical
1

So we have a puzzler. Our robot uses a sector gear driven by a toughbox 3 and a CIM to lift an arm to position us for a shot. It’s critical to our robot function. We use an an AMT CUI 103 encoder to know exactly where the arm is and to keep it in position.

It works great, except in semi finals. That is, through all of our building, all of our shadow building, all of our practice matches, all of our in pit testing, all of our qualification matches, it worked great; it never failed once.

But at both regionals we went to, the arm encoder failed during semi finals. (The most recent one was quite spectacular, our robot fell over and died in a nice emulation of Hamlet).

After the first failure in Duluth, we replaced the encoder and the wiring run. After the failure at 10K, we very carefully tried to assess what caused the failure. Nicely, it was in-operational when we got it back to the pit; the encoder held a constant -11 tick count, even as we moved the arm. We then very carefully touched the output shaft of the TB3; it was spinning. We touched the wiring plugged into the encoder (one of these:
http://www.digikey.com/product-detail/en/cui-inc/CUI-435-1FT/102-1504-ND/968159)
it was firmly seated. But after that touch, everything started working great.

And no attempt on our part to break it again worked; we could wiggle, loosen, poke, prod, but we got no failure. (Well, okay, if we disconnected the wire entirely it didn’t work, but…).

Note that we were very careful not to disturb any of the wires going into the rio; our plan was to test them next. (And this cable had strain relief, and it was firmly pressed into the rio and held by electrical tape). We can’t say for absolute sure, but to the best of our ability to control the environment, we did not change the rio end of the wire connection.

At this point, we’re baffled. I don’t think it’s a software bug. It is a pretty big body of code:
https://github.com/HP-Robotics/Automatons-2016
so we could be wrong. But I’m pretty sure we don’t have any
if (matchType == SF)
fail_spectacularly();
code in there. :slight_smile:

We completely replaced the wiring and had the same failure, so I don’t think it was a wiring fault. (And the wires work perfectly now, and no amount of stressing or twisting or tweaking enable it to fail).

I had a theory that the wire run passing over a drive CIM could have, when the CIM was hot from being worked so much, caused a fault, but a smarter mentor than I feels strongly that’s not probable. My only other thought is that there is something faulty on these two particular ports. So our next likely move is to move the encoder down two pins.

Anyone else have any ideas or other possible failures we’ve overlooked?

Cheers,

Jeremy

2

Our drive line encoders failed in the semis at MSC. It took two matches, but found drill shavings in the roborio.

Hemostats, chewing gum, and on to finals.

Check power rails of the roborio, red led on power.

Interesting info on failure, we use npn photoeyes for ball sensing, which all worked with the power rail failure. Solenoids worked. PWM motor controllers worked. (assume DIO and PWM power rails are isolated)

We played basically a normal teleop for two matches, as we only use the drive encoders in autonomous.

On my list to do before worlds, is to see if roborio reports out this fault so we can log the event, maybe already in driverstation log? need to check.

3

It’s hard to say for certain but the CUI encoders have a grounded metal chassis. Is it possible something is shorting?

4

The quick live check is on the Driver Station Power & CAN tab where short faults are separated into 6v/5v/3.3v

5

Yeah, that’s a good point. We are aware of the ground (got magic smoke last year :slight_smile: ), and we’ve got the encoders up off the chassis on vhb. But that’s the sort of thing where there could be a problem that vanishes mysteriously and not return.

Thanks!