XM430-W250-T Overload Error

[swinterbotix]

Setup is done using an Ubuntu Linux laptop to a U2D2. The U2D2 controls 8 Dynamixel X-Series servo motors. Six of them are the XM-430-W350-T model while two of them are the XL430-W250-T model. The IDs range from 1 - 8 with all of them being controlled using Protocol 2.0 at 1 Mbps. All the motors are powered from a 12V/5A power supply.

The layout of the servos are as shown below.

The issue I am having is specifically with one of the elbow motors - ID : 4. For your reference, the register values for the 'elbow' motors are the default ones with the following adjustments. Also note that the operating mode for both of these servos are set to 'Velocity Control Mode'. Commands are sent to all the 'non-shadow' motors of the robotic arm via the Dynamixel Workbench 'syncWrite' function.

elbow: ID: 4 Baud_Rate: 3 Return_Delay_Time: 0 Drive_Mode: 1 Velocity_Limit: 131 Min_Position_Limit: 1002 Max_Position_Limit: 3446 Secondary_ID: 255

elbow_shadow: ID: 5 Baud_Rate: 3 Return_Delay_Time: 0 Drive_Mode: 0 Velocity_Limit: 131 Min_Position_Limit: 1002 Max_Position_Limit: 3446 Secondary_ID: 4

Essentially, the issue I am seeing is that the motor with ID : 4 tends to 'error out' with an Overloading Error about 6-8 minutes after the robot arm starts moving. The only payload that the elbow joint is seeing is just the rest of the arm - no additional payload was added. Additionally, it does not seem like the motor is being overloaded as the 'Present_Current' register is reporting a current around 75 - 100 mA before 'erroring out'. Furthermore, the 'Present_Temperature' register is reporting a temperature of just 32 degrees Celsius. Lastly, if the arm in NOT moving but just holding its position (with all the links after the elbow joint fully extended so that they are parallel to the ground), the motor with ID : 4 does not 'error out' at all (though the last part was tested when all the arm motors were in position control mode).

Any help with how to prevent the motor from overloading would be much appreciated!

[JaehyunShim]

@swinterbotix

Please check the current limit of the motor with ID 4. If the problem is not you set it to a wrong value, as the question is about Dynamixel rather than about Workbench, leave your question at the link.

Ryan

[swinterbotix]

@rjshim,

The current limit register is set to 1193 (a.k.a 3.2 Amps) so I don't think that's the issue. I went to the link, but did not see an option to post an issue. Just a search bar to search for questions. How should I go about asking my question at the link? Or, would it also be alright to ask this question in the DynamixeSDK repo?

[ROBOTIS-Will]

@swinterbotix Hi, this may have to do with the overload error algorithm. I'll request more information on this case and get back to you as soon as possible. Thank you!

[swinterbotix]

@ROBOTIS-Will,

Thanks! I appreciate it.

[ROBOTIS-Will]

@swinterbotix Hi, I've received response from corresponding department. When using a Velocity Control mode, the velocity value is also referring the magnetic encoder which is at the end of the output axle. Therefore, the response could be a bit slower than PWM control and may cause minor discrepancies in speed between two DYNAMIXEL when they are used in a single joint. When using multiple DYNAMIXELs in a single joint, it is recommended to use Position or PWM control method. Is there a specific reason of running the joint with Velocity Control mode?

[swinterbotix]

"Therefore, the response could be a bit slower than PWM control and may cause minor discrepancies in speed between two DYNAMIXEL when they are used in a single joint."

How does that end up leading to an overload error?

Regarding your second point, there are a few reasons why you'd want to use velocity control when working with a robotic arm.

1) The ROS package MoveIt generates trajectories with waypoints that contain both goal positions and velocities. In my experience, doing velocity control on a robot's joints tends to generate smoother movements. Position control tends to be very jerky when working with trajectories. True - you can play around with tuning the profile_velocity and profile_acceleration registers, but it's much easier to just skip that step and just work with Velocity control.

2) I've run into issues when doing Position control where a Dynamixel servo can't quite reach its goal position due to gravity. While it is possible to accommodate for this by bumping up the Position_P_Gain, Position_I_Gain, or Position_D_Gain values, that tends to make the joints in the robot arm move much quicker (which isn't always desirable) and has led to more Overload errors. To fix this, I found that keeping the firmware PID gains at their defaults, and just implementing my own velocity-based-position-feedback-controller in software has been able to compensate for gravity errors pretty well.

3) There is a whole branch of robotic manipulation called inverse-velocity-kinematics where one is able to set the desired Twist for an end-effector and be able to figure out what velocities all the joints in an arm need to be commanded to achieve that Twist. That makes Velocity control an attractive feature for controlling the arm joints. See more in section 6.3 in http://hades.mech.northwestern.edu/images/7/7f/MR.pdf

[ROBOTIS-Will]

@swinterbotix Thank you very much for the thorough explanation.

How does that end up leading to an overload error?

Although the detailed algorithm that flags the overload error is not disclosed, I was briefly explained that when DYNAMIXEL cannot reach to a given position or velocity under the certain condition, it is likely to set the overload error flag in order to prevent hardware damage. In your application, ID 4 and 5 may have not been synchronized perfectly and causing one or both DYNAMIXEL trying to reach to a given velocity or even oscillating. It is because even though transmitting the exact same Velocity value for both DYNAMIXEL, their behavior may slightly be vary and this could cause discrepancies in the velocity.

[swinterbotix]

@ROBOTIS-Will,

That makes sense. I'll see if I can make Position Control work for me, and also see if realigning the dual-joint servos helps to reduce this error. However, if it would be possible to make the 'overload' algorithm more robust when doing velocity control, that would definitely be appreciated.

[ROBOTIS-Will]

@swinterbotix Sure, I'll share your feedback with DYNAMIXEL department engineers. Thank you very much!

[swinterbotix]

Thanks for your support!

[swinterbotix]

Hi again,

So I've been playing around with Position control due to the issue you mentioned about velocity control not working so well with dual joints, and I've run into a similar issue. If I set the Position_I_Gain register to 100 for the two servos in a dual joint (leaving the Position_P_Gain and Position_D_Gain values at their defaults) and then assign a goal position, one of the motors will end up going into an error state within 30 seconds. I believe this is due to the fact that no matter how well you align two servos in a dual joint, there will always be some discrepancy (maybe half a degree) in their Present_Position values. My guess is that this problem would be averted if you just command the slave servo with the same but inverted PWM value as the master servo. I noticed that this feature is available with some of your Dynamixels ('Dual Mode') but unfortunately, not with the ones I'm using (XM430-W350).

Besides for messing with the Homing Offsets on the slave servo in the dual joint so that its Present Position matches the master servo, do you have any other suggestions on how to fix this issue?

Best, Solomon

[ROBOTIS-Will]

@swinterbotix Increasing Position I gain will cause an overshoot and prolonged stabilization time so if possible, I'd recommend to use PD gain control when using dual joint. As you know, XM/XH540 series and MX-106 come with Dual Joint drive mode so that PWM signal can synchronize Master and Slave joints. Though it may not be a much difference, setting the secondary ID of slave joint identical to the master joint and simply send a command to master ID could reduce a very slight delay between two joints if you haven't been already using sync write or bulk write protocol.

Due to the characteristic of PID controller, it is difficult to make up a small difference as control gets weaker near the Goal Position. However, adjusting P gain(but increase overshoot) then adjust D gain(to decrease overshoot) is pretty effective in most cases with a single joint so this could also work with dual joint case.

Thank you.

[swinterbotix]

Hi Will,

Thanks for getting back to me! I've already been using SyncWrite with the slave servo's secondary ID set to the master servo. However, I have not tried PD control, so I'll give that a shot. By the way, what exactly is the difference between SyncWrite and BulkWrite? Is one better than the other?

[ROBOTIS-Will]

@swinterbotix Hi, SyncWrite allows to access the same control table address(or multiple control table addresses in sequential) of multiple DYNAMIXELs whereas BulkWrite allows to access multiple control table addresses(that are not sequential). For example in X series, you can use SyncWrite to write Profile Velocity and Goal Position(as their addresses are in sequential from 112-119) for multiple X series. If you want to write Goal Current(102-103) and Goal Position(116-119) at the same time for multiple DYNAMIXELs, you should use BulkWrite instead of SyncWrite. In performance wise, SyncWrite is faster as it uses less packet, and if you need to access multiple control table items at a time with accelerated speed, you can consider using Indirect Address and Indirect Data to sequentially align separated control table addresses.

[swinterbotix]

Thanks Will! That makes sense.

[ROBOTIS-Will]

I'll close this issue unless you have more topics to discuss. Please feel free to reopen this when needed. Thank you.

[swiz23]

Hi again,

Going back to the dual motor setup for a single joint (position control), if I set the slave servo's secondary ID to the master but operate the slave in PWM mode (while master is in position mode), won't this solve the issue? Now the slave will just command the PWM value found in the master's Goal PWM register, correct? So no matter if the slave servo is off by half a degree or 37 degrees, it should work just the same without the two servos 'fighting' each other!

FYI - I've stopped using my swinterbotix account and am now using my personal swiz23 account. I'm the same person tho 🙂.

EDIT:

Just tried this out, and it unfortunately does not work, though I'm not sure why...

[ROBOTIS-Will]

Hi @swiz23 Glad to see you back :) Are you still working with XM430-W350? First of all, setting DYNAMIXEL in PWM mode will disable the Profile Acceleration and Profile Velocity, but using maximum acceleration and velocity. Even if sending the exact Present PWM of the DYNAMIXEL in Position Control mode to the one in PWM mode won't work because the internal controller logic iterates much faster than you can get from reading DYNAMIXEL control table. It's like converting an analog signal to a digital signal which inevitably introduce some loss and this case, discrepancy in final position.

[swiz23]

Hi @ROBOTIS-Will,

Thanks! I'm the ROS engineer at Trossen Robotics currently, so I'm working with a whole bunch of your servos - the XM430s, XM540s, XL430s, 2XL430s, and some of the XCs.

I understand better now as to why this can't be done. I imagine though that if both servos were operating in PWM mode, then the slave servo would follow the PWM command of the master servo? Of course, you then loose the advantage of working with the Profile_Velocity and Profile_Acceleration registers...

[ROBOTIS-Will]

Oh, that's awesome. Are you using DYNAMIXEL SDK by any chance? Although DYNAMIXEL Workbench is widely used, I'd recommend to utilize DYNAMIXEL SDK. We're planning to create a ROS package that could replace the workbench which initially designed for managing DYNAMIXEL on linux environment.

Using PWM mode to sync mutliple DYNAMIXELs may not work because the PWM mode will blindly and directly supply a voltage to the core motor without using a controller. This may cause a slightly different behavior in the output shaft(horn) as there could be differences in core motor, friction of gear set, etc.

[swiz23]

I've done all my development on the dynamixel_workbench_toolbox ROS package. I like the fact that it abstracts away all the register information, provides higher level functions, and allows you to use any Dynamxiel servo without having to change your code.

I'd be curious to know how your new ROS package will be different and/or similar to the dynamixel_workbench_toolbox.

About the PWM thing... I'm assuming you would program your own PID controller or similar that would run on your computer, then command PWMs to the servos using the sync_write functionality. However, that does kind of defeat the purpose of using dynamixels, lol.

[ROBOTIS-Will]

I agree that wrapping the low level SDK code with bunch of predefined DYNAMIXEL information and don't have to worry about collecting product specific information is a beauty of workbench. When designing a ROS package, this should also be considered carefully so that developers don't have to waste their time to search for control table.

In some cases, we do create our own profile generator for humanoids / manipulator, but haven't heard about a custom PID controller yet. Sounds interesting but could be painful to me as I don't have much understanding about motors xD

[adkoessler]

I've been messing around with my Pincher PX-150 arm (with XL430s) and came across the same problem. On a position-servoed axis with two motors, setting a non-null value for the "Position I Gain" results in overload error within 40 seconds.

@swiz23, did you find a workaround in recent releases? I'm using the robot with a Rasp Pi 3, so the package may be outdated (link). I'd be eager to know if you still consider this a problem, as it's affecting the positioning precision of the robot.