I’m investigating the relationship between polling frequency and actual data update rates in Dynamixel servos and experiencing unexpected data repetition patterns.
SETUP:
Multiple Dynamixel XM430/XL430 series servos
USB/RS485 communication at 4Mbps baudrate, Protocol 2.0
DynamixelSDK version 3.8.2
C++ application using GroupBulkRead
OPTIMIZATIONS APPLIED:
USB Latency Timer: Reduced to 1ms (from default 16ms)
Return Delay Time: Set to 0 for all servos (via Dynamixel Wizard)
Using GroupBulkRead for efficient bulk operations
OBSERVED BEHAVIOR:
When polling servos at high frequencies (1000Hz):
Application successfully calls SDK at target frequency
SDK responds immediately to each call
However: Position/velocity/current values show repetition patterns
Pattern: Multiple identical consecutive values before seeing new data
ANALYSIS:
Despite communication optimizations, this suggests servo internal systems update at their own
fixed rate, and faster polling returns cached values from servo’s internal state.
QUESTIONS:
What are the documented internal update rates for Dynamixel servos (encoder sampling, current measurement, velocity calculation)?
Is data repetition at high polling frequencies expected behavior?
Are there servo parameters to configure internal update rates?
What are the recommended maximum polling frequencies for different servo models?
The current documentation doesn’t clearly specify internal servo control loop frequencies or the relationship between polling rate and data freshness. This information would help developers set appropriate polling frequencies and understand when data repetition is normal vs problematic.
I see. Even when I tried to read only three paramters ( Position, Velocity, and Current) for just one dynamixel, the minimum time interval I could read the paramters was close to 16 ms. Can you suggest some ways I can implement to get it close to 10ms?
You are on the right track with GroupBulk and GroupSynch commands. 3 parameters for every 16 ms is faster that I can usually get out of XL DXLs and controller such as CM-550 and OpenRB-150 which are limited to 1 Mbps. Your project seems to be I/O bound. So the next approach is to use parallel processes and multiple U2D2s along with dividing your robot into multiple independent DXL networks - if your robot can be controlled that way.
I won’t be able to use multiple U2D2s due to some restrictions.
Also, when I try to read around 6 parameters and try to take actions if there is any violation in any of the paramter, My system takes approximately 3-4 secs to complete that action (for example: turning off the torque, etc.) which is a lot of delay! Do you have any idea regarding this? Right now I have not even introduced ROS2 in between, I am directly communicating with dynamixels, even then I am getting such a large delay.
Any help would be appreciated!
Robotis firmware on their DXLs is proprietary so that is the extend of my knowledge about them.
Also usually, I only use Torque-ON/OFF only once at the beginning of my program to set some EEPROM parameters (which also take time to perform) - when the DXLs are not moving anyway. Consequently, these longer-timing processes did not affect my expected performances of my robot that much, and so far I did not need to manipulate TORQUE in later stages of my program.
I was just looking at the specs of OMY, and this latest arm from ROBOTIS manages 400 Hz (i.e. every 2.5 ms) control rate (out of an RPi5). So your needs of 1000 Hz control rate is a very high bar to reach!
Thank you very much for this!
Also, I found something interesting which does solve my problem to some extent. When I read 3 parameters from just a single dynamixel, I am able to read at a rate of 60 Hz. But, if I bulk read a greater number of dynamixels ( say, 2 or more), I am getting ‘true’ read rates ranging from 330 Hz - 500 Hz . It does seem counterintiutive, though I am reading and logging perfectly fine.
One more thing, the 400 Hz control rate for the ROBOTIS arm you mentioned, is for controlling the arm (as the name suggests). Whereas, my issue is around ‘reading’ the values which are not mentioned even for the arm. However, since they have a control rate of 400 Hz (which is a very good control rate in my opinion) I believe the read rate from the dyanmixels should be a lot greater.
