Robotics Domain Task Force Final Agenda ver.1.1.1 robotics/2008-12-01 http://robotics.omg.org/ Host Joint (Invited) Agenda Item Purpose Room 9:00 9:45 Robotics Steering Committee Arrangement 10:00 10:20 Robotics-DTF Plenary Opening Session Robotics plenary openning 10:20 12:00 User Identification Service RFP 2nd Review - Su-Young Chi(ETRI), Hyunsoo Kim(Samsung), and Toshio Hori(AIST) presentation, discussion, Voting 12:00 13:00 Magnolia, Lobby Level 13:00 18:00 Architecture Board Plenary Bayshore, 2nd Floor Robotic Infrastructure WG (2.5h) - Noriaki Ando(AIST) discussion Napa 1, Lobby, Level Services WG(2.5h): User Identification Service RFP Meeting - Su-Young Chi, Hyunsoo Kim, and Toshio Hori discussion Napa 3, Lobby Level Robotic Infrastructure WG (2.5h) - Noriaki Ando(AIST) discussion Napa 1, Lobby, Level Robotic Localization Services FTF (2.5h) - Kyuseo Han, Yeon-Ho Kim and Shuichi Nishio discussion Napa 3, Lobby Level Robotic Localization Services FTF (2h) - Kyuseo Han, Yeon-Ho Kim and Shuichi Nishio discussion Camino Real, 2nd Floor Services WG(2h): User Identification Service RFP Meeting - Su-Young Chi, Hyunsoo Kim, and Toshio Hori discussion Room 1335, 13th Floor 11:00 11:30 Robotics Special Talk: Real World Robot Challenge in Tsukuba (RWRC2008) - Takashi Tsubouchi (Univ. of Tsukuba) and Makoto Mizukawa (Shibaura-IT) presentation and discussion 11:30 12:00 Robotics Special Talk: A Lightweight Message-Driven Component Framework for Robotic Systems - Saku Egawa (Hitachi Ltd.) presentation and discussion 12:00 13:00 Magnolia, Lobby Level 13:00 13:50 Robotics Invited Talk: ROS: A new development environment for a new generation of robots - Brian Gerkey (willow Garage) presentation and discussion 13:50 14:30 Robotics The QoS and Fault-tolerance Issues on the Robot Component Execution Enviornment - Beom-Su Seo (ETRI) and Seung-Woog Jung (ETRI) presentation and discussion 14:30 15:10 Robotics The issues on robot component directory service and repository Contents - Kang-Woo Lee (ETRI) presentation and discussion Break (30min) 15:30 16:30 Robotics Special Talk: Architecture Framework for Unmanned System (AFUS) - Laurent Rioux (Thales) presentation and discussion 16:30 17:10 Robotics WG Reports and Discussion (Service WG, Profile WG, Robotic Localization Service WG) presentation and discussion 17:10 17:30 Robotics Contact Reports: - Makoto Mizukawa(Shibaura-IT), and Yun-Koo Chung(ETRI) Information Exchange 17:30 17:40 Robotics Roadmap and Next meeting Agenda Discussion Robotics-DTF Co-Chair election Robotics plenary closing, Voting 17:40 Adjourn plenary meeting 17:40 17:45 Robotics Robotics WG Co-chairs Planning Session (Preliminary Agenda for next TM, Draft report for Friday) planning for next meeting Lafayette, 2nd Floor Robotic Localization Services FTF (3h) - Kyuseo Han, Yeon-Ho Kim and Shuichi Nishio discussion mendocino, Lobby Level 12:00 14:00 Magnolia, Lobby Level Robotic Localization Services FTF (4h) - Kyuseo Han, Yeon-Ho Kim and Shuichi Nishio discussion mendocino, Lobby Level 18:00 20:00 Mezzanine East/West, 2nd Floor 12:00 13:00 Magnolia, Lobby Level 13:00 18:00 Architecture Board Plenary Bayshore, 2nd Floor 8:30 12:00 AB, DTC, PTC Magnolia, Lobby Level 12:00 13:00 Cypress, 2nd Floor 8:00 8:45 OMG New Attendee Orientation San Tomas, 2nd Floor 9:00 12:00 OMG Tutorial - Introduction to OMG Specifications San Tomas, 2nd Floor 10:00 17:00 OMG Tutorial - Introduction to the OMG System Modeling Language (OMG SysML) Lawrence, 2nd Floor 18:00 19:00 OMG New Attendee Reception (by invitation only) Terra Couryard 7:30 9:00 OMG Liaison ABSC Napa1, Lobby Level 9:00 15:00 OMG Tutorial - Introduction to the OMG System Modeling Language (OMG SysML) Stevens Creek, 2nd Floor 15:00 17:00 OMG SysML Information Days Stevens Creek, 2nd Floor 10:00 12:00 OMG Seminar- Semantic Interoperability in Financial Networks: An Overview of ISO 20022 Cypress, 2nd Floor 9:00 17:00 OMG SysML Information Days Stevens Creek, 2nd Floor 9:00 17:15 OMG SOA Consortium Quarterly Meeting Cypress, 2nd Floor 8:30 17:00 OMG SOA Consortium Quarterly Meeting Cypress, 2nd Floor 9:00 12:00 OMG ManTIS Plenary Alameda, 2nd Floor Please get the up-to-date version from http://staff.aist.go.jp/t.kotoku/omg/RoboticsAgenda.pdf Friday LUNCH Other Meetings of Interest Monday Tuesday Thursday Wednesday OMG Technical Meeting - Santa Clara, CA, USA -- Dec.8-12, 2008 TF/SIG Monday: Robotics Plenary(am) and WG activites(pm) Robotics 13:00 15:30 Lafayette, 2nd Floor Thursday LUNCH 9:00 11:00 14:00 18:00 Lafayette, 2nd Floor LUNCH Wednesday WG activity follow-up 9:00 15:30 18:00 LUNCH and OMG Plenary OMG Reception Tuesday: WG activities and Robotics Plenary 12:00 Lafayette, 2nd Floor
137
Embed
Robotics Domain Task Force Final Agenda ver.1.1.1 robotics ...Minutes of the Robotics DTF Plenary Meeting June 23-27, 2008 Ottawa, Ontario, Canada (robotics/2008-12-02) Minutes Highlights
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Robotics Domain Task Force Final Agenda ver.1.1.1 robotics/2008-12-01
Robotic Infrastructure WG (2.5h)- Noriaki Ando(AIST)
discussionNapa 1, Lobby, Level
Services WG(2.5h): User Identification Service RFP Meeting- Su-Young Chi, Hyunsoo Kim, and Toshio Hori
discussionNapa 3, Lobby Level
Robotic Infrastructure WG (2.5h)- Noriaki Ando(AIST)
discussionNapa 1, Lobby, Level
Robotic Localization Services FTF (2.5h)- Kyuseo Han, Yeon-Ho Kim and Shuichi Nishio
discussionNapa 3, Lobby Level
Robotic Localization Services FTF (2h)- Kyuseo Han, Yeon-Ho Kim and Shuichi Nishio
discussionCamino Real, 2nd Floor
Services WG(2h): User Identification Service RFP Meeting- Su-Young Chi, Hyunsoo Kim, and Toshio Hori
discussionRoom 1335, 13th Floor
11:00 11:30 Robotics Special Talk: Real World Robot Challenge in Tsukuba (RWRC2008)- Takashi Tsubouchi (Univ. of Tsukuba) and Makoto Mizukawa (Shibaura-IT)
presentation anddiscussion
11:30 12:00 Robotics Special Talk: A Lightweight Message-Driven Component Framework for RoboticSystems- Saku Egawa (Hitachi Ltd.)
presentation anddiscussion
12:00 13:00 Magnolia, Lobby Level13:00 13:50 Robotics Invited Talk: ROS: A new development environment for a new generation of robots
- Brian Gerkey (willow Garage)presentation anddiscussion
13:50 14:30 Robotics The QoS and Fault-tolerance Issues on the Robot Component Execution Enviornment- Beom-Su Seo (ETRI) and Seung-Woog Jung (ETRI)
presentation anddiscussion
14:30 15:10 Robotics The issues on robot component directory service and repository Contents- Kang-Woo Lee (ETRI)
presentation anddiscussion
Break (30min)15:30 16:30 Robotics Special Talk: Architecture Framework for Unmanned System (AFUS)
8:00 8:45 OMG New Attendee Orientation San Tomas, 2nd Floor9:00 12:00 OMG Tutorial - Introduction to OMG Specifications San Tomas, 2nd Floor10:00 17:00 OMG Tutorial - Introduction to the OMG System Modeling Language (OMG SysML) Lawrence, 2nd Floor18:00 19:00 OMG New Attendee Reception (by invitation only) Terra Couryard
7:30 9:00 OMG Liaison ABSC Napa1, Lobby Level9:00 15:00 OMG Tutorial - Introduction to the OMG System Modeling Language (OMG SysML) Stevens Creek, 2nd Floor15:00 17:00 OMG SysML Information Days Stevens Creek, 2nd Floor10:00 12:00 OMG Seminar- Semantic Interoperability in Financial Networks: An Overview of ISO 20022 Cypress, 2nd Floor
9:00 17:00 OMG SysML Information Days Stevens Creek, 2nd Floor9:00 17:15 OMG SOA Consortium Quarterly Meeting Cypress, 2nd Floor
Please get the up-to-date version from http://staff.aist.go.jp/t.kotoku/omg/RoboticsAgenda.pdf
Friday
LUNCH
Other Meetings of InterestMonday
Tuesday
Thursday
Wednesday
OMG Technical Meeting - Santa Clara, CA, USA -- Dec.8-12, 2008TF/SIG
Monday: Robotics Plenary(am) and WG activites(pm)
Robotics
13:00 15:30
Lafayette, 2nd Floor
ThursdayLUNCH
9:00 11:00
14:00 18:00
Lafayette, 2nd Floor
LUNCH
Wednesday WG activity follow-up9:00
15:30 18:00
LUNCH and OMG Plenary
OMG Reception
Tuesday: WG activities and Robotics Plenary
12:00
Lafayette, 2nd Floor
Minutes of the Robotics DTF Plenary Meeting June 23-27, 2008
Ottawa, Ontario, Canada (robotics/2008-12-02)
Minutes Highlights
1) The revised submission for the Robotic Localization Service RFP was recommended for adoption.
2) As the 1st Review, the draft of User Recognition Service RFP was discussed 3) We have 2 Special Talks (Univ. of Auckland, and RoboCup) in the DTF plenary meeting 4) We have no volunteers for the Robotics-DTF Co-Chair. The Co-Chair election has been
extended to the upcoming meeting in Santa Clara. 5) We decided to cancel the OMG Orlando Technical Meeting in September, 2008, due to the
schedule conflicts with IROS2008 in Nice. List of Generated Documents robotics/2008-06-01 Final Agenda (Tetsuo Kotoku) robotics/2008-06-02 Washington DC Meeting Minutes [approved] (Toshio Hori and Hyun-Soo Kim) robotics/2008-06-03 Steering Committee Presentation (Tetsuo Kotoku) robotics/2008-06-04 Roadmap for Robotics Activities (Tetsuo Kotoku) robotics/2008-06-05 Opening Presentation (Tetsuo Kotoku) robotics/2008-06-06 RLS revised submission presentation (Shuichi Nishio) robotics/2008-06-07 User Recognition Service Interface RFP – DRAFT (Su-Young Chi) robotics/2008-06-08 User Recognition Service Interface RFP presentation (Su-Young Chi) robotics/2008-06-09 User Recognition Service Interface API examples (Su-Young Chi) robotics/2008-06-10 Filter Condition (Itsuki Noda) robotics/2008-06-11 University of Auckland Research in Robotic Software Engineering Environment (Bruce MacDonald) robotics/2008-06-12 RoboCup (Itsuki Noda) robotics/2008-06-13 Robotic Functional Services WG Meeting Report (Hyunsoo Kim) robotics/2008-06-14 Robotic Localization Service WG Meeting Report (Yeon-Ho Kim) robotics/2008-06-15 Robotic Localization Service (RLS) FTF Charter - DRAFT (Shuichi Nishio) robotics/2008-06-16 Contact Report (Makoto Mizukawa) robotics/2008-06-17 Announcement of JCK2008 in Toyama, Japan (Tetsuo Kotoku) robotics/2008-06-18 Announcement of SIMPAR2008 in Venice, Italy (Itsuki Noda) robotics/2008-06-19 UML profile for Robotics / Unmanned Architecture Framework (Laurent Rioux) robotics/2008-06-20 Closing Presentation (Tetsuo Kotoku) robotics/2008-06-21 Next Meeting Preliminary Agenda - DRAFT (Tetsuo Kotoku) robotics/2008-06-22 DTC Report Presentation (Tetsuo Kotoku) robotics/2008-06-23 Ottawa Meeting Minutes - DRAFT (Su-Young Chi and Geoffrey Biggs) MINUTES Monday, June 23, 2008, Albert, Lower Lvl 09:00 - 09:20 Steering committee 09:45 - 09:55 Robotics DTF Plenary meeting, Chair: Dr Kotoku, Quorum: 3 Joined organizations: AIST, ETRI, JARA, Samsung, Shibaura IT, Technologic Arts - Minute takers: Geoffrey Biggs and Su-Young Chi - Approval of minutes of Washington DC meeting - Approved: Shibaura-IT (motion), ETRI (seconded), Technologic Arts (white ballot) - Special talk on RUPI Project not possible. Replaced with a talk by Itsuki Noda.
10:00 - 11:30 Robotic Localization Service Revised Submission Presentation (Albert, Lower Lvl) Shuichi Nishio (JARA/ATR) - First published 2007-06-25 - Revised submission 2008-05-02, 2008-05-03, 2008-05-04 - Basic location representation is handled under GIS specification - Complex architecture "wraps" GIS framework - Robots can use GIS data - GIS *may* use (downgraded) robotic data - Filter function decision still needed - In discussion, it was mentioned that it could be a compliance point. - From a process simplification point of view, leave in for now and consider removing in 12 months at FPF - Confirm the voting member present (Quorum 3): AIST, ETRI, JARA, Samsung, Shibaura IT, Technologic Arts - Voting for the vote- to-vote - JARA motioned a vote to vote process, Shibaura IT seconded. - Poll: 6 in favor, no objections, no abstain, motion passed - Voting for the recommended for adoption of the revised submission
(2008-05-01,-02,-03,-04,-05,-06) - JARA motioned, ETRI seconded, Shibaura IT proposed white ballot.
- No objections, motion passed. Will go to vote at AB this afternoon. 13:20 - 14:00 Architecture Board plenary Robotic Localization Service submission accepted 14:00 - 15:00 User Recognition Service Interface RFP (Capital, 2nd floor) Dr. Su-Young Chi (ETRI) - Solicits proposals for a PIM and at least one CORBA PSM or C++ PSM of User Recognition API for HRI. - User Awareness Module (UAM) is the basic module that performs user identification. - User Identification Coordinator (UIM) integrates info from UAM and transmits it to robot applications. - Information exchange protocols between these and the application are to be standardized. - Extension: User Awareness Component (UAC) may be defined that represents the functionality of both the UAM and UIC. Tuesday, June 23, 2008, Albert, Lower Lvl 13:00 - 18:00 Robotics DTF Plenary meeting continued -Special Talk: University of Auckland research in robotic software engineering environments by Bruce MacDonald - Focus on tools for developing robots. - Target tools towards robot software engineers, who are not advanced trained programmers. - Consider interaction between developer and robot - greater than developer and computer, more immersion. 14:10 - 15:00 Special Talk: RoboCup by Itsuki Noda
15:30 - 16:15 Robot User Recognition RFP 1st review by Dr. Su-Young Chi (ETRI) - Many comments - too many to cover, so decided to defer to the next meeting. - Need to determine suitable scenarios. - Describe and compare the robot-specific API to other standards, especially the BioAPI document. - Describe the relationship to other standards (e.g. localization standard). - Information exchange protocols are not mentioned in the scope of the mandatory requirements. - Issues to be discussed at the next meeting - RFP revision based on the first review and comments from it. - 2nd RFP formal review and AB (aiming to issue the RFP in December 2008 meeting). - Presentation of the RFP should include feedback on the comments. - Schedule before the next meeting - Prepare revised RFP draft and presentation by early September, circulate by e-mail. - Make changes and improve the draft in September. - Meet in the first week of November if necessary for final amendments. - Submit the revised draft to the OMG server by November 7, 2008. - No changes to roadmap since the last meeting. 16:15 - 16:25 Localization WG report - Revised submission presented and discussed on Monday, with a vote-to-vote and recommendation vote (passed) and accepted by the AB review. - No more sessions. - Revised submission accepted by the AB. 6 members recommended: AIST, ETRI, JARA, Samsung, Shibaura IT, Technologic Arts - Discussion towards FTF on Tuesday. - Reviewed draft of the proposed charter for FTF. - Filter condition was discussed. Further discussion will take place by e-mail after reviewing more real-word examples. - FTF meeting at next OMG meeting in December, 2008. - ETRI motioned to charter the FTF. Tsukuba Univ seconded. Tsukuba Univ proposed white ballot. No objections, motion passed. Contact report by Makoto Mizukawa - Offer from ISO/TC 184/SC 5 to add ORiN to ISO 20242. - Coming conferences: - IROS 2008, Nice, France - ICCAS 2008, Seoul, Korea - Real World Robot Challenge: Tsukuba Challenge, Nov 20-22, 2008 Contact report by Tetsuo Kotoku - 3rd Japan-China-Korean joint robotics workshop, Sep 29 - Oct 1, 2008 in Toyama, Japan. Contact report by Itsuki Noda - International Conference on Simulation, Modeling and Programming for Autonomous Robots (SIMPAR 2008), Nov 3-7 in Venice, Italy. - Considering organizing a workshop on standardization. Proposal for UML profile for robotics / Unmanned Architecture Framework by L. Rioux - SAE Technical committee AS-4 on Unmanned Systems. - 5 standards already. One is an Architecture Framework for Unmanned Systems.
- Use UML as a standard for architecture framework, like DODAF and MODAF. - Use a well-known language for robotics, reuse OMG standards. - Guarantee interoperability between standards. - Propose a call for RFP for a UML profile for Unmanned Systems / Robotics Architecture Framework. Closing presentation and next meeting agenda by Tetsuo Kotoku
Call for volunteers - Election for Robotics-DTF co-chair in Santa Clara technical meeting - Robotic Infrastructure WG co-chair - Robotic Data and Profiles WG co-chair
Next meeting: December 8-12 (Santa Clara, CA, USA) Special talk candidates
- Tsukuba Challenge 2008 report (Prof. Takashi Tsubouchi, Tsukuba Univ) - Robotics Project in Japan (Prof. Sato, Univ of Tokyo) - RUPI Project (Dr. Hyun Kim, ETRI) Adjourned plenary meeting at 17:15 Attendee: 23 Participants Bruce MacDonald (Univ. of Auckland) Geoffrey Biggs (AIST) Hiroyuki Nakamoto(SEC) Hyunjin Min (Samsung) Hyun-Soo Kim (Samsung) Itsuki Noda (AIST) Kyuseo Han (ETRI) Laurent Rioux (Thales) Makoto Mizukawa (Shibaura-IT) Manfred Koethe (88solutions) Miwako Doi (Toshiba) Noriaki Ando (AIST) Omar Bahy (IBM/Univ. Ottawa) Seongho Choo (Kangwon National Univ.) Shuichi Nishio (JARA/ATR) Soohee Han (Kwangwon National Univ.) Su-Young Chi (ETRI) Takashi Suehiro (AIST) Takashi Tubouchi (Univ. of Tsukuba) Takeshi Sakamoto (Technologic Arts) Tetsuo Kotoku (AIST) Toshio Hori (AIST) Yeon-Ho Kim (Samsung) Prepared and submitted by Su-Young Chi (ETRI) and Geoffrey Biggs (AIST).
Robotics Plenary: (23 participants)R i i d b i i f RLS RFP– Review revised submission for RLS-RFP
– 2 Special Talk:• Univ of Auckland (Bruce MacDonald) [robotics/2008-06-11]Univ. of Auckland (Bruce MacDonald) [robotics/2008-06-11]• RoboCup (Tsuki Noda) [robotics/2008-06-12]
– 2 WG Reports [robotics/2008-06-13,-14]
– 1 Contact Report [robotics/2008-06-15]
– 1 New Activity Proposal [robotics/2008-06-19]
AgendaAgenda
• Agenda Review• Minutes and Minutes TakerMinutes and Minutes Taker• Roadmap Discussion• Next meeting Schedule
Agenda ReviewAgenda ReviewMon(Dec. 8th):
Steering Committee, RUIS-RFP Revised Submission Presentation & Voting(AM)WG activities(PM) Service WG , Infrastructure WGWG activities(PM) Service WG , Infrastructure WG
Tue(Dec. 9th): WG activities(AM) Localization WG, Service WGRobotics-DTF Plenary(11:00-)
Wed(Dec. 10th):WG activities Service WG ?WG activities Service WG, ?
Thu(Dec. 11th):RUIS-RFP Voting (AM)g ( )
please check our up-to-date agendaplease check our up to date agendahttp://staff.aist.go.jp/t.kotoku/omg/RoboticsAgenda.pdf
Minutes and Minutes TakerMinutes and Minutes Taker• Process:
– Make a draft with in 5days– Send the initial draft to [email protected]
P t th d ft t th OMG ithi k– Post the draft to the OMG server within a week– Make an announcement to [email protected]– Send comments to [email protected]@ g g– Approve the revised minutes at the Next meeting
• Volunteers for this Meeting– Geoffrey Biggs– Yeonho Kim
W h t t ti i t ithi k!We have to post our meeting minutes within a week!
Tue:Tue:11:00-12:00 Special Talk13:00-17:00 Special Talk17 00 17 20 WG R t d R d Di i17:00-17:20 WG Reports and Roadmap Discussion17:20-17:30 Contact Reports17:30-17:40 DTF Co-Chair election17:40 Adjourn
Thu:Thu:09:00-11:00 RUIS Voting
please check our up to date agendaplease check our up-to-date agendahttp://staff.aist.go.jp/t.kotoku/omg/RoboticsAgenda.pdf
Robotics/2008-12-06 Review Comments from AB [Hugues VINCENT] All, Here are my preliminary comments on the User Identification Service Interface RFP (documents numbers robotics/2008-11-01). First, the PDF file does not match the doc file. Since the .doc file seemed cleaner than the other one, I reviewed the .doc file. Second, I don’t know which RFP template was used but the one identified is ab/08-08-26 that refers to a non-existent document. The correct template document is ab/08-08-01. Taking into account this last document will have to be done and should not be too difficult a job on account of the revision bars that have been purposely left in the template document. Next, specific comments: Section 6.1: IMHO, for the sake of readability: The fourth line of this section should end with a : (colon) and not with a ; (semicolon) The following line beginning with “A robot that is intended for…” should be bulleted. The following line beginning with “A robot that provides …” should be bulleted at the same level than the previous bulleted line. The 11 following lines should be bulleted with one more level. And no “ is necessary at the end of the “Planetary robot explorer” line. Besides, are you sure that UAV, drones and planetary robot explorer need to recognise users? It seems like out of sci-fi, doesn't it? “In the proposed proposal” reads odd to me, which proposals are you speaking of? The sentence “This means that even if the new environment that the identified user moved is difficult to recognize that user, the robot system can provide the service based on the previous ID information” is obscure; please rephrase. Figure 1 looks bad (not wrong but bad: please enhance). In the sentence beginning with “In this model, …” remove the parenthesis. Section 6.3: PIM and PSM for SDO: current last formal version is 1.1 [formal/2008-10-11] UML Infrastructure: current last formal version is 2.1.2 [formal/2007-11-04] UML superstructure: current last formal version is 2.1.2 [formal/2007-11-02]
Lightweight CCM is now incorporated into the CCM spec: version 4.0 [formal/2006-04-01] Robotic Technology component spec 1.0 is formal now: formal/08-04-04. Localization service: 1.0 Beta 1 [dtc/2008-07-01] Section 6.4: It seems that ISO/TC184/SC2 is also of interest here. Section 6.5: I’m clearly not an expert in that domain field, yet shouldn’t it be of interest to ask for a standardized initialisation files schema (i.e. for an XML PSM)? Section 6.7: I propose to add in the issues to be discussed: - Proposals shall discuss the way they bring real-time support (cf. section 6.2, point (6)). Best regards, Hugues VINCENT
[Victor Giddings] Comments on User Identification Service Interface RFP OMG Document: robotics/2008-11-01 General Comments It is apparent that a significant amount of effort has gone into the drafting of this RFP. However, it could be improved significantly by focussing some of the statements in the requirements area. See the specific comments below for more detail. I have a concern with the proposed scope of this RFP. The range of technologies to be brought under this RFP seems very broad. The data used by the different technologies would seem to be very disparate, e.g., facial recognition vs. fingerprint or other biometric recognition. My concern is whether there is enough commonality to allow unification in a single PIM. However, I am certainly not an expert in these fields, nor cognizant of the research, so I will defer to the consensus of the task force on this. Specific Comments Section numbers in the PDF have been mangled; they all start with 1.x. (They seem to be correct in the Word version -- but not in the .odt version, so this was probably simply a translation problem.) In this review, I will use the section numbers that appear in the Word version. Front cover: Extra "<" remaining after "OMG Document" "Letters of Intent due:" and "Submissions due:" - actual dates needed Section 6.1: Problem Statement Figure overlaps caption text. The proposed architecture may be completely reasonable, but it is impossible to tell from this description. More description is needed to justify that this is the proscribed architecture around which the responses will be based (as opposed to allowing responders to propose their own architecture). In particular, the description of the User Identification Coordinator is too general ("integrates ... and transmits") If both interfaces of this module are to be specified, there must be a desire to make this a replaceable module. Thus there would seem to be a more specific purpose for it than that described. I also note that the proscribed modules (User Awareness Module and User Identification Module) do not appear in the mandatory requirements (section 1.20). I wonder if this is simply an example of an architecture that might be seen in responses to this RFP. If so, it should be more clearly stated. Section 6.2 Scope of Proposals Sought As an overview of the requirements for responses to the proposal, this section is satisfactory. However, there is a mixture of requirements and scope statements in this section. Some of the statements are actually more detailed than the formal requirements in section 1.24. For example, the bullets under item (3) list a number of required data element, e.g., "essential information such as the (face or voice) feature vector and descriptor format with I.D" while the mandatory requirements just mentions "Basic data structure".
Also, there are no requirements that support many of the items in this scope statement. As an example, item (1) states: "The user recognition service interface specification shall provide a framework for supporting flexible configuration of its own functionalities." There aren't any requirements in 6.5 that support the "configuration of its own functionalities", nor is there an elaboration of what is required of the "framework". There are a number of other examples of this. Section 6.5 Mandatory Requirements I am surprised that Robotics Technology Components are not required to be used as part of the solution. All of the requirements are stated in terms of "modules". I do note that RTC is listed in 6.4 "Relationship to Existing OMG Specifications", but it is listed along with Lightweight CCM, a competing technology. It would seem that the responses to this RFP would be a standard component or set of component interfaces. Victor Giddings [email protected]
Real World Robot Challenge in Tsukuba (RWRC 2008)Tsukuba (RWRC 2008) - Tsukuba Challenge 2008 -
Takashi Tsubouchi, ProfessorUniversity of Tsukuba,
and
Makoto Mizukawa, ProfessorShibaura Institute of TechnologyS b u s u e o ec o ogy
robotics/2008-12-13
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Tsukuba Challenge((November 20 and 21, 2008)
The second challenge event in Japan
Funded by
N T h l F d i (NTF)New Technology Foundation (NTF) and
Tsukuba City
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Tsukuba Challengeg(November 20 and 21, 2007)
Organizers:Chair: Shin’ichi Yuta (U of Tsukuba)Chair: Shin ichi Yuta, (U. of Tsukuba)
Makoto Mizukawa (Shibaura IT)Hideki Hashimoto (U of Tokyo)Hideki Hashimoto (U. of Tokyo)Hirofumi Tashiro (NTF)Prersons from Tsukuba cityPrersons from Tsukuba city
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Tsukuba Challenge• http://www robomedia org/challenge/index html• http://www.robomedia.org/challenge/index.html• Real World Robot Challenge (RWRC)
It i t ll d “ titi ”– It is not so called “competition”– Generalization of robotics technologies by means of
“Development of methodology for the mission completion and disclosure of technical information”
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Tsukuba Challenge 2008Mission
• Autonomous run for 1km on the street for pedestrianspedestrians
• The robot must stop at the goal• The robot must be self-contained• Environment as they arev o e s ey e
– No special treatment for the surface of the street– No postponed in case of rain– No postponed in case of rain– There are pedestrians and bicycles
N CASH P i• No CASH Prize
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Regulation• Robot size within 75cm (W) , 120cm (L), 150cm (H)• Robot weight within 100kgg g• Maximum speed 4km/h• Emergency stop switch• Emergency stop switch• Accompanying operator for malfunction when the
b t ithrobot moves with power
• Design the robot in accordance with environmental and ecological attention
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Environment at the Tsukuba ChallengeEnvironment at the Tsukuba Challenge (2007)
Epochal Tsukuba(Int Conf Center)
Epochal Tsukuba(Int. Conf. Center)
(Int. Conf. Center)
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Environment at the Tsukuba Challenge (2008)
N
Environment at the Tsukuba Challenge (2008)
N
Tsukuba EXPOTX Tsukuba Tsukuba EXPOCenter
TX Tsukuba station
Start and GoalDesired course
Start and Goal
Walkers street for pedestrians
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Environment at the Tsukuba Challenge (2008)
N
Environment at the Tsukuba Challenge (2008)
N
Tsukuba EXPOTX Tsukuba Tsukuba EXPOCenter
TX Tsukuba station
Start and GoalDesired course
Start and Goal
Walkers street for pedestrians
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Test Running Days• more than the last year
– August 3, September 7, October 5 and 17,g , p , ,– November 2, 16 , 18 and 19
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Participants and Results• 50 groups entry • On 20 Nov. : Trial RunOn 20 Nov. : Trial Run
– (100m from start within 12min.)• 47 groups tried � 22 groups passed
• On 21 Nov. : Final RunOn 21 Nov. : Final Run– (1km from start, within 2hrs.)
O l 1 i i l d– Only 1 group mission completed“YAMAHA Motor Tsukuba Challenge TF”
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Photo’s and Movies of ProfPhoto s and Movies of Prof. Mizukawa’s lab.
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
University of TsukubaUniversity of Tsukuba“Okugaigumi” Trialg g
Atsushi Hirosawa, Yusuke Suzuki, Mehrez Kristou, Tomoya Yamaguchi, Yukiko Sawada, and Naoki MorikawaTomoya Yamaguchi, Yukiko Sawada, and Naoki Morikawa
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
For the participation into the TsukubaFor the participation into the Tsukuba Challenge from the Intelligent Robot lab.
P ti i t d i t th h ll f li hi td• Participated into the challenge for polishing our outdoor mobility technologies.
• We had mission completed last year.�What kind of approach do we take for this year?– Rather than small or step by step improvement,– liked and prefered to have new technologic challenges for us
• Compared to the course last year– wide street, but must use only the east side half, y– oncoming robots and operators– catching up with slow robot going ahead of the later startedg p g g– street side detection developed last year seems to be not enough
etc. etc. etc.
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Y bi “Hit t b ” f 2008Yamabico “Hitotsubo” for 2008GPS antennaGPS antenna
TOP-URG
Digital VideoCameras
PC
IMU
Classic-URG
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Complete Redesign of Total System ofComplete Redesign of Total System of the Robot
• Recheck the date flow• Vision system• Vision system
– Stereo vision (obstacle detection)– Edge orientation detection for pavement tiles (positionEdge orientation detection for pavement tiles (position
correction)• Use of LIDAR (Sokuiki sensor) system( ) y
– Street tree trunk detection (position correction)– Wall detection of the buildings (position correction)g p
• Matured algorithm - naturally taking the obstacle avoidance into account for the path following algorithm
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Vision system stereoVision system - stereo • Aim: Obstacle detection
– Coloring with heightg g• Calculate only heights of obstacles based on the disparity image• Green : (ground) 0-0.1m, Red: obstacles (0.1-2m), Blue: Obstacles (2m- )
– Extract brobs for the “red” obstaclesFil h b b ki f d i i f di d i d id if– Filter the brobs taking account of deviations of distance and size and identify them as walkers, trees and other obstacles
– Center x-y coordinate and width of the filtered brobs are transferred the obstacle avoidance processobstacle avoidance process
Stereo camera coloring with height extracted obstacles
polarizing filters
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
LIDAR (Sokuiki sensor) systemLIDAR (Sokuiki sensor) systemStreet tree trunk detection (position correction)• Aim: Correction of dead-reckoned postion
– Clustering based on distance– Circle fitting of the clusters– Tree trunks are detected based on the size, radius and
their covariancetheir covariance
Tree trunk detection (red: fitting success, green: fitting missed)
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Path follo ing and obstacle a oidancePath following and obstacle avoidance• Keeping good enough position p g g g p
estimation• Go along the path (folded line
t th d)
reference velocity vectorattractive
segments on the ground) fundamentally
• Reference velocity vectorrepulsive vector
vector
Reference velocity vector= attractive force vector from the given path + repulsive force vectors
obstacles
from the obstacles• Naturally the robot avoids obstacle
if any on the path and returns onto
Given path
if any on the path and returns onto the path
• Local minima problem is a “merit”
Reference point
v0
Rp
• Look ahead velocity control reference vel.vector
v0
v1�� R
v1
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Path following and obstacle avoidance
• Videos
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Date processing flowp g• Utilize SSM
[Takeuchi, Robomec 2008] forRobomec 2008] for Data exchange
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Integretion• In the indoor laboratory environment, the
stereovision and other systems are connected and yintegrated. Experiments have sccess.
• However and unfortunately image processing• However and unfortunately, image processing computer could not recognize the IEEE 1394 IF at the test run just before the trial and the final.
• The vision could not utilized at all.The vision could not utilized at all.
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
Date processing flowp g• Utilize SSM
[Takeuchi, Robomec 2008] forRobomec 2008] for Data exchange
not integrated
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
ResultResult• At test run, 2 times mission completed and 3
times completed with some human assistance.• The trial passed at the first trialThe trial passed at the first trial• However, we had found a phenomenon that
important process hanged up sometimesimportant process hanged up sometimes.– This phenomenon arose at the final run - retired.
Th 18 j b (5 1 i d )– There are 18 major sub-processes (5ms-1s periods).– More robust implementation on software necessary
f iti l f OS t t it hfor critical case of OS context switch. • At 255m run, the hanging up prevented the
running.
Yamabico PROJECTSINCE 1977
�������Intelligent Robot Laboratory
A Lightweight Message-Driven Component Framework
for Robotic Systems
Saku EgawaMechanical Engineering Research
LaboratoryHitachi, Ltd.
OMG Robotics DTF, Santa Clara, 12/9, 2008robotics/2008-12-14
Robotics in Hitachi• Hitachi has been developing robots since the 1970’s.
• Introspection– No extension (currently not supported by MDC)
• PSM– Add message-based PIM
Conclusion• Hitachi has developed a Message-Driven Component
(MDC) framework.• MDC is lightweight and flexible enough for robotic
applications.• Extension of RTC specification is needed before MDC to
become RTC compliant.
Hitachi is interested in possible collaboration with any organizations with ideas about revising RTC.
ROS: A new development environment for a new generation of robots
Brian GerkeyDecember, 2008
robotics/2008-12-15
Autonomous Personal Robots will Change the World
PR1
PR1 (teleoperated)
PR2
PR2 (teleoperated)
7
Future Exponential Growth in Personal Robots
• Transform the Service Industry AND Light Manufacturing
• Being a catalyst makes good business sense
8
Time to Productivity
vs
9
An Open Platform is the Catalyst• Modular hardware with open interfaces• Open Source software available for
everyone to use– Linux (or maybe Ubuntu) for robotics
• Willow Garage will make available 10 PR2 robots to research labs at no cost
10
How do we fund open platforms?• This kind of effort is hard to sustain– VC funding?– Government grants?– Industry funding?
• Willow Garage is unique– Privately funded– Mix of research and development– Committed to impact through open source– Will spin off companies later (timing)
11
ROS• Robot Operating System
Robot Open Source• Goal: Improve Robotics Research– Leverage the work of others– Replicate results – Good Science– “No more trial by video”
• Wrap�other�open-source projects:– Player, OpenCV, ffmpeg, OGRE, etc.
16
Minimal example
17
2D navigation in simulation
18
Fetch a stapler
19
ROS Design• Unix-inspired – small tools• Modularity• Flexibility• Re-use of components– with or without framework
• Cross-language, cross-platform– Linux, OS X, eventually Windows– C++, Python, LISP, soon Octave / Matlab
• Leverage modern open source tools
20
ROS Features• Distributed• Coordinate transforms built in• Focus on whole-body calibration• General robot description• Visualizations• Lots of useful algorithms
ROS: A Distributed System• Personal Robots need lots of computation– Sensing– Planning
• ROS makes it trivial to move computation around the network– Initiating processing nodes– Understanding state of the computation– Monitoring distributed log messages
ROS General Robot Description• Robot kinematics and dynamics described
in XML• Inspired by PR2, not dependent on it– Ex: Stanford, CMU-Intel use Segway with
Barrett arm– ROS format being merged into OpenRAVE
• 3D Physics simulation– Currently based on Gazebo– Even low-level control loops can be simulated
ROS General Robot Description• 3D Physics
simulation– Currently
based on Gazebo
– Even low-level control loops can be simulated
ROS Transforms• Problem: Sensors can move relative to
� An OMG Standard on robotic components and their� An OMG Standard on robotic components and their lifecycles• First standardization on RTCs and RT-Middlewares (RTMs)
f• Achieves the portability of robotic components• A RTC can be run on any RTMs (of same PSM)
� A reference implementation is available• OpenRTM-aist (ver. 0.4.2, CORBA-PSM, open source)
What is the next step of the RTC?What is the next step of the RTC?
� A candidate would be “Interoperability of RTMs”� A candidate would be Interoperability of RTMs• RT-components of different RT-Middlewares can work together to
provide a robotic service• Moreover they can interoperate with non RTM• Moreover, they can interoperate with non-RTM
(e.g. MSRS, Players/Stage, OPRoS, etc.)
Robotic serviceRTM1
RTM 2Non-RTM (with adaptor)
Interoperability of RTMsInteroperability of RTMs
� Why is it important?� Why is it important?• Basic infrastructure for “Multi-Robot Collaboration”• More advanced and intelligent robotic services
• S i b bi i lti l b t ( f diff t biliti )• Services by combining multiple robots (of different capabilities)• Ubiquitous robotic services (RT + Ubiquitous devices)
� Key considerations• How to search appropriate RTCs running at diverse RTMs?• H bi h i b li i• How to combine them into an robot application
� The second one is partially covered by RTC specification� The second one is partially covered by RTC specification(if the runtimes use a same PSM)• Standard on communication protocol is crucial (e.g. IIOP)
RTC Directory ServiceRTC Directory Service
� Manage the references and properties of running RTCs� Manage the references and properties of running RTCs• RTC registration/unregistration
� Search the appropriate RTC based on• RTC identifier, and/or• RTC properties
� Notified upon the changes on target RTCs� Notified upon the changes on target RTCs
referencesproperties
RT-Components
referencesproperties
searchregisterregister
notify
RTC DirectoryServer
Why “RTC Directory Service”Why RTC Directory Service
� A step toward “Interoperation of RTM”� A step toward Interoperation of RTM• Clients can search appropriate RTCs from different RTMs and
weave them to build applications• Inter RTC Directory lookup protocol enables to combing RTCs• Inter-RTC Directory lookup protocol enables to combing RTCs
from a larger geographical area
RTC DirectoryServer
RTCfrom RTM A
RTCfrom RTM B
Why “RTC Directory Service” (Cont’d)Why RTC Directory Service (Cont d)
� Provide “property-based RTC search” without accessing� Provide property based RTC search without accessing remote RTCs directly• Enable power and easy search method
S• Save unnecessary communications during the search
� Enable clients to keep track of their target RTCs• Clients get notified when the status of the RTCs are changedClients get notified when the status of the RTCs are changed
means:Notify me whenever a camera component at ‘Room L89’ is registered or unregistered
Current StatusCurrent Status
� No relevant specification in Robotic DTF� No relevant specification in Robotic DTF
� OpenRTM-aist provides its own directory servicep p y• Dependent on the CORBA naming service• Only RTC references are registered (cf. Properties are kept in RTC
itself)itself)• Property-based search is not directly supported• Unlikely to interoperate with other RTC implementations, though
th l b d CORBAthey are also based on CORBA
� Related standard specifications in OMGp• CORBA naming service• CORBA trader service
SummarySummary
� Two considerations on “Interoperability of RTMs”� Two considerations on Interoperability of RTMs• Searching right RTCs from diverse RTMs• Combining them into a robot application
� We proposed “RTC Directory Service” in order to address the first considerationthe first consideration• Manage the references to RTCs along with their properties• Provide a property-based search method to the clients
Architecture Framework for Unmanned Systems (AFUS)Systems (AFUS)SAE/AS4 – JAUS - AIR5665L. Rioux - THALES
Research & Technologyrobotics/2008-12-19
The Thales picture
2
What is an architecture Framework ?
Architecture Framework: A structure that supports the organisation and development of architectures for systems
What for ? To provide� Objectives� Rules� InfrastructureFor the creation, the use of system architectures.
AFUS: Architecture Framework for Unmanned Systems
3
AFUS
3 views:
Conceptual Capabilities Interoperability AFUS
Architectural Principes (rules)
Objectives
- Conceptual: lexicon + concepts- Capabilities: what the US can do in the conceptual terms
4
Capabilities: what the US can do in the conceptual terms- Interoperability: various aspects of intereroperablity across US
Objectives
Support for all classes of unmanned systems
Interoperable operator control units
Interchangeable/interoperable payloads
Interoperable unmanned systems
5
Architectural Principles (1/2)
-Clear semantics: It is clear from the representation what semantic are intented
-Orthogonality and Separation of concernsConcept that two or more things will undergo changes independent of one another.
-Technology independenceUnmanned Systems will evolve for many years
-Platform independenceMany platforms exist (UGVs, UAVs). The framework must not flavor one platform over others.
-Mission independenceNo assumed mission or restriction on types of mission that an US can carry out.yp y
-Compute capability independenceNo assumption about the number or type of compute capabilities available on the US
6
No assumption about the number or type of compute capabilities available on the US (even far in the future, there will be unmanned systems with minimal compute capabilities)
Architectural Principles (2/2)
-Operator Use IndependenceNo assumption about how the operator will or should use an USNo assumption about how the operator will, or should use an US.
-Communications IndependenceCommunications IndependenceNo assumption should be made about how communications will be carried out by the unmanned system
-Autonomy Level independenceUnmanned Systems will exhibit varying levels of autonomy (as described in ALFUS).
7
Conceptual view (1/6)
About nouns (what abilities unammned systems have)
Conceptual view is the collection ofConceptual view is the collection of -Terms,-Definitions,,-AttributesRequired for the architecture framework
Concept TopicsId tit Id tifi ti A th it S f t d A tIdentity Identification, Authority, Safety and Autonomy
Composition Platform/Vehicule, Communication Equipment, Sensors, Actuators and emitters.
Knowledge Measurements, Detection, World model, Time, Space, Mechaninics and Energy
Actions Decide Plan Team Move Acutation and
8
Actions Decide, Plan, Team, Move, Acutation and environmental Effects
Conceptual view (2/6)
Authority� Is a right, delegated or given, to perform a specific action on a
resourceresource.
SafetySafety� The probability and severity of the mishap occuring together form
risk
Autonomy� Is an unmanned system’s own ability of sensing, perceiving,
analyzing, communicating, planning, decision-making and acting/executing to acheive its goal assigned.acting/executing to acheive its goal assigned.
Composition: answer to What am I ?
9
p
Conceptual view (3/6)
Platform/vehicle� Physical unammed systems have an infrastructure, or platform, that
contains or supports the various devices, mechanisms and stores neededcontains or supports the various devices, mechanisms and stores needed by the unmanned system.
C i ti E i tCommunication Equipement� US sends and received signals (messages) to and from other US and C2
systems.
Sensors� US senses the world around them throught a hardware interface, a sensor,
which responds in specific ways to specific phenomena in the environment.
Actuators: is a mechanical device that can change shape in response in a signal
10
Emitters: is anything that can discharge a substance or radiation into the environment.
Conceptual view (4/6)
Knowledge: what do I Know ?Knowledge: what do I Know ?
Measurement:Measurement: � Is the processing of a raw sensor product within a customary unit
which may include the combinaison of numerous raw of sensor products.
Detection: i t ti l lti i l ti fDetection: is a computational process resulting in cooreleation of raw of sensor product within an a priori ontology.
World model: is a logical representation of the real-world, internal to an US.
Time: is measured on a time scale using time tags, intervals, durations and frequencies [NELSON01]
11
and frequencies [NELSON01]
Conceptual view (5/6)
Mechanics� The field of physics called mechanisms deals with motion� The field of physics called mechanisms deals with motion
(kinematics) and forces that cause motion (kinetics or dynamics)
Energy� US require energy and must carry consumable, stored energy for
self contained operation
Actions: what can I do ?Actions: what can I do ?
Decide:Decide:� is a final product of the specific mental/cognitive process of an
individual or a group of persons/organizations which is called
12
decision making.
Conceptual view (6/6)
Plan:Plan:� Planning is the proces of « thinking » about the activities required to
create a desired future on some scale.
Team:� A team comprises any group of systems, and people linked in a
common purpose.
Move: Mobility for an US to change its location or orientation under its own powerown power.
Actuation: include articulation, manipulators and actuators ActuationActuation: include articulation, manipulators and actuators Actuation is a chain of links connected at joints with angular or linear actuators.
13
Environment Effects alter the environement in some way.
Capability view: it is about verbs
CAPABILITIES: What unmanned systems can do.
Discovery:� Learning about nearby entities for the purpose of possible
interactions.Include: dynamic discovery and their capabilities.
14
Capabilities
Communication� Communication is about exchanging information with the world
outside the unmanned system as well as internally within itoutside the unmanned system, as well as internally within it.
AccessAccessControl capabilities include gaining, transferring and relinquishing access to systems and their capabilities
Example: Gain Access
15
Capabilities
Control� Control capabilities include gaining, transferring and relinquishing
control of systems and their capabilities
Scenario:Scenario: gain Control
Platform� US are embodied in a platform. A platform has a number of
h t i ti i l di it h i l di i b i
16
characteristics, including its physical dimensions, bays, sensing devices, hardpoints for paylaods, etc.
Capabilities: mobility
MobilityMobility encompasses a variety of capabilities that permit an unmanned system to maneuverunmanned system to maneuver.Each mobility capability focuses on different abstraction used to express the mobility instructions to the unmanned system.
• Cordonate systemSystem for representing a Point in an n-dimensional space
• Position:• Position: A coordinate of a point is the components of a tuple of numbers represent the location of the point in a coordinate system.
• Orientation:The orientation of a rigid body is the components of a tuple of numbersThe orientation of a rigid body is the components of a tuple of numbers represent the rigid body’s rotation about the various of axes in a specific Coordinate system.
17
• Pose: is the combination of Coordinates and Orientation in a specific Coordinate System.
Capability: Mobility scenario
Scenario: Path Mobility
18
Capabilities
Command� Command is the ability to control and command one or more
unmanned system.
P tiPerception� Perception is the « process of acquiring, interpreting, selecting and
organizing sensory information » [Wake]organizing sensory information » [Wake]
Effects� Environement effects is an ability to alter or affect the environement
in some way. This include grasping, pushing, and/or pulling objects, generating emissions such as heat light sound and subtancesgenerating emissions such as heat, light, sound and subtances.
19
Interoperability view
Interoperability view is the guidelines The various aspects of interoperability across unmanned systemssystems.
Standards facilitate and highly recommended:Standards facilitate and highly recommended:� Physical data formats (including endianism, real number formats,
variable lenght formats, alignment and padding.
� Logical message formats (including field semantics, complex structures d ti l l t )and optional elements)
� Message exchange rules including sequences and timeouts� Message exchange rules, including sequences and timeouts
� Physical form factors electrical connections and wave forms
20
� Physical form factors, electrical connections and wave forms.
Notional Model for Interoperability
Application Services
Service A Service B Service C
Discovery Management
Common Services
Status
Access ControlConfiguration
Transport Transport Transport
Transport Methods
Link/Net Link/Net Link/Net
Link / Network methods
21
Link/Net Link/Net Link/Net
Conclusions
AFUS: help designer to design an US
OMG Standardisation:- AFUS and UML:� Conceptual view: Could be UML data types� Capability: Could be UML sequence diagrams which specify the
capabilities of the UScapabilities of the US � Interoperability: UML composite structure and interfaces to model
the interoperability.p y� UML profile for AFUS.
RTC services: reused Common ServicesDiscovery, Configuration, Management, Status, Access Control
22
Infrastructure WGInfrastructure WGProgress Reportg p
Noriaki Ando, AIST
robotics/2008-12-20
TopicsTopics
• Recruiting co-chair • Purpose of Infrastructure WGPurpose of Infrastructure WG• Brief introduction to two special talk from
ETRIETRI• Discussionscuss o
2
Purpose of infra WGPurpose of infra. WG
• The purpose of the Infrastructure Working Group of the Robotics Domain Task Force pis to standardize fundamental models, common facilities and middleware tocommon facilities, and middleware to support the development and integration of a broad range of robotics applicationsof a broad range of robotics applications.
3
Infrastructure WG Co ChairInfrastructure WG Co-Chair
• Co-chairs– Saeha Kim (SNU, resigned)( , g )– Rick Warren (RTI, resigned)
Noriaki Ando (AIST)– Noriaki Ando (AIST)• New co-chair candidate
– Beom-Su Seo (ETRI)
• The DTF approval is required
4
Proposal and IssuesProposal and Issues
• The QoS and Fault-tolerance Issues on the Robot Component Execution Environment– Beom-Su Seo (ETRI) and SeungWoog Jung (ETRI)
• The issues on robot component directory service p yand repository contents– Kang-Woo Lee (ETRI)g ( )
5
QoS FT and Directory serviceQoS, FT and Directory serviceQ S• QoS– Communication between RTCs
CORBA/Web serviceCORBA/Web service– Directory service
• Directory servicey– No specification– CORBA naming/trading services are not enoughg g g
6
Next stepNext step
• RFI– Deployment and configurationp y g
• DiscussionQ S FT– QoS, FT
– Directory service• Roadmap
RFP for new specification– RFP for new specification– RTF for improvement RTC model
7
robotics/2008-12-21
- OMG Robotics DTF-Robotic Functional Services Working Group
- OMG Robotics DTF-Robotic Functional Services Working Group- Robotic Functional Services Working Group -
Meeting Report- Robotic Functional Services Working Group -
Meeting ReportMeeting Report- Santa Clara TC Meeting -
Meeting Report- Santa Clara TC Meeting -gg
Santa Clara (CA, USA) – Dec 09, 2008
What we want to do?Functional Services WG Report 1
• What we want to do?– We want to have a standard to make
R b t i d t t b bl tRobot industry to be able to use any vendor’s user recognition algorithm without the need of re developmentwithout the need of re-development.
• Why we need URS, when we have Localization i ?service?
– The entity and its id is not enough for what we are t i t d (R d l t bl t d t thtrying to do. (Re-development problem to adopt other vendor’s user recognition and detection algorithm)Same reason as the difference between the BioAPI– Same reason as the difference between the BioAPI and URS (see next page)
robotics/2008-03-12
Functional Services WG Report 2• Why not the existing standard, such as BioAPI?
– We need unique robotic application environment.• BioApi needs controlled environments and favorable user.o p eeds co o ed e o e s a d a o ab e use
– We need to deal with higher level interface for robot application.
• BioApi only deals with APIs inside the Biometric• BioApi only deals with APIs inside the Biometric recognition.
– We need to deal with the multiple user.Bi A i l d l ith• BioApi only deal with one person.
– We need to deal with detection technology.• BioApi does not include interface for detection technology.
– We need unique event handling. (for example, one person appeared or disapeared)
• BioApi assumes that the person is always thereBioApi assumes that the person is always there.– We need unique error handling (for example, the distance is
too far from the person, robot need to approach the person or ask the person to come closerask the person to come closer.
• BioApi does not include error handling interface, we need.robotics/2008-03-12
Relationship between URS and RLS
Application1
Application2
ApplicationN
RLS APIRobotic
LocalizationService
RLS API
Service
URS
URS API
robotics/2008-03-12
Why URS ?Why URS ?<With URS> <Without URS>
Application Application
<With URS>
RLS RLSNo RedevelopmentFor Interface Matching
RedevelopmentFor Interface Matching
Recognition Algorithm A
URSRecognition Algorithm B
Recognition Al ith A
Recognition Al ith B
robotics/2008-03-12
Algorithm A Algorithm B Algorithm A Algorithm B
What if URS inside RLS ?What if URS inside RLS ?<Inside RLS> <Outside RLS>
Application Application
RLS
URS RLS No RedevelopmentFor Interface Matching
RedevelopmentFor Interface Matching
URSRecognition Algorithm A
Recognition Algorithm B
Recognition Algorithm A
URSRecognition Algorithm B
robotics/2008-03-12
Roadmap
Item Status
Washing ton D.C
March-2008
OttawaJune-2008
OrlandoSep.-2008
Santa ClaraDec.-
Washing ton D.CMarch-
EuropeJune-2009
2008 2008 2008 2009
Human Robot Interaction Service On-going Discussion 1st review
(for issues repoted until 2008.12) 2009.01: First distribution of report 2009.02: First vote 2009.02.23: Comments due 2009.03.01: Revised documents & reports 2009.03: Second report distribution & vote
(if necessary) 2009.03.23-27: Washington D.C. Meeting 2009.05: Document upload to OMG server 2009.06: Architecture Board
Dr. Lee will be the editor
1
Contact Report:
ISO / TC 211 Tsukuba Meeting2008.12.09NISHIO Shuichi
S i b t h i li ti d i d• Service robots have various application domains and technological fields.– A toy robot in home to a space robot in MarsA toy robot in home to a space robot in Mars– Hardware control to ubiquitous computing
• S/W modularity and standards make it possible to develop service robots cheaper, faster and better.– Common features and customized developmentCommon features and customized development– Modularity, Reusability, and Reliability
• Let’s get started now to take the initiative.– After the market is fully open, it may be too late to standardize.
What S/W standards are needed?What S/W standards are needed?What S/W standards are needed?What S/W standards are needed?
C O t l• Common Ontology• Architecture and Middleware• Functional Components• Functional Components• Applications• Interoperability• Interoperability
• Just my opinion• Divide into 5 areas
Common OntologyCommon OntologyCommon OntologyCommon Ontology
T i l R t ti th d ( ti ) d C• Terminology, Representation method (notion) and Common ontology– Terminology (SC2/PT3)– Representation method (SC4/EXPRESS, OMG/UML)– Ontology
Common OntologyCommon OntologyCommon OntologyCommon Ontology
Terminolog Representation method (notion) and Common• Terminology, Representation method (notion) and Common ontology– Terminology (SC2/PT3)
R t ti th d (SC4/EXPRESS OMG/UML)– Representation method (SC4/EXPRESS, OMG/UML)– Ontology
• Common ontology is a formal specification of a sharedCommon ontology is a formal specification of a shared concept and relationships that can exist for software design and development of service robots.– Formal: The ontology should be machine readable.o a e o to ogy s ou d be ac e eadab e– Shared: The ontology should capture consensual knowledge
accepted by the communities.– Conceptualization (Concept and relationships) : An ontology is an
abstract model by having identified the relevant concepts of thoseabstract model by having identified the relevant concepts of those phenomena.
– Semantic network for domain concept
Architecture and MiddlewareArchitecture and MiddlewareArchitecture and MiddlewareArchitecture and Middleware
• While the software architecture is related to a high-level design principal and a generic model including software design analysis functional specification andsoftware design, analysis, functional specification and integration, the middleware is a kind of software platform based on the architecture.p– Architecture, communication and integration framework (SC5)
• The robotic functional components specify the common interfaces of service robot’s core functions such as human robot interaction navigation and manipulationhuman-robot interaction, navigation and manipulation.
public interface IWatch {public interface IWatch {public void setTime(Time t);public Time getTime();…
Wh th b t i d t l t d l b t• When the robot is used not only as standalone one but also as one of autonomous devices together with other devices in our daily life, the interoperability becomes y , p yimportant.
• Interoperability deals with seamless integration and communication between robots, environments, and service/contentsservice/contents.– Interoperability between robots with different models– Interoperability between robots and the environment
i l di bi i kincluding ubiquitous sensor networks– Interoperability between robots and different kinds of
ORiN: Current Status� Offer from ISO/TC 184/SC 5 (24th, June,2007)
Architecture, communications and integration frameworks, has drawn our attention to possible overlaps with their work item ISO 20242, Industrial automation systems and integration - Service interface for testing y g gapplications, and potentially other SC 5 projects. Also the former robot companion standard ISO 9606 may be relevant to the RAPI proposal.relevant to the RAPI proposal.
� Japan domestic committee (14th, Nov,2008) of p ( , , )the SC5 approved to add ORiN specification to ANNEX of ISO20242 Part 4.
22008.12.9 Robotics DTF, OMG TM, Santa Clara (c) Makoto Mizukawa
Conferences and Exhibitions� 2008 IEEE/RSJ International Conference on
Intelligent Robots and Systems (2008 IROS) http://www.iros2008.org/� Acropolis Conf. Center, Nice, France� Sep 22 Sep 26 2008� Sep 22-Sep 26 2008
� 2008 International Conference on Control� 2008 International Conference on Control, Automation and Systems (ICCAS 2008) www.iccas.orgg� COEX in Seoul, Korea� October 14 - 17, 2008
32008.12.9 Robotics DTF, OMG TM, Santa Clara (c) Makoto Mizukawa
Conferences and Exhibitions� IFR International Conference on Robotics
� COEX in Seoul, Korea� October 14 16 2008� October 14 - 16, 2008
� ROBOT WORLD2008 http://www robotworld or kr/2008/eng/maihttp://www.robotworld.or.kr/2008/eng/mai
n.asp� COEX in Seoul, Korea,� October 15 - 19, 2008
� RoboDevelopment www.robodevelopment.com� Santa Clara Convention Center, Santa Clara, CA� November 19-20 2008� November 19 20, 2008
42008.12.9 Robotics DTF, OMG TM, Santa Clara (c) Makoto Mizukawa
RWRC (Real World Robot Challenge)RWRC (Real World Robot Challenge)Tsukuba Challenge, Nov 20-22, 2008
� 1km Navigation in Natural environment on the pedestrian road inthe pedestrian road in Tsukuba City
� No traffic control to� No traffic control to pedestrians and bicycles
� New features in 2008� Round trip� Passing� bi di ti l t ffi
Chi d G ff Bi )Chi and Geoffrey Biggs)robotics/2008-12-03 Steering Committee Presentation (Tetsuo Kotoku)robotics/2008-12-04 Roadmap for Robotics Activities (Tetsuo Kotoku)robotics/2008-12-05 Opening Presentation (Tetsuo Kotoku)robotics/2008-12-06 Review comments from AB (Hugues VINCENT
and Victor Giddings)robotics/2008-12-07 2nd review for User Recognition Service API RFP
with Comments (Su-Young Chi)robotics/2008-12-08 Resolution to Issue #13130, Error Type inconsistency
(Shuichi Nishio)(Shuichi Nishio)robotics/2008-12-09 Topics - Robotic Localization Service FTF (Itsuki
Noda)robotics/2008 12 10 Name Mapping Rule (Itsuki Noda)robotics/2008-12-10 Name Mapping Rule (Itsuki Noda)robotics/2008-12-11 RoLoArchitecture (Itsuki Noda and Takeshi
Sakamoto)robotics/2008 12 12 Revised RoLoArchitecture (Itsuki Noda and Takeshirobotics/2008-12-12 Revised RoLoArchitecture (Itsuki Noda and Takeshi
Sakamoto)
Document Number (cont.)( )robotics/2008-12-13 Special Talk: Real World Robot Challenge in
Tsukuba (RWRC2008) (Takashi Tsubouchi)robotics/2008-12-14 Special Talk: A Lightweight Message -Driven
Component Framework for Robotic Systems (Saku Egawa)robotics/2008-12-15 Invited Talk: ROS: A new development (Brian
G k )Gerkey)robotics/2008-12-16 The QoS Issues on the Robot Component Execution
Environment (Beon-Su SEO)b ti /2008 12 17 F lt t l I th R b t C trobotics/2008-12-17 Fault-tolerance Issues on the Robot Component Execution Environment (Seung-Woog Jung)
robotics/2008-12-18 The Issues on robot component directry services and repository contents (Kang-Woo Lee)repository contents (Kang-Woo Lee)
robotics/2008-12-19 Special Talk: Architecuture Framework for Unmanned System (AFUS) (Laurent Rioux)
robotics/2008-12-20 Infrastructure WG Progress Report (Noriaki Ando)robotics/2008-12-20 Infrastructure WG Progress Report (Noriaki Ando)robotics/2008-12-21 Robotics Functional Services Working Group Meeting
Report (Su-Young Chi)robotics/2008-12-22 Robotic Localization Service WG Report (Shuichirobotics/2008-12-22 Robotic Localization Service WG Report (Shuichi
Nishio)
Document Number (cont.)( )robotics/2008-12-23 Contact Report: ISO/TC211 Tsukuba Meeting
�Hi hli h f hi M i�Highlights from this Meeting:Robotics-DTF Co-chair electionRobotics-DTF Co-chair election
Laurent Rioux (Thales) and Young-Jo Cho (ETRI)
Robotics Plenary: (29 participants)– 2nd review of Robotic User Identification RFP
4 Special Talk [ b ti /2008 12 13 14 15 19]– 4 Special Talk [robotics/2008-12-13,-14,-15, -19] • ROS: A new development environment for a new generation of robots
(Brian Gerkey) [robotics/2008-12-15]
3 New work item Talk [robotics/2008 12 16 17 18]– 3 New work item Talk [robotics/2008-12-16,-17,-18]
– 3 WG Reports [robotics/2008-12-20,-21,-22]
– 3 Contact Report [robotics/2008-12-23,-24,-25]
– Preliminary Agenda for upcoming meeting [robotics/2008-12-27]
Robotics-DTFDate: Friday, 12th December, 2008Chair: T. Kotoku, L. Rioux, and Y. –J. ChoURL: http://robotics omg org/Robotics DTF URL: http://robotics.omg.org/email: [email protected]
�Deliverables from this Meeting:�Deliverables from this Meeting:–Nothing Special
�Future deliverables (In-Process):�Future deliverables (In-Process):–Robotic User Recognition Service RFP–Robotic Configuration and Deployment (potential RFP)Robotic Configuration and Deployment (potential RFP)
�Next Meeting (Washington DC, USA):–Review of User Recognition Service RFP–Review of User Recognition Service RFP–Guest presentations–Roadmap discussionRoadmap discussion–Contact reports
Minutes of the Robotics DTF Plenary Meeting - DRAFT December 8-12, 2008
Santa Clara, CA, USA (robotics/2008-12-29)
Minutes Highlights
1) Laurent Rioux (Thales) and Young-Jo Cho (ETRI) have been elected as Robotics-DTF Co-Chairs.
2) As the 2nd Review, the draft of Robotic User Identification Service RFP was discussed, but we decided to have more discussions to issue the RFP.
3) We have one invited talk of Dr. Brian Gerkey (Willow Garage). 4) We have 3 special talks (Tsukuba Challenge, Hitachi, AFUS). 5) We have 3 new work item talks (QoS, Fault-tolerance, Directory service)
List of Generated Documents robotics/2008-12-01 Final Agenda (Tetsuo Kotoku) robotics/2008-12-02 Ottawa Meeting Minutes [approved] (Su-Young Chi and Geoffrey Biggs) robotics/2008-12-03 Steering Committee Presentation (Tetsuo Kotoku) robotics/2008-12-04 Roadmap for Robotics Activities (Tetsuo Kotoku) robotics/2008-12-05 Opening Presentation (Tetsuo Kotoku) robotics/2008-12-06 Review comments from AB (Hugues VINCENT and Victor Giddings) robotics/2008-12-07 2nd review for User Recognition Service API RFP with Comments (Su-Young Chi) robotics/2008-12-08 Resolution to Issue #13130, Error Type inconsistency (Shuichi Nishio) robotics/2008-12-09 Topics - Robotic Localization Service FTF (Itsuki Noda) robotics/2008-12-10 Name Mapping Rule (Itsuki Noda) robotics/2008-12-11 RoLo Architecture (Itsuki Noda and Takeshi Sakamoto) robotics/2008-12-12 Revised RoLo Architecture (Itsuki Noda and Takeshi Sakamoto) robotics/2008-12-13 Special Talk: Real World Robot Challenge in Tsukuba (RWRC2008) (Takashi Tsubouchi) robotics/2008-12-14 Special Talk: A Lightweight Message -Driven Component Framework for Robotic Systems (Saku Egawa) robotics/2008-12-15 Invited Talk: ROS: A new development environment for a new generations of robots (Brian Gerkey) robotics/2008-12-16 The QoS Issues on the Robot Component Execution Environment (Beon-Su SEO) robotics/2008-12-17 Fault-tolerance Issues on the Robot Component Execution Environment (Seung-Woog Jung) robotics/2008-12-18 The Issues on robot component directory services and repository contents (Kang-Woo Lee) robotics/2008-12-19 Special Talk: Architecture Framework for Unmanned System (AFUS) (Laurent Rioux) robotics/2008-12-20 Infrastructure WG Progress Report (Noriaki Ando) robotics/2008-12-21 Robotics Functional Services Working Group Meeting Report (Su-Young Chi) robotics/2008-12-22 Robotic Localization Service WG Report (Shuichi Nishio) robotics/2008-12-23 Contact Report: ISO/TC211 Tsukuba Meeting (Shuichi Nishio) robotics/2008-12-24 Contact Report: ISO/TC184/SC2 Software Standardization (Hyun Kim) robotics/2008-12-25 ORiN: Current Status (Makoto Mizukawa) robotics/2008-12-26 Closing Presentation (Tetsuo Kotoku) robotics/2008-12-27 Next Meeting Preliminary Agenda - DRAFT (Tetsuo Kotoku) robotics/2008-12-28 DTC Report Presentation (Tetsuo Kotoku) robotics/2008-12-29 Santa Clara Meeting Minutes - DRAFT (Geoffrey Biggs and Yeonho Kim)
MINUTES Monday, December 8, 2008, Lafayette, 2nd floor 09:00 – 09:20 Steering Committee 10:00 – 10:10 Robotics DTF Plenary Meeting, Chair: Dr Kotoku, Quorum: 3 Joined organizations: AIST, ETRI, Hitachi, JARA, Kangwon National Univ., Samsung, Shibaura-IT, Univ. of Tsukuba, Technologic Arts, Thales
• Minute takers: Geoffrey Biggs and Yeonho Kim • Approval of minutes of Ottawa meeting
◦ Approved: Shibaura-IT (motion), Thales (seconded), ETRI (white ballot). 10:10 – 12:00 User Identification Service RFP 2nd Review (Lafayette, 2nd floor) Su-Young Chi (ETRI)
• Dr Nishio gave several comments. • Review comments received from two Architecture Board members, to be responded to. • Use word "identification" instead of "recognition" in title ("recognition" does not include
selecting a single identity from a list of possible identities). • More clearly define what the difference, particularly in assumptions made, between biometric
systems and robotic systems. • Issue of if tracking should be included in RFP was raised. • Change the scope of the RFP to only the interface between the user identification module and
applications. • Significant confusion over wording around “user identification,” “user awareness” and “user
recognition.” It was noted that one interpretation of Figure 1 is identical to the localization standard. Will discuss during WG sessions.
Tuesday, December 09, 2008, Lafayette, 2nd Floor 11:05 – 17:40 Robotics DTF plenary meeting continued 11:05 – 11:35 Special talk: Tsukuba Challenge 2008 report, Prof Tsubouchi, Univ. of Tsukuba
• Almost same rules as 2007 Tsukuba Challenge. • 50 groups entered, 1 group finished. • New route this year, more difficult than last year (straight line), involving reversing direction
twice and returning to start point. 11:35 – 12:05 Special talk: A lightweight Message-Driven Component Framework for Robotic Systems, Saku Egawa, Hitachi, Ltd.
• Hitachi has developed a minimum component framework, Message-Driven Component (MDC). ◦ Messages contain a command and data, are asynchronous, with no data marshalling
(application is responsible for building data part of message). ◦ Lightweight and fast: only 358KB of code for the middleware.
• Not currently compatible with RTC standard. Could add an MDC-based PSM. Need some extensions to RTC for MDC to become RTC-compliant: ◦ Lightweight RTC needs to accept single-Execution Context, multiple-component models.
◦ Execution semantics need a message-driven execution model (stimulus response execution semantics is not enough).
◦ Add MDC PSM. 13:05 – 14:00 Invited talk: ROS: A new development environment for a new generation of robots, Brian Gerkey, Willow Garage
• Willow Garage's goal is an open platform: modular hardware with open interfaces, open source software. "Linux for robotics."
• PR2 robot: make 20 or so, possibly more. Not a unique robot. • WG is privately funded, committed to open source, will spin off companies later. • ROS: Robot Operating System (or Robot Open Source) is flagship software system.
14:00 – 14:30 The QoS and Fault-tolerance Issues on the Robot Component Execution Environment, Beom-Su Seo, ETRI
• QoS technology in distributed environment for robotics. • QoS characteristics in consideration of robots: performance, reliability, accuracy and demand. • OMG QoS profile is too general and broad, not sufficient for robotics. Need to enhance and
update it. Establish a "QoS profile" for the robot component standard. • Add a QoS manager to component middleware. • Faults in robotics: faults, fault detection, fault recovery and fault tolerance. Tolerance is the
ability to detect and recover, providing continuous service in spite of faults. • Add a fault tolerance manager to component middleware. Need a Fault Tolerance profile that
tells how to recover from faults. 14:30 – 15:00 Issues on RTC Directory Service, Kang-Woo Lee, ETRI
• Interoperability of RTMs. Make RT-Components of different RT-Middlewares work together to provide a robotic service. Moreover, allow them to interoperate with non-RTM systems, e.g. MSRS, Player, OPRoS, etc.
• RTC Directory service to manage the references and properties of running RTCs. (Registration/unregistration).
• No relevant specification in Robotics DTF. OpenRTM-aist provides its own directory service based on the CORBA naming service. Does not provide all desired features. ◦ Related standards in OMG: CORBA naming service, CORBA trader service.
15:30 – 16:10 Architecture framework for unmanned systems (AFUS), Laurent Rioux, Thales
• Principles: Clear semantics, orthogonality and separation of concerns, independence from technology, platform, mission, compute capability, operator use, communications, autonomy level.
• Supports dynamic discovery and access control to remote entities. • AFUS in OMG:
◦ Can make AFUS conceptual view UML data types, capability could be UML sequence diagrams, interoperability could be UML composite structure.
◦ AFUS Common Services could be reused in RTC. 16:10 – 16:20 Infrastructure WG report
• Restart WG after two new topics proposed by ETRI.
• Confirmed purpose of Infrastructure WG. • New co-chair: Beom-Su Seo (ETRI).
• Next step is to make an RFI for deployment and configuration, a roadmap for RFP for new specifications, and RTF for improvements to the RTC model.
16:25 – 16:55 Robot Functional Services WG report
• Had discussion on what trying to do, to clear up misunderstandings from Monday's discussions. • Clarified why URS is needed rather than using the localization service or the BioAPI standard. • Still significant disagreement over wording.
16:55 – 17:05 Localization WG report
• 48 issues raised so far, most typos, and most solved. • Two remaining issues to be discussed (on Wednesday morning):
◦ Definition of orientation in common data formats. ◦ XML-PSM definition and RoLo Element local naming issue (new issue).
• Planned schedule presented. • Dr. Lee has volunteered to be the report editor.
17:05 – 17:15 Contact report by Shuichi Nishio
• ISO/TC211 Tsukuba Meeting, 2008/12/01 • Two invited talks on RLS activity.
• ORiN project current status: ◦ Offer from ISO/TC184/SC5, 24 June 2007 ◦ Japan domestic committee, 14 Nov 2008, of the SC5 approved to add ORiN specification to
ANNEX of ISO20242 Part 4. • Conferences:
◦ IROS 2008, Nice, France ◦ ICCAS 2008, Seoul, Korea ◦ IFR International Conference on Robotics, Seoul, Korea ◦ ROBOT WORLD 2008, Seoul, Korea ◦ RoboDevelopment, Santa Clara, CA, Nov 19-20 2008
• Tsukuba Real World Robot Challenge, Nov 20-22, 2008 • Coming conferences:
◦ ICRA 2009, Kobe, Japan
Closing presentation and next meeting agenda by Tetsuo Kotoku • Call for volunteers
◦ Election of new DTF co-chairs: Luarent Rioux (Thales) and Young-Jo Cho (ETRI) ▪ Approved: AIST (motion), Kangwon National Univ. (second), Thales (white ballot).
◦ Kyuseo Han no longer Localization WG co-chair. ◦ Election of Localization WG co-chair: Dr. Lee
▪ Approved: JARA (motion), Thales (second), ETRI (white ballot). • Next meeting: March 23-27, Washington DC, USA • Special talk candidates
◦ Gearbox Project, Geoffrey Biggs, AIST, Japan ◦ Robotics Project in Japan, Prof. Sato, Univ. of Tokyo, Japan ◦ RUPI Project, Dr. Hyun Kim, ETRI, Korea
Adjourned plenary meeting at 17:40 Attendee: 29 Participants
• Akihiko Ikezoe (SEC) • Beom-Su Seo (ETRI) • Brian Gerkey (Willow Garage) • Geoffrey Biggs (AIST) • Hong-Seong Park (KNU) • Hugues Vincent (Thales) • Hyun Kim (ETRI) • Hyun-Soo Kim (Samsung) • Itsuki Noda (AIST) • Jeong-Seok Kang (KNU) • Kenichi Wada (Hitachi) • Kim Siman (Tobesoft) • Kyuseo Han (ETRI) • Laurent Rioux (Thales) • Makoto Mizukawa (Shibaura-IT) • Miwako Doi (Toshiba) • Noriaki Ando (AIST) • Saku Egawa (Hitachi) • Seung –Woog Jung (ETRI) • Shuichi Nishio (JARA/ATR) • Soo-Hee Han (KNU) • Sung-Soo Kang (KOSTA) • Su-Young Chi (ETRI) • Takashi Suehiro (AIST) • Takashi Tubouchi (Univ. of Tsukuba) • Takeshi Sakamoto (Technologic Arts) • Tetsuo Kotoku (AIST) • Toshio Hori (AIST) • Yeon-Ho Kim (Samsung)
Prepared and submitted by Geoffrey Biggs (AIST) and Yeon-Ho Kim (Samsung).