ros-industrial / abb_libegm Goto Github PK

Add sections for:

• Structure/class descriptions
• Troubleshooting
• Acknowledgements

As per title.

I've ran into a controller that was updated to RW 6.10.

The readme currently states that only 6.07 6.08 has been tested, but are there any known incompatibilities between abb_libegm and RW 6.10?

As per title.

Currently unsupported modes are:

• EGM Path Correction
  Path correction can be used to correct a programmed robot path (requires using special RAPID move instructions).

• EGM Position Stream (requires RobotWare 6.07 or later)
  Position streaming can be used for when it is only interesting to track a mechanical unit's position, and not to control it's motion.

This can for example be done by implementing additional EGM interface classes.

Hi @jontje , I have a question about EGM frequency.

So, I'm using this library with IRB 4600, and I tried to print out the time it took to get new data from the robot both using real robot and RobotStudio. Since I used your sample codes, I'll just put the codes that are related to this issue here:

while(ros::ok())
{
ros::Time start_time =  ros::Time::now();
    if(egm_interface.waitForMessage(500))
    {
        ros::Time time_now = ros::Time::now();
        std::cout<<time_now-start_time<<std::endl;
    }
}

It turns out in RobotStudio, it takes about 0.016s, and 0.025s when working with the real robot. My setup is following:

• using EGM_ControllerInterface
• SampleRate in RAPID code is set as 4 ms
• RobotWare 6.08
• Protobuf 3.6.1
• ubuntu 14.04.

I noticed that you mentioned control lag in issue #15 and I checked ABB documentation. As you also mentioned in issue #25 that you're using 4ms primarily, so the questions are:

• do you also have this much lag when using joint velocity control?
• is there a way to reduce the lag?
• the fastest 4ms is just for the robot to take new control references, which is open loop, and closed loop usually has 10-20 ms delay, is that correct?

Appreciate any feedback. Thanks.

In order to streamline community contributions, we need to add contribution guidelines.

This would be similar to #13, but specific to this repository.

We are wanting to use EGM to perform velocity control to move our robot to a designated position. The problem we are running into is that the robot does not maintain the desired velocity for the entire duration of the movement. If you change the reference velocity in the code @jontje provided to a constant (code provided below), the robot will move for only a few seconds and then stop, rather than run at that velocity for the desired amount of time. We are thinking that this may be due to a sudden change in velocity or some safety feature? Here are the steps we've taken to try to remedy the issue:

-Use the EGM_STOP_HOLD parameter in the EGMRunJoint command
-Tried running the robot at small velocities, to see if it was due to high acceleration

• Set the MaxSpeedDeviation to a super high number to allow for large changes in speed

All of these produced the same result: The robot would move for only a couple of seconds and then stop.

On a side note, does anyone know if abb_libegm is compatible with ROS-melodic/ubuntu 18.04?

We'd greatly appreciate any help with this issue!

Hi All,

I know this perhaps is not the best place to ask questions. However, we are on a tight schedule and have to make a decision recently to purchase a large robot for force control.

I wonder if abb_libegm allows for the control of joint_velocity in real-time? If so, could you please briefly tell me its real-time performance of joint velocity tracking and its difference from abb_librws?

Thank you a lot for your good contribution for me to ask this question here. Really appreciate your time and help.

@traversaro et al.: your fork appears to have some interesting changes that may be good to upstream.

Things that caught my eye:

• windows build fixes (I don't believe we currently target Windows too much, but it'd be good to try and be nice to other users)
• s/Boost/std/g
• Protobuf related changes/fixes (although we need to maintain bw-compatibility with CMake 3.6 for now)
• changes to better support cross-compilation

and a few others.

Would you be interested in submitting some of that as PRs here?

Hi, everyone:
I always get the error " EGM state chang error", when runing the EGM in RobotStudio.
We'd greatly appreciate any help with this issue!Thank you very much!

The RAPID program in here:

MODULE TRob1Main
    ! Home position.
   ! LOCAL CONST jointtarget home := [[0, 0, 0, 0, 0, 0], [9E9, 9E9, 9E9, 9E9, 9E9, 9E9]];
    ! Identifier for the EGM correction.
    LOCAL VAR egmident egm_id;
    
    ! Limits for convergance.
    LOCAL VAR egm_minmax egm_condition := [0, 0];
    VAR JointTarget joints_target;
    PROC main()
        joints_target := CJointT();
        MoveAbsJ joints_target, v200, fine, tool0;
        WHILE TRUE DO
            ! Register an EGM id.
            EGMGetId egm_id;
            
            ! Setup the EGM communication.
            EGMSetupUC ROB_1, egm_id, "default", "ROB_1", \Joint;
            
            ! Prepare for an EGM communication session.
            EGMActJoint egm_id
                        \J1:=egm_condition
                        \J2:=egm_condition
                        \J3:=egm_condition
                        \J4:=egm_condition
                        \J5:=egm_condition
                        \J6:=egm_condition
                        \SampleRate:=4
                        \MaxPosDeviation:=1000
                        \MaxSpeedDeviation:=1000.0;
                        
            ! Start the EGM communication session.
            EGMRunJoint egm_id, EGM_STOP_HOLD, \J1 \J2 \J3 \J4 \J5 \J6 \CondTime:=5;
            
            ! Release the EGM id.
            EGMReset egm_id;
        ENDWHILE
        
    ERROR
        IF ERRNO = ERR_UDPUC_COMM THEN
            TPWrite "Communication timedout";
            TRYNEXT;
        ENDIF
    ENDPROC
ENDMODULE

Moved question asked by @geohn in issue #18 (comment) to a new issue.

@jontje thanks for your help , i want to implement the interpolator method of this C++ code on matlab , but i dont know what's actual defferents between the two viriables ‘sample_time’ and 'condition_duration'
Thanks sincerely!

The EGMInterpolator class has the following subclasses for calculating interpolations:

• SplinePolynomial
• Slerp
• SoftRamp

SplinePolynomial and Slerp are used when following a known trajectory (with one or more goals that doesn't change), while SoftRamp is used when only either a position or a velocity goal (that can be changed) is known.

All of them uses condition_duration to specify the time it should take to reach the goal, while SoftRamp uses sample_time for estimations (i.e. estimate position if velocity goal and vice versa).

I hope this helps!

With the requirement of using at least version 6.07.01 of RobotWare in #32, we've had a few reports of users running into issues when trying to use an older version of RW (see #42 and #45).

It would be good if abb_libegm supported some sort of version check, as this could help us print an error message if/when an incompatible version is being used.

As per title

I've had EGM working on my desktop for about 6 months now, and I've decided to offload running the robot from my desktop to another computer. I copied the program I've been running (which essentially is a modification of https://github.com/kth-ros-pkg/yumi) and I find that when I run the program, the state machine add-in gets to line 326 in the program TRobEGM, when it setsup EGMActJoint, I get that an error on the controller saying that the load is undefined. I've never had this issue before and the only thing that changed is I downloaded the latest version of this package, and modified my CMake file to reflect that this is no longer a catkin package.

Is there any change to this package which may have caused this? I see that egm_load has a 0kg load, defined on line 151 of the same module. I'm not exactly sure if it's safe to modify this, and it also seems likely that it was set to load0 on line 305 (which is .001kg).

I haven't followed the flow of the StateMachineAddIn enough to see if this is the case, or if I should just modify the egm_load defined in the addin... but since I didn't have this issue before, I thought I'd post it here.

Any assistance would be highly appreciated!

As per subject.

This would enable CI for this repository.

I viewer this answer ros-industrial/abb_librws#49 , and to test the EGM parameters. I find that whether set PRG or PCG to zero, the will become the pure velocity control. Morever if you in pure velocity control, when you stop to send the targert velocity, the robot will continue the runing for a period of time , the value is equal the \CommTimeout of use EGMSetupUC instruction set. And chang the PPG notrequires to restart the IRC5 cointroller, but chang the PCG need to Pstart the IRC5 controller.
In the process of testing the EGM parameters, I found some strange problems.
1: In the Technical reference manual RAPID instructions,Function and Datatypers.pdf about paramers \PoseCorrGain the value is between 0 and 1, but when i set the value more then 1, it didn't occur error. And have any way to test the separate effect of these two parameters on the EGM controller?
2: In the EGMActJoint instruction have a parameters \LpFilter, the desciption is low pass filter bandwith, used to filter sensor noise. in the tesing ,i try to set this value 0 ,-100,-10000, it also din't occur error. The EGM working well, so i guess if the value is set \LpFilter <=0, it will be reset to default value, but i didnot know the default value about \LpFilter.
Thank you very much!

Hi,

in a project in which we are integrating the IRB 14000 YuMi with ROS2, motion control of YuMi is handled via the abb_libegm library and the EGM interface of the robot controller.

A fully functioning system was achieved with ROS2 Dashing. However, when transitioning to ROS2 Eloquent, the same code crashes the robot controller.

When a motion command is issued (joint position reference) to the robot controller, it activates the joint brakes on both arms and freezes for a couple of seconds before crashing (FlexPendant reboots etc). It then automatically reboots, but gets stuck trying to connect to the robot controller. When manually powered down and restarted, the FlexPendant informs us the robot controller is in a System Failure state.

Error messages read from FlexPendant , in order of occurrence

Event Message 20192 "System data from last shutdown is lost"
Event Message 20193 "Robot data update warning"

-- It gets stuck rebooting, we manually reboot --

Event Message 10056 "System restarted"
Event Message 10014 "System failure state"

The robot controller is running a StateMachine Add-In instance for both arms. Same issue have occurred with the following configurations:

• RW 6.08.00.01 and StateMachine 1.0
• RW 6.09.02 and StateMachine 1.0
• RW 6.10.01 and StateMachine 1.1

Desktop PC: Ubuntu 18.04 with today's (and several older) build(s) of abb_libegm.

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.

Seperate issue for @CaptainNUS's question from #66 (comment):

Hi @gavanderhoorn @jontje:

May I check if there is some other libraries or techniques to support sending trajectories to the FlexPicker robot? Right now I can only program with RAPID codes for robot control.

I used Python codes to get the desired position information and sent to the FlexPicker through socket. But I don't know how to do the motion planning with Python or C++ in Ubuntu system.

Any help is much appreciated. Thanks.

I'm having issues getting abb_libegm to connect to both robotstudio and the robot. I've tried several things to try to remedy the issue. Here is a list of items that I verified before posting here:

• -Made sure IP addresses are in same domain
• -Compiled .proto files using protobuf compiler (version 2.6.1)
• -Performed a clean catkin compile before trying to run code
• -Made sure that Configuration IP addresses in robotstudio match IP address of remote computer
• -Tried connecting using sample code, including the Pack&Go file
• • Restarted both the robotstudio rapid program and the controller
• • Disabled firewalls

We've got EGM working before in the past, but it is no longer connecting for some unknown reason. Any help would be greatly appreciated.

Hi All,

I am using the abb_libegm_samples on a real robot of ABB IRB360. I tried several examples in the samples. But it seems the egm_interface is not connected. It always showed that "wait for an EGM communication session to start", even though I have started the RAPID codes on the controller. I have successfully configured the transmission protocol in RobotStudio, which has tested on rpi_abb_irc5. I can read the joint and position data via rpi_abb_irc5, based on the same configuration. But I do not know why it does not work for the abb_libegm_samples. How to trigger the EGM communication session on the controller side?

Any help is much appreciated.

The version of StateMachine Add-In is 1.1. The RobotWare is 6.09.00.01.
The EGM code is listed as:

MODULE TRobMain

    ! Home position.
    LOCAL CONST jointtarget home := [[0.49, -17.68, 4.91, -41.38, 0, 0], [9E9, 9E9, 9E9, 9E9, 9E9, 9E9]];
    
    ! Identifier for the EGM correction.
    LOCAL VAR egmident egm_id;
    
    ! Limits for convergance.
    LOCAL VAR egm_minmax egm_condition := [-0.1, 0.1];
    CONST num STATE_IDLE              := 0;
    CONST num STATE_INITIALIZE        := 1;
    CONST num STATE_RUN_RAPID_ROUTINE := 2;
    CONST num STATE_RUN_EGM_ROUTINE   := 3;
    VAR num current_state := STATE_INITIALIZE;
    
    ! Error numbers.
    VAR errnum CHANGE_STATE := -1;

    PROC main()
        EGMReset egm_id;
        EGMGetId egm_id;
        
        MoveAbsJ home, v200, fine, tool0;
        
        ! Setup the EGM communication.
        EGMSetupUC ROB_1, egm_id, "ROB_1", "ROB_1", \Joint \CommTimeout:=10;
        
        ! Prepare for an EGM communication session.
        EGMActJoint egm_id
                    \J1:=egm_condition
                    \J2:=egm_condition
                    \J3:=egm_condition
                    \J4:=egm_condition
                    \J5:=egm_condition
                    \J6:=egm_condition
                    \MaxPosDeviation:=100.0
                    \MaxSpeedDeviation:=100.0;
                    
        WHILE TRUE DO    
            ! Start the EGM communication session.
            EGMRunJoint egm_id, EGM_STOP_HOLD, \J1 \J2 \J3 \J4 \J5 \J6 \CondTime:=10 \RampOutTime:=10;
            WaitTime 2;
        ENDWHILE
        
    ERROR
        IF ERRNO = ERR_UDPUC_COMM THEN
            TPWrite "Communication timedout";
            TRYNEXT;
        ENDIF
    ENDPROC
ENDMODULE

I have tried several similar RAPID codes. But they always failed due to egm_interface is not connected.

When PR #81 has been merged it would be possible to re-add support for the currently incompatible RobotWare versions 6.0 - 6.06.03.

E.g. C++11 and start using std::shared_ptr instead of boost::shared_ptr

Tracking this here, even though it's not really the place.

@jontje wrote (in #73 (comment)):

The RAPID modules are currently only available in the distribution format, i.e. packaged into v1.0 and v1.1. But, yes, it would be nice to make the RAPID modules available directly as well.

New issue for @ChunyangXia's question from #15 (comment).

I.e.:

After you have the RAPID code, then you need to make sure that the RAPID EGMRunX instructions's PosCorrGain argument is set to zero (to allow for pure velocity control).

@jontje
Thanks for your help. After setting PosCorrGain=0, the velocity can be controled realtime, but the movement lose control, robot will go along X direction until safe guard stop. Do you know why? How to regulate the path of movement under this situation. The following is my RAPID. Thanks again

@ChunyangXia, did you manage to solve this? I have been out of office and just got back today.

I did a quick test with RobotStudio simulations, and since I don't know your setup I just used the following:

• RobotStudio:
  • RobotWare 6.08.01
  • An IRB1600 robot
  • Your RAPID code
• C++ program:
  • EGMControllerInterface
  • Generated a mock sinusoidal velocity on the x-axis

The robot moved as expected for me.

If this is still an issue, could you provide some details about your actual setup? And what did you mean with "movement lose control"? E.g. did the robot stop responding to your EGM references?

I've included modified parts of the code given in the sample code (names a1_joint_trajectory_node.cpp, and corresponding RAPID program). The problem I'm having is that the robot only seems to execute the first point or two of 9 in the trajectory. I'm wondering if there is a maximum number of points that should be in each of the abb::egm::wrapper::trajectory::TrajectoryGoal objects? If not, any ideas as to the cause of this? The relevant code is here:

void goalCB() {
  ROS_INFO("asdf");
  goal_ = as_.acceptNewGoal();

  std::vector<trajectory_msgs::JointTrajectoryPoint> trajArray =
      goal_->trajectory.points;
  abb::egm::wrapper::trajectory::PointGoal* p_point;
  abb::egm::wrapper::trajectory::TrajectoryGoal trajectory_1;

  p_point = trajectory_1.add_points();
  // p_point->set_duration(2.5);
  double prevtime = 0;
  std::cout << trajArray.size() << "number of points in msg" << std::endl;
  for (int i = 0; i < trajArray.size(); i++) {
    // p_point->set_duration((trajArray[i].time_from_start.toSec()-prevtime)*10);
    p_point->set_duration(2.5);
    p_point->set_reach(true);

    std::cout << trajArray[i].time_from_start.toSec() - prevtime << " duration"
              << std::endl;

    prevtime = trajArray[i].time_from_start.toSec();
    for (int j = 0; j < trajArray[i].positions.size(); j++) {
      std::cout << "joint angle: " << trajArray[i].positions[j]
                << " Number of joints in pose " << i << " is "
                << trajArray[i].positions.size() << std::endl;
      p_point->mutable_robot()
          ->mutable_joints()
          ->mutable_position()
          ->add_values(trajArray[j].positions[j] * 180 / 3.1415926);
    }
    /*if(i%3 == 0){
            egm_interface.addTrajectory(trajectory_1);
    }*/
  }

  ROS_INFO("2: Add joint trajectories to the execution queue");
  egm_interface.addTrajectory(trajectory_1);
  ROS_INFO("3: Wait for the trajectory execution to finish...");
  abb::egm::wrapper::trajectory::ExecutionProgress execution_progress;
  wait = true;
  while (ros::ok() && wait) {
    ros::Duration(0.5).sleep();
    if (egm_interface.retrieveExecutionProgress(&execution_progress)) {
      wait = execution_progress.goal_active();
      std::cout << "goal is active" << std::endl;
    } else {
      std::cout << "goal is not active" << std::endl;
    }
  }
}

Thanks in advance!

Promoting #17 (comment) by @traversaro to this issue:

Besides #3, a few additional fixes will be necessary to correctly compiled the library on Windows. One issue for sure is symbol visibility, but that can be easily addressed by setting CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS to TRUE (see https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/).

If the library is supposed to be distributed in binary form on Windows, some additonal work may be necessary to create a relocatable CMake package (see https://cmake.org/cmake/help/v3.12/manual/cmake-packages.7.html#creating-relocatable-packages), to make sure that the library can be used also if it installed in a location different from the build-time installation destination.

From #53 (comment):

I found another way, which is to make sure that the EGM Server starts first and be waiting for the client, then run the EGMRunJoint command in the rapid code, this will ensure synchronization from the begining.

This is how I always do it, and I can clarify this in the readme or in some examples. Sorry for the lack of instructions!

I know you guys are busy people, but this issue is somewhat urgent. I'm having an issue with getting EGM to maintain a connection with the physical robot. I am using the sample RobotStudio code and a modified version of the C++ code, which has worked on the robot our group has purchased.

We are now testing EGM on an older model (IRB 4600)...the robot is orange if that description helps. Our test code, which just moves the robot to a specified position, works in RobotStudio and the newer robot we purchased. When we test it on this older model, we are getting an error which I believe is caused by EGM not maintaining its connection. When I run the C++ code, it says it's connected, but the RobotStudio code continues to iterate in a loop, until it hits a manual jog instruction. The error says that jog/manual move isn't allowed during EGM, which makes sense. What I don't know is why this robot loses connection with EGM. Here are the items we have checked so far:

• Replaced RobotStudio code with successfully tested version
• Tested from a linux computer which successfully executed EGM on our robot
• Made sure IP addresses matched and verified by pinging
• Tried starting the robotstudio/C++ programs in different orders
• Tried code in both manual/automatic mode
• Ensured that EGM was installed on physical controller

The only differences that come to mind are the robot model year and the port we are using for the connection. Before we were using the service port, but for this testing we have been using a port on the bottom of the controller. We greatly appreciate any assistance! I've attached screenshots of the error message we are receiving in robotstudio and on the teach pendant.

When using a slightly modified version of abb_libegm, under some configurations (Ubuntu 18.04, Debug with Boost 1.69, Debug with standalone Asio) we experienced the following linking errors when linking an executable that linked abb_libegm we experienced the following linking errors:

../../../lib/libidjl_motion_control_egm.so: undefined reference to `abb::egm::EGMControllerInterface::ControllerMotion::WRITE_TIMEOUT_MS'
../../../lib/libidjl_motion_control_egm.so: undefined reference to `abb::egm::EGMBaseInterface::WAIT_TIME_MS'

After some investigations, we found that this was due to the fact that for these two attributes, the definition was missing, so whenever they are passed to functions that takes their inputs by (even const) reference, they will result in a linking error (see https://stackoverflow.com/questions/16957458/static-const-in-c-class-undefined-reference/16957554).

A possible solution is contained in iit-danieli-joint-lab@4280e66 .

Create samples to showcase how to use the interface classes, including:

• C++ code
• RAPID code (and possibly a RobotStudio Pack&Go file for a simulation setup)
• Instructions

I'm having difficulty building the abb_libegm_samples from: issue 18

I downloaded a protoc executable from: link, copied it to /usr/bin and chmod +x protoc so it would run, I was able to build abb_libegm. I was not able to experience the same success when I tried to build the samples file.

which protoc = /usr/bin/protoc
protoc version = libprotoc 3.6.1
Ubuntu: 16.04
ROS: Kinetic

See output below.

Any ideas on how to resolve: undefined reference to `google::protobuf::xxxxx?

CMakeFiles/abb_libegm_samples_joint_trajectory_node.dir/src/a1_joint_trajectory_node.cpp.o: In function google::protobuf::Arena::AllocHook(std::type_info const*, unsigned long) const': a1_joint_trajectory_node.cpp:(.text._ZNK6google8protobuf5Arena9AllocHookEPKSt9type_infom[_ZNK6google8protobuf5Arena9AllocHookEPKSt9type_infom]+0x3d): undefined reference to google::protobuf::Arena::OnArenaAllocation(std::type_info const*, unsigned long) const'
CMakeFiles/abb_libegm_samples_joint_trajectory_node.dir/src/a1_joint_trajectory_node.cpp.o: In function google::protobuf::RepeatedField<double>::Reserve(int)': a1_joint_trajectory_node.cpp:(.text._ZN6google8protobuf13RepeatedFieldIdE7ReserveEi[_ZN6google8protobuf13RepeatedFieldIdE7ReserveEi]+0x359): undefined reference to google::protobuf::internal::ArenaImpl::AllocateAligned(unsigned long)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::ArenaImpl::AllocateAlignedAndAddCleanup(unsigned long, void (*)(void*))' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::DecrementRecursionDepthAndPopLimit(int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::AssignDescriptors(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, google::protobuf::internal::MigrationSchema const*, google::protobuf::Message const* const*, unsigned int const*, google::protobuf::Metadata*, google::protobuf::EnumDescriptor const**, google::protobuf::ServiceDescriptor const**)' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::ReadVarint64Fallback()'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::UnknownFieldSet::default_instance()' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::IncrementRecursionDepthAndPushLimit(int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::DestroyMessage(void const*)' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::ReadVarint32Fallback(unsigned int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::InitSCCImpl(google::protobuf::internal::SCCInfoBase*)' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::RegisterAllTypes(google::protobuf::Metadata const*, int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::Message::SpaceUsedLong() const' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::SkipFallback(int, int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm//libhome//libabb_libegm.soejbkdb:/ sandingundefined/ catkin_wsreference/ develto/ .privategoogle/:abb_libegm:/protobuflib:/:libabb_libegm.soio:: :undefinedCodedInputStream :reference: ReadVarintSizeAsIntFallbackto( )'google
:/:homeprotobuf/:ejbkdb:/internalsanding:/:catkin_wsArenaImpl/:devel:/AllocateAlignedAndAddCleanup.(privateunsigned/ abb_libegmlong/,lib /voidlibabb_libegm.so :( *undefined) (referencevoid *to) )'google :/:homeprotobuf/:ejbkdb:/iosanding:/:catkin_wsCodedInputStream/:devel:/ReadTagFallback.(privateunsigned/ abb_libegmint/)lib'/ libabb_libegm.so/:home /undefinedejbkdb /referencesanding /tocatkin_ws /develgoogle/:.:privateprotobuf/:abb_libegm:/iolib:/:libabb_libegm.soCodedInputStream:: :undefinedDecrementRecursionDepthAndPopLimit (referenceint )to'
/googlehome:/:ejbkdbprotobuf/:sanding:/internalcatkin_ws:/:develOnShutdownRun/(.voidprivate /(abb_libegm*/)lib(/voidlibabb_libegm.so :const *undefined) ,reference voidto constgoogle):':
protobuf/:home:/internalejbkdb:/:sandingAssignDescriptors/(catkin_wsstd/:devel:/__cxx11.:private:/basic_stringabb_libegm</charlib,/ libabb_libegm.sostd:: :undefinedchar_traits to, stdgoogle::::allocatorprotobuf<:char:>internal :>: RepeatedPtrFieldBaseconst:&:,InternalExtend (googleint:):'protobuf ::internal::MigrationSchema const*, google::protobuf::Message collect2: error: ld returned 1 exit status const* const*, unsigned int const*, google::protobuf::Metadata*, google::protobuf::EnumDescriptor const**, google::protobuf::ServiceDescriptor const**)' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::ReadVarint64Fallback()'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::UnknownFieldSet::default_instance()' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::IncrementRecursionDepthAndPushLimit(int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::DestroyMessage(void const*)' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::ReadVarint32Fallback(unsigned int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::InitSCCImpl(google::protobuf::internal::SCCInfoBase*)' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::RegisterAllTypes(google::protobuf::Metadata const, int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::Message::SpaceUsedLong() const' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::SkipFallback(int, int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::Arena::OnArenaAllocation(std::type_info const*, unsigned long) const' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::ArenaImpl::AllocateAligned(unsigned long)'
/make[2]: *** [/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm_samples/lib/abb_libegm_samples/a1_joint_trajectory_node] Error 1
home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::ReadVarintSizeAsIntFallback()' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::io::CodedInputStream::ReadTagFallback(unsigned int)'
/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/make[1]: *** [CMakeFiles/abb_libegm_samples_joint_trajectory_node.dir/all] Error 2
libabb_libegm.so: undefined reference to google::protobufmake[1]: *** Waiting for unfinished jobs.... ::internal::OnShutdownRun(void (*)(void const*), void const*)' /home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm/lib/libabb_libegm.so: undefined reference to google::protobuf::internal::RepeatedPtrFieldBase::InternalExtend(int)'
collect2: error: ld returned 1 exit status
make[2]: *** [/home/ejbkdb/sanding/catkin_ws/devel/.private/abb_libegm_samples/lib/abb_libegm_samples/a2_pose_trajectory_node] Error 1
make[1]: *** [CMakeFiles/abb_libegm_samples_pose_trajectory_node.dir/all] Error 2
make: *** [all] Error 2
cd /home/ejbkdb/sanding/catkin_ws/build/abb_libegm_samples; catkin build --get-env abb_libegm_samples | catkin env -si /usr/bin/make --jobserver-fds=6,7 -j; cd -

The following user interaction methods for EGMTrajectoryInterface should return feedback to the user, so that it is clear if the interaction was accepted or not:

• addTrajectory(...)
• stop(...)
• resume(...)
• updateDurationFactor(...)
• startStaticGoal(...)
• setStaticGoal(...)
• finishStaticGoal(...)

I tried a lot of different trajectories each with different velocities and number of points, the robot doesn't start motion until after a certain number of messages(always between 70 to 80).

I tried a very simple solution to add 70 points with zero velocity before the actual trajectory points, and the number of messages before starting robot motion increased by 70, so it seems to be aware of the velocity change in the sent data, not just waiting for this certain number of messages.

I am using joint mode, with velocity only control(I also tried position only outputs).
I am using egm controller interface not the trajectory interface.

Also it seems that the sent messages aren't ignored because if they were it would have resulted in a Dynamic Load, which could mean that they are stored in a buffer.

Any help would be appreciated, thanks.

Right now the code contains several "A constructor" or "A default constructor" descriptions. It would be nicer to have more descriptive documentation.

Hi All,

We were using the EGM to do real-time control and want to move the robot 4th joint, for example, from 0 degree to 30 degree. The simulation on robot studio works just fine. However, the joint angle reading changes from 0 to 1710, instead of 0 to 30, when we run the experiments on the real robot. We tested all the joints and the angle reading almost always has to be divided by 57 to get a seeming accurate reading. Since we are doing real-time control, this reading is vital to us and we would like to have an accurate reading, if possible.

I wonder if you may know what's going on. The customer service agent was not responding to our questions since they don't know this EGM library...

Thank you.

We may want to add a syntax key to the .proto files we ship here (these):

[libprotobuf WARNING google/protobuf/compiler/parser.cc:547] No syntax specified for the proto file: egm.proto.
Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)

As mentioned in PR #83, then there exist certain cases which warrants throwing exceptions.

For example, if a user tries to send NaN or infinity values.

Hi,

I am trying to implement a continuously running system that controls the robot on RobotStudio, that can also mitigate automatically from RobotStudio runtime errors like Dynamic Load and Joint Out Of Range without me having to manually restart the system or code.

I am currently using two ros nodes:
The First one using abb_librws with State Machine Add-in to restart motion, handle runtime errors, and to send trajecotry data to abb_libegm.
The Second is using abb_libegm to send the calculated trajectories to the robot.

I found that the best way to handle RobotStudio runtime errors, specially Dynamic Load was to close egm ros node and run it again, so is there a proper way to restart egm session automatically without me having to manually shutdown the node?

Example execution sequence that gives Dynamic Load:

First use MoveAbsJ to go to starting position
Second execute EGM trajectory to go to desired goal.

Then repeat with the same EGM trajectory.

After executing this cycle several times, then the problem of Dynamic Load occurs, and i can't mitigate from it unless i manually intervene, i tried stopping the rapid execution and starting it again from abb_librws node but it just keeps giving the dynamic load every time.

Thanks.

This issue is in regards to updating the sample code to fix the EGM connection issues that were described in issue #54 . Thanks

I have a bottom-mounted servo (M7DM1), which I'm hoping to control at the same time as the robot arm via EGM. I'm curious if this is possible, and if so what modifications (if any) would need to be incorporated in the state machine to allow such functionality?

Thanks in advance,
Josh

As mentioned in PR #68, then there is currently no check in abb_libegm for NaN values. If NaN values are allowed to pass to the robot controller, then this will cause a system failure.

It should be straight-forward to add checks for NaN to the methods here and here.

I'm trying to run catkin_make_isolated, and a package which depends on abb_libegm leads to:

/home/joshua/catkin_ws/src/abb_libegm/include/abb_libegm/egm_base_interface.h:42:10: fatal error: egm.pb.h: No such file or directory
 #include "egm.pb.h"         // Generated by Google Protocol Buffer compiler protoc

Not sure how to fix!

Edit, one such example would be the egm samples package.

The headers (and sources) generated by protobuf are not installed by the build script at the moment.

This is less of a problem in a Catkin workpace, as there the include will resolve to the build and / or devel folder (where the files are stored after code generation), but for a stand-alone build/install (or a user that uses the install space) this will not work.

Adapt CMakeLists.txt so we can accomodate building the library without Catkin / in a non-ROS (build) environment.

The internal states that EGMTrajectoryInterface can be in is:

• Normal trajectory execution
• Ramping down current references
• Tracking a static goal

Right now, it can be a bit difficult to follow how the states and sub states are changed and this can be simplified.

We're currently using an ABB IRB 1200 without EGM and are looking to switch over. Has anyone used EGM and ROS to control an arm via a Linux computer (perhaps with real-time kernel patch / other modifications)? How much jitter is acceptable / how hard of a real-time system do we need? (If it matters, we're also planning to incorporate an external axis and will be switching from a compact controller to a single cabinet controller.)

Thanks!

For example in the sample time estimation done in the EGMBaseInterface::InputContainer::estimateSampleTime() method in egm_base_interface.cpp

Hej,
In the protobuf definition of Quaternion, it is not very clear to which quaternion dimension each field corresponds, e.g:

Is it the case that

u1 = x
u2 = y
u3 = z
u4 = w

Or

u1 = w
u2 = x
u3 = y
u4 = z

for a quaternion defined as w + x i + y j + z k ?

Thank you.

I was wondering if it is possible to concurrently use the egmControllerInterface and egmTrajectoryInterface classes in the same program. Robotstudio only allows one port per robot, and I'm not sure if it's even possible for more than one socket to connect to the same port. Any help would be greatly appreciated!