Issues for Mailing list of the Robotic Interaction Service (RoIS) Framework 1.0 Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 16560: Command Result Message definitions (rois-ftf)
Issue 16893: Definition of HRI Engine is ambiguous
Issue 16894: Order of HRI Engine and Service Application should be changed
Issue 16895: Relationship with RTC and ROS
Issue 16923: Parameter definitions for Error Message
Issue 16924: Occurrence of sub component for Component Profile
Issue 16925: Parameter in HRI Engine Profile
Issue 16926: RoIS_Common in System Information component
Issue 16927: Parameters for System Information component
Issue 16928: Parameters for Localization component
Issue 16929: Parameters for Speech Synthesis component
Issue 16930: Additional Normative References
Issue 16931: Notification of Profile change
Issue 16932: Wrong Expression
Issue 16933: Condition for identifying message
Issue 17133: Atomic allocation of multiple HRI Components required
Issue 17134: Dependency among HRI Components should be defined
Issue 17135: Miss speling in Table 7.2
Issue 17136: Unifying Notation of Terms
Issue 17137: Complex definition of "Command Unit List"
Issue 17138: Ambiguous definition of "Condition"
Issue 17139: General System Message Class should be defined
Issue 17140: Table number missing in 7.6
Issue 17141: "Supported by" in Acknowledgements should be modified
Issue 17142: Copyright holders should be modified
Issue 17143: Two types of parameters to be distinguished
Issue 17145: Schematic diagram of RoIS Framework (Figure 5, in Section 7.2) requires an update

Issue 16560: Command Result Message definitions (rois-ftf) (rois-ftf)

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

In Section 4, definition of HRI Engine is ambiguous

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

Relationship with ROS, RTC should be clarified

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.

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".

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.

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

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>.

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.

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

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

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

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

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).

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

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

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

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

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

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

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

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

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.

ATR and AIST should be removed from copyright holders.

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.

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.