Skip to content

Latest commit

 

History

History
257 lines (169 loc) · 11.6 KB

rep-I0007.rst

File metadata and controls

257 lines (169 loc) · 11.6 KB
Raw
REP: I0007
Title: Naming conventions for ABB robots in ROS-Industrial
Author: G.A. vd. Hoorn <[email protected]>
Status: Active
Type: Process
Content-Type: text/x-rst
Created: 9-Mar-2017
Post-History: 9-Mar-2017

Outline

  1. Abstract
  2. Motivation
  3. Definitions
  4. Assumptions
  5. Conversion of product names
  6. ABB ROS name template
  7. Names in namespaced contexts
  8. Examples
    1. ABB IRB 1600ID-4/1.55
    2. ABB IRB 14000-0.5/0.5 (YuMi)
    3. ABB IRBT 4004
  9. Alternatives
  10. References
  11. Revision History
  12. Copyright

Abstract

Resource and artefact naming in ROS-Industrial is based upon the rules defined by the greater ROS community. On-top of this, to ensure consistency and uniformity, the ROS-Industrial community has defined additional naming conventions for use in specific contexts such as robot support and MoveIt configuration packages.

This REP extends those conventions with rules specific to ABB robots and related hardware and documents how to transform product names into legal ROS resource names. Additionally, it provides some guidelines on how such names should be used within ROS and ROS-Industrial packages.

Motivation

Names given by ABB Robotics to their products cannot be directly used as names in ROS or ROS-Industrial contexts. Among other things, whitespace is not allowed, punctuation characters are illegal and certain special characters (such as the forward slash) are reserved and have a special function in ROS [3]. There is thus a clear need to convert ABB product names into legal ROS resource names and this REP provides the rules used in ROS-Industrial to do that.

The following are the requirements and constraints that guided the design of the conversion rules:

  1. must be legal names in accordance with ROS resource naming guidelines [3]
  2. converted names must resemble the original names as much as possible
  3. must be as recognisable as possible for users with experience with ABB products
  4. names must be unambiguous and should uniquely identify a particular robot series, variant or other piece of related hardware
  5. must not result in overly verbose (ie: long) names

Definitions

Robot Series
A grouping of (industrial) robots produced by a single manufacturer according to a set of shared characteristics, such as minimum and maximum payload, arm reach or intended use. Example: the ABB IRB 1600 series of industrial robots.
Robot Variant
One specific member of a robot series, with specific choices for the characteristics that make this robot a member of the series. Example: the ABB IRB 1600ID-4/1.55 variant.

Assumptions

  1. The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in RFC-2119 [1].
  2. In addition to what is described in this REP, naming of topics, services, actions, parameters, files, directories and other artefacts shall comply with base ROS naming guidelines as described in [3].

Conversion of product names

Names of ABB Robotics' products cannot be used to name ROS resources, as they violate the ROS naming rules [3]. Such names must first be converted into valid resource names by use of the following steps:

  1. convert all characters to lowercase
  2. replace all whitespace with underscores ('_'), making sure to never introduce two consecutive underscores
  3. remove the underscore between irb and the series number

If the product name includes a maximum handling capacity and reach (ie: names a variant):

  1. replace the dash ('-') separating the payload from the series number with an underscore
  2. replace the forward slash ('/') separating the reach from the payload with an underscore
  3. convert the reach to centimetres

If the payload is below one (1) kilogram:

  1. multiply the payload by ten (10)
  2. truncate the result
  3. prefix the result with a zero (0)

The resulting string should now be a valid ROS resource name, containing no whitespace, no punctuation characters other than underscores and lowercase only.

ABB ROS name template

The following are the constituent parts of an ABB Robotics' product name after conversion to a ROS compatible name:

abb_irbSERIES[MODIFIER]_PAYLOAD_REACH

Here:

  • SERIES is a numeric string representing the product series number
  • MODIFIER is an optional alphanumeric string containing a code that identifies which particular variant of the series this is
  • PAYLOAD is a numeric string that encodes the maximum handling capacity in kilograms (see Conversion of product names for dealing with payloads smaller than one kilogram)
  • REACH is a numeric string representing the reach of the robot in centimetres

Note that not all parts are required in a name as a particular robot series may not have designated variants. For such models, MODIFIER for instance should be omitted.

Names in namespaced contexts

In contexts where the name of the manufacturer is already part of the fully qualified path to an artefact, such a prefix may not be added again to the name of said artefact.

Examples of this would be rospack commands (such as xacro find) and package:// URIs to artefacts within ROS-Industrial robot support packages: in accordance with [4], such packages already include the name of the manufacturer as a prefix, making the same prefix on files in such packages superfluous.

Automatically generated artefacts (such as those in MoveIt! packages) are exempt from this rule.

Examples

This section provides three examples of package and artefact naming according to the conventions described in the previous sections.

ABB IRB 1600ID-4/1.55

This is the ID (Integrated Dressing) variant of the IRB 1600 series, with a maximum supported handling capacity of 4 kg and a reach of 1.55 metres [5].

Conversion of product name:

Original  Converted
-------------------
     ABB        abb
     IRB        irb
    1600       1600
      ID         id
       4          4
    1.55        155

Note the conversion of the reach from 1.55 metres into 155 centimetres.

Name in non-namespaced contexts: abb_irb1600id_4_155.

Name in namespaced contexts: irb1600id_4_155.

ABB IRB 14000-0.5/0.5 (YuMi)

A model in the IRB 14000 series, with a handling capacity of 0.5 kg and a maximum reach of 0.5 metres [6].

Conversion of product name:

Original  Converted
-------------------
     ABB        abb
     IRB        irb
   14000      14000
     0.5         05
     0.5         50

Note the 0-prefix on the payload element to encode the below-one-kilogram handling capacity.

Name in non-namespaced contexts: abb_irb14000_05_50.

Name in namespaced contexts: irb14000_05_50.

ABB IRBT 4004

This is the 4004 variant of the X004 series of linear tracks [7].

Conversion of product name:

Original  Converted
-------------------
     ABB        abb
    IRBT       irbt
    4004       4004

Name in non-namespaced contexts: abb_irbt4004.

Name in namespaced contexts: irbt4004.

Alternatives

This section reasons about alternative conversion rules and why they were rejected.

Ignoring payload

For many robot series, the largest differences for variants are in reach and handling capacity (or payload), with variations having higher payloads but identical reaches, joint position and joint velocity limits. Naming in ROS and ROS-Industrial is typically done in such a way that prefixes and suffixes are used to make them more specific [4], making it possible to group related entities by exploiting late branching in names (ie: removing suffixes). With PAYLOAD before REACH, naming of robots which differ only in maximum supported payload can't make use of this (to avoid duplication of files in support packages fi) as REACH is neither a suffix nor a prefix. REACH could be placed before PAYLOAD, but this does not address the issue, as now variants which differ in reach but not in maximum payload would still receive non-overlapping names.

One alternative approach considered was to ignore payload altogether and only include the maximum reach in converted names. This would resolve the issue described above (as only reach-variants of robots would have to be separately modelled) and would not have any real impact on the (re-)usability of support packages, as payloads (and to a large extent: dynamics) are not currently taken into account by any of the drivers or default motion planners in use in ROS and ROS-Industrial.

While this approach would perhaps make naming slightly easier it was rejected because of three main reasons: it reduces future reusability of support packages, introduces ambiguity for users (not) already familiar with ABB Robotics product naming and reuse of models for particular payload-variants can be equally well addressed with documentation.

Future reuseability is reduced because improved drivers and planners are likely to start taking payload information into account. Not modelling payloads would require that information to be added retrospectively to all supported packages.

Further, ignoring payload could actually increase ambiguity, both to users familiar with ABB product names and those that are not. For the former it would be a deviation from ABB's regular naming (which always includes both payload and reach), while the latter would need to depend on documentation to figure out that what is included in the name is the reach, and not the payload.

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.

References

[1]Key words for use in RFCs to Indicate Requirement Levels, on-line, retrieved 24 January 2017 (https://tools.ietf.org/html/rfc2119)
[2]Define ABB specific naming rules/guidelines, ros-industrial/abb issue tracker, on-line, retrieved 24 January 2017 (ros-industrial/abb#75)
[3](1, 2, 3, 4) Names, ROS Wiki, on-line, retrieved 24 January 2017 (http://wiki.ros.org/Names)
[4](1, 2) REP-144: ROS Package Naming, 28 January 2015, ROS Enhancement Proposal, on-line, retrieved 24 January 2017 (http://www.ros.org/reps/rep-0144.html)
[5]IRB 1660ID, ROB0337EN A, Sept 2016, ABB Robotics, on-line, retrieved 24 January 2017 (https://library.e.abb.com/public/2adfb38d7fbd4dccab7f9b1c153887bb/ROB0337EN_A_IRB_1660ID.pdf)
[6]IRB 14000, ROB0317EN, April 2015, ABB Robotics, on-line, retrieved 24 January 2017 (https://library.e.abb.com/public/55362813a776464383279a729b715c89/ROB0317EN_YuMi.pdf)
[7]IRBT 4004/6004/7004, PR10335EN R3, Aug 2016, ABB Robotics, on-line, retrieved 24 January 2017 (https://library.e.abb.com/public/890958c5e98649a28a1ceba0f377938d/PR10335EN_R3_IRBT_X004_trackmotion.pdf)

Revision History

2017-03-09  Initial revision

Copyright

This document has been placed in the public domain.