XM540-W270-R expected communication frequency

Technical Support
, , ,
1

Use the following template to help create your post:

  1. What model of servo are you using?
    XM-540-W270-R

  2. Describe your control environment. This includes the controller or interface, and any power source.
    Servos are controlled by Python script (using dynamixel_sdk library, Protocol 2.0) with GroupSyncWrite and GroupSyncRead classes. Python script runs on RPi 4 which is connected to the motors via U2D2 module. I have 15 motors on my robot (it’s a five-legged spider robot with 3 daisy chained motors on each leg). Motors are powered via 12V regulated power supply.

  3. Specify the operating mode for applicable models, and any firmware settings you are using.
    Operating mode is set on velocity control, baudrate is set on 2Mbaudps. Return delay time of all motors is set to 0.

  4. Include pictures if possible.
    /

  5. Include a full description of the issue.

Problem: Currently i am achieving very low control-loop frequency (about 20Hz). Control loop contains reading current positions of the motors (with GroupSyncRead), PD controller and at the end of the loop writing new values to the motors with GroupSyncWrite. Among these three steps of the control loop, reading and writing to the servos take from 0.03 to 0.05 seconds (between those two, reading (as expected) takes much more time than writing), so even 20Hz frequency is sometimes compromised. Is there any trick i am missing to achieve higher frequency? What should be the expected frequency with the given setup?
Also, frequency was pretty much the same when Python code was running on computer (and not on RPi), so i am guessing that this is not the problem.

1 Like
2

Well… DYNAMIXEL itself may not gurantee to low the internal frequency / period on user side.
The only trick that comes to my mind is to look at Fast Sync Read which would give you better performanace in reading the multiple data for differnt DYNAMIXELs.

See DYNAMIXEL Tips | Use Fast Sync and Fast Bulk Read Instruction for Speedy Communication - YouTube

@Gaiajoypop is one of the expert in this community, he could give you another insigh !

1 Like
3

Thanks for your answer. Will try the Fast Sync Read method.

4

Have you tried to reduce the USB Timer Latency from the default 16 ms to 1 ms? Also have you been using TxRx type of functions? If so you can try just Tx functions only to reduce the number of status packets going back to the RPi.

1 Like
5

Thank you all for your answers. All of them proved to be very useful. I solved the problem with using a Fast Sync Read from develop branch and also setting a USB Timer Latency to 1 ms. With all that, reading procedure now takes around 3ms, which is huge improvement.
Thanks again.

2 Likes