Read joint motor torques using EGM resources

Question

Read joint motor torques using EGM resources

Mariunil opened this issue 5 years ago · 13 comments

Hi,

We are working on external control of the ABB YuMi, and wish to read the joint motor torques of the arm's joints and send these to the external computer controlling the robot, preferably at a high Hz.

Are there any EGM routines which can be used to retrieve and transmit this information? If not, what would be our best bet at fetching these values?

Answer 1 · 2020-03-06T16:09:56.000Z

Hi @Mariunil,

You could perhaps use TestSignDefine(Channel SignalId MechUnit Axis SampleTime) in the RAPID code to setup some test signals.

Extract from the manual:

The following test signals are available for both robot and additional axes and are predefined in the system. All data is measured on the arm side of the axis.

Test signal Signal ID Unit

Position 4000 degrees or mm [1]

Speed 4001 degrees/second or mm/s [1]

Torque 4002 Nm

External torque [2] 4003 Nm

[1] The unit depends on if the axis is rotational or linear.
[2] Returns an estimated externally applied torque (by contact with the environment). On an additional axis External torque might not be valid.

And here are two potential options for accessing the test signal values.

Option 1

The EGM protocol has a field for test signals, but I haven't tried to use this myself so I haven't exposed this in the abb_libegm's interface classes. But it might be worth to investigate.

Option 2

Use abb_librws to setup a RWS subscription to an IO-signal, so that you get a notification with its new values when it is updated.

Then create a RAPID timer that periodically reads the test signals and updates the IO-signal. If I remember correctly, then RAPID timers can only run at 10 Hz. And if the timer is too slow, then you could setup a separate RAPID task which can run faster but is slightly more complicated to configure than a timer.

Also, I haven't looked, but there might exist RWS services for reading test signals directly. Please note that RWS is not designed for high performance, but I would suggest to at least try it out.

I hope this can help!

Answer 2 · 2020-03-10T10:28:18.000Z

You could perhaps use TestSignDefine(Channel SignalId MechUnit Axis SampleTime) in the RAPID code to setup some test signals.

Test signal | Signal ID | Unit
-- | -- | --
Position | 4000 | degrees or mm [1]
Speed | 4001 | degrees/second or mm/s [1]
Torque | 4002 | Nm
External torque [2] | 4003 | Nm

Option 1
The EGM protocol has a field for test signals, but I haven't tried to use this myself so I haven't exposed this in the abb_libegm's interface classes. But it might be worth to investigate.

Hi all,

I'm working with my team on a ABB IRB 2600 6-axis industrial robot, we're setting up all the motion control framework based on abb_libegm for high performance, and testing the implementation against RobotStudio.

Since we also need the measurements of joint motor torques, the above comment has been really useful to us.

Considering we are interested in Option 1, I investigated a little bit and performed the following steps to be able to extract the test signals:

from RAPID side I put the TestSignDefine calls in the TRobMain, inside main, before the while LOOP

PROC main()
        ! Initialize the submodules.
        TPErase;
        printMainMessage "Initializing submodules...";
        initializeSubmodules;
        
        runRAPIDRoutine;


        FOR ii FROM 1 TO 6 DO
            TestSignDefine ii, 4002, ROB_1, ii, 0.004;
        ENDFOR  

        ! Run the state machine.
        printMainMessage "Starting the state machine";   
        
        WHILE TRUE DO           
                      
            TEST current_state
                CASE STATE_RUN_RAPID_ROUTINE:

                CASE STATE_RUN_EGM_ROUTINE:
                    runEGMRoutine;

                DEFAULT:
                    ! Do nothing.
            ENDTEST

            WaitTime 0.01;
        ENDWHILE

        ERROR(CHANGE_STATE)
            TRYNEXT;
    ENDPROC

To see if the signals are actually read, in a semistatic task I perform:

MODULE TGetMotorTorques(SYSMODULE)
    
    PROC main()
        
        VAR num torques{6};
                
        WHILE TRUE DO
            
            FOR ii FROM 1 TO 6 DO
                torques{ii} := TestSignRead(ii);
            ENDFOR  
            
            SetAO motorTorque1, torques{1};
            SetAO motorTorque2, torques{2};
            SetAO motorTorque3, torques{3};
            SetAO motorTorque4, torques{4};
            SetAO motorTorque5, torques{5};
            SetAO motorTorque6, torques{6};
            
            WaitTime 0.004;
        
        ENDWHILE
        
    ENDPROC
    
ENDMODULE

And by inspecting with the Signal analyzer I can see the 6 measured torques values changing accordingly to an imposed motion.

from C++ side, here's the modifications inside this commit within our fork of abb_libegm: iit-danieli-joint-lab@73b71f4, to expose TestSignals in the abb_libegm interface.

However the problem is that when I try to read this values as:

abb::egm::wrapper::TestSignals jointTorques;
        jointTorques.CopyFrom(dataPtr->in_buffer_.testsignals());

google::protobuf::RepeatedField<double> signals = jointTorques.signals();

by printing signals I get this strange values X 0 0 0 0 0, where X seems to be a counter increasing of one unit after each run.

Could you explain me if the pipeline followed is correct and, if not, which are the faulty stages?

I remain at disposal for clarification about my comment.

Answer 3 · 2020-03-10T14:28:17.000Z

Hello @AlbertoRemusIIT,

by printing signals I get this strange values X 0 0 0 0 0, where X seems to be a counter increasing of one unit after each run.

I ran a simple test of my own, and I experienced the same behaviour as you. I have checked with one of the developers, and unfortunately it seems that the test signal part of EGM has not been fully implemented.

Could you explain me if the pipeline followed is correct and, if not, which are the faulty stages?

The pipeline looks fine, and as I mentioned above, then the fault is inside the robot controller.

Answer 4 · 2020-03-10T14:58:24.000Z

Thanks a lot for the feedback @jontje, I'll stay tuned for any update.

Answer 5 · 2020-03-10T15:25:26.000Z

@jontje: what are the chances of this getting fixed "upstream"?

If there is a chance, we can keep this open as blocked on dependency. Otherwise I suggest we close it (for now).

Answer 6 · 2020-03-10T15:46:45.000Z

@jontje: what are the chances of this getting fixed "upstream"?

If there is a chance, we can keep this open as blocked on dependency. Otherwise I suggest we close it (for now).

I think the chances are slim at the moment, at least that was the impression I got.

So I will close this for the time being, but feel free to post additional comments if necessary.

Answer 7 · 2020-09-16T07:12:32.000Z

According to this post on the RobotStudio forum, this should now work ?

Answer 8 · 2020-09-16T10:33:34.000Z

According to this post on the RobotStudio forum, this should now work ?

Unfortunately, no, I don't think so. This issue is about the testSignals field in the EGM messages, and not the measuredForce field.

What I understood from the post is the following:

measuredForce: Works as intended, but it needs the Force Control Base [661-2] option that requires an external force sensor according to the manual:

Force Control Base requires either a 6 DOF (Degree Of Freedom) full force/torque sensor or a 1 DOF Force sensor. The 6 DOF sensor offers more flexibility in force control directions than the 1 DOF sensor, as 1 DOF sensor only controls the force in one direction. With 1 DOF sensor it is normally very important that the tool is correctly orientated.

The choice of sensor input depends on the required flexibility of the application.

The sensor may be mounted on the robot (between the tool flange and the tool) or stationary in a room fixed position. It is not necessary to mount sensor and tool on the same place.
testSignals: Is not mentioned to work for EGM, but the post refers to a separate program called Test Signal Viewer (e.g. included in RobotWare Tools and Utilities 6.11 found here). As far as I know, then that program doesn't use EGM.

Also, I haven't seen anything in the RobotWare release notes about EGM getting full support for test signals.

Answer 9 · 2020-09-16T14:19:26.000Z

Hm, teaches me to post something without fully reading it :(

Too bad though. Any idea why the test signals part is not implemented fully?

Seems like something that would be really worthwhile to have.

Answer 10 · 2020-09-17T13:09:17.000Z

Hm, teaches me to post something without fully reading it :(

No worries, it's better to ask than not.

Too bad though. Any idea why the test signals part is not implemented fully?

Hm... I don't know, maybe because there haven't been enough customer requests about it.

Seems like something that would be really worthwhile to have.

I agree, it would be useful.

Answer 11 · 2020-09-17T13:13:07.000Z

Too bad though. Any idea why the test signals part is not implemented fully?

Hm... I don't know, maybe because there haven't been enough customer requests about it.

On which channel do you think it would be more appropriate for a customer to make a request in this direction?

Answer 12 · 2020-09-17T13:20:44.000Z

On which channel do you think it would be more appropriate for a customer to make a request in this direction?

I suggest to try one of these channels:

Contact your local ABB Robotics sales organization
ABB Robotics User Forums
RobotStudio Suppot Tool:

Answer 13 · 2023-04-12T20:20:25.000Z

@jontje
Has there been any updates on this endeavor? Using test signals to read out joint torque values?

Test signal	Signal ID	Unit
Position	4000	degrees or mm [1]
Speed	4001	degrees/second or mm/s [1]
Torque	4002	Nm
External torque [2]	4003	Nm