How to make a connection between ROS PC and a custom robot controller（TMS320C6748）?

[shyr...@gmail.com]

Hi. I am a beginner in ROS /ROS-I. Now my lab want to develop a new control system using ROS-I. The hardware has completed and what I need to do is building the software part.I have read the tutorial of ROS-I and most of the wiki introduction of ROS-I and have a general understand. When I decided to start the work I still have many confusion and need some help and support. Here are my questions.I will be appreciate if anyone can give me some suggestion. To build the whole control system the first part I need to do is build the connection between ROS PC and the Robot Controller.  the Robot Controller we used is developed from a DSP (TMS320C6748)made by TI,which support C/C++.Now I have some questions .

1.I learned that interface layer which actually is a client.but I don't know how the client combine itself with simple message or use simple message?

2.Simple_message defines a simple messaging connection and protocol for communicating with an industrial robot controller.is there any node in simple message?I didn't found it. 

3.I want to build the TCP connection via Ethernet . And I learned that I should build a server on the robot controller.Is there any example about the server?

4. When data send to the robot controller by using simple message, how is the data decoded on the  robot controller? In the description of simple_message package, The typed message base class provides methods for creating topic, reply, and request messages. If used in both the client and server, the developer need not understand the structure of the data payload. I guess that I should put the simple message on the robot controller,right?But how to use it?

5.In the industrial_robot_client, there are two different way to send data,JointTrajectoryDownloader and JointTrajectoryStreamer. From their description I think the downloader one will be a good choice because it download all the point information to robot controller at once ,however steamer need many times.But there is no example how to use this method. If I use steamer , I want to send the point position at least 125HZ. How can I do this successfully?6. I'm a beginner,so I don't know How to start the project.Should I understand the whole code in industrial_core?Or just know how to use it?

I still have many questions about this project,so it is extremely hard for me to complete the project.  I asked some questioin on answers,ros.org,and there is somebody told me I should send a message here. I will be appreciate if someone can give me some suggestions.Thanks!  

[G.A. vd. Hoorn - 3ME]

On 14-8-2017 19:06, shant...@sjtu.edu.cn wrote:
> Hi. I am a beginner in ROS /ROS-I. Now my lab want to develop a new control system using ROS-I. The hardware has completed and what I need to do is building the software part.I have read the tutorial of ROS-I and most of the wiki introduction of ROS-I and have a general understand. When I decided to start the work I still have many confusion and need some help and support. Here are my questions.I will be appreciate if anyone can give me some suggestion. To build the whole control system the first part I need to do is build the connection between ROS PC and the Robot Controller. the Robot Controller we used is developed from a DSP (TMS320C6748)made by TI,which support C/C++.Now I have some questions .
>
> 1.I learned that interface layer which actually is a client.but I don't know how the client combine itself with simple message or use simple message?

simple_message defines the message structures and serialisation library.

industrial_robot_client is the package that implements the clients that
make use of simple_message.

> 2.Simple_message defines a simple messaging connection and protocol for communicating with an industrial robot controller.is there any node in simple message?I didn't found it.

No, because it only provides the messaging infrastructure, which could
be used without ROS.

industrial_robot_client make use of this infrastructure.

> 3.I want to build the TCP connection via Ethernet . And I learned that I should build a server on the robot controller.Is there any example about the server?
>
> 4. When data send to the robot controller by using simple message, how is the data decoded on the robot controller? In the description of simple_message package, The typed message base class provides methods for creating topic, reply, and request messages. If used in both the client and server, the developer need not understand the structure of the data payload. I guess that I should put the simple message on the robot controller,right?But how to use it?

Most server implementations are done in the controller's / mfg's native
language, not a general purpose programming language.

One of the few open-source server implementations in C is the one in
MotoROS [1].

There will be parts that are tied to the underlying vxworks / motoplus
rtl, but the design document [2] should make the important parts clear
and answer most of your questions.


> 5.In the industrial_robot_client, there are two different way to send data,JointTrajectoryDownloader <http://ros.org/doc/groovy/api/industrial_robot_client/html/classindustrial__robot__client_1_1joint__trajectory__downloader_1_1JointTrajectoryDownloader.html> and JointTrajectoryStreamer <http://ros.org/doc/groovy/api/industrial_robot_client/html/classindustrial__robot__client_1_1joint__trajectory__streamer_1_1JointTrajectoryStreamer.html>. From their description I think the downloader one will be a good choice because it download all the point information to robot controller at once ,however steamer need many times.But there is no example how to use this method. If I use steamer , I want to send the point position at least 125HZ. How can I do this successfully?6. I'm a beginner,so I don't know How to start the project.Should I understand the whole code in industrial_core?Or just know how to use it?

downloading implies that trajectories are bounded in size, and is
typically not well suited for on-line / closed-loop control, as
executing typically only starts after the complete trajectory has been
received.

streaming supports unbounded trajectories, and is more on-line. The
MotoROS server implementation I linked above supports the streaming
approach, but the client side (ROS) implements more of a hybrid in that
only complete JointTrajectory messages can be streamed. See [3] for a PR
that adds streaming on the ROS side.

Note that in order to limit impact of network hickups most streaming
drivers include a small point buffer at the server side.


---


Using simple_message is really only needed if your controller doesn't
support anything else. If your platform supports regular C, you might
want to look at other options - perhaps even some of the embedded
variants of ROS2 [4, 5] - which would make your controller a first-class
citizen of a ROS node graph and remove the need to use the intermediary
layer that simple_message provides.


Gijs

PS: as an additional source of information on simple message, you might
want to take a look at [6], which is a wip document describing the protocol.


[1]
https://github.com/ros-industrial/motoman/tree/kinetic-devel/motoman_driver/MotoPlus
[2]
http://wiki.ros.org/motoman_driver?action=AttachFile&do=view&target=MotoRos_EDS.pdf
[3] https://github.com/ros-industrial/motoman/pull/88
[4] https://github.com/ros2/ros2/wiki
[5] https://discourse.ros.org/t/ros2-on-microcontrollers-with-riot/1293
[6]
https://github.com/gavanderhoorn/rep-ros-i/blob/retrospective_simple_msg/rep-ixxxx.rst

[G.A. vd. Hoorn - 3ME]

On 15-8-2017 10:41, G.A. vd. Hoorn - 3ME wrote:
[..]

> streaming supports unbounded trajectories, and is more on-line. The
> MotoROS server implementation I linked above supports the streaming
> approach, but the client side (ROS) implements more of a hybrid in that
> only complete JointTrajectory messages can be streamed. See [3] for a PR
> that adds streaming on the ROS side.

[..]

just remembered that there is also the fs100_motoman [7] package that
uses the same MotoROS driver, but targets real-time streaming instead of
traj based streaming.

I haven't used it myself, so I don't know how compatible it still is
with the latest versions of MotoROS, but it could be a source of
information.


Gijs

> [1] https://github.com/ros-industrial/motoman/tree/kinetic-devel/motoman_driver/MotoPlus
> [2] http://wiki.ros.org/motoman_driver?action=AttachFile&do=view&target=MotoRos_EDS.pdf
> [3] https://github.com/ros-industrial/motoman/pull/88
> [4] https://github.com/ros2/ros2/wiki
> [5] https://discourse.ros.org/t/ros2-on-microcontrollers-with-riot/1293
> [6] https://github.com/gavanderhoorn/rep-ros-i/blob/retrospective_simple_msg/rep-ixxxx.rst

[7] http://wiki.ros.org/fs100_motoman

[Tengfei Shan]

>Most server implementations are done in the controller's / mfg's native
language, not a general purpose programming language.

One of the few open-source server implementations in C is the one in
MotoROS [1].

There will be parts that are tied to the underlying vxworks / motoplus
rtl, but the design document [2] should make the important parts clear
and answer most of your questions.

Thanks for your reply!My robot controller does not have its native language and what it supports is general C/C++. I am sorry I don't uderstand the differences between the implementations used by controller's native language and general language like C/C++.Could you please tell me something about that? Is there any trouble when the server implemented by general language?

Few open-source server implementation means I should transplant the code into my controller.Can I understand like this? Because I haven't use Moto's robot,so I don't know whether my robot controller support the MotoROS,or vxworks/motoPlus rtl you mentoined. 

>downloading implies that trajectories are bounded in size, and is
typically not well suited for on-line / closed-loop control, as
executing typically only starts after the complete trajectory has been
received.

streaming supports unbounded trajectories, and is more on-line. The
MotoROS server implementation I linked above supports the streaming
approach, but the client side (ROS) implements more of a hybrid in that
only complete JointTrajectory messages can be streamed. See [3] for a PR
that adds streaming on the ROS side.

Note that in order to limit impact of network hickups most streaming
drivers include a small point buffer at the server side.

Compared with downloader,streaming is a better methods.Right?But I still do not know How to ensure the frequency of sending data(at least 125Hz.I haven't read the documents you give me.Is there anything mentioned this problem?) 

Using simple_message is really only needed if your controller doesn't
support anything else. If your platform supports regular C, you might
want to look at other options - perhaps even some of the embedded
variants of ROS2 [4, 5] - which would make your controller a first-class
citizen of a ROS node graph and remove the need to use the intermediary
layer that simple_message provides.

Does the simple message should be used both on industrial_client run on PC and  server run on robot controller if I want to use simple message? My platform supports regular C , so besides the variants of ROS2,is there anyother option? because i‘m a fresher in ROS,so I want to choice a relatively simple method. 

I am looking forward to your reply!Thanks

Tengfei 

[Tengfei Shan]

>Most server implementations are done in the controller's / mfg's native
language, not a general purpose programming language.

>One of the few open-source server implementations in C is the one in
MotoROS [1].

>There will be parts that are tied to the underlying vxworks / motoplus
rtl, but the design document [2] should make the important parts clear
and answer most of your questions.

 I realized that vxworks works on ARM while my controller is DSP so the structure is quite different.Maybe the server source cannot apply successfully on the DSP. So does the document[2]stil work for my server designing?

[G.A. vd. Hoorn - 3ME]

On 16-8-2017 4:38, Tengfei Shan wrote:
>> Most server implementations are done in the controller's / mfg's native
>> language, not a general purpose programming language.
>>
>> One of the few open-source server implementations in C is the one in
>> MotoROS [1].
>>
>> There will be parts that are tied to the underlying vxworks / motoplus
>> rtl, but the design document [2] should make the important parts clear
>> and answer most of your questions.
>
> Thanks for your reply!My robot controller does not have its native language
> and what it supports is general C/C++. I am sorry I don't uderstand the
> differences between the implementations used by controller's native
> language and general language like C/C++.Could you please tell me something
> about that? Is there any trouble when the server implemented by general
> language?

Take a look at languages like INFORM (Motoman), Karel (Fanuc), Val3
(Staubli) and KRL (KUKA).

You'll find that they come nowhere close to what a generic programming
language such as C can do.

And often the runtimes of those languages are limited in the kind of
support they have for network communication, so very elaborate protocols
will be hard(er) to implement than in regular C.

> Few open-source server implementation means I should transplant the code
> into my controller.Can I understand like this? Because I haven't use Moto's
> robot,so I don't know whether my robot controller support the MotoROS,or
> vxworks/motoPlus rtl you mentoined.

re: transplant: no, that is not what I meant.

I only mentioned the MotoROS code because it is one of the few
open-source examples of a ROS-Industrial / simple_message compatible
server implementation that is written in C.

So you could perhaps use it for inspiration and see how you could
approach things.

You asked about how to implement a server in C: the MotoROS code is a
server in C.

And your controller doesn't have to support MotoROS or MotoPlus
directly. The code is essentially ANSI C, so apart from some specifics
that interface with the Motoman motion controller, things like socket
and queue management, message (de)serialisation and interpolation should
be generic enough.

>> downloading implies that trajectories are bounded in size, and is
>> typically not well suited for on-line / closed-loop control, as
>> executing typically only starts after the complete trajectory has been
>> received.
>>
>> streaming supports unbounded trajectories, and is more on-line. The
>> MotoROS server implementation I linked above supports the streaming
>> approach, but the client side (ROS) implements more of a hybrid in that
>> only complete JointTrajectory messages can be streamed. See [3] for a PR
>> that adds streaming on the ROS side.
>>
>> Note that in order to limit impact of network hickups most streaming
>> drivers include a small point buffer at the server side.
>>
> Compared with downloader,streaming is a better methods.Right?But I still do
> not know How to ensure the frequency of sending data(at least 125Hz.I
> haven't read the documents you give me.Is there anything mentioned this
> problem?)

Reading those documents would help, but "ensuring the frequency of
sending data" is slightly orthogonal to implementing the server.

You'll somehow need to implement your client such that it can sustain
that rate.

As you noted in your ROS Answers question about this, the current
clients do not support pure streaming, only trajectory based streaming.
So the generic clients provided by industrial_robot_client will not be
directly usable in your case, if you decide to go with pure streaming.

>> Using simple_message is really only needed if your controller doesn't
>> support anything else. If your platform supports regular C, you might
>> want to look at other options - perhaps even some of the embedded
>> variants of ROS2 [4, 5] - which would make your controller a first-class
>> citizen of a ROS node graph and remove the need to use the intermediary
>> layer that simple_message provides.
>>
> Does the simple message should be used both on industrial_client run on PC
> and server run on robot controller if I want to use simple message? My
> platform supports regular C , so besides the variants of ROS2,is there
> anyother option? because i‘m a fresher in ROS,so I want to choice a
> relatively simple method.

No, you don't have to use the /library/ simple_message per se. You could
write all the (de)serialisation code yourself - as was done in MotoROS.
You could also reuse simple_message on your server, but keep out the ROS
parts.

simple_message is C++ though, so you'll have to make sure your
controller supports that.


Gijs

[G.A. vd. Hoorn - 3ME]

Don't bother with vxworks, it's not a factor here.

As I wrote in my earlier reply: you could use the MotoROS code to learn
from, not necessarily directly port to your system.

The design document can help you understand how it is structured,
nothing more.


Gijs

[Tengfei Shan]

As you noted in your ROS Answers question about this, the current
clients do not support pure streaming, only trajectory based streaming.
So the generic clients provided by industrial_robot_client will not be
directly usable in your case, if you decide to go with pure streaming.

Thanks for your explanations!Maybe I should spend several days understanding these key points.But I still don't understand the differences between pure streaming and trajectory based streaming.If I use the pure streaming what are the advantages compared with trajectory based streaming?Could you please give some explanations?Thanks!

Tengfei  

[G.A. vd. Hoorn - 3ME]

trajectory based streaming assumes 0 velocity and acceleration as
starting and ending conditions. The action interface only accepts
complete trajectories. The generic clients do not support trajectory
replacement or blending, so only complete trajectories can be executed.

Pure streaming would mean that single trajectory points are accepted by
the ROS nodes and immediately forwarded to the server which should try
to execute them with as little delay as possible.

As I wrote in my earlier reply, this is not supported currently by the
generic clients. See also [1].


Gijs

[1] https://github.com/ros-industrial/industrial_core/issues/139

[Tengfei Shan]

Thanks for your reply!Thank you!

[Tengfei Shan]

streaming supports unbounded trajectories, and is more on-line. The
MotoROS server implementation I linked above supports the streaming
approach, but the client side (ROS) implements more of a hybrid in that
only complete JointTrajectory messages can be streamed. See [3] for a PR
that adds streaming on the ROS side.

Sorry to bother you.But I confused that   but the client side (ROS) implements more of a hybrid in that only complete JointTrajectory messages can be streamed.  A hybrid means that different messages send to controller using the manager and handlers? What is more, I don't understand that why only complete JointTrajectory messages can be streamed and the relation between complete trajectory and implementation of a hybrid?

[Tengfei Shan]

在 2017年8月17日星期四 UTC+8上午2:16:52，gavanderhoorn写道：

I have read the issue you linked and read the description of 

• industrial_robot_client
• generic_implementation

 again.I noticed that the trajectory based streaming is equal to Downloader.Here is the introduction :The streaming interface sends trajectory commands to the robot on-the-fly. At the ROS level this is functionally equivalent to the download interface, some robot require points be streamed at the driver level:.  So the trajectory based streaming should send all points data of the trajectory to the controller,then the robot can move,right? from this point of view ,there is no difference  between trajectory based streaming provided by industrial_client and the downloader. Both of them should send the complete trajectory data before the robot start motion.Can I understand like this?

[G.A. vd. Hoorn - 3ME]

On 17-8-2017 13:50, Tengfei Shan wrote:
> 在 2017年8月17日星期四 UTC+8上午2:16:52，gavanderhoorn写道：
>> On 16-8-2017 18:08, Tengfei Shan wrote:
>>>> As you noted in your ROS Answers question about this, the current
>>>> clients do not support pure streaming, only trajectory based streaming.
>>>> So the generic clients provided by industrial_robot_client will not be
>>>> directly usable in your case, if you decide to go with pure streaming.
>>>
>>> Thanks for your explanations!Maybe I should spend several days
>>> understanding these key points.But I still don't understand the differences
>>> between pure streaming and trajectory based streaming.If I use the pure
>>> streaming what are the advantages compared with trajectory based
>>> streaming?Could you please give some explanations?Thanks!
>>
>> trajectory based streaming assumes 0 velocity and acceleration as
>> starting and ending conditions. The action interface only accepts
>> complete trajectories. The generic clients do not support trajectory
>> replacement or blending, so only complete trajectories can be executed.
>>
>> Pure streaming would mean that single trajectory points are accepted by
>> the ROS nodes and immediately forwarded to the server which should try
>> to execute them with as little delay as possible.
>>
>> As I wrote in my earlier reply, this is not supported currently by the
>> generic clients. See also [1].
>>
>>
>> Gijs
>>
>> [1] https://github.com/ros-industrial/industrial_core/issues/139
>>
>
> I have read the issue you linked and read the description of

> - industrial_robot_client
> - generic_implementation
> <http://wiki.ros.org/industrial_robot_client/generic_implementation>again.I

> noticed that the trajectory based streaming is equal to Downloader.Here is

> the introduction :The streaming* interface sends trajectory commands to the

> robot on-the-fly. At the ROS level this is functionally equivalent to the
> download interface, some robot require points be streamed at the driver

> level:. *So the trajectory based streaming should send all points data of

> the trajectory to the controller,then the robot can move,right? from this
> point of view ,there is no difference between trajectory based streaming
> provided by industrial_client and the downloader. Both of them should send
> the complete trajectory data before the robot start motion.Can I understand
> like this?

No, that is not correct.

The main difference between downloading and streaming is on the server side:

- with streaming the server may start executing the motion as soon as
it has the first traj pt.

- with downloading the complete trajectory must first be transmitted
by the client, and only /then/ will the server start executing the motion.


Downloading is typically only used by controllers that only support
'motion jobs' (ie: execute entire trajectories with a single command)
that cannot be appended to.

Streaming - ie: piecewise execution - is preferred /unless/ it has a
dramatic adverse effect on motion performance.


Gijs

[Tengfei Shan]

Thanks.So the difference between Downloading and streaming is on the server side. The difference between trrajectory based streaming  and pure streaming is on the client side:

trajectories must be completed before the trajectories points sent to action interface.Once the trajectories points are sent to action interface,the trajectories can never be changed.Only after all the trajectory points are received by action interface,the points will stream to the server.This is trajectory based streaming.As for pure streaming,it is not necessary for trajectories to be complete.the client can send the single point om-the-fly to the action interface and the points are sent to server immediately.

On the server side, both trajectory based streaming and pure strreaming  start executing the motion as soon as it has the first traj pt. Is it right?