Closed ddliu365 closed 4 years ago
@ddliu365
Hi, thank you for your inquiry.
If you are connecting multiple DYNAMIXEL in a single network, it is recommended to reduce the Return Delay Time to 0
so that each DYNAMIXEL can respond without delays.
Also, make sure that your USB serial port latency is set to 1
ms.
Thnx!
It works like a charm!
control loop time = 8ms
I tried several possible ways. When I found the communication time (retrieve data and send command position)is within 2ms after turning on debug mode in robotis controller
, I guess the problem is not caused by communication. I am wrong here.
Another question: what is the desired power source we should use to get the best performance of these 20 motors together? Indeed we concluded the reason of this jagged shape was caused by power supply(we only use 10A 12V power supply compared with maximum about 70A calculated based on simulated torque).
Lipo battery can get the best current discharge. However, it is restricted by our environment. Can we use a 100A 12V switching power source(AC to DC converter) to replace it?
Another question is the minimal control loop for the robot, I can achieve 3ms for the best case. If I reduce the control loop time, the similar case happened again. What is the best control loop time you can achieve? Is there other approach to reduce the control loop time?
The baud rate I am using is 4M Hz.
control loop time = 3ms:
control loop time = 2ms:
@ddliu365
Hi, glad to hear that reducing the latency worked out.
By simply adding up the maximum current based on the stall torque current, your application get about 80A with 12V. However, this is not a realistic calculation as we recommend to use DYNAMIXEL under 20% of the stall torque to ensure the best lifetime and performance. Although you may use high torque region for a short amount of time, it should not reach to the stall torque current. I believe 12V 100A SMPS would be good enough, but some SMPS may fail in providing enough current during a full load condition so please use qualified one to protect your system.
When designing high current required application with DYNAMIXEL MX-106, it is recommended to use a separate power line for each of them or at least a couple of them. For MX-64 and MX-28, I'd suggest using a separate power line for 1 or 2 MX-64 with a few MX-28 depending on the power use. In this way, you can prevent the brownout during full load condition. I normally suggest to take a conservative power supply measure because I do not have thorough understandings about customers' application.
Regarding the control frequency, the FTDI chipset in U2D2 inevitably introduces the 1ms delay so I'd say 1ms would be the maximum control frequency for a single DYNAMIXEL(this can be tested with DYNAMIXEL Wizard 2.0 graph optimization), but with 20 DYNAMIXEL, I think this could be difficult as there will be 20 more data to receive.
Please also note that increasing the Baudrate may affect to the communication distance as faster signal tend to easily affected by noises. For a humanoid application, I usually recommend 8ms control frequency(which is default of ROBOTIS-Framework) with 2~3Mbps baudrate. Thank you.
Thanks for your suggestions.
We implement the power supply based on your advice. However, we run out of power hub and wires right now, but we tried to do three separate power lines to power different parts of humanoid independently.
The results after and before are similar to each other for mx28, but it shows better tracking performance for MX 106 and MX64.
Hi,
I used robotis actuators to assemble a humanoid robot and connected them via one U2D2. All motors are running within a cycle of default 8ms. The actuators are using position control mode.
However, the motors cannot track predefined trajectory well.
I checked encoder information and compared it with predefined trajectory. The encoder information has a lot of jagged shape:
control loop time = 8ms
I also tested one motor under this framework and it worked well.
therefore, I think the problem is caused by communication issue and reading or writing speed is not high enough due to increase of motors.
I improved the baudrate from 1M to 4M, however, the jagged trajectory still exists.
the hardware is constructed by 4 x Mx28 + 6 x Mx64 + 10 x Mx106.
Except the tracking issue, there is no connection problem and the protocal is 2.0.
Can you give some advice to fix this issue under this framework?