Here are robot parameters for KUKA KR240 R3330

[yvanblanchard]

KUKA KR240 R3330:

Parameters:

a1 = 0.500 a2 = 0.055 b = 0.00 c1 = 1.045 c2 = 1.300 c3 = 1.525 c4 = 0.290

Offset correction (opw convention): offsets[2] = -M_PI / 2.0

Sign correction: J1=J4 =J6 = -1

Need to apply offset values for axes J2 and J3 (for KUKA controller convention): J2 = -90deg J3 = +90deg

Test:

[Levi-Armstrong]

Thank you. @marip8 How do you think we should manage this? Should we just have a single header which we put these in to build up a database and use the ROS Industrial URDF naming convention for the definition?

[marip8]

• I think I would rather store these parameters as a YAML file instead of a c++ header and provide a parser from YAML to OPW c++ struct
• I think I would rather not store parameters for a bunch of robots in this repo
  • Some repos (like motoman and abb ) have been storing these parameters as YAML files in the support package. I think it makes more sense to store the information there closer to the other information you need for doing planning (e.g., URDF, meshes, Tesseract/MoveIt configuration information, etc.)
  • For robots without support packages, we could open a discussion on the repo to provide these parameters for reference until the support package gets created

[yvanblanchard]

sorry @marip8 , I did not know the best way to share those parameters. But I think it can clearly save time to people to get them. I think a good way would consist to store them in URDF file, using a dedicated XML tag (even if the existing URDF format/convention does not manage them), and find the best repo (ROS?) for managing/sharing the urdf files of all (or most of) the robots.

[gavanderhoorn]

I think a good way would consist to store them in URDF file, using a dedicated XML tag (even if the existing URDF format/convention does not manage them), [..]

seeing as OPW (and its various implementations) see usage outside of ROS, perhaps using URDF to store these handful of constants is not necessarily a good idea.

The "ROS world" can easily load a .yaml, and that would make these values available to everyone, whether they use ROS or not.

[yvanblanchard]

I think a good way would consist to store them in URDF file, using a dedicated XML tag (even if the existing URDF format/convention does not manage them), [..]

seeing as OPW (and its various implementations) see usage outside of ROS, perhaps using URDF to store these handful of constants is not necessarily a good idea.

The "ROS world" can easily load a .yaml, and that would make these values available to everyone, whether they use ROS or not.

Ok, but please notice that URDF format is not only used by ROS users, but also now in plenty of software (NVidia omniverse, Matlab, Unity, Blender,..)

[gavanderhoorn]

But we typically use XACRO in ROS, not URDF.

And parsing a .xacro without first running it through xacro to convert to URDF is often non-trivial for non-ROS users, making it non-trivial for non-ROS users to access the data.

I would suggest to store data in formats that are as easy as possible to read/load, and in my opinion, YAML wins over URDF.

Could you perhaps clarify why you would not go with @marip8's suggestion to use YAML?

---

Edit: the Rust library you mention in #78 even supports loading the format used in the repositories linked by @marip8 (docs).

[Levi-Armstrong]

I also prefer yaml and given the light weight nature of these parameters I do not feel they need to kept in a separate repository. I think have a single yaml file in the repository which should be fine.

[Levi-Armstrong]

@yvanblanchard I went ahead and created a wiki page where this data can be stored. Can you review and confirm it is correct?

[yvanblanchard]

@yvanblanchard I went ahead and created a wiki page where this data can be stored. Can you review and confirm it is correct?

@Levi-Armstrong The offset to apply is only for J2 axis (opw kinematics / paper convention). The 'reference' robot position usually uses non-null values for both J2 and J3 axes (-90deg and +90deg respectively, in order to get robot looking as a "L" ; see picture of DELMIA V5 software). The KUKA controller (or Siemens NC) uses those offsets in practice. But for opw kin solver, only J2 axis needs an offset (-90deg). Sorry for the confusion.

[yvanblanchard]

Please also find the axes limits for this robot:

J1 min = -185 J1 max = +185

J2 min = -130 J2 max = +20

J3 min = -100 J3 max = +144

J4 min = -350 J4 max = +350

J5 min = -120 J5 max = +120

J6 min = -350 J6 max = +350

[Levi-Armstrong]

Update.