Robot version organization and planned breadth of support

[BrettHemes]

@gavanderhoorn

I feel there is some room for improvement regarding robot support package organization. ...but looking at Kuka's taxonomy I realized how many variants there actually are. I assume that the current procedure is to add support on a per-case/request basis but am wondering if we shouldn't plan organizationally now before moving things out of the experimental repo... at the very least we should adopt a strategy and stick with it (currently we are using two, AGILUS family-based and then all of the rest...).

Kuka has a brochure with (all?) of their current offerings with their organizational scheme here. From what I can deduce Kuka's organization is as follows:

1. High-level "size"
   • e.g., small, low/med/high payload, palletizing, linear
2. Type
   • This is the family name (e.g., AGILUS, CYBERTECH, etc.) along with some variant and/or max payload designations
3. Rated Payload
   • The payload in kg of the robot version
   • Note that there is some overlap here... for example, the KR 600 FORTEC type contains the KR 420, 510, and 600 payloads and the KR 500 FORTEC type contains the KR 340, 420, and 500 payloads.
4. Reach
   • The reach in mm of the robot version

I am not sure the above makes the most sense and was thinking about using the family name (if it exists) and then breaking out the versions in the meshes folder. One solution could be like the following where I have used the LBR iiwa and AGILUS families as examples:

• lbr_iiwa
  • launch
  • load_lbr_iiwa_14_r820.launch
  • load_lbr_iiwa_7_r800.launch
  • meshes
  • iiwa_common
  • r800
  • r820
• kr_16
• kr_20
• kr_30
• kr_60
• kr_agilus
  • launch
  • load_kr10r1100sixx.launch
  • load_kr10r900sixx.launch
  • load_kr6r700sixx.launch
  • load_kr6r900sixx.launch
  • meshes
  • agilus_common
  • r1100
  • r700
  • r900
• kr_cybertech
• kr_quantec
• kr_fortec

Benefits:

1. Mesh reuse to avoid large repo size
2. Less top-level folders (vs one-per-offering)

Some issues:

1. Knowing what geometries are shared Ideally what we would gain most is a hierarchical sorting of meshes that promotes sharing within families... but knowing if a particular geometry belongs in the "common" folder or in a reach-specific folder version is not straightforward and requires good Kuka family knowledge
2. Deep folder structure and issues with payload/reach splits.
   • Do we split based on reach or payload?
     • It seems for the AGILUS series the payloads have no effect and the geometry difference are purely reach-based). Maybe this is the reason for the overlapping family breakdowns mentioned above (e.g., KR 400 FORTEC vs KR 600 FORTEC)? Not sure...
   • Does the common folder hold all file common to any two (or more) versions?
   • ...
3. Maintenance
   • Future changes result in having to change all respective launch files (this could be error-prone)

I like the AGILUS repo folder approach but is this worth it to do across the whole repo? Ultimately I think we should pick a single strategy (i.e., flat OR family-based hierarchy) before moving out of experimental but am not sure about the best way to go. Ideas are welcome :)

[gavanderhoorn]

Just a quick comment: the current distribution of variants over the support pkgs was setup exactly to put variants of the same robot series in a single package. This is similar to how it's done in ROS-I for all other robot mfgs. See Naming conventions for ABB robots in ROS-Industrial for a REP that makes this explicit for ABB products.

Whether we've succeeded in this repository I'm not sure: I'm not a KUKA expert, and got involved with this repository quite late, after the clustering according to KR nnn had already been done.

The goal of such clustering (and the existence of robot support packages, instead of a _description pkg for each variant) is to avoid introducing too many pkgs - and to exploit potential sharing of resources, such as meshes, as you noted.

[gavanderhoorn]

I assume that the current procedure is to add support on a per-case/request basis

if with this you mean that we only add support for variants (and create the corresponding support pkg for the series) if/when a user contributes it (including us), then yes, that is how it works.

If the clustering of variants is done right, this approach should work, as a user needing support for a new variant would just have to contribute some files to an existing package (or, in the case of a completely unsupported series, contribute the support package as well).

but am wondering if we shouldn't plan organizationally now before moving things out of the experimental repo...

As far as I was aware we had a strategy, but if there is a better one for KUKA products, I'm all for updating the pkgs to match something better.

What I don't think is feasible however is to setup some sort of plan for incrementally adding support for all series and variants. That doesn't make sense to me, and would just mean a lot of work, with potentially little gain. Adding a new variant is an hours work, at most (depending on the source material).

at the very least we should adopt a strategy and stick with it (currently we are using two, AGILUS family-based and then all of the rest...).

I'm not sure I understand you: all variants are clustered according to KR nnn. kuka_kr6_support and kuka_kr10_support contain all Agilus variants we currently support. It does mean that not all Agilus variants may be found in the same support package.

[gavanderhoorn]

In the end clustering product variants like this comes down to three things:

1. does the mfg define some sort of product hierarchy (and can we use that)
2. which parts of product identifiers do people exposed to that hierarchy actually use to identify variants
3. how much (apparent) influence do product identifier parts/tokens have on the actual product specifications

Ad 1 seems clear: see the PDF you link

Ad 2 is not so clear for me: as a (relative) outsider, I see all KUKA robot product names starting with KUKA KR nnn. The Quantec, Fortec etc is at the end. How much difference is there between a KUKA KR nnn Ryyyy Quantec and a the same as a Fortec (I haven't looked at the PDF yet, so perhaps this is a stupid question as this can never happen, but still)?

Ad 3 is more complicated: 'influence' here is not just 'in the real world', but also wrt ROS interaction/use with/of the resulting packages. Example: there are no motion planners right now in ROS that use information about max payload, or adjust planning parameters based on dynamic properties of robots (other than perhaps max acceleration). In the case of the ABB REP I linked earlier fi, this has led to payload not being used as a branching point in variant identification (see the Alternatives section). The xacros still have all the information, and if/when properties ignored right now do become important, additional variants can be added, but until then, some variants can be supported using the models of others.

As I noted earlier, I'm not intimately familiar with all of KUKAs offerings, so that makes it difficult for me to gauge how well we can use this for clustering KUKA variants.

[gavanderhoorn]

Finally (for now): the planned support in terms of robot support packages would be: all variants of all series, but only if support for a specific variant is requested or contributed.

[gavanderhoorn]

@gavanderhoorn wrote:

As I noted earlier, I'm not intimately familiar with all of KUKAs offerings, so that makes it difficult for me to gauge how well we can use this for clustering KUKA variants.

I'd actually very much welcome input from the community here, in addition to @BrettHemes'.

[BrettHemes]

Just to be clear, I actually don't have a problem with the current approach. There seemed to be some concern previously about the repository's current size, however, and I thought a family-based hierarchy might help or at least be worth discussing. As an example the KR 10 R900 sixx has the same geometry as the KR 6 R900 sixx but in the current organization they would exist in different packages. It seems however that maybe it is not the best approach... :)

What I don't think is feasible however is to setup some sort of plan for incrementally adding support for all series and variants. That doesn't make sense to me, and would just mean a lot of work, with potentially little gain. Adding a new variant is an hours work, at most (depending on the source material).

Wasn't implying that we do this.... an hour is fast, especially on versions with non-convex-hull-friendly link geometries.

at the very least we should adopt a strategy and stick with it (currently we are using two, AGILUS family-based and then all of the rest...).

I'm not sure I understand you: all variants are clustered according to KR nnn. kuka_kr6_support and kuka_kr10_support contain all Agilus variants we currently support. It does mean that not all Agilus variants may be found in the same support package.

I don't know what I was thinking here either ???

From the ABB naming rep:

Finally, a simpler approach would be to include both payload and reach, and then to document the fact that payload-variant model X1 should be used in all cases where payload-variant model X2 is actually needed. The same approach can be used for reach-variant models with identical payloads. This avoids all potential ambiguity, stays as close as possible to ABB Robotic's product naming and also allows to completely avoid duplicating any models or related support infrastructure.

This seems relevant considering we are naming with payload AND range. In the context of the KR 6/10 R900 example is this suggesting we note somewhere the equivalence?

[gavanderhoorn]

@BrettHemes wrote:

There seemed to be some concern previously about the repository's current size, however, and I thought a family-based hierarchy might help or at least be worth discussing. As an example the KR 10 R900 sixx has the same geometry as the KR 6 R900 sixx but in the current organization they would exist in different packages. It seems however that maybe it is not the best approach... :)

I'm always up for a discussion of development practices, whether current or best. If you feel something can and/or should be changed/improved, I welcome input.

re: agilus: yes, that seems to be a non-optimal clustering that we should perhaps rethink.

What I don't think is feasible however is to setup some sort of plan for incrementally adding support for all series and variants. That doesn't make sense to me, and would just mean a lot of work, with potentially little gain. Adding a new variant is an hours work, at most (depending on the source material).

Wasn't implying that we do this....

Ok. I just wanted to be sure I understood you.

an hour is fast, especially on versions with non-convex-hull-friendly link geometries.

It depends a bit on your experience with doing this as well :) I can do a Fanuc variant in about an hour, if not faster. But then I do depend on Fanuc providing me with a SolidWorks or similar model.

I don't know what I was thinking here either ???

well, if you don't know, I don't know how I'm supposed to know ;)

From the ABB naming rep:

Finally, a simpler approach would be to include both payload and reach, and then to document the fact that payload-variant model X1 should be used in all cases where payload-variant model X2 is actually needed. The same approach can be used for reach-variant models with identical payloads. This avoids all potential ambiguity, stays as close as possible to ABB Robotic's product naming and also allows to completely avoid duplicating any models or related support infrastructure.

This seems relevant considering we are naming with payload AND range. In the context of the KR 6/10 R900 example is this suggesting we note somewhere the equivalence?

Yes. If they are indeed identical apart from the payload spec, then we should remove one and note that the remaining one should be used.

Looking at the PDF you linked, it would seem that could make sense for at least the Agilus series.

[gavanderhoorn]

Have you thought about this more @BrettHemes?

[BrettHemes]

I don't know what the "right" answer is, and there probably isn't any just one. I do now however think that my proposal in the initial comment is most likely not in that group of right answers :smile:

Shall we close this then?

[gavanderhoorn]

@BrettHemes wrote:

I don't know what the "right" answer is, and there probably isn't any just one. I do now however think that my proposal in the initial comment is most likely not in that group of right answers :smile:

I'm not so sure about that.

If KUKA groups their robot models differently from how we are doing it, it might make sense to re-evaluate our approach. Your suggestion makes sense. We just need to figure out whether it makes enough sense to reorganise the repository.

[fmauch]

I also think that from a package side of view having an agilus package makes sense. Especially since they share meshes and even the complete urdf structure (for the r900 at least).

Sharing meshes across packages or even xacro-macros as in #134 is very confusing I think.

[simonschmeisser]

Yes. If they are indeed identical apart from the payload spec, then we should remove one and note that the remaining one should be used.

I'm not sure I agree here, I would prefer having two (or n) description packages, one for each name and then just reusing meshes and kinematics as much as possible. (but maybe that is just what you meant ...)

[simonschmeisser]

In https://github.com/ros-industrial/kuka_experimental/pull/146 I posed the question whether to separate series or not. We currently have a request for a new Kuka Iontec KR70R2100 robot and I'm not sure whether it should be packaged as kuka_iontec_kr70_support or kuka_kr70_support

Kuka separates those lines/series (cybertec vs Iontec vs classical agilus) and they share not much besides payload that's why I'm in favor of including it ... but I'm fine either way