[dynamixel_workbench_controllers] Protocol 2.0 servos with Present Load Registers

[swiz23]

Hi,

I noticed at...

dynamixel-workbench/dynamixel_workbench_controllers/src/dynamixel_workbench_controllers.cpp

Line 483 in 455fb5a

else effort = dxl_wb_->convertValue2Current((int16_t)dynamixel_state_list_.dynamixel_state[id_cnt].present_current);

...that even if a Protocol 2.0 servo does not have a Present_Current register, but a Present_Load register, the line mentioned above still converts the raw load value to a current (by mutliplying by 2.69). I was just curious to know if this was done on purpose as opposed to just putting the raw load value directly into the joint states topic? Or does multiplying by 2.69 actually give a more accurate representation of what the current might be?

[ROBOTIS-Will]

Hi @swiz23,

You are right.
Some DYNAMIXELs that support Protocol 2.0, but only have Present Load instead of Present Current will return incorrect effort values as those DYNAMIXELs are not designed with Current Controller (XL430, MX-28 with 2.0 f/w).
These DYNAMIXEL should be using convertValue2Load(), but this issue may not be rectified as DYNAMIXEL Workbench will be replaced by DYNAMIXEL SDK.
In addition to the constant 2.69, some DYNAMIXELs like MX-64(2.0) and MX-106(2.0) use different conversion constant of 3.36.
Thank you.

[swiz23]

Wait...

I checked the convertValue2Load() function. That function is meant to convert raw register values that go from 0 - 2047 as explained here by the xl320 or a similar servo. The purpose is to map the values from -1022 to 1022. However, the xl430 servo doesn't need this function as its raw register value already is mapped from -1000 to +1000 (as shown here). So why should those dynamixels need to use the convertvalue2load function?

Also, what do you mean that the the dynamixel workbench will be replaced by the Dynamixel SDK? Are you saying that the dynamixel_workbench_toolbox api will no longer be maintained, and only the lower level dynamixel_sdk repo will be supported?

[ROBOTIS-Will]

@swiz23
Although XL430 or MX-28(2.0) use different range for the Present Load, the Present Load itself is representing the percentile range of load applied to the horn. Technically, the convertValue2Load should be revised in order to correctly represent XL430 and MX-28(2.0) Present Load, but this will not be revised.

DYNAMIXEL Workbench was initially designed to support DYNAMIXEL configuration under Linux environment, and some additional packages had been appended to support ROS.
However, the DYNAMIXEL Wizard 2.0 is now supporting Linux, and rather than maintaining the workbench, the SDK will be improved in order to support ROS environment.

[swiz23]

One of the really nice things about the dynamixel_workbench_toolbox package though (specifically the toolbox package as opposed to the dynamixel_workbench_controllers or dynamixel_workbench_operators packages) is that it abstracts away all register addresses, and provides a higher level api for developers to use. Will this package be ported over into the dynamixel_sdk? Or will it be totally redesigned? Or will it just not be included?

I've done a bunch of development on-top of the dynamixel_workbench_toolbox package (like 25 different types of robots I wrote software for use it), so I'm kind of freaking out now :/

Also, I thought that the Dynamixel Wizard 2.0 tool isn't something you can develop on - it's just a really good debugging and testing utility...

[ROBOTIS-Will]

@swiz23
Sorry, your reply has slipt through from my attention.
You're right. Wizard 2.0 is a GUI tool for easier configuration and simple testing, but never can replace workbench at the moment.
We're trying to expand the DYNAMIXEL SDK into various ROS packages, and planning to collaborate with other ROS users.
Abstracting the lower level code of SDK is one of key point and should be able to provide acceptable level of changes in migration from the workbench.