Encoders start counting automatically when powering the motor

I measured 3.30v on the teensy board,, but there is 4.41v on the brown cable, which goes to the motors, in the enclosure box. May it be cause this? Shouldn't it be also 3.30v ? 🤔

The second problem can be solved by check all the boxes to disable all the encoders on the config settings, after that the robot arm should move just find without throwing errors

@nhan-truong Like I said, there is no problem without encoders.

I changed and relace 3 ethernet cables and checked them with the resistance of the multimeter. This a continuity test. Result is OK: 0 resistance. But I am still getting "Collision or Motor Error" from J5 encoder.

Voltage on the left and center terminals of the distribution block was, which I measured, 4.44v. (Not 5V)

Voltage on the right and center terminals of the distribution block was 3.16v. (Not 3.30v)

I feeded those wires by an external adapter and made them became their voltage 5v and 3.30v and tested again. Encoder works fine after some moves, but then, I get Collision or Motor Error again. After that error, it works when I try to move same joint and the error message goes.

Still confused... 🤔

I'm also having problems with the encoders. Although I used an earthed screen for all the encoders the signals are very noisy (at similar voltage levels to the ones you have recorded) and joint 5 only has an output on one of the two encoder outputs from it. I took the encoder off and had continuity between both of the encoder outputs and the corresponding teensy pins. Maybe this is a faulty encoder? By disabling the encoders I don't get collision warnings. I don't know whether to pursue this issue or just live with encoders disabled. I'm not sure that the encoders provide much value?

Hello. I have exactly the same problem, and only with the encoders of J4, J5, and J6. All cables are shielded, and I have rewired everything three times to be sure, but the issue still persists. Has anyone found a solution?

@david-walter

I struggled with this issue for forever. The best advice I can give is to make sure that your cable shield is properly terminated and that your wires are as short as practical, a complete rats nest in the robot base will exacerbate the issue.

With all that said while I managed to make the issue less pronounced with these methods I never managed to make it fully go away.

I ended up going all in and designed some custom PCBs to utilize the differential output of the encoders. This works perfectly but it was a decent amount of extra work.

@oliver-johansson I thank you very much for the quick response to my post, but I believe the error lies elsewhere. Many people, I think, have built the AR4, but there is only this one entry on Google related directly to this issue. If I buy and install stepper motors with encoders, and 50% of these encoders do not work, I believe that someone capable of replicating the AR4 would also ask questions if these encoders do not work. Therefore, I assume it's a problem with fewer people. My wiring is well shielded, and I have done it three times, using cables of the shortest possible length, but that hasn't made any difference to the issue. I think I am overlooking something else.

@david-walter

If it's only an issue when the motors are enabled it's almost definitely related to either noise or a ground loop.

I had a look at the datasheet for the chip used in these encoders (MT6816) and they use push-pull outputs. They are however quite weak at only 2mA so with the fairly long wire runs in a noisy environment I could see them struggling to overpower noise, inductance, and capacitance.

Especially with the relatively sensitive inputs on the teensy.

Therefore one thing worth trying and even mentioned in the Teensy Encoder library is to add external pull-up resistors. If you have some resistors available I'd say it's definitely worth giving a try.

I'd try adding pull-up resistors for both of the J6 encoder pins (24 and 25 on the teensy) first as it should, in theory, be the noisiest. If possible start at something like 100K then 10K and finally 1K. Of course, if one of the higher resistance values solves the issue there's no sense in going lower as it would just stress the onboard voltage regulator unnecessarily. Just to be clear add these on the teensy side, not by the encoders on the robot.

Other than this I don't have many simple ideas left. A low pass filter with a capacitor might help but that starts becoming a lot of extra wiring if you don't want to spin up a custom board.

I'd of course be happy to send you the files for the differential driver boards I made if you ever feel like sending in the cavalry but they take a bit off setup too. (Not at all difficult mind you, just time consuming)

@oliver-johansson

hello sir can you give me a driver file to test? 🙂

my email address is igbtkj@gmail.com

I encountered the exact same with my J1 -> J3. Simply place a ceramic cap (4.7nF worked fine) across one encoder channels on each axis to ground. You essentially create a low pass filter to ground. The Encoder trace on the scope is a LOT cleaner and the encoder drift stopped. Not a single false pulse on the Encoder Test program. Ideally you would want to put a cap across each of the two channels but I didn't see the point since my problem was solved. I opened the encoder housing on J2 and there's heaps of space to solder a small capacitor in there, I might end up doing that to tidy up the controls.

As per @Ray Carberry 's suggestion, adding ceramic caps on all the encoder wires to ground solved the issue for me. I had 12x 0.1uF ceramic caps spare, and they worked well.

https://anninrobotics.com/wp-content/uploads/2025/08/3.avif

Small caps helped me as well!

Yes, happened to me as well. I've added caps (100nF) to all the encoders signals, it worked eventually. @chris annin I really think this should be part of the user manual, as I'm pretty sure it will happen to everyone..