AX-12 - Status polling and Overload Errors

[iandanforth]

I have two questions, for context I am using the Python dynamixel module and a usb2dynamixel for communication:

1. What is the most efficient way to continually get the status of each of my networked servos? (I read that there is a register for Status Return Level, that I'm not to clear on. It looks like there is a way to get the servos to respond with updated information each time I send a command)

2. How do the values of "current load" relate to the overload errors? The returned values of ~-512 on one of my servos don't get near any of the torque limits, and yet that servo will regularly return an overload error while trying to hold a certain position.

Thanks in advance!

Ian

[jwatte]

The status return level just lets you set whether a servo will acknowledge all commands (2), only read commands (1), or only the ping command (0).
To actually know what the values of the servo is, you have to send a read command to it. You should do this periodically. You can read more than one register in a single read command, so read groups of registers you care about that are close together, as one command.
If you have many servos, you'll likely not be able to read status out from all servos more than, say, 50 times a second.

I don't know how current load is calculated on the AX-12.

[iandanforth]

"read groups of registers you care about that are close together"

Interesting, any idea the order of magnitude timescale difference trying to read registers 0 and 1, vs 0 and 24 (for example)?

[tician]

The read command returns sequential registers (return X number of bytes starting at register Y) as specified on the Robotis AX-12 support page and manual. Reading two bytes starting at zero would take a lot less time than reading 24 bytes starting at zero. If you wanted only 0 and 24, two read commands for a single byte each would probably be faster.

The "present load" returned by the AX-12/18, MX-28, and RX-28 (maybe RX-64 as well) is simply the PWM value being used to drive the H-bridge. It has no relation to reality other than wishful thinking. If the servo has a PWM over some threshold for some period of time without sensing any movement, it throws an overload error. Keep it loaded without movement and the servo will poweroff to prevent damage. This works well for the AX-12 as we've never had a failure in a upwards of ~100 servos, but does not work so great in the MX-28 (can burn out the H-bridge in far less time than the overload timeout).

[iandanforth]

"If the servo has a PWM over some threshold for some period of time without sensing any movement, it throws an overload error."

Is that threshold configurable? The limits I know I can set don't seem to be related to when the error is thrown.

The manual says the error is triggered when "the current load cannot be controlled with the set maximum torque" which suggests to me that the compliance margin might be involved if it thinks it can't achieve the desired goal position with the supplied torque.

Ian

[tician]

The "max torque" setting controls the maximum PWM value it will use and when it will throw the overload error. I do not remember any AX-12 going into overload shutdown (cuts power to motor and flashes LED) if the threshold is below ~200, but I am not certain whether the overload shutdown limit is configurable or not. I did a wireless marionette project using two Gerwalk, both with and without force feedback in the low-torque master, but I cannot remember if the master changed its goal position when a joint was freely moving (low-torque mode that changed its goal position to match the human's influence on each joint) or if I just dropped the max torque/PWM register to a tiny value.

I'm pretty sure the line about "the current load cannot be controlled with the set maximum torque" is referring explicitly to the physical load currently being applied to the servo not being able to be positioned by the servo's motor using the currently set maximum PWM value. The compliance slope is the rate at which the servo will change its PWM value. The compliance margin is the range within the goal position where the motor will not attempt to change its position ('good enough'). The punch is the minimum PWM it will use in an attempt to not overshoot the goal position (sort of like a 'coast' mode) and is basically the PWM at which the motor will no longer provide meaningful torque (so don't even bother powering it).
Set slope too high and you will get oscillation. Set margin too small and you will get oscillation. Set punch too high and you will probably not reach your goal position and/or drastically overshoot.

[Xevel]

The read command returns sequential registers (return X number of bytes starting at register Y) as specified on the Robotis AX-12 support page and manual. Reading two bytes starting at zero would take a lot less time than reading 24 bytes starting at zero. If you wanted only 0 and 24, two read commands for a single byte each would probably be faster.

While this is true with a controller like with an arbotix or a CM-XXX, it is not so straightforward when communicating with the servos from a computer through a USB interface.
All USB interfaces will suffer from a latency that is quite important compared to the time it actually takes to send the READ command and get its answer on the Dynamixel bus.
At high baudrate, it might be faster to get 25 bytes than to make two READ commands.

The actual USB latency can depend on the computer, the OS, the serial lib used, and the interface chip and its driver.

If you want to go as fast as possible to read values from servos, there are a few possible improvements that can be done, here are the easiest and most rewarding ones:
- replace the USB2Dynamixel by my USB2AX (shameless plug). It has lower latency by design, and from a Python application it's nearly a drop-in replacement.

- with the USB2AX, use the SYNC_READ command. This command will make it possible to read from multiple servos with one USB transaction (instead of one per servo). The benefits are very important when reding from a lot of servos at a time.

With these two changes, you can expect to get nearly as fast as currently possible to read data from multiple servos on a PC. All your WRITE commands will benefit a little from it too.
(I knew I should have tackled this "low latency guide" earlier...)

[jwatte]

All USB interfaces will suffer from a latency that is quite important compared to the time it actually takes to send the READ command and get its answer on the Dynamixel bus.

This is only true if you're using a serial-based USB protocol. If you write a custom protocol on top of libusb, you can get very fast turn-around times, and you can pipeline commands.
SYNC_READ is a movement in that direction, but still suffers from some serial protocol problems (not being block oriented, and the Linux USB serial drivers are pretty bad)

[TXBDan]

So that AX12 can't tell you the torque that's its providing? I figured with the closed loop, it should know how much current its driving to maintain a position. That current is proportional to torque, no?

I was hoping to some day use that feature to determine if my foot has reached the ground or not yet instead of using a contact switch.

[tician]

It reports the PWM value used to drive the H-bridge controlling the motor. The PWM value is roughly proportional to the current through the motor, which is proportioal to the torque required to maintain a position under load. The load value is mostly wishful thinking, but it can be useful for detecting resistance to movement of the servo horn (if there is a large load on the horn, it will require a higher PWM value to reach/maintain the goal position). It just is not very accurate or able to be converted to any real world units. It usually works plenty well enough to act as a contact switch (I used it for 'force feedback' marionette system, but it was not very smooth partly because the 'load' value can fluctuate very rapidly).