Encoder instability

[cantdecide]

We're using the PG71 motor from Andymark which has an hall-effect encoder to hold the shooter at an angle, and it works marvellously, but only when it does. However, sometimes, despite the shaft moving, we won't get any signals for a few seconds. This usually causes the whole shooter system to mess up, and we had to add an encoder reset function for the operator to press when we see that we've lost control. I'd still like to fix it altogether instead of a hack that makes us lose time. We've tried so far:

• Trying different encoders(the whole assembly really)
• Changing cables
• Even trying a new roboRIO!

Is anyone else having these problems with the PG71 gearmotor, or the hall-effect sensor from Andymark? Thanks!

[c0d3rman]

As it seems you've replaced a lot of your hardware already, have you considered it may be code?

[GeeTwo]

How much do you lose the angle? Is it small enough just to be backlash, or is this really a significant amount?

Under what conditions does this happen/not happen? E.g. only when being backdriven, only in reverse, only when the last joystick command was x. Any patterns as to when it does/does not happen can help point to a cause.

Mechanically, if larger than a backlash value, i do not see how the problem could be inside the gearbox unless some teeth are practically missing or there's a similarly large failure. The coupling of the encoder to the backshaft is a possibility. Losing transitions electrically is certainly possible, especially if it happens in conjunction with collisions (including crossing defenses quickly) or another motor/actuator being operated.

Just for completeness, is the sensor connected to a pair of DIO ports on the RIO, or going to an SRX or Jaguar's encoder inputs? Especially if it's not coming from the DIO, are you sure you're using a 5V supply?

[cantdecide]

Originally Posted by c0d3rman

As it seems you've replaced a lot of your hardware already, have you considered it may be code?

I have considered that, but I have code backups from when it didn't happen, and the problem happens even with old code.

Originally Posted by GeeTwo

How much do you lose the angle? Is it small enough just to be backlash, or is this really a significant amount?

Under what conditions does this happen/not happen? E.g. only when being backdriven, only in reverse, only when the last joystick command was x. Any patterns as to when it does/does not happen can help point to a cause.

Mechanically, if larger than a backlash value, i do not see how the problem could be inside the gearbox unless some teeth are practically missing or there's a similarly large failure. The coupling of the encoder to the backshaft is a possibility. Losing transitions electrically is certainly possible, especially if it happens in conjunction with collisions (including crossing defenses quickly) or another motor/actuator being operated.

Just for completeness, is the sensor connected to a pair of DIO ports on the RIO, or going to an SRX or Jaguar's encoder inputs? Especially if it's not coming from the DIO, are you sure you're using a 5V supply?

We usually lose a significant amount, in the 90-100 degrees range, and that's enough to completely render our shooter useless. It also tends to hit a few things on its way up, sometimes damaging parts.

The conditions happen to be random, but it's mostly immediately after the robot is enabled or while the robot is sitting still. I can't remember an instance where it "jumped" while the robot was in motion.

The outputs are connected to DIO ports, and I've tried switching between different ports. We use the 6V(?) supply from the DIO ports. Might that be a problem?

[Ether]

Originally Posted by cantdecide

We're using the PG71 motor from Andymark which has an hall-effect encoder

What part number motor are you referring to?

What's the part number of the encoder?

sometimes, despite the shaft moving, we won't get any signals for a few seconds.

How do you know you're not getting a signal from the encoder? Is that a direct¹ observation, or a conclusion based on indirect² evidence?


¹ e.g. measuring the encoder signal with an oscilloscope
² e.g. the arm went crazy, so it must mean the encoder isn't providing a signal.

[cantdecide]

Originally Posted by Ether

What part number motor are you referring to?

What's the part number of the encoder?



How do you know you're not getting a signal from the encoder? Is that a direct¹ observation, or a conclusion based on indirect² evidence?


¹ e.g. measuring the encoder signal with an oscilloscope
² e.g. the arm went crazy, so it must mean the encoder isn't providing a signal.

The part number is am-2816a.

The code prints encoder values to SmartDashboard, and during the periods where the arm goes crazy, Rate goes down to 0 and Distance stays the same for a few seconds. So I guess you could say ~indirect.

[Ether]

What programming language are you using? To rule out a coding problem, try loading and running a standalone example program.

[snekiam]

We are having a similar problem with position control with the same encoder on our gatherer. Sometimes it works fine, and goes to the setpoint perfectly both physically and digitally. But seemingly randomly, the setpoint is correct digitally, but the gatherer is in the completely wrong position physically, making it seem like the arm is moving without updating encoder values. The encoders are plugged directly into the DIO ports on the roborio. We have also tried swapping cables, encoders, and motors. It seems to make no difference.

[Alan Anderson]

Grasping at straws...

It's a Hall Effect sensor, right? Perhaps there's magnetic interference. Might you have a high-current conductor running too close, or the side of a really powerful motor jammed up against it?

Do you have anything in the program that resets the encoder value? Maybe it's being told to do it at an inappropriate time.

[snekiam]

It came for us mounted to our http://www.andymark.com/Gearmotor-p/am-2971.htmmotor

[cantdecide]

Originally Posted by Ether

What programming language are you using? To rule out a coding problem, try loading and running a standalone example program.

I'll try to check tomorrow.

Originally Posted by Alan Anderson

Grasping at straws...

It's a Hall Effect sensor, right? Perhaps there's magnetic interference. Might you have a high-current conductor running too close, or the side of a really powerful motor jammed up against it?

Do you have anything in the program that resets the encoder value? Maybe it's being told to do it at an inappropriate time.

The closest motor to it, obviously other than the gearmotor itself, is our drive motors, and it seems to happen even while we're not driving. In fact, it can happen without any of the other motors moving. However, the PID loop does often drive the gearmotor at ~20-30% to keep the arm in place. Maybe that creates some interference?
There is a command to reset the encoder(which I added because of this problem), but the actual accumulated value doesn't go to zero when the problem happens. It just stops accumulating(and the encoder rate goes down to 0) for a period of time.

[ahartnet]

We had an encoder problem where we weren't putting pull up resistors - but that doesn't seem to be needed by this encoder. I've also seen where there's a bad solder joint or a bad crimp that could cause similar problems. Buying a motor that already has the encoder installed and premade cables would seemingly eliminate those problems.

So like others in this thread - it seems to me that the code might be getting hung up. I think in Labview it's probably easier to accidentally do that than in some other languages. Are you able to command other things during this time?

In particular the teleop function in labview (I think, my memory is fuzzy) must complete within a certain amount of time and it could be relatively easy to accidentally take more time than you're allowed (especially if you're doing vision). When you put old code back in - was it all the old code? Or just the old code for controlling your arm.

I'd second Ether's recommendation of a standalone program that does nothing except reading the encoder and move the arm. My suspicion would be that you have something that is holding your processors attention longer than it should.

[cantdecide]

Originally Posted by ahartnet

We had an encoder problem where we weren't putting pull up resistors - but that doesn't seem to be needed by this encoder. I've also seen where there's a bad solder joint or a bad crimp that could cause similar problems. Buying a motor that already has the encoder installed and premade cables would seemingly eliminate those problems.

So like others in this thread - it seems to me that the code might be getting hung up. I think in Labview it's probably easier to accidentally do that than in some other languages. Are you able to command other things during this time?

In particular the teleop function in labview (I think, my memory is fuzzy) must complete within a certain amount of time and it could be relatively easy to accidentally take more time than you're allowed (especially if you're doing vision). When you put old code back in - was it all the old code? Or just the old code for controlling your arm.

I'd second Ether's recommendation of a standalone program that does nothing except reading the encoder and move the arm. My suspicion would be that you have something that is holding your processors attention longer than it should.

We're using C++, and the odd thing is, all of the other values(that are set in the same loop as the encoder function) in SmartDashboard are updating while the encoder stalls, so it's probably not software hanging. We also do vision on a co-processor.

Also, when I said "old code", I meant "old complete code that worked". I unfortunately don't have the option of testing an arm at this moment since our robot is bagged, but I'll try to test a standalone encoder + motor assembly's stability tomorrow.

[Ether]

Originally Posted by cantdecide

We're using C++, and the odd thing is, all of the other values(that are set in the same loop as the encoder function) in SmartDashboard are updating while the encoder stalls, so it's probably not software hanging.

But it could be some other software problem, other than "hanging".

Also, when I said "old code", I meant "old complete code that worked".

The old code worked with an old hardware configuration. That could have been serendipity. It could still be a software problem.

[snekiam]

Ours never seemed to work completely, but with a seemingly random error it is hard to tell. Weirdly we are also using C++, adding to the idea that software may be to blame here.