Relationship among Robotic Service and Service Robot including the viewpoint of Robotic Interaction Service to be described in the overview section.
The current document already defines the events detected from environments by functional components and the actions caused in the environments by functional components.
However, there is a lack of definitions of vocabulary to describe the events notified to services and the actions requested from services.
Therefore, it is currently impossible to describe relationships between the environment, components, and services.
(This issue is identical to ROSO11-2, and the resolution in RoSO 1.1 RTF is expected to be reflected into RoIS 2.0 FTF.)
Relationships between function/component and event/action are not described.
To describe them, vocabularies such as 'detects' and 'causes' have to be defined.
(This issue is identical to ROSO11-3, and the resolution in RoSO 1.1 RTF is expected to be reflected into RoIS 2.0 FTF.)
Paragraphs in p.10 and p.36 are identical.
The duplicated one in p.36 should be simplified and moved into following four sections.
In Table 8.48, there is one he/she expression in the second sentence.
For diversity perspective, it should be replaced with "user" like the other parts.
Titles of Table 8.39 and 8.40 are different from those in their rdfs:label columns. They should be fixed.
It is hard to understand the steps for HRI Engine to choose appropriate sub HRI Engine.
There should be more specific explanation.
There is a lack of definitions of vocabularies to define parameters of RoIS component functions and it causes insufficience in some of the use cases.
More vocabularies should be defined.
(This issue is identical to ROSO11-4, and the resolution in RoSO 1.1 RTF is expected to be reflected into RoIS 2.0 FTF.)
As 'hasTimeLimit' is defined in RoSO 1.0 FTF, descriptions of RoIS components to be updated with it.
The description of "person detection" component says "Detects number of people", but Figure 8.14 shows the flow that firstly returns if there are people.
There is a conflict between them.
It may be a good idea to review the definition of "navigation".
Considering the expansion of the features of service robots of these days, the current definition of "navigation" in this document is too limited.
This document only defines navigation as navigating another agent to the indicated goal point. These days, there are some other "navigation" tasks that robots can do.
Some arrows in Figure B.1 are not aligned to the destination boxes.
"Platform Specific Model (PSM)" is located in the chapter 7 "Platform Independent Model (PIM)" currently.
PSM should be located at the same level with PIM.
Move the description of PSMs in Chapter 7.7 to a new chapter.
Description of C++, CORBA and XML PSMs in Chapter 7.7 were moved to a new chapter 9 (created).
No update of its contents was required.
The specification starts with an “Overview” section, that has useful information to understand the specification. However it is placed before Clause 1 “Scope” and therefore a bit misplaced, from a standards document layout point of view. It would be good if a follow-on RTF would place this material into a more appropriate location, preferably as a new, informative Clause 7 and move the existing Clauses 7 and higher up by one number.
The new Clause 7 should then be combined with the material from the existing Clause 7.2, which has good explanations, but is a bit misplaced in the middle of normative message and interface specifications.
A new chapter 'RoIS Framework' was created and merge 'Overview' and (old) Section 7.2 were merged into the chapter.
The overview and the structure of RoIS Framework were placed in the 'Overview' section and Section 7.2 in RoIS 1.1 so we merge them into one place (a chapter).
We create a new chapter 7 entitled 'RoIS Framework' and merge the overview and the structure of RoIS Framework into this new chapter.
As a result, the (old) Chapter 7 will be renumbered to Chapter 8.
The specification would benefit in the future from an overview Package and UML Class diagram [class names only].
Two extra layers of Packages named “RoIS” around the Packages containing real model elements. While strictly speaking not wrong, those extra onion layers look a bit odd.
A new section is added for package overview and the model is updated.
In accordance with the resolution of issue 12-5, the package structure is added as a new section "8.2 Package structure” with a package diagram as below.
The model is also updated with the attached xml file that do not contain the extra RoIS layer.
It is referenced as http://www.omg.org/spec/RoIS/20171201/UML_Model.xmi.
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.
The specification would benefit in the future from an overview Package and UML Class diagram [class names only].
Two extra layers of Packages named “RoIS” around the Packages containing real model elements. While strictly speaking not wrong, those extra onion layers look a bit odd.
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
The specification starts with an “Overview” section, that has useful information to understand the specification. However it is placed before Clause 1 “Scope” and therefore a bit misplaced, from a standards document layout point of view. It would be good if a follow-on RTF would place this material into a more appropriate location, preferably as a new, informative Clause 7 and move the existing Clauses 7 and higher up by one number.
The new Clause 7 should then be combined with the material from the existing Clause 7.2, which has good explanations, but is a bit misplaced in the middle of normative message and interface specifications.
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
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.
Since the contribution from ATR was done under a research project of Ministry of Internal Affairs and Communication, Japan, both ATR and MIC should be listed in the supported by part of Acknowledgment.
Add an organization to Acknowledgment.
Since the contribution from ATR was done under a research project of Ministry of Internal Affairs and Communications, Japan, both ATR and MIC should be listed in the supported by part of Acknowledgment.
CORBA PSM fails to compile. It lacks proper typedef to imported types. It does not include RLS (and ISO19XXX) definitions as well as C++ PSM.
CORBA PSM fails to compile. It should implement data types imported from RLS 1.1.
Just as same as C++ PSM (issue ROIS11-39), CORBA PSM does not contain definitions of RLS (and ISO19XXX) related elements. The IDL files also lacks proper typedef to imported types.
As a solution RLS related element is implemented in RoIS_HRI.idl. Other IDL files modified to include RoIS_Common.idl (and indirectly RoIS_HRI.idl) to import corresponding types and then typedef definitions are added in each module.
RLS related definitions are included in five files: RoIS_Face_Localization.idl, RoIS_Navigation.idl, RoIS_Person_Localization.idl, RoIS_Sound_Localization.idl, RoIS_System_Information.idl.
Typedef of 'RoLo_DataSeq' is added to each module to define corresponding variables.
In addition, as a trivial revision, unnecessary 'public' label is removed from RoIS_Person_Identification.idl.
Even though RLS machine readable files are imported, RoIS C++ PSM is not able to compile because it does not contain ISO19XXX definitions.
C++ PSM should implement data types imported from RLS 1.1.
There are no definition of RLS 1.1 related elements in RoIS 1.1 C++ PSM. The machine consumable files are therefore incomplete to be compiled. Even though RLS machine readable files are imported, they does not implement ISO19XXX definitions.
As a possible and concise solution, the RLS-related definition(s) are implemented in RoIS_HRI.hpp, which is included by ALL other header files.
In addition to this issue, editorial fixes to RoIS11-31 are also included in the attachment file. #ifndef, #define directives were capitalized so modified them into lower-case.
When validating FaceDetection.xml against the XML Schema dtc/15-06-11.xsd, a list of errors are reported.
Component Profiles are not valid against the XML Schema dtc/15-06-11.xsd.
When validating FaceDetection.xml against the XML Schema dtc/15-06-11.xsd, a list of errors are reported.
The section 7.7.3 XML PSM is newlly added in this RTF according to the issue RoIS11-19. Since this issue is also applied to the newly added section, the modifications do not appear in the specification changebar file.
The set of C++ header files included lack proper include protection. [From a procedural point of view this is considered as an editorial correction since their technical content is identical with the files resulting from the revision process.]
Also, each C++ header specifies its own namespace, which reflects the name of the header. While this is not wrong, it would be advisable to make those namespaces more unique, for example with a “rois” prefix, or enclose them within an outer rois namespace. [this is a suggestion for the future and not an error in the current revision]
C++/CORBA PSMs lack Include protection.
The set of C++ header files included lack proper include protection. From a procedural point of view this is considered as an editorial correction since their technical content is identical with the files resulting from the revision process.
In RoISCommon.xml (and other xml files) are empty comments for "Event Message", "Error Message" and "Parameter". [This is not per se wrong but cosmetically not so pleasing. If you choose to remove them, that would be editorial]
Empty comments in XML files should be removed.
In RoISCommon.xml (and other xml files) are empty comments for "Event Message", "Error Message" and "Parameter". This is not per se wrong but cosmetically not so pleasing. Removal of them would be editorial.
The section 7.7.3 XML PSM is newlly added in this RTF according to the issue RoIS11-19. Since this issue is also applied to the newly added section, the modifications do not appear in the specification changebar file.
RoIS 1.0 refers to UML 2.3 as a normative reference. It should refer to UML 2.4.1 (dated version 20110701).
Reference to UML specification should be updated from 2.3 to 2.4.1.
RoIS 1.0 refers to UML 2.3 as a normative reference. It should refer to UML 2.4.1 (dated version 20110701).
There are several errors in CORBA IDL in Section 7.7.2 which should be corrected.
These should be corrected to conform to CORBA standard.
Correct errors in CORBA IDL files
CORBA PSM (CORBA IDL files) in Section 7.7.2 is corrected as follows:
There are errors in C++ header files which should be corrected.
These should be corrected so that the header files can be compiled.
Correct errors in C++ headers
C++ PSM (C++ headers) in Section 7.7.1 is corrected as follows:
Robotic Localization Service (RLS) was revised after RoIS 1.0 was submitted so its reference is changed from 1.0 to 1.1.
Reference URLs in C++ header files are also changed accordingly.
Reference to RLS including C++ header files are updated from 1.0 to 1.1
To follow the revision of Robotic Localization Service (RLS), normative reference and reference URLs in C++ header files are updated.
Definition of timestamp refers to non normative document [W3C-DT] in section 7.6.
It should refer to [ISO8601].
*Type 'DateTime [W3C-DT]' changed to 'DateTime[ISO8601]'. *
Definition of time stamp refers to non normative document [W3C-DT] in section 7.4.2.2, 7.4.3.4, 7.4.3.6 and through out the section 7.6. It should refer to [ISO8601].
This change affects: Table 7.6 (in section 7.4.2.2), Table 7.21 (in section 7.4.3.4), Table 7.23 (in section 7.4.3.6) and Table 7.37 through 7.46 (in section 7.6).
A field "operable time" in System Information is defined as a single 'Date Time' value in ver.1.0, but service time (i.e. operable time) of a robot system may be described as multiple time spans, such as "9AM-5PM, Mon-Fri and 10AM-5PM, Sat&Sun".
Single 'Date Time' data type cannot deal with such use case so the data type of this field should be modified.
Parameter type of 'operable time' is modified to be a list of DateTime.
in Type of operable_type is changed to List<DateTime[ISO8601]>.
Reference to non-normative document [W3C-DT] is changed to [ISO8601] as the normative one.
XML Profiles of Basic Component is missing. To be added as a part of PSM as well as C++/CORBA PSM.
Add a section of XML Component Profile as a PSM.
In RoIS 1.0, section 7.7.3 describes XML schema definition of HRI Component Profile but examples of Component Profiles of Basic HRI Component in XML is missing. (partly shown in Appendix A.)
Here I propose to insert a new section of 'XML PSM' as section 7.7.3 with attached XML profiles, as well as C++/CORBA PSM in the previous sections.
Rename the current 7.7.3 as '7.7.4 XML PSM of Component Profile Schema.'
As a new example of User-defined HRI Component, WheelChairComponent was proposed in 2014 Boston meeting and it was suitable to be added as section C.4.
A new example of WheelChairComponent was added as section C.4.
A new example of WheelChairRobot component that extends existing Navigation component was proposed as Section C.4.
As well as the fix of DateTime in Section 7.6, DateTime should refer to [ISO8601] instead of [W3C-DT] through Section C.
DateTime modified through Section C.
Definitions of time stamp refers to non normative document [W3C-DT] are modified to refer to [ISO8601].
In Table C.1, definitions of parameter timestamp, timestamp_speech_start and timestamp_speech_end were modified.
Other timestamps in Table C.4 and Table C.5 were also modified.
In the definition of Move component in C++ PSM, List is used instead of vector.
Other part in the C++ PSM consistently use vector and there seems no reason to use List.
Use of List in C++ PSM is modified to vector.
In the C++ PSM, use vector consistently instead of List.
Use of List in the definition of Move Component (Move.h) are replaced with vector.
In the definition of Person Localization component, get_parameter method should return two parameters such as detection threshold and detection interval.
The former is duplicated and the latter is missing.
Missing parameter 'minimum interval.'
As result values of get_parameter method of Person Localization component, definition of 'minimum interval' parameter was missing but 'detection threshold' was duplicated.
A parameter 'minimum interval' should be defined here.
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 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.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
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.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
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.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
In Section 4, definition of HRI Engine is ambiguous
No Data Available
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.”
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.
"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.
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
ATR and AIST should be removed from copyright holders.
These organizations were added by misunderstanding. So I propose removing them.
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
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
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
In p. 46, line 3, Table number (7.31) is missing.
TYPO. Should be added.
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
