Controlling 5 DOF Dynamixel arm: YARP vs. ROS

[pauljurczak]

I will have a 5 or 6 DOF arm build with Dynamixel smart servos. I need to move the gripper along Cartesian trajectory, which I will calculate in my C++ application. I looked at ROS, but the learning curve is pretty steep and it looks like a major overkill for this use case. I know that YARP has a similar distributed system design foundations, but I'm not sure how it's learning curve compares to ROS.

Can my arm be controlled with YARP? Will it be a simpler solution than using ROS?

[pattacini]

Hi again @pauljurczak,

I don't know how steep you might find approaching YARP, and how it compares with ROS in this respect for a newcomer, but YARP allows you to deal with Jacobian math, trajectory control and hardware interface with increasing levels of complexity (yes, I've noticed your original post on SE 😏).

You could think of tackling your "big" problem step by step.
Here we go.

Inverse Kinematics & Trajectory Generation

To address IK problems, we have provided some time ago the iKin library, which is contained within the icub-main repository. iKin enables to solve inverse kinematics of serial link chains with revolute joints by resorting to Ipopt, a nonlinear optimizer that is capable of coping with nonlinear constraints fast (near real-time) and very effectively with respect to more classical methods (e.g. DLS). See this article for more details.

We have prepared some tutorials to illustrate how iKin works:

1. The first example (fwInvKinematics) is a self-contained snippet that basically does everything in one place: it instantiates a generic chain and asks for forward and inverse kinematics computations.
2. The second example (onlineSolver) implements a stand-alone module that exposes IK services through YARP ports, so that we can make it run wherever we want in the network.
3. Finally, the third example (genericChainController) accomplishes one further task: once the IK is solved, it also produces suitable joints trajectories to be sent to the motors in order to move the structure in a human-like fashion (i.e. quasi-straight movements of the end-effector with bell-shaped velocity profiles). We just generate joints reference but here we do not implement low-level control yet.

Hardware Interface & Trajectory Control

You could consider using YARP and iKin to solve inverse kinematics and generate joints references only and then relying on different tools to implement actual joints control, or you may want to employ YARP also for low-level control and hardware interface, which was actually one of the reason YARP was designed for.

I can point you at proper YARP documentation for developing device drivers for your specific equipment (look also at this tutorial). YARP foresees the possibility to proxy the device drivers over the network by means of the so-called wrappers, that are responsible for exchanging information (control commands and feedback readouts in this case) among modules running on the cluster. If you don't want this degree of sophistication, well, simply skip the wrapping stage.

According to our practice, the device drivers needs to implement some basic functionalities that are exposed via motor interfaces. For example, to get joints limits we have the IControlLimits interface; to get joints readouts we go with the IEncoders interface; whereas to control a motor in velocity mode we make use of the IVelocityControl interface. We have many more motor interfaces, but you need only a small subset to start with. I also imagine that, as first yet effective implementation of such drivers, we will have some PID controllers under the hood.

Cartesian Interface

If you will decide to implement YARP device drivers for your motors and expose them through a bunch of motor interfaces, then you will have - finally - the possibility to plug on top the Cartesian Interface that can be easily customized for your own robot. Interestingly, the tutorial does contain a device driver designed for a fake motor you could draw inspiration from.

I hope this gives you an helpful overview on a possible road map to yarpize your robot.

[pauljurczak]

Hi Ugo,

Thanks a lot for your detailed answer. I will certainly look at the references you provided. In the meantime, I have two related questions:

1. There is a DynamixelAX12FtdiDriver YARP class, which seems to be a hardware interface to Dynamixel AX-12 servos I'm planning to use. Can you verify that I can use it with YARP's Cartesian Interface, so I don't have to write a device driver?
2. Can my use case be solved with direct API function calls in a single process or does YARP require using distributed architecture even for simple scenarios?

[pattacini]

1. From inspecting the inheritance diagram it comes out that DynamicxelIAX12FtdiDriver does implement IEncoders, but neither IControlLimits nor IVelocityControl, even though it is quite an easy task to get them done. These interfaces compose the minimal set required to customize the Cartesian Interface. (Btw, I didn't know that the driver was already available, that's good).
2. The answer is YES. The server part of the Cartesian Interface gets opened by passing it on the list of drivers implementing the low-level control. These latter drivers can also be physical (i.e. the DynamicxelIAX12FtdiDriver above) and not necessarily wrappers, so all the services will be implemented as function calls with no network gateways. Further, the server can be used as API straightaway, hence there's no need to launch the client part of the Cartesian Interface.

[pauljurczak]

1. Are there any plans to add IControlLimits and IVelocityControl to DynamixelAX12FtdiDriver in the near future? It looks easy, but may be too much for the first day with YARP, e.g. yarp::dev::IControlLimits::setLimits description is pretty terse: are these speed limits, position limits, something else?
2. That's great. It may be the biggest complexity reduction compared with doing it in ROS.

[drdanz]

According to robotology/yarp#480, the dynamixelAX12Ftdi plugin was broken... I just fixed the issue, but I suppose nobody has been using it for quite a long time. @pauljurczak Please let us know if it still works, or if you find issues!

[drdanz]

By the way, this also means that in order to use it, you will have to build yarp from sources using the latest master.

[pauljurczak]

@drdanz Thanks, I will let you know, but first I must find the time to learn YARP and buy the servos. It may be a while.

[pattacini]

@pauljurczak
I don't think it's in our plan to extend that specific driver. I'm afraid it will be left to the will of eager contributors 😏

Of course, we are always available to help.
The IControlLimits is intended to specify joint position bounds.

[pattacini]

From copyright disclaimer it's likely that @jizecn is the author of the driver.
He might want to chime in.

[jizecn]

I have not been actively developing this work for quite a while.
If needed, I could spend some time to have a look later.

[pattacini]

Thanks @jizecn for your possible availability, that's very much appreciated.

For the meantime closing this issue.
Feel free to reopen it when necessary.