ReactorX arm intermittently stopping, jumping frantically.

[RobbGodshaw]

Hi All!

My robot is acting up and I am hoping someone can tell me why.

It is a Trossen ReactorX AX12A-based arm (https://www.trossenrobotics.com/p/phantomx-ax-12-reactor-robot-arm.aspx) with no serious modifications. It is running on the ArbotixM board.


Essentially, the robot is very intermittent in it's behavior.
I thought it might be the wires, a bad servo, a bad power supply, or a bad arbotix board.
I have systematically checked everything with unit-testing and swap-outs except the arbotix board, which may be the culprit.


I have made a 2 minute video showing the problem. Here is a link. It shows the issue very clearly. (https://www.youtube.com/watch?v=HfR8seLGj10)


The issue is that the arm often seems to lose contact with the board. Sometimes, if i force one of the axes manually, it will suddenly fix itself at a terrifying speed, swinging wildly to get to its target.


It doesn't seem to matter how I am controlling the robot, the problem is universal.
I have this unreliability problem no matter what system I run the arm from. Pypose, ReactorTest.ino (https://github.com/treeherder/arduino_sketches/blob/master/ArbotiX%20Sketches/Tests%20Sketches/ReactorTest/ReactorTest.ino)as well as BioloidController running sequences made with PyPose.

Best,

[jwatte]

Do you have a logic analyzer of some sort? (A Saleae Logic is the typical recommendation)
Or just a second Aruino that you can hook to the serial bus, only for receiving, to print out what it actually receives?
Looking at the packet flow when it's working normally, versus when it's "sagging," might tell you something.

Also, I wonder if any of the servos are indicating an error -- when they respond to status, are any of the status bits set?

Also, if there's a communication problem (potentially signal integrity?) then that would be visible on the logic analyzer (or oscilloscope, even.)

I would assume the reason it suddenly "snaps" back is that the driver/controller has advanced the time forward, so the intended pose is ahead in the motion; once the servos all get their new desired pose update, it's a desired pose "far ahead" of where they currently are, and thus they will "snap" to that new position. You can reduce the amount of snapping by configuring a maximum movement speed on the servos, or making your sketch always send a maximum movement speed.

Those are some things to try. I don't know how well-versed you are with the Dynamixel protocol on the bus itself, and what tools you have available to look at the communication flow, but that's what I would start looking at.

[KurtEck]

Note: there is another thread: http://forums.trossenrobotics.com/showthread.php?10547-Robot-suddenly-stops-starts-again-when-wiggled
About this issue as well.

[RobbGodshaw]

Thanks for the detailed reply, and sorry for my 7-month delay.
The problem seemed to have been a bad cable. I swapped out one cable at a time until it was reliable again.
Very strange and frustrating, but solved!

Also sorry for the double post.