Does ABB robot support to real time control ?

Paramin

I will work on IRB 140 in my thesis but I'm now have a little bit confuse that Does ABB robot support to real time control or not ?

Thank you in advance for anyone who gives me the useful information.

Paramin

Henrik Berlin

Hi Aramin,

I am not sure I understand your question correctly. However, the virtual robot controller used by RobotStudio supports 'virtual time' which means that RobotStudio can control the time. During a simulation RobotStudio feeds the controller with time that the controller consumes during execution. By this way, several controllers and any SmartComponents present in the simulation can be synchronized time wise. Just ensure that you have selected 'Time Slice Mode' in the RobotStudio Options. The other virtual time option 'Free Run' allows the robot controllers to control the execution speed themselves. In both cases, the simulated robot program execution times will match the true robot exeuction time within a few percentages.

It is recommended to use 'Time Slice mode' which will be the best option for most cases. Time Slice mode will also ensure correctly recorded Station Viewers and Simulation Recordings (.avi, wmv).

Henrik Berlin2012-02-23 12:46:19

Paramin

Thank you for your useful response.

I will work on an ABB IRB 140 robot for transfering an object to a human while force sensors and 3D cameras are going to be used. It needs to be a quick response to accomplish the task. Someone told me It can not possible to control ABB robots in real time because the ABB robots can not support for the real time control mode.

Could you make me clear about this issue.

Thank you in advance and looking forward to hear from you. 

Best regards,
Paramin

Henrik Berlin

There is a RobotWare option for Force Control that may be of interest to you. Moved to RobotWare forum.

j_proulx

The Safe interaction between the Human and robot manipulator is accomplished through our SafeMove product. Go to the ABB web site  http://www.abb.com/product/seitp327/ec6cfad87f69dd2dc12572d300775f5b.aspx?productLanguage=us&country=00

BR Jim Proulx

Paramin

Thank you.

leonardolt

Paramin, if it is a simple real time position control you need, you can do it "indirectly".
Let me explain: You can stabilish a communication wit the controller using RS232 or TCP/IP (I've never tried any CAN) and use this communication channel to update the position you want the robot to move to. I think the simplest way to do this is to put the folowing move instriction in a loop and update the offsets:
   Move(L or J) Offs( InitialPosition, dX, dY, dZ)
With this you can update the x, y and z positions whenever you send a new value to the robot controller. The bad thing if that you can not reorient the tool. To do so, you will need to send the robot the target quaternions value and update it before.

I'm sorry if I was not clear and also if I misunderstood your needs. Feel free to ask for more information.

Leo

Enrique del Sol

Hi,

 

the communication strategy that leonardolt is proposing would only reach up to 5 Hz. I suppose that with real time control we should be reach something like 100 Hz. With quicker speeds it would be possible to create a much better human robot interaction.

 

Paramin, did you find out if the ABB has any Real Time option? I am interested as well. Thanks

 

Enrique

Jaco Cronje

We have an IRB 6650S robot, and I'm trying to do real-time control with it.
There is a latency of about 460ms between executing the MoveL command and the robot actually moving. Is this normal ?
I suspect it's the path-finding / inverse kinematics algorithm of the ABB controller that causes the 460ms delay. Is it possible to replace / by-pass this with a custom IK solver ?
What is the minimum latency that I can expect ?
Could it be the flexpendant that slows things down ? It's displaying the RAPID code all the time.

Thanks,
Jaco

Enrique del Sol

Dear Jaco,

What version of controller do you have? IRC5 or SC4?
You can have a look to my post on (

http://forums.robotstudio.com/forum_posts.asp?TID=7833) where I explain my delay problems with several instructions. I am commanding joints values so I will do the IK but I still have problems if I want to execute this in real time continuously because the Stop Move and Clear Path commands take 300 ms more or less.

The MoveAbsJ (To command joint values directly) is very fast (several ms) but the rest of the necessary instructions are not. And if you wait the robot to finish the movement in order to command a new point you obviously have a longer delay.

How are you measuring the latency?

I do not think the FlexPendant is slowing the things. I have been told that the maximun frecuency with the most modern controller IRC5 with
the software option of Robot Reference Interface can it manage a maximum
of 250 Hz. Unfortunately I do not have either.

 

Regards

Enrique

Jaco Cronje

Hi Enrique,

We have the IRC5 controller, with RW5.14

I measure the latency by sending the robot on a sinusoidal path based on time elapsed, so I know where the robot should be at a specific time. I then read back the position of the robot at each time step. Then I plot the input path and the actual robot position at each time step and compare the 2 graphs. The offset between the 2 graphs gives me the latency.

I'm sending and receiving commands between the PC and IRC5 at a rate of 250Hz. But only perform a MoveL command at a rate of 25Hz. With the MoveL command I tell the robot to move to a location and take 40ms to get to the target location in order to match the 25Hz. The robot freaks out when I try to go faster.

Do you really need to call StopMove and ClearPath ? Can't you just update with joints with small increments at a high speed ?
I haven't tested the MoveAbsJ command yet, it might be a good idea to test the latency in the same way.

Regards,
Jaco

Jaco Cronje

TMS angle 1&2 are the actual positions at each time step.

The measure latency is 0.46 seconds.

Enrique del Sol

Hi Jaco,

that is a very interesting method. Why are you sending a sinusoidal path instead of a linear one? What I was doing is to set digital outputs on and off and measure the frequency with an oscilloscope.
I think 25 Hz is not too bad taking into account that the robot should move itself. I suppose that you wait for the robot to reach the target position before it accepts a new one. With the time that the robot invest in moving itself I think it is not too bad.  When I do the same with the SC4 controller and old serial communication I get at most 5 Hz. Yo should take into account that the maximum speed that the robot moves is only in automatic movement.
I was using StopMove and ClearPath in order to send continuous commands at high frequency even if the robot has not reached them but it did not work well for the time in executing them.
I will try your method of measuring latency at some point.

Regards
Enrique

Jaco Cronje

The sinusoidal path was for test purposes, we have another mechanical (non ABB) rotating platform that must be alligned with the ABB robot. When putting this device and the ABB robot on the same sinusoidal path "should" keep them alligned, but we noticed the huge delay when trying out the generated paths.

25Hz is not bad, BUT with a 460ms delay its sort of useless for our application.

I don't wait for the robot to reach the target position. I keep a circular buffer that collects the messages (target positions every 4ms) and only process the last one every 40ms.

leonardolt

Hi people.
I also faced some problems regarding to execution time of some commands. In my application I have some target points programmed  to be followed by the robot. Those are control points whis known position and orientation. I perform an interpolation of the robot's position in between the control points. I know that the robot has reached the point using a TriggL command and sending me a message by TCP/IP.
The first time I figured out that I was having some timing problem I blamed the TCP/IP connection, cause it is not time deterministic. Further I noticed that some of those problems were caused in two different situations:
1) before phisically getting to the point the controller sends the message. So all the calculation were performed with wrong timing.
2) if the number of control points is too large, the situation is the opposite, instead of advancing timing, there is a delay inthe received messages.

So I found it would demmand a lot of work to get maybe poor improvement and thus I decided to let is as it is. Now my approach is to use an inertial naviagation system to determine in real time  the position of the robot. Unfortunatly this solution is not implemented yet, because this project is stand by for a while.

By the way Enrique, could you tell me more why the method I used would reach up to 5Hz?


Best regards
Leo

Jaco Cronje

I got a delay of 600ms by using the MoveAbsJ command to just rotate one of the joints (J6) continuously... it does not make sense

Paramin

Hello all,

In my case, I have finished establishing my system (as recomended by leonardolt ). It collects ATI F/T sensor over RS-232 prior to processing, after that the output delta (x,y,z) is sent to IRC5 over TCP/IP. Linux has been used as an external computer.

 

I've just measured the cycle time taken during TCP/IP communication of around 300 ms (by sending a set of data and receving an acknowledge from the robot).

 

Could anyone tell me how to program the robot to complete a task, where a robot is required move to delta (x1,y1,z1) and if the command MOVE delta (x2,y2,z2) is suddenly fetched, the robot has to move second point automatically (eventhough the first point is whether reached or not !) 

Thank you very much.

Regards,

Paramin

leonardolt

Dear Paramin,

I think the way you could do that is creating another task that will only treat your system's requests. So, whenever you need, send this task a message and it should execute a StopMove (to effectively stop the actual movement of the robot) and a ClearPath (to flush the move buffer and let it ready to receive your next position).
I suggest you to create another task only to avoid that your changing target position request would get delayed by the execution of any move instruction, but the best practice will depend on how you are fetching the commands.

Any doubts on StopMove or ClearPath can be checked in the instruction set documentation: 3HAC16581-1_REVH_EN

Hope this helps you a bit.
Best regards
Leo

Paramin

Thank you very much again, Leo

I will try to do it but I've never tried to create two tasks in a one program before (I'm a very new learner). Have you got any document about how to make it ? I will be greately appriciated if you can recommend me again.

PS. Do I have to upgrate my Robotware in IRC5 to support  the multi-task programing or It's already installed ?

Thanks again for your all support.

Best regards,
Paramin



Paramin2013-03-15 11:51:27

leonardolt

Paramin, unfortunatly I don't know if any upgrade is necessary, but I don't believe so. Creating a new task from teach pendant is as easy as creating a new module. The only issue is that the new task will not be a moving task, once it will only be used to manage the system.
I found some information you may be interested in the followinng documet: 3HAC16580-1_REVH_EN

Feel free to feed back whenever you have some results.
Best regards,
Leo

Paramin

Thank you again for your help, Leo

I will check it out very soon and let you know the results then.

Btw. I've modified my Linux program to collect ATI F/T data and send to IRC 5; it took around 10 ms/cycle which is very OK I think. I will do the next step as your suggestion and let you know then!

Thank you again,
Paramin

leonardolt

That's good to know! How could you get quite a dramatic reduction of cycle timing?

Paramin

I have changed my system; instead of using QNX, I have used Linux - Ubuntu. It's quite much more quicker and I've also modified the Rapid codes again to achieve the ATI F/T data only (not send any data back to the PC). Furthermore, the ATI F/T data have been improved its board rate to be fastest rate.  

Then, finally, I've got it.  

Regards,
Paramin

graemepaulin

Hi,

 

You need the option MultTasking to be able to have multiple taks, if your system does not currenlty have this option you will need to contact your local ABB to have it upgraded.

 

Regards

Graeme

Paramin

Hello Graeme

 

Thank you for your information.

Btw could you give me sugestion how to check whether my ABB robot has been upgraded the MultTasking option or not ? 

 

Sorry to trouble you again but, actually,I'm quite a new learner.

 

Thank you again.

Regards,

Paramin

Paramin2013-03-17 12:45:46

graemepaulin

Hi,

 

You can find this sevral ways:

1)Through the Flexpendant under System Info (Expand System Properties, then Control  Module and finally under Options you will see the loaded options).

2)From a backup- open the backinfo.txt (located in the backinfo folder) with a text editor.

3) From RobotStudio

 

Hope this helps

 

Regards

Graeme

Paramin

Hi Graeme
Thank you very much for your support. I've checked but It's not upgraded yet.


! Btw. I have suggested that I also could use the Interrupt function already installed in ABB robot controller.
For example, the Interrupt will be based on the time taken during ATI F/T sensor data acquisition and update delta (x,y,z) before letting the robot execute MoveL (offset)....

Anyone has any idea about this ? please give me some suggestions.

Thank you in advance.
Regards,
Paramin



Paramin2013-03-18 11:35:05

Paramin

Hi  again

In my system, I have sucessfully connected an external computer using Real-time Linux, which can acquire Force/Torque data in every 10 ms, to an IRB 140 over TCP/IP. But the time of robot movement to update every small incremental position is approximately 100 ms each cycle (I suppose that with real time control we should be reach something like 100 Hz). 
 
Are there any options that will be upgrated to make my system as Real-time force control.
 
Or I need to set up my system as you suggest only; could you please give me more detals
 
I would be gretely appriciated if you could provide me both information and all approximate costs because I will be going for meeting with my team very soon.
 
Thank you in advance sir.

Best Regards
Paramin

arnasIV

Hi,

I am working on a project with PC SDK, and I face the same problem, after changing position via app it takes 0,5 s for the robot to start moving.
Has anyone solved this issue?

bartvanessen

Hello there,
I have kind of a similar problem. I'm sending a boolean to the robot by TCP-IP Connection (RRI) .
This seems to be working with a delay of 16 ms.
I have bound that variable to a Interrupt using the IPERS command.
However between the change of the Variable and initiating the stop f the robot, we are facing a delay of ~ 0.5 s, what is way too much.
Has anyone experienced  delays occuring with interrupts?