search

ros-industrial / abb_libegm

A C++ library for interfacing with ABB robot controllers supporting Externally Guided Motion (689-1)
BSD 3-Clause "New" or "Revised" License
93 stars 53 forks source link

EgmClock message does not represent UNIX time #119

Closed mkatliar closed 3 years ago

mkatliar commented 3 years ago

The definition of EgmClock in proto/egm.proto is 

message EgmClock                // Time in seconds and microseconds since 1 Jan 1970
{
    required uint64 sec = 1;
    required uint64 usec = 2;
}

Below are headers of EGM messages sent from RobotStudio on my system:

header {
  seqno: 352216
  tm: 28397221
  mtype: MSGTYPE_DATA
}
feedBack {
  joints {
    joints: 0.00025089801056310534
    joints: -0.010418600402772427
    joints: 0.03861050307750702
    joints: -0.0001342049945378676
    joints: 45.01199722290039
    joints: -0.0667094737291336
  }
  cartesian {
    pos {
      x: 1216.9378662109375
      y: 0.0046911695972085
      z: 1187.1817626953125
    }
    orient {
      u0: 0.3823593258857727
      u1: -0.0005403859540820122
      u2: 0.9240135550498962
      u3: -0.00022283525322563946
    }
    euler {
      x: -179.93319209849528
      y: 44.95977143802771
      z: -179.90533858705996
    }
  }
  time {
    sec: 28397
    usec: 216500
  }
}
...

The time data sec: 28397 does not look like "time in seconds and microseconds since 1 Jan 1970".

gavanderhoorn commented 3 years ago

So just to be clear: this repository is not where ABB maintains its EGM implementation.

This is an OSS library which implements an interface to EGM running on an ABB (robot) controller.

Issues with EGM itself -- as it seems yours is -- should be either reported to your local ABB branch office (which will then escalate them if/when appropriate) or posted on one of the official ABB fora.

From your description, I don't have the impression the issue you are reporting is specific to this library.

If you agree, please close the issue.

If you post on the RobotStudio forum fi, it would be appreciated if you could post a final comment here with a link to your post there, so we can keep things connected.

gavanderhoorn commented 3 years ago

Having written that: I could imagine that RobotStudio uses a non-wallclock internally for the robot controller, and the timestamps you show are relative to when the virtual controller was started.

For 28397 specifically, that would be about 8 hours ago.

mkatliar commented 3 years ago

@gavanderhoorn I agree. I thought maybe the documentation needs to be changed. What is the source of information about what EgmClock should contain? I could not find it in EGM documentaion.

gavanderhoorn commented 3 years ago

Perhaps @jontje can clarify where EgmClock comments come from.

They were added in #32, which copied the files distributed with RobotStudio.

I thought maybe the documentation needs to be changed

we try not to diverge from upstream here.

If the documentation should be updated, it should be done in the upstream files first. Then we can update here.

mkatliar commented 3 years ago

@gavanderhoorn what is the upstream?

gavanderhoorn commented 3 years ago

The EGM developers @ ABB Robotics.

jontje commented 3 years ago

Perhaps @jontje can clarify where EgmClock comments come from.

They were added in #32, which copied the files distributed with RobotStudio.

If I remember correctly, then EgmClock was added to the EGM protocol in RobotWare 6.07, but the release notes don’t mention it at all as far as I can see.

gavanderhoorn commented 3 years ago

@mkatliar: would it be OK to close this issue?

Have you reached out to ABB on the RobotStudio fora?

We could potentially add a clarifying comment here, but if it's not necessary that would be great.

gavanderhoorn commented 3 years ago

Closing.

mkatliar commented 3 years ago

@gavanderhoorn the issue is not present on the real robot, so it is probably a RobotStudio bug. I started a discussion on the ABB forum: https://forums.robotstudio.com/discussion/12743

mkatliar commented 3 years ago

This is the response that I got from ABB support:

according to our support EGM is not supported by RS this is why You notice different behavior of EGM clock. 

"
I checked with RobotStudio R&D and they advised that RobotStudio doesn't do anything with EGM, so it is not a bug with RobotStudio, instead it is not designed to work with it.
"
gavanderhoorn commented 3 years ago

That's a very interesting response, as both @jontje and me use RobotStudio to test and work with EGM.

@jontje ?

mkatliar commented 3 years ago

@gavanderhoorn I was also surprised. If it "doesn't do anything with EGM", why does it support EGM commands and even send EGM data.

gavanderhoorn commented 3 years ago

Perhaps a lost in translation? Perhaps "doesn't do anything with EGM" actually means: "RobotStudio does not influence any of the internals of EGM".

As I wrote in https://github.com/ros-industrial/abb_libegm/issues/119#issuecomment-786703538:

I could imagine that RobotStudio uses a non-wallclock internally for the virtual robot controller, and the timestamps you show are relative to when the virtual controller was started.

For 28397 specifically, that would be about 8 hours ago.

perhaps that's what's meant by "RS doesn't do anything with EGM", as in: RS uses some internal clock, doesn't adjust anything in EGM so EGM just reports whatever clock RS happens to use.

But this is all (wild) speculation by me (and I don't work for ABB).

mkatliar commented 3 years ago

"EGM is not supported by RS" also sounds interesting.

gavanderhoorn commented 3 years ago

Yes, I agree.

That's the first time I hear that stated about RS.

But then again, I'm just "a user".

jontje commented 3 years ago

This is the response that I got from ABB support:

according to our support EGM is not supported by RS this is why You notice different behavior of EGM clock. 

"
I checked with RobotStudio R&D and they advised that RobotStudio doesn't do anything with EGM, so it is not a bug with RobotStudio, instead it is not designed to work with it.
"

I think there has been some misunderstanding somewhere in the support chain, and that response is very vague.

When you simulate a robot "in" RobotStudio, is is technically a background process that emulates RobotWare. And it is the RobotWare process that, for example, interpret RAPID code and manages EGM clients and communication.

But this is not something users generally don't know about, so it is reasonable to send bug reports etc. via the RobotStudio channels.

So the question should have been passed along (by the support people) to the RobotWare R&D, and not RobotStudio R&D.

gavanderhoorn commented 3 years ago

So the question should have been passed along (by the support people) to the RobotWare R&D, and not RobotStudio R&D

yeah, that's in summary what I was trying to say in https://github.com/ros-industrial/abb_libegm/issues/119#issuecomment-800401636.

@mkatliar: you could perhaps rephrase your question to ABB support and see whether it ends up at the right people?

mkatliar commented 3 years ago

@gavanderhoorn I will.

mkatliar commented 3 years ago

@gavanderhoorn this is what I got from ABB support:

Regarding EgmClock : I don’t know. But usually we don’t care on that. The time from the first sequence is the reference time “Time 0”, then time difference from next sequence is calculated.
gavanderhoorn commented 3 years ago

Seems to confirm what I suspected in https://github.com/ros-industrial/abb_libegm/issues/119#issuecomment-786703538.

thanks for reporting back.

Was this in a thread on the RobotStudio forum, or a private email?

mkatliar commented 3 years ago

It was in a private email.

mkatliar commented 3 years ago

They agreed though that this is not consistent with the documentation:

Anyway I agree regarding documentation.
gavanderhoorn commented 3 years ago

Was there any indication the documentation / comments will be updated?

mkatliar commented 3 years ago

Was there any indication the documentation / comments will be updated?

No

mkatliar commented 3 years ago

The issue seems to be fixed in RobotStudio 21.2.9526.0 -- the timestamps look like UNIX time now.

gavanderhoorn commented 3 years ago

Nice, so even if they stated this wouldn't be fixed, it has now been fixed?