**Minutes of the 4th RIA/NIST Workshop on Open Architecture Control in
Robotics**

Friday, June 8, 2001

DoubleTree Hotel -- O'Hare

Rosemont, IL

This was the fourth meeting in the series of open architecture robotics
workshops sponsored by the Robotic Industries Association (RIA) and the
National Institute of Standards and Technology (NIST). This meeting was
held following the 2001 Robots and Vision Show at the Stevens Convention
Center in Rosemont, IL near O'Hare Airport.

In attendance were Jeff Becker (Weldtech); Fabrice Ciccarelli (Nachi
Robotics); Nicholas Dagalakis, Fred Proctor, and Bill Rippey (NIST);
Dave Faulkner (Cimetrix); Jeff Fryman (RIA); Horst Geiblinger (KEBA);
David Gravel (Ford); Larry Hamilton and Jim Heaton (General Motors);
Bill Kneifel (KUKA Development Labs); JP Rasaiah (Applied Manufacturing
Technologies); and Greg Webb (Motoman).

JP Rasaiah of AMT gave an overview of the RIA R15.07 Simulation and
Off-Line Programming (OLP) committee work. JP co-chairs this committee
with Craig Battles of Boeing. The committee issued the first technical
report in 1995. The intent of R15.07 reports and standards is to define
information shared between robots and simulation/OLP systems, to enable
more accurate simulation of robot positions and cycle times. R15.07 has
expanded this to include peripheral equipment, such as welding and
clamping systems, whose cycle times have a significant impact in the
overall robot cell cycle times.

There is a European standards committee working in this area, termed
"Realistic Robot Simulation" (RRS). The RRS committee includes Delmia,
Keba, Kuka, Nachi, and Technomatics. Membership is paid, and is led by
the IPK at the University of Berlin Fraunhofer Institute. The goal of
RRS is a data repository for robot characteristics, that can be queried
for detailed information such as kinematics, dynamics, and calibration,
but doesn't divulge implementation details that may compromise vendor
intellectual property.

In addition to robot- and peripheral device characteristics,
simulation/OLP systems also require knowledge of the robot programming
language. Currently it is typical for these systems to provide their own
language for programming robot motion and peripheral device commands,
which is then run through simulations to verify robot motion, proper
sequencing, and compute cycle times. These programs are then converted
to programs in robot-specific languages, which are tweaked to run in
production. In the future it is expected that each simulation system
would support the direct programming of robot-specific languages, in
some cases using virtual teach pendants. This would allow the full use
of statements in the robot language, instead of the simulation
language's statements that correspond to a subset common to most robots.
It would also eliminate the translation step. The drawback is that
simulation programs are not portable between robots, an apparently
little-used benefit.

There was an ISO standard for a robot programming language that met
considerable vendor resistance, due to the expected limits it would
impose on innovation. That is, if a vendor added a new robot capability,
it would not be accessible via the standard language and would require a
lengthy standards revision process. This is the usual argument against
standards. Jim Heaton of GM described how this was handled in the
database world. Here, the union-of-functionality approach was taken,
where the set of core functions common across all vendor databases was
standardized. To handle the many vendor-specific features, explicit
statements were included that allowed these to be specified. Use of
these statements prevented direct program portability from one database
to another, but made it obvious where attention should be paid when
doing the porting work. It also served as a start toward documenting
those features that became widely available in an ad hoc manner after
the standard was published, which accelerated the revision process.

Nich Dagalakis of NIST gave an overview of the differences between the
U.S. and ISO robot performance standards, RIA R15.05-1 and -2, and ISO
9283 respectively. Some differences include:

1.  the U.S. standard specifies that tests be done with absolute masses,
    e.g., a 40-kg payload. The ISO standard specifies that tests be done
    with relative masses, e.g., 50% of rated robot payload. The 2^nd^
    edition of the ISO standard does allow the voluntary use of the US
    standard test mass and offset distances.

2.  ISO allows normal testing planes to the command path to be specified
    by the tester. This allows "creative testing," where a robot vendor
    may conduct tests at known good regions. R15.05 specifies the
    testing planes in the tests.

3.  The formulas for reporting accuracy and repeatability are different.
    For the same raw test data, the U.S. calculated accuracy value is
    always larger than the ISO value; the U.S. repeatability is smaller
    than the ISO repeatability. This makes it impossible to compare two
    robots that were tested differently. The U.S. is considering
    adopting the ISO definitions.

4.  Test procedures vary slightly between the two standards.

5.  The test paths in the U.S. standard are representative of paths
    typical in automotive applications. Thus the U.S. feels that they
    yield more realistic measures of robot performance, given that
    automotive applications are the majority. The U.S. hopes that that
    ISO will adopt these test paths.

Jeff Fryman of RIA proposed that the U.S. consider adopting ISO 9283
with a national deviation for the use of automotive-type test paths.
This compromise would simplify the confusion between the two standards
in the short term, and show U.S. good will that may make it more likely
the U.S. national deviations would be incorporated into the next
revision of the ISO standard. The 15.05 committee has remained dormant
since the time the two robot performance standards were approved. Jeff
Fryman has started the process to reactivate it for the purpose of
harmonizing the US and ISO standards.

The group discussed the impact on current robot testing if Jeff's
proposal were followed. Dave Gravel of Ford and Jim Heaton of General
Motors agreed to ask if their companies put R15.05 performance testing
in their contracts. \[Dave Gravel responded in a later email that Ford
does require performance testing according to the R15.05 standard.
General Motors responded that they require the ISO test using the U.S.
example for test paths.\]

Fred Proctor of NIST gave an overview of the RIA/NIST open architecture
workshops and a status report of the R15.04 Communication and
Information committee draft technical report on communication standards.
The R15.04 committee was revived based on the results of the previous
open architecture workshop at FANUC in Rochester Hills, MI in which the
group decided to formalize the "Wave 1" requirements for Ethernet,
TCP/IP, and FTP in either a technical report or standard. The committee
decided that a technical report was the best avenue, and met in April to
write a draft.

Aside from specifying that robot controllers shall have Ethernet,
TCP/IP, and FTP, which were not controversial, the technical report
defined six categories of robot files (e.g., calibration, user data) and
a seventh all-of-the-above category, and specified that the controller
should support upload and download of these file groups. Bill Kneifel of
Kuka Development Labs and Claude Dinsmoor and Jim Huber of FANUC met
earlier in the week and discussed this. Bill reported their discussion
at the meeting. They believed that rather than being part of the
controller, this requirement was more properly for documentation. Robot
vendors would be required to document their robot files according to the
categories, but not put any software in place that would otherwise
automate the upload/download of file categories. Representatives from
the user community responded that this is adequate, and they plan on
writing maintenance scripts themselves that would make any software on
the controller side redundant. As a result, the committee plans on
revising the technical report so that the file categorization is not a
controller requirement but a documentation requirement.

The group moved into discussions of the Wave 1, 2, and 3 protocols. Greg
Webb of Motoman noted that his company's control software team in Japan
had implemented a subset of the full FTP protocol on their controllers,
and that the R15.04 committee may want to specify this subset also,
since compliance to the full FTP specification may be unnecessary. Greg
agreed to report on the FTP exclusions.

Fabrice Ciccarelli of Nachi noted that the BOOTP network boot protocol
uses TFTP (trivial FTP), which in turn uses the unreliable UDP datagram
transport mechanism rather than reliable TCP. Because of this, BOOTP may
not be as suitable for disaster recovery and automated software install.
This will come up during our work revising the technical report to
handle the future waves, which have now been reworked as:

Wave 1: Ethernet with RJ-45 connector, TCP/IP, FTP (perhaps a subset,
depending on Motoman report)

Wave 2: DNS, DHCP, NTP

Wave 3: BOOTP, TFTP, UDP, SNMP/MIB-II, and remaining Wave 3 items (HTTP,
HTML, XML)

Regarding XML, Dave Faulkner, Cimetrix, agreed to circulate the IPC
evolving standard on an XML data vocabulary for component placement
equipment. This will help get us started on Wave 3, which will entail
standards development rather than the standards blessing in Waves 1 and
2.

Bill Kneifel reported on IDA and the IAONA working groups in Europe. IDA
is the Interface for Distributed Automation, which applies Ethernet and
Web technologies to distributed automation. IAONA is the Industrial
Automation Open Networking Alliance, which promotes the use of open
networking in industrial and embedded applications and will recommend
extensions to standards to meet industrial requirements. Clearly we
should be aware of IDA and collaborating with IAONA, and Bill was
drafted to serve as the liaison between our working group and IAONA.
Bill will look into inducing someone from IAONA, possibly the ODVA
Device Net association representative, to participate in the RIA Forum
in November.