Methods "search," "bind" and "bind_any" may be extended for allocating
multiple components at once avoiding race condition.

Atomic allocation of multiple HRI components requires API changes.

To achieve atomic allocation of multiple HRI components, a new API such as bind_all() may be required. Such a change should be discussed in major update (RoIS 2.0).

"Condition" is used in many interfaces and method, but it is difficult
to implement without example.

*Four examples of "Conditions" are added as Annex E to illustrate how to implement "Condition." *

As "Conditions" are used in many interfaces and methods, there are no particular examples in the previous revision of RoIS. Four examples of "Conditions" are added to illustrate how to implement "Condition."

Contents of the attached file (RoIS12-2-AnnexE.odt) is added at the last of specification as a new section named "Annex E: Examples of Conditions."

Dependencies (Requisite conditions) among HRI Components should be
defined in HRI Profile.

Components' dependency will be addressed in conjunction with simultaneous allocation of multiple components in major update.

If a component requires several sub components to work, it is desirable such subcomponents are bound automatically when the top-level component is bound. Such a solution (at least internally) requires API extension to bind multiple components at once as discussed in ROIS12-3. This issue is proposed to be merged into ROIS12-3, that is proposed to be deferred to RoIS 2.0 major update.

Methods "search," "bind" and "bind_any" may be extended for allocating
multiple components at once avoiding race condition.

This issue should be deferred to the future revision.

This issue is not discussed thoroughly and there are several opinions to resolve this so I propose to defer the issue to the future revision.

"Condition" is used in many interfaces and method, but it is difficult
to implement without example.

This issue should be deferred to the future revision.

This issue is not discussed thoroughly and there are several opinions to resolve this so I propose to defer the issue to the future revision.

Dependencies (Requisite conditions) among HRI Components should be
defined in HRI Profile.

This issue should be deferred to the future revision.

This issue is not discussed thoroughly and there are several opinions to resolve this. Though a resolution is partially described in a new example of Wheel Chair Robot in C.4 but
I propose to defer the issue to the future revision.

In Table 7.36 “person_localization”( and other localization components), parameters of sensing-cycle and/or resolution (minimum position difference which sensor can distinguish) are required. These parameters should be added for (optional ) get_parameter. In addition, Detection-cycle (multiple of sensing-cycle) and Detection-difference (larger than resolution) may be set by set_parameter.

Add command_method entries for set_parameter and get_parameter to the table 7.36, and also add two parameters detection-threshold and minimum-interval.

In Table 7.34 “System Information”, “robot ref(List<RoIS_Identifier>)” is required for “robot_position”, same as person position data in "Person localization"
In addition, ”position_data” should be List<Data>.

A system may operate several robots in an HRI Engine when the engine has sub HRI Engines or it controls multiple robots. In this case, each robot position should be distinguished by robot's ID (i.e. robot ref). So the ordered lists of robot ref and position are returned as result parameters

Miss speling in ATR (missing 'd').
Several organization should be added such as Korean Robot Association,
Future Robot Co., Ltd., University of Tokyo an Hitachi.

As these organizations supported drafting a document, I'd like to add them to the acknowledgment list

In p. 46, line 3, Table number (7.31) is missing.

TYPO. Should be added.

In Figure 17, “RoIS_Common” should be removed because System Information component does not include RoIS_Common messages.

RoIS_Common should be removed

In Table 7.30 “HRI_Engine_Profile”, parameters of HRI engine is defined in this profile. However, these parameter should be defined in the Component Profile of “System Information Component” for this Engine. Therefore, "parameter" definitions in HRI engine profile should be removed.

Remove the definition of "parameter" from the profile

"HRI Engine," "HRI Components" and other terms defined in Section 4 should be
unified as in the definition table.

For example, "engine" and "component" are general words while the terms "HRI Engine" and "HRI Component" are specific to this document. To distinguish them, the notation of specific terms will be unified as "HRI Engine," "HRI Component," etc. as in Section 4.

In Table 7.2 (p.31), the word "Enghien" should be "Engine." (in the "connect" row)

TYPO. Should be corrected.

In 3.1 “Normative References”, ISO19143 (Geographic information - Filter encoding) should be added in the list.
This reference is referred for QueryExpression.

The reference should be added

In Table 7.44 “speech synthesis”, data type of the argument and result parameter of “character” should be “RoIS_Identifier”.

"Character" in this context indicates male, female, adult, child, etc. and the available character types depend on a speech synthesis component. To distinguish and designate a character type in Command Message (set_parameter) and Query Message (get_parameter), it is better to use identifiers assigned to each character types than strings.

P.23 line 3, “each type of error” should be corrected to “each error”.

This is a grammatical error so it should be corrected.
Revised Text:
In 7.4.1.1.2 System Error Notification, “each type of error” should be replaced with “each error”.

It is required to consider methods about notification when the engine or component profile changed.
"receive_error" method is usable for this purpose.
“PROFILE_CHANGED( tentative name )” should be added in the enumeration of "Error Type" (Table 7.7).
However, this status is not an error, so "receive_error" and "Error Type" should be renamed

Disposition: See issue 17139 for disposition

Implementing "Command Unit List" is very difficult. It should be simplified

Difficulty of the originally proposed Command Unit List resides in its structure which allows hierarchical parallel command sequences (i.e. parallel command sequences in a parallel command sequence). To simplify the structure, modify it as follows:
1. Rename CommandUnitList to CommandUnitSequence.
2. Make CommandUnit class abstract then derive both CommandMessage and ConcurrentCommands from it.
3. A ConcurrentCommands should hold Branches instead of CommandUnits, then each Branch should hold a sequence of CommandMessages instead of CommandUnit.
By this change, CommandUnitSequence can hold a sequence of CommandUnit and the units are executed sequentially in their order. Some unit in the sequence can be a ConcurrentCommands-class object which holds Branch-class objects and each Branch is executed in parallel. This resolution prohibits a hierarchical parallel command sequence because the Branch-class object cannot hold any ConcurrentCommands objects.

The structure of message-related classes should be organized
concerning issues #16560, #16923 and #16931.

Merged with #16931.
Rename the methods receive_event () and receive_error () to notify_event() and notify_exception() respectively.
Following topics are discussed and decided not to change in this revision. Discussion should be deferred to the next revision.
• A base class for all Messages can be defined.
• In PIM, for types of messages should be separated.
• In Table 7.7, rename the “Error Type” to “RoIS Exception Type.”

Condition of ”get_error_detail (Table 7.2),” “get_command_result (Table 7.3),” and “get_event_detail (Table 7.5)” can be omitted because these method can identify their message by message_id (such as command_id, event_id and error_id).

No Data Available

In Section 4, Order of HRI Engine and Service Application should be changed

All the entries in Terms and Definitions table are arranged alphabetically for simplicity (i.e. not to concern about forward/backward references).

In Section 4, definition of HRI Engine is ambiguous

No Data Available

In 7.4.3 “Message Data”, there is no definition of “Error Message” for “get_error_detail” method, and there is no profile for the result parameters for this message in 7.5.2 7.5.3.

Resolution for issue #16560 is merged with this issue.
Add definition of “Error Message” as section 7.4.3.6 and table 7.24.
Add definition of “Error Detail Message” as section 7.4.3.7 and table 7.25.
Remove definition of “Event Message Profile” in section 7.5.3 because “Event Message” has no extensible element so it does not require any profile definition.
Add definition of “Command Result Message Profile”, “Event Detail Message Profile” and “Error Detail Message Profile” in section 7.5.3 as table 7.28, 7.31 and 7.32, respectively.
Add both message profile classes to Figure 16.

Relationship with ROS, RTC should be clarified

Add description in Overview section.

In Table 7.29 “Component Profile”, occurrence of sub_component is N to avoid double definition. For example, if the each sub component include “RoIS_Common”, the main component may include the two same common messages defined in RoIS_Common.
Therefore, the occurence should be "1".

The occurrence of sub_component in HRI Component Profile should be changed as 1.

In 7.5.2 there is no profile for the result parameters related with 7.4.3.2

Disposition: See issue #16923 for disposition

Interfaces between the Service Application and HRI Engine had been
changed when we submitted the revised submission but the diagram had not
updated upon submission.

I also found TYPOs and grammatical mistakes so I correct them when I
submit the FTF report.

Update the diagram to conform to the latest interface structure

ATR and AIST should be removed from copyright holders.

These organizations were added by misunderstanding. So I propose removing them.

There are two types of parameters to be distinguished.
For example, "language" and "character" in speech synthesis are stable ones,
but on the other hand, "speech_text" and "volume" are instant ones.
Engine or Component should re-transmit or interpret them correctly.

No Data Available