Questions regarding the joint control rate

[ghost]

Hi All,
I know the Robot runs at 250 Hz. But I wonder how long is the duration of the motion if I just send one joint velocity command to the robot,? For example, If I want to let one joint rotate at 0.1rad/s and I just send one command, is the total angular rotation angle be 0.1*0.004? I know perhaps I can do the experiment. But I'm afraid I still need your suggestions. Thank you.

The rapid code we used is outlined in here we also set \PosCorrGain:=0 as suggested by here used the sample_code.zip provided by Jontje for the joint velocity control as in here.

We have robotware 6.08 and the most recent abb_libegm. Today is Sep.10 2019.

[jontje]

Hi @Thompson104,

By sending one command, do you mean sending just a single EGM message or continuously sending EGM messages with constant command values?

In the first case the robot will probably not start moving at all, in my short simulation tests it takes at least 4 EGM messages before the robot starts moving. But this was with default settings of the EGM communication channel and it will change if you for example use filtering of the EGM commands or not.

If you send enough EGM messages to make the robot start moving and then kill the external EGM communication server, then how much the joint will rotate depends on, again, the EGM settings. For example:

• The ramp in time you have specified (default 1 s), which make the initial motion smoother
• The max speed deviation allowed (default 1 deg/s), which affects the acceleration/deacceleration
• And most importantly, the timeout (default 1 s) specifying how much time is allowed without new EGM commands. When the timeout is exceeded then the robot stops.

If you continously send EGM messages with constant values, then the joint will continue to rotate until it gets too close to the joint limit which will then trigger a complete stop of the robot.

I hope this helps!

[ghost]

Hi Jontje:

Thank you for your detailed explanation. Sorry I could not explain my problem in a clear fashion.

What I meant to ask is how long the robot would execute one EGM message when the robot is moving. For example, when the robot is in motion, I want to rotate one joint at 0.1 rad/s. Since the EGM runs at 250 Hz, I assume when the robot is moving already, and then in the current time step it receives one and only one EGM message, is it going to execute that command for 1/250 = 0.004 s?

My second question, assume the the robot would execute one EGM message for 0.004 s. What if the robot receives another EGM message during this 0.004 s? Let's say the robot receives a new EGM message after T (T < 0.004) second. For example, T can be 0.00001 or 0.003 second. Would this command be stored in system buffer and to be executed later or just be discarded?

I think the "timeout (default 1s)" answers my third question. If my control calculation in each time step takes longer than 0.004 second, that means the robot would "timeout" after 0.004 s, the timeout command specifies how the robot would respond.

I would really appreciate your help on this topic. We are using the ABB robot for real-time control and this information is really important to us. I noticed the robot studio has approximately 1 ms or more delay for the EGM simulation under ROS environment (we just need to read the joint states and send joint velocity). The robot we have is ABB 4600 which is relative large and it is hard to tell how long the robot executes the motion.

[jontje]

No worries, communication is usually prone to errors regardless of the situation (both human and robot cases included).

Snippet from the manual:

Clarification attempt:

• The motion control box corresponds to an inner task, inside the robot controller, that is always executed at 250 Hz (as far as I know). It is for example the component that communicates with the actual drive system.
• The EGM box corresponds to another task executed inside the robot controller (when an EGM communication session is active). I usually call this the EGM client, because it sends out feedback messages that it expects command replies to. This task is executed at a rate depending on the current EGM settings. 250 Hz is the highest frequency, but it can be lower (but always a multiple of 4 ms due to the inner motion control task).
• The sensor box is outside the robot controller. For me then it is almost always a computer running a C++ program (e.g. using the abb_libegm library) and communicating with a robot or virtual controller via UDP channels. I usually call the program the EGM server because it processes the feedback messages from the EGM client, incorporate user inputs, and creates the command replies.

You should be able to find more details in RobotStudio --> File tab --> Help --> Controller Software (under the documentation section) --> Engineering tools --> Externally Guided Motion [689-1]. Or in the Application manual - Controller software IRC5.

Your questions:

What I meant to ask is how long the robot would execute one EGM message when the robot is moving. For example, when the robot is in motion, I want to rotate one joint at 0.1 rad/s. Since the EGM runs at 250 Hz, I assume when the robot is moving already, and then in the current time step it receives one and only one EGM message, is it going to execute that command for 1/250 = 0.004 s?

The inner motion control task will always execute the next message, from the EGM task's buffer, for 4 ms. E.g. if the EGM task is set to execute every 16 ms, then the motion task would follow the same command four times in a row. That is, according to the control loop description in the snippet above, where k is the same as the position correction gain in the EGM settings.

My second question, assume the the robot would execute one EGM message for 0.004 s. What if the robot receives another EGM message during this 0.004 s? Let's say the robot receives a new EGM message after T (T < 0.004) second. For example, T can be 0.00001 or 0.003 second. Would this command be stored in system buffer and to be executed later or just be discarded?

If I remember correctly, then the EGM UDP variant will only send out feedback and read received commands at the rate specified in the EGM settings. And since this rate isn’t allowed to be faster than the inner motion control task, then there should never be many messages in the EGM buffer. For the EGM IO-signal variant it might be different, but I have only used the UDP variant.

Anyway, the recommended way to use the EGM UDP variant is to make the sensor box only send a new command message after receiving a feedback message from the EGM client. This is to be in synch with the EGM task, and the abb_libegm implementation attempts to do just that by using asynchronous UDP sockets.

I think the "timeout (default 1s)" answers my third question. If my control calculation in each time step takes longer than 0.004 second, that means the robot would "timeout" after 0.004 s, the timeout command specifies how the robot would respond.

Yes, if you would set the EGM timeout setting to be 0.004 s then the robot would timeout and stop if it doesn’t receive a new command from you within that time.

I hope this helps and that it wasn't too unclear.

By the way, which class(es) are you using from the library? And, if you wouldn't mind, could you briefly describe the application? It is always interesting to know what the use cases are.

[gavanderhoorn]

I'm going to assume that @jontje answered the questions posted by @Thompson104 (with an extremely elaborate and informative answer, 👍 @jontje).

As such, I'm going to close this. That does not mean no further discussion can take place here. It just means there is nothing directly actionable here.