robotics domain task force final agenda ver.1.0.4...

Robotics Domain Task Force Final Agenda ver.1.0.4 robotics/2006-04-04

Host Joint (Invited) Agenda Item Purpose Room

8:30 12:00 SDO Robotics Robot Technology Components RFP submitter's meeting (closed) St. Peters12:00 13:00 Grand Ballroom ABC13:00 18:00 Architecture Board Plenary Grand Ballroom D13:00 14:20 Robotics WG (Service) discussion

14:20 15:40 Robotics WG (Profile) discussion

15:40 17:00 Robotics WG (Tool) discussion

17:00 18:00 Robotics SDO Steering Committee of Robotics DTF(included Publicity Subcommitee discussion)

Volunteer recruit

8:30 9:00 MARS SDO,Robotics

Progress Report of the Robot Technology Components RFP revised submission reportingGateway2

10:05 10:20 Robotics,SDO

Welcome and review agenda Robotics/SDO JointMeeting Kick-off


SDO,Robotics

<Special Talk>"Real-Time ORB Middleware: Standards, Applications, and Variations”- Prof. Chris Gill (Washington University)

Informative

11:20 12:00 Robotics (SDO) "Communication protocol for the URC robot and server”- Hyun-Sik Shim (Samsung Electronics)

RFI response

12:00 13:00 Grand Ballroom ABC13:00 14:00 Robotics (SDO) <Special Talk>

"URBI: a Universal Platform for Personal Robotics”- Prof. Jean-Christophe Baillie (ENSTA/UEI Lab)

Infomative

14:00 14:40 Robotics (SDO) "Fujitsu's robotics research and standardization activities”- Toshihiko Morita

RFI response

14:40 15:20 Robotics (SDO) "Standardization of device interfaces for home service robot”- Ho-Chul Shin (ETRI)

RFI response

Break (20min)15:40 16:20 Robotics (SDO) “Voice interface standardization items network robot in noisy environments”

- Soon-Hyuk Hong (Samsung Electronics)RFI response

16:20 17:40 Robotics SDO WG (Infrastructure) discussion

8:30 9:10 Robotics (SDO) “Home robot navigation in SAIT”- Seok Won Bang and Y. H. Kim (Samsung Advanced Institute of Technology)

RFI response

9:10 9:50 Robotics (SDO) “ITR – Internet Renaissance - The world’s first humanoid robot to be harmonizedwith the family -”- Hiroyuki Nakamoto (Systems Engineering Consultants)

RFI response

Break (10min)10:00 11:40 Robotics (SDO) WG Reports and Roadmap Discussion

(Infrastructure, Service, Profile)chartering WG

11:40 11:50 Robotics (SDO) Contacts Report Informative


Publicity, Next Meeting Agenda Discussion, etc Robotics/SDO Closingsession

12:00 Adjourn12:00 14:00 Grand Ballroom ABC

Infrastructure WG [14:00-18:00]the current component model RFP as well as other topics of interest to themembers including possible additional areas for standardization.

follow up discussionPoplar

(14:00-18:00)

Service WG [16:00-18:00] follow up discussion Missouri(16:00-18:00)

18:00 20:00 Grand Ballroom CD

8:30 10:00 SDO Robotics Robot Technology Components RFP submitter's meeting (open) Grand Ballroom F10:00 12:00 Robotics Service WG follow up discussion Grand Ballroom F

12:00 13:00 Grand Ballroom ABC13:00 18:00 Architecture Board Plenary Grand Ballroom D13:00 14:00 MARS SDO,

RoboticsRobotics RFI Summary Report

Blanchette2

14:00 15:00 MARS SDO,Robotics

"Real-Time ORB Middleware: Standards, Applications, and Variations"- Prof. Chris Gill (Washington University) Blanchette2

8:30 12:00 AB, DTC, PTC Grand BallroomDEF

12:00 13:00 Grand Ballroom AB

8:00 8:45 OMG New Attendee Orientation Poplar9:00 12:00 OMG MOF Metamodeling Tutorial Discovery13:00 17:00 OMG Architecture-Driven Modernization Concepts and Task Force Update Discovery18:00 19:00 OMG New Attendee Reception (by invitation only) Posh's Dining

13:00 17:30 OMG MDA–Where it Came From and Where It’s Going Discovery

9:00 12:00 OMG Introduction to UML 2.0 Discovery14:00 17:00 OMG Introduction to the Data Distribution Service Discovery

Poplar

Thursday

TF/SIG

Tuesday (April 25) Robotics Plenary

LUNCH and OMG Plenary

OMG Reception

Poplar

LUNCH

Wednesday (April 26) Robotics Plenary

Poplar

OMG Technical Meeting - St. Louis, MO, USA -- April 24-28, 2006

LUNCH

Monday (April 24) WG and Committee Activites

Gateway3

Friday

LUNCH

Wednesday

Tuesday

Other Meetings of InterestMonday

LUNCH

14:00 18:00 Robotics

Robotics DSteering Committee Meeting

April 24, 2006St. Louis, MO, USA

Hilton St. Louis AirportGateway 3

robotics/2006-04-05

Agenda

• Agenda Review• Publicity• Working Group Discussion• Roadmap Discussion• Next meeting Schedule

Review AgendaTuesday, April 25, 2006

10:05-12:20 Welcome and Review Agenda10:20-11:20 Special Talk: Prof. Chris Gill 11:20-12:00 RFI response presentation

13:00-14:00 Special Talk: Prof. Jean-Christophe Baillie14:00-16:20 RFI response presentation 16:20-17:40 WG (Infrastructure)

Joint Meeting with MARS/RTESSThursday, April 27, 200613:00-14:00 (Banchette2)

Poplar

Review AgendaWednesday, April 26, 2006 Poplar

08:30-09:50 RFI response presentation 10:40-11:40 WG Reports and Roadmap Discussion11:40-11:50 Contacts Report11:50-12:00 Next meeting, etc.12:00 Adjourn

14:00-18:00 WG (Infrastructure)16:00-18:00 WG (Service)


Publicity Activities

• 4 page fly sheetDraft of Abheek@ADA SoftwareAbheek@ADA Soft, Olivier@AIST,Chung@ETRI,Yokomachi@NEDO

Action:Send each organization logo to Abheek.

4 page fly sheet will be authorized in Boston4 page fly sheet will be authorized in Boston4 page fly sheet will be authorized in Boston

Publicity Activities• Korea-Japan RSW2006

Friday, June 16, 2006, Jeju Island, KoreaChung@ETRI

• RoboBusiness2006June 20-21, 2006, Pittsburgh, PA, USAhttp://www.robobusiness2006.com/Jon Sigel and Bruce@Systronix

• IROS2006 WorkshopOctober 9-15, Beijing, Chinahttp://www.iros2006.org/Kotoku@AIST, Chung@ETRI, Mizukawa@Sibaura-IT

• SICE-ICASE International Joint ConferenceOctober 18-21, Pusan, Koreahttp://sice-iccas.org/Mizukawa@Sibaura-IT

Roadmap (WG organization)

4 Discussion Groups:• Infrastructure: Rick@RTI, Ando@AIST• Service: Chi@ETRI, Lemaire@AIST• Tool: Abheek@ADA soft• Profile: Lee@ETRI, Bruce@Systronics

Robotics-DTF Plenary Meeting •Guest Presentation(s)•WG reports & Roadmap discussion•Contact reports•Resolution

Wednesday :

Monday :

Next Meeting Agenda June 26-30, 2006 (Boston, MA, USA)

RTCs RFP revised submission review [MARS]Steering Committee

Monday-Tuesday, Thursday :WG activities

Robotics-DTF Meeting Minutes – Tampa, FL, USA – approved (robotics/2006-04-06)

Overview and votes The first plenary of Robotics Domain Task Force was held, following the charter of Robotics DTF in the last Burlingame meeting. We had one special talk and 14 RFI response presentations. We decided to start 4 working group activities, which will be chartered officially in the upcoming St. Louis meeting. With the sponsorship of MARS, the deadline of the Robotics Systems RFI was re-extended to April 3rd, 2006 (3 weeks before the St. Louis meeting). By the proposal from ADA Software, the Publicity Sub-Committee has been chartered. OMG Documents Generated robotics/2006-02-04 Robotics-DTF Final Agenda (Tetsuo Kotoku) robotics/2006-02-05 Steering Committee Presentation (Tetsuo Kotoku) robotics/2006-02-06 Burlingame Meeting Minutes [approved] (Olivier Lemaire) robotics/2006-02-07 Opening Presentation (Tetsuo Kotoku) robotics/2006-02-08 Robotics-DTF Roadmap (Tetsuo Kotoku) robotics/2006-02-09 “Hitachi's needs for robotic system standards” (Saku Egawa, Hitachi) robotics/2006-02-10 “Towards Plug and Play Robotics” (Abheek Bose, ADA Software Group) robotics/2006-02-11 “SEC's Approach to the Standardization of Robotic Systems” (Masayuki Nagase and Hiroyuki Nakamoto, SEC) robotics/2006-02-12 “Development of Food Robots, Meat Processing Robots, and Request for Standardization of RTC” (Tomoki Yamashita, Mayekawa MFG) robotics/2006-02-13 “RT service framework using IT infrastructure” (Wonpil Yu, ETRI) robotics/2006-02-14 “A Mobile Robot Software System Architecture with Unified Sensory Data Integration” (Takashi Tsubouchi, Tsukuba Univ.) robotics/2006-02-15 “Navigation of mobile robots” (Wonpil Yu, ETRI) robotics/2006-02-16 “OMG Robotics Systems RFI response from AIST” (Olivier Lemaire, AIST) robotics/2006-02-17 “Current State of Robotics Script and Control Languages [and Standards]” (Lloyd Spencer, CoroWare) robotics/2006-02-18 “Special Talk: Lessons Learned About Software for Rescue Robots” (Matt Long, Univ. of South Florida) robotics/2006-02-19 “Development Framework for Mobile Robot based on JAUS and RT-Middleware” (Wataru Inamura, IHI) robotics/2006-02-20 “Applicable SWRadio Spec Concepts for Robotics Domain” (Jerry Bickle, PrismTech) robotics/2006-02-21 “COMPARE Response to the Robotics RFI” (Virginie Watine, THALES) robotics/2006-02-22 “Robot Server Middleware” (Seung-Ik Lee, ETRI) robotics/2006-02-23 “Toshiba's Approach to RT Standardization and Where the Standardization is Needed” (Fumio OZAKI, Toshiba) robotics/2006-02-24 OMG Robotics Task Force RFI Survey Result (Olivier Lemaire, AIST) robotics/2006-02-25 Query Report (Olivier Lemaire, AIST) robotics/2006-02-26 Publicity Activity Proposal (Abheek Bose, ADA software) robotics/2006-02-27 Summary of Activity Robotics TF - Tampa (Olivier Lemaire, AIST) robotics/2006-02-28 DTC Report Presentation (Tetsuo Kotoku) robotics/2006-02-29 Meeting Minutes - DRAFT (Saku Egawa, Soo-Young Chi) Agenda 13 February, Monday 15:00-17:00 – Steering Committee of Robotics DTF 14 February, Tuesday 08:40-09:00 – Welcome and Review Agenda

09:30-10:30 – Robot Technology Components RFP initial submission – Noriaki Ando (AIST) 10:30-11:30 – Robot Technology Components RFP initial submission – Hung Pham (RTI) 13:00-13:40 – Hitachi's needs for robotic system standards – Saku Egawa (Hitachi) 13:40-14:20 – Towards Plug and Play Robotics – Abheek Kumar Bose (ADA Software Group) 14:20-15:00 – SEC's approach to the standardization of robotics systems – Hiroyuki Nakamoto and Masayuki Nagase (SEC) 15:20-16:00 – Development of Food Robots and Meat Processing Robots, and Request for Standardization of RTC – Tomoki Yamashita (Maekawa MFG) 16:00-16:40 – RT service framework using IT infrastructure – Wonpil Yu (ETRI) 16:40-17:20 – A mobile robot software system architecture with unified sensory data integration – Takashi Tsubouchi (Tsukuba Univ.) 17:20-18:00 – Navigation of mobile robots including mapping, localization, and motion – Wonpil Yu (ETRI) 15 February, Wednesday 08:10-08:50 – Response from AIST – Olivier Lemaire (AIST) 08:50-09:30 – Current State of Robotics Script/Control Language Standards – Lloyd Spencer (CoroWare) 09:30-10:20 – Lessons Learned About Software for Rescue Robots – Matt Long (iSSRT, Univ. of South Florida) 10:40-11:20 – Development Framework for Mobile Robot based on JAUS and RT-Middleware – Wataru Inamura (IHI) 11:20-12:00 – An overview of PIM & PSM for SWRadio Components specification – Jerry Bickle (Prismtech) 14:00-14:40 – Response from Compare Project – Virginie Watine (THALES) 14:40-15:20 – Robot Server Middleware: CAMU – Seung-ik Lee (ETRI) 15:40-16:20 – Toshiba's approach to RT standardization and where the standardization is needed – Fumio Ozaki (Toshiba) 16:20-17:40 – Summary of RFI responses and working group discussion 17:40-17:50 – Publicity Activity 17:40-17:50 – Next Meeting Agenda Discussion 18:00 Adjourn Minutes 14 February, Tuesday AM Plenary Tetsuo Kotoku, presiding co-chair Meeting Week – Kick-off Meeting was called to order at 08:40. Saku Egawa (Hitachi) volunteered to take minutes of the Tampa meeting. Tetsuo Kotoku provided a brief overview of the Burlingame Minutes. (robotics/2006-02-06) Action: The Burlingame minutes were unanimously approved. Tetsuo Kotoku reviewed today's agenda. (robotics/2006-02-07) Char Wales, presiding co-chair Joint Meeting with MARS-PTF and SDO-DSIG “Review of the initial submissions of Robot Technology Components RFP” Introduction – What is important for RTC specification (mars/2006-02-09)

Takashi Suehiro (AIST) provided background on the RTC RFP and the goals they hope to achieve with these submissions. Presentation – Robot Technology Components RFP Initial Submission – Noriaki Ando (AIST) (mars/2006-02-10) Noriaki Ando (AIST) presented the first initial submission Basing it on the existing SDO specification. Extending it and modifying it. Seeking to achieve a pseudo-real-time capability for distributed components. Presentation – Robot Technology Components RFP Initial Submission – Hung Pham (RTI) (mars/2006-02-11) Hung Pham (RTI) presented the second initial submission. Looking at how a robotics systems behaves – ‘behavioral layering in robotic systems’ – reactive nature of robotics systems – Range of requirements from (e.g.) tightly coupled to loosely coupled interactions. is there a common component model that can be used to bridge between these characteristics? Propose to establish a PIM that uses PSMs to address various “quadrants” of requirements. PIM needs to satisfy 3 basic requirements (in presentation). PIM based on Lightweight CCM (LW CCM), which is based on UML, COMPARE, and Constellation (an RTI Product) and PSM mapping based connector implementation such as DDS, CORBA/IIOP Discussion Char Wales (MITRE) discussed how what could be the next step – if it is desired – is to form an Evaluation Team so that the submitters and users can work together to help craft the revised submission. Victor Giddings (OIS) stated that such an action would be premature; that it should not happen until the first revised submissions are received. In addition, it would be better – for now – for the submitters to resolve/work out the differences (if they exist) between their submissions. Action: Make a progress review presentation at the upcoming St Louis meeting. PM Plenary Yun-Koo Chung, presiding co-chair Presentation – RFI Response: “Hitachi's needs for robotic system standards” – Saku Egawa (Hitachi) (robotics/2006-02-09) Saku Egawa talked about needs for standardization in Hitachi Ltd. and showed two examples of their robotic systems, a cleaner robot and a workmate robot. Their first priority for standardization is in the field of real-time control system, where platform for integration of multiple domains of knowledge is especially needed. Their cleaner robot is a small-scale system that has only a 28 MHz RISC processor, while their workmate robot is a more complicated system with four processors and message-based software platform. They expect Robotics TF to build scalable standards that can cover wide range of products in the company. Presentation – RFI Response: “Towards Plug and Play Robotics” – Abheek Kumar Bose (ADA Software Group) (robotics/2006-02-10) About robotics, ADA Software is primarily focusing on developing “intelligent components,” which mean distributed set of robotic components having basic intelligence and adaptability. Abheek Kumar Bose emphasized on the need for standardization by comparing the current situation of robotic development where interoperability is very low with very standardized automobile industry. He introduced his experiences in the Volksbot project at the Fraunhofer Institute for Autonomous Intelligent Systems. In the project, modular approaches in both in hardware and software are used. By combining the behavior modeling system “Dual Dynamics Designer” and the visual programming system “IConnect” model based development of autonomous robot became possible. His current project is to develop the Robot Modeller by extending the Control Designer Framework, an Eclipse based system developed by the Fraunhofer AIS. Presentation – RFI Response: “SEC's approach to the standardization of robotics systems” – Hiroyuki Nakamoto and Masayuki Nagase (SEC)

(robotics/2006-02-11) SEC has experiences in development of on-board computer of spacecrafts, software for cellular phones, and Internet systems. As for robotic systems, the company has advantages in the technologies, such as firmware on robotic systems, robot control and robot monitoring server applications, robotic content service systems. Their motivation for standardization is to make a cooperative system of the robot and its surrounding devices and services, such as neighboring robots, RFID tags, GPS, and Internet services. The presenters listed up the points for standardization about methods for detecting environment, detecting position, and adapting the robot to the environment. As an example, they introduced the OMA Download Architecture Specification for the cellular phone system. Presentation – RFI Response: “Development of Food Robots and Meat Processing Robots, and Request for Standardization of RTC” – Tomoki Yamashita (Maekawa MFG) (robotics/2006-02-12) Mayekawa’s robot divisions have been developing various meat processing robots. From 2003 to 2006, they participated in a joint research project for development of food handling robots that can pack foods in a lunch box. To handle foods with various shape, they developed an easy changeable hand-tool system. They also developed a harvest transportation robot, using the RT component system developed by AIST, “OpenRTM-aist.” Based on their experience, the presenter stated four requests for the RTC system: user-friendly development tools, support for non-PC based controller device including the programmable logic controller (PLC), “plug-n-play” function of RTC, and safety management for errors in hardware, communication, and software. Presentation – RFI Response: “RT service framework using IT infrastructure” – Wonpil Yu (ETRI) (robotics/2006-02-13) To realize an RT service for real-world, technologies such as perception of objects, behavior control (navigation, localization), and connectivity to IT infrastructure should be developed. Their approach to implement RT service is to decompose it into three conceptual spaces: physical space, semantic space, and virtual space. Standardization of interface between three spaces (API) is needed. Presentation – RFI Response: “A mobile robot software system architecture with unified sensory data integration” – Takashi Tsubouchi (Tsukuba Univ.) (robotics/2006-02-14) Intelligent Robot Laboratory of University of Tsukuba has been developing autonomous mobile robots “Yamabico family.” Tsubouchi pointed out that not only an software architecture or data flow, data structure should be discussed. He proposed a data structure of free space description, the Unified Sensory Data (USD). USD is a 2D scrolling ring buffer that contains an occupancy grid map of the vicinity of the robot and holds abstracted information of free pace independent from specific type of sensors. By using USD, behavior description program can be written independent from sensor types. Presentation – RFI Response: “Navigation of mobile robots including mapping, localization, and motion” – Nakju Doh Wonpil Yu?(ETRI) (robotics/2006-02-15) Navigation is a key component in mobile robots. The navigation technology includes three sub-techniques: mapping, localization, and motion. To solve the current problem of stand-alone robots, high cost and low performance, a client-sever system is used in the Ubiquitous Robotic Companion (URC) project. The mobile robot (client) sends information such as relative position, range data, and image data to the server over the TCP/IP network, and the server returns robot path and location. As a candidate for standard for navigation, the speaker presented data structures for mapping, localization, and motion. 15 February, Wednesday AM Plenary

Tetsuo Kotoku, presiding co-chair Presentation – RFI Response: “Response from AIST” – Olivier Lemaire (AIST) (robotics/2006-02-16) Olivier Lemaire introduced the use cases of the robotics technology in the Ubiquitous Functions Research Group, AIST and showed needs for standardization of robotics technology. “Robotic Space” is a robotic room for daily life support, which uses distributed wireless active RFID. “Librarian Robot” has a minimal on-board processing system and takes full advantage of infrastructure, such as ID tags, to do many usual robotic tasks. The system is constructed by integrating RT Middleware infrastructure and Web service infrastructure. Standardization is needed for re-using technology to develop new robot faster and cheaper by integrating COTS technologies, and for managing complexity of a broad and complex field needed for robotics. Standards are needed at all levels of abstraction, the model layer, the platform layer, the implementation layer, and the hardware layer. He also introduced the Japan’s joint national project on the Robot Technology Middleware. Presentation – RFI Response: “Current State of Robotics Script/Control Language Standards” – Lloyd Spencer (CoroWare) (robotics/2006-02-17) Robotics interfaces can be categorized as programmatic interfaces, protocol interfaces, scripting and control interfaces. All of the above interfaces can be defined using XML Web Services. XML Web Services should be considered as a viable model for local resource interfaces for arms, motors, sensors, local robotic function interfaces for localization, mapping, vision recognition, and remote robotic function interfaces for higher level navigation functions and tactical objectives. The presenter requested that OMG should create an RFI for Robotics Markup Language. Special Talk: “Lessons Learned About Software for Rescue Robots” – Matt Long (iSSRT, Univ. of South Florida) (robotics/2006-02-18) Matt Long of USF talked about a robotic software architecture design based on their experience on rescue robots. He listed desirable characteristics of an architecture of a distributed field robot, including incorporation of reactive and deliberative components, fault tolerance, adaptability in the face of changing operating conditions. To provide a consistent programming model, their Distributed Field Robot Architecture uses Java and Jini. DFRA has benefits of flexibility and critical capabilities owing to the robust middleware employed, while it has tradeoffs in complexity, performance overhead, and steeper learning curve. Hung Pham, presiding co-chair Presentation – RFI Response: “Development Framework for Mobile Robot based on JAUS and RT-Middleware” – Wataru Inamura (IHI) (robotics/2006-02-19) Approach of IHI to standardized robotic architecture is to use two existing open architectures, JAUS and OpenRTM-aist. JAUS defines application specifications of a mobile robot, such as software structure, function assignment to each component, messages between components, and the behavior of a component, while OpenRTM-aist implements components and message communication. A JAUS component is mapped to a RT-Component and JAUS messages are sent through the RTC InPort and OutPort objects. The state machine of JAUS component is mapped to the RTC state machine. Two examples of mobile robot system using the proposed framework were presented. Presentation – RFI Response: “An overview of PIM & PSM for SWRadio Components specification” – Jerry Bickle (PrismTech) (robotics/2006-02-20) SWRadio specifications include UML profile for SWRadio and SWRadio facilities. The UML Profile for SWRadio consists of the Generic Component Framework, a rich set of semantics for component and container based development, and Communication Channel & Equipment, which defines basic types and

properties for the communication channel and for each specific equipment. The SWRadio Facilities are optional interfaces for component behavior extensions, such as common layer for PDUs, error control, or flow control, networking layer, physical layer, and radio control. Robotics may use these facilities as appropriate and supplement these facilities with their own that are specific to the robotics domain. Presentation – RFI Response: “Response from Compare Project” – Virginie Watine (THALES) (robotics/2006-02-21) Virginie Watine made a talk on a component / container model for real-time / embedded software defined by the Compare Project. The model is based on the Lightweight CCM with adaptations specific to RT/E systems. To isolate timing properties, a concept of Activity, which represents an execution path, is introduced. For interaction between components, Connectors, which capture captures interaction logics in a fully reusable manner, are used. In the robotics domain, profiling for robotics could be defined, such as dedicated Connectors, Container Services, and Predefined Components. Presentation – RFI Response: “Robot Server Middleware: CAMU” – Seung-ik Lee (ETRI) (robotics/2006-02-22) The basic concept of the URC consists of a ubiquitous sensor network, a high-performance computer, and a hardware robot. The URC server expands the robot functions and services, improves the context-awareness, and enhances the robot intelligence. The server system, robots, and devices communicate by the PLANET framework. PLANET is based on the remote method invocation and has light-weight protocol to minimize the communication load. Presentation – RFI Response: “Toshiba's approach to RT standardization and where the standardization is needed” – Fumio Ozaki (Toshiba) (robotics/2006-02-23) Toshiba started to adopt the object oriented technology for robot software development. The idea of the Open Robot Controller Architecture is to use standard IT, concentrating on robot control, and define the framework and standard APIs. From lessons learned from their experiences, they use Python for scripting language, HORB for networking middleware, UPnP for home appliances connection. The presenter pointed out several issues needed to be discussed. He also stated that high level technologies that should be developed in the future, for example, AI, are not for standardization because a standard should not prevent the development of new technologies. Tetsuo Kotoku, presiding co-chair Summary of RFI responses and working group discussion (robotics/2006-02-24, -25) Olivier Lemaire reported the result of the survey on possible working groups gathered by email just this meeting. There were answers from 5 organizations in Japan, 5 in Korea, 2 in US, 1 in France, and 1 in India. The survey showed that the needs for standards and intention of participation are high and the robotic system infrastructure has got the highest score. Based on the survey, four working groups were defined and volunteers for each potential working group are listed as: Robotic Infrastructure WG: Rick Warren (RTI), Noriaki Ando (AIST) Robotic Service WG: Soo-Young Chi (ETRI), Olivier Lemaire (AIST) Robotic Tools WG: Abheek Bose (ADA Software) Robotic Profiles WG: Seung-Ik Lee (ETRI), Bruce Boyes (Systronix) Working groups should start discussion by email and the founding chairs should report on the mission statement and real chairs in the next technical meeting. Motion: To recommend an extension of the submission date for the Robotics Systems RFI (mars/05-06-12) to 3 April 2006, 3 weeks before the St. Louis meeting by Yun-Koo Chung(ETRI). Established Task Force quorum of 3 Second: Olivier Lemaire (JARA) Discussion: none

WB proposed: Masayoshi Yokomachi (NEDO) No objection to WB PASSED Publicity Activity (robotics/2006-02-26) Abheek Bose proposed to start the publicity activity to promote the OMG robotics standardization especially in Japan, EU, India, and SE Asia. A motion to setup the publicity subcommittee was approved. The voluntary members of the subcommittee are: Abheek Bose (ADA Software) Olivier Lemaire (AIST) Yun-Koo Chung (ETRI) Masayoshi Yokomachi (NEDO) The initial mission of the subcommittee is to make a 4 page flyer and web pages to invite people to the OMG Robotics DTF. Volunteers for attending RoboBusiness event being held in June were requested but no organizations answered. It was decided to propose standardization workshop for IROS 2006 in October. Tissue Kotoku (AIST), Yun Koo Chung (ETRI), and Makoto Mizukawa (Shibaura Institute of Technology) volunteered to become co-organizers for the workshop. ETRI will host the URC Technical Cooperation Forum, March 9, Seoul. Hung Pham (RTI) and an OMG staff will make a talk on the robotics standardization activity. Motion: To charter Publicity Sub-Committee by Abheek Bose (ADA Software). Established Task Force quorum of 3 Second: Yun-Koo Chung (ETRI) Discussion: none WB proposed: Masayoshi Yokomachi (NEDO) No objection to WB PASSED Next Meeting Agenda Discussion The tentative agenda of the next technical meeting was decided as follows: Monday: WG meeting & Steering committee Tuesday-Wednesday: Plenary meeting RFP progress report (MARS joint meeting) RFI response presentations Roadmap discussion Contact reports ADJOURNED @ 18:00 Participants (Sign-in) Steering Committee: 13 February, Monday (23 participants)

• Tetsuo Kotoku (AIST) • Yun Koo Chung (ETRI) • Hung Pham (RTI) • Yung-Jo Cho (ETRI)

• Makoto Mizukawa (Shibaura Institute of Technology) • Soo-Young Chi (ETRI) • Masayoshi Yokomachi (NEDO) • Saku Egawa (Hitachi) • Tomoki Yamashita (Mayekawa MFG) • Fumio Ozaki (Toshiba) • Seung-Ik Lee (ETRI) • Wonpil Yu (ETRI) • Rick Warren (RTI) • Ho Chul Shin (ETRI) • Roy Bell (Raytheon) • Wataru Inamura (IHI) • Hiroyuki Nakamoto (SEC) • Masayuki Nagase (SEC) • Hideo Shindo (NEDO-DC) • Olivier Lemaire (JARA) • Takashi Suehiro (AIST) • Noriaki Ando (AIST) • Abheek Bose (ADA Software)

Plenary: 14 February, Tuesday (26 participants)

• Tetsuo Kotoku (AIST) • Yun Koo Chung (ETRI) • Hung Pham (RTI) • Claude Baudoin (Schlumberger) • Takashi Suehiro (AIST) • Soo-Young Chi (ETRI) • Masayuki Nagase (SEC) • Hiroyuki Nakamoto (SEC) • Masayoshi Yokomachi (NEDO) • Takashi Tsubouchi (University of Tsukuba) • Roy Bell (Raytheon) • Ho Chul Shin (ETRI) • Mitola (MITRE) • Hideo Shindo (NEDO-DC) • Tom Anderson (Objective Interface) • Rick Warren (RTI) • Olivier Lemaire (JARA) • Noriaki Ando (AIST) • Wonpil Yu (ETRI) • Abheek Bose (ADA Software) • Wataru Inamura (IHI) • Saku Egawa (Hitachi) • Fumio Ozaki (Toshiba) • Yung-Jo Cho (ETRI) • Seung-Ik Lee (ETRI) • Roger Burkhart (Deere & Company)

Plenary: 15 February, Wednesday (34 participants)

• Tetsuo Kotoku (AIST) • Yun Koo Chung (ETRI) • Hung Pham (RTI) • Saku Egawa (Hitachi) • Fumio Ozaki (Toshiba) • Abheek Bose (ADA Software)

• Ho Chul Shin (ETRI) • Takashi Suehiro (AIST) • Masayoshi Yokomachi (NEDO) • Jerry Bickle (Prismtech) • Matt Long (iSSRT) • Juergen Boldt (OMG) • Duame Clarkson (Deere & Company) • Gerardo Pardo (RTI) • Feed Waskviewicz (OMG) • Roger Burkhart (Deere & Company) • Claude Baudoin (Schlumberger) • Shinobu Koizumi (Hitachi) • Noriaki Ando (AIST) • Hideo Shindo (NEDO-DC) • Takashi Tsubouchi (University of Tsukuba) • Wataru Inamura (IHI) • Yung-Jo Cho (ETRI) • Seung-Ik Lee (ETRI) • Hiroyuki Nakamoto (SEC) • Masayuki Nagase (SEC) • Tomoki Yamashita (Mayekawa MFG) • Lloyd Spencer (CoroWare) • Rick Warren (RTI) • Soo-Young Chi (ETRI) • Tom Anderson (Objective Interface) • Olivier Lemaire (JARA) • Jeff Simith (IDTS) • Virginie Watine (Thales)

Prepared and submitted by Saku Egawa with the assistance of Soo-Young Chi and Olivier Lemaire.

Robotics-DTF/SDO-DSIGPlenary Meeting

April 24, 2006St. Louis, MO, USA

Hilton St. Louis AirportPoplar

robotics/06-04-07

Approval of Tampa Minutes • Ask for a volunteer (minutes taker)

– Hung Pham– Yun-Koo Chung

• Tampa Minutes review[Robotics] The first plenary of Robotics-DTF. The

deadline of Robotic Systems RFI was re-extended. We had 1 special talk (Matt Long, USF) and 14 RFI response presentations. Make 4 groups for WG activities.

[SDO] Review of the initial submissions of Robot Technology Components RFP.

Review AgendaTuesday, April 25, 2006

10:05-12:20 Welcome and Review Agenda10:20-11:20 Special Talk: Prof. Chris Gill 11:20-12:00 RFI response presentation

13:00-14:00 Special Talk: Prof. Jean-Christophe Baillie14:00-16:20 RFI response presentation 16:20-17:40 WG (Infrastructure)


Poplar

Review AgendaWednesday, April 26, 2006 Poplar

08:30-09:50 RFI response presentation 10:40-11:40 WG Reports and Roadmap Discussion11:40-11:50 Contacts Report11:50-12:00 Next meeting, etc.12:00 Adjourn

14:00-18:00 WG (Infrastructure)16:00-18:00 WG (Service)


Document Numberrobotics/2006-04-04 Final Agenda robotics/2006-04-05 Steering Committee presentation robotics/2006-04-06 Tampa Meeting Minutes [approved]robotics/2006-04-07 Opening presentation robotics/2006-04-08 Robotics-DSIG Roadmaprobotics/2006-04-09 Special Talk: Chris Gill presentationrobotics/2006-04-10 Hyun-Sik Shim presentationrobotics/2006-04-11 Special Talk: Jean-Christophe Baillie presentationrobotics/2006-04-12 Toshihiko Morita presentationrobotics/2006-04-13 Ho-Chul Shinpresentationrobotics/2006-04-14 Soon-Hyuk Hong presentationrobotics/2006-04-15 Seok Won Bang and Y. H. Kim presentationrobotics/2006-04-16 Hiroyuki Nakamoto presentationrobotics/2006-04-17 Service WG activity report robotics/2006-04-18 Profile WG activity report robotics/2006-04-19 Infrastructure WG activity report robotics/2006-04-20 Contact Report: KIRSF robotics/2006-04-21 Contact Report: ORiNrobotics/2006-04-22 Robot Technology Components RFP Progress Report in MARSrobotics/2006-04-23 Summary Report of Robotic Systems RFI robotics/2006-04-24 DTC Report Presentationrobotics/2006-04-25 Meeting Minutes - DRAFT

Publicity Activities

• 4 page fly sheetDraft of Abheek@ADA SoftwareAbheek@ADA Soft, Olivier@AIST,Chung@ETRI,Yokomachi@NEDO

Action:Send each organization logo to Abheek.

4 page fly sheet will be authorized in Boston4 page fly sheet will be authorized in Boston4 page fly sheet will be authorized in Boston

Publicity Activities• Korea-Japan RSW2006

Friday, June 16, 2006, Jeju Island, KoreaChung@ETRI

• RoboBusiness2006June 20-21, 2006, Pittsburgh, PA, USAhttp://www.robobusiness2006.com/Jon Sigel and Bruce@Systronix

• IROS2006 WorkshopOctober 9-15, Beijing, Chinahttp://www.iros2006.org/Kotoku@AIST, Chung@ETRI, Mizukawa@Sibaura-IT

• SICE-ICASE International Joint ConferenceOctober 18-21, Pusan, Koreahttp://sice-iccas.org/Mizukawa@Sibaura-IT

Robotics-DTF Plenary Meeting •Guest Presentation•WG reports & Roadmap discussion•Contact reports•Resolution

Wednesday :

Monday :

Next Meeting Agenda June 26-30, 2006 (Boston, MA, USA)

RTCs RFP revised submission review [MARS]Steering Committee

Monday-Tuesday, Thursday :WG activities

Roa

dmap

for R

obot

ics

Act

iviti

es ro

botic

s/20

06-0

4-08

Item

Stat

usTa

mpa

St. L

ouis

Bos

ton

Ana

heim

DC

TBA

TBA

Feb-

2006

Apr

-200

6Ju

n-20

06Se

p-20

06D

ec-2

006

Mar

-200

7Ju

n-20

07R

obot

Tec

hnol

ogy

Com

pone

nts

RFP

(SD

O m

odel

for r

obot

ics

dom

ain)

In P

roce

ssIn

itial

Subm

ittio

nPr

e-re

view

Rev

ised

Subm

ittio

nis

sue

SD

O m

odel

for x

xx D

omai

nno

pla

ndi

scus

sion

draf

t RFP

RFP

Cha

rter o

n R

obot

ics

WG

in S

DO

done

Oct

-200

4

Rob

otic

Sys

tem

s R

FI[R

obot

ics:

Initi

al S

urve

y]In

Pro

cess

Res

pons

ePr

esen

tatio

nR

espo

nse

Pres

enta

tion

revi

eww

hite

pape

rW

hite

pape

r

Flye

r of R

obot

ics-

DTF

[Pub

licity

Sub

-Com

mitt

ee]

In P

roce

ssdi

scus

sion

disc

ussi

onis

sue

ver.1

.0

Loca

lizat

ion

Serv

ice

RFP

[Ser

vice

WG

]In

Pro

cess

disc

ussi

ondr

aft R

FPre

view

RFP

RFP

Initi

alSu

bmitt

ion

Use

r Ide

ntifi

catio

n R

FP[S

ervi

ces

WG

]Pl

anne

ddi

scus

sion

draf

t RFP

revi

ew R

FPR

FP

Prog

ram

mer

s A

PI: T

ypic

al d

evic

e ab

stra

ctin

terf

aces

and

hie

rach

ies

RFP

[Pro

file

WG

]

Plan

ned

Topi

cdi

scus

sion

draf

t RFP

revi

ew R

FPR

FP

Har

dwar

e-le

vel R

esou

rces

: def

ine

reso

urce

pro

files

RFP

[Pro

file

WG

]

Plan

ned

Topi

cdi

scus

sion

draf

t RFP

revi

ew R

FPR

FP

Dep

lym

ent a

nd C

onfig

urat

ion

RFP

[Infr

astr

uctu

re W

G]

Plan

ned

Out

line

disc

ussi

ondr

aft R

FPre

view

RFP

RFP

etc…

Futu

reTo

pic

disc

ussi

ondr

aft R

FPre

view

RFP

RFP

Cha

rter o

n W

Gs

[Ser

vice

, Pro

file,

Infra

stru

ctur

e]do

neA

pr-2

006

Gro

upin

gis

sued

Cha

rter o

n R

obot

ics

TFdo

neD

ec-2

005

Cha

rter o

n R

obot

ics

SIG

done

Feb-

2005

Rob

otic

s In

form

atio

n D

ay[T

echn

olog

y S

how

case

]do

neJa

n-20

05

��

��

��

�� !"�� #��"�$�

� �� !"��%��!"�&��'( �"�'))*"�� #��"�$�"��&

��#��$ ��"��!%%&'(�)'��'*+*,-.��/0��!%%&'(�))��%)1*��!%%&'(�)%��1''',"�.�/

��#��2#��3��2��4��5��$��4��5��$�4��5��$�67��4��5��$�6�� 8��

4��5��$�� 3��9��2��-�:��$��;

2 - Chris Gill – 4/25/2006

��

� ��6��$< ��6$��6��=��$

� ��2��#�< 3��5��$5��$6��< ��$��$��66��#��6��6��#��

� 3��6��$>��2��$��?��@< .=2=��6��#��?��< .=2=��6��#��$��6��6��

� �5��2��#��2��66��5��$��#��,��$�6��$��5��5��/

3 - Chris Gill – 4/25/2006

��5��2.A��5�� #��2

� 8��6��2��6��< .A��2��2��$��5��9

� ��66��2�B#��$��6��$< ��2��5��$�#��2��#��

� 3�$#��6��6��$��@< !�� C��.A��5��DDC��< !��E��6�!"��2��2��< !��5��#��2��

low bandwidth radio link

virtual folder,images

adaptationmiddleware

transmissionmiddleware

cockpitdisplays

serverside

clientside

imageserver

Collaborative research with Boeing, BBN,Honeywell Technology Center, supported

by Boeing/AFRL contractF33615-97-D-1155/0005 (WSOA)

4 - Chris Gill – 4/25/2006

�#��8��#��5��2$��#��

� ��'=)< F��C��2#�2��$��$��< ��66��6��6��#��

� F�2��2�� < ��$��$��,��/��6�2#��< ��66��6��6�2#��6

� ��'=G< "�#22��$��#��2��#��< ��66��6��A��$��5��

5 - Chris Gill – 4/25/2006

��2$��#�$8��'=)

� F��C��2#�2��$� F��$� ��"�� 66�

< ��6��6��#��

6 - Chris Gill – 4/25/2006

��F��CF��2#�2��$

� 8 F��5��$��6��$��5�� H��6��,8��/

< .��8"��H��8 ��=� ��6��6��6��5��2��

< ��#�� 5��9�� #��2�� 6��6��#��

< :��9��5��#��A��=< �+,�� -��.�/��

ORB ORB

Stub

Client

Skeleton

Servant

IIOPmessage

objectreference

7 - Chris Gill – 4/25/2006

.A��2 ��2�!��6��F��F��$

� ��#��$��6��66��< ��#��$��#��5��#��A��2��=< �5��6��$"��8;��9��6��< ��A3��9��F$�A��74��F��#ACF��

� ��5��9��2�B#�#��2��9��2��=

��"�&��0��1

8 - Chris Gill – 4/25/2006

��'=)��"��

� F��6��$�� #,��/��,�$�/I�6�� 9��E��#��6��2��B#��#66��2

// Define two lanesRTCORBA::ThreadpoolLane high_priority ={10 /*Prio*/, 3 /*Static Threads*/, 0 /*Dyn Threads*/ };

RTCORBA::ThreadpoolLane low_priority ={5 /*Prio*/, 2 /*Static Threads*/, 2 /*Dyn Threads*/};

RTCORBA::ThreadpoolLanes lanes(2); lanes.length (2);lanes[0] = high_priority; lanes[1] = low_priority;

RTCORBA::ThreadpoolId pool_id =rt_orb->create_threadpool_with_lanes

(1024 * 10, // Stacksizelanes, // Thread pool lanesfalse, // No thread borrowingfalse, 0, 0); // No request buffering

// Define two lanesRTCORBA::ThreadpoolLane high_priority ={10 /*Prio*/, 3 /*Static Threads*/, 0 /*Dyn Threads*/ };

RTCORBA::ThreadpoolLane low_priority ={5 /*Prio*/, 2 /*Static Threads*/, 2 /*Dyn Threads*/};

RTCORBA::ThreadpoolLanes lanes(2); lanes.length (2);lanes[0] = high_priority; lanes[1] = low_priority;

RTCORBA::ThreadpoolId pool_id =rt_orb->create_threadpool_with_lanes

(1024 * 10, // Stacksizelanes, // Thread pool lanesfalse, // No thread borrowingfalse, 0, 0); // No request buffering

Thread Pool with Lanes

PRIORITY10

PRIORITY5

9 - Chris Gill – 4/25/2006

3��66�8��2��

� ��5� ��2� ��#��#��,�=2=��6��/� "��2��5��#��$�� #��$��#�� 2��2��A��$� ��#��66��5�=6��5�=6��#�� ,��#��/��5��$��@

12

43

Acoustic Waves (kHz Range)

Structure with Embeddedor Bonded Piezoelectric

Transducers

10 - Chris Gill – 4/25/2006

��2��2��

� ��#��#��2��5��$�6��< ��#�� 6��5�6��#��

� .A��6��#��$��< .=2=�!��$��9��$��2��#��

� -��#�$��6��#��B#��

� !#��< ��$C��E��< ��6��#��E��

11 - Chris Gill – 4/25/2006

��"��$��66��

Simple ObjectAdapter

Operation lookupand dispatch

Foo()

Bar()

Skeleton code(using ACE_CDR)

Unmarshallparameters

Call to implementation

Reactor

AcceptorConnection

CacheORB

Reactor

AcceptorConnection

CacheORB

Stub code(using ACE_CDR)

Marshallparameters

Remote call

11

2

3

4Could be avoided forhomogenous nodes

1)

Only a subset of GIOPmessages

2)

3) Simple Life cyclemanagement

4) Hash-table vs linearsearch

12 - Chris Gill – 4/25/2006

!��.��

0

200

400

600

800

1,000

1,200

1,400

1,600

1,800

2,000

Fo

otp

rin

tin

KB

NodeNodeRegistry

Node 376 1800 567 1738 509

NodeRegistry 324 1778 549 1725 492

ACE TAO nORBcompile

optimized TAO

compileoptimized

nORB

ACE costs 212KB; nORB+ACE costs 345KB; TAO+ACE costs ~1.7MBNode application code alone costs 164KB

13 - Chris Gill – 4/25/2006

"��2��#��2��2��5��2��

14 - Chris Gill – 4/25/2006

��2$��#�$8��#��$

� �� 2��2< "��2#�2�C��< ��5��5��6��E�C��2�E�

� ��'=)��J��< .=2=��E��=< :��2�6��#��=2=�6��$

� :��5��A��#��< .=2=��2��$��#��5��@

< ��#��6��9��2��< !#��K��2��6��L�$��

15 - Chris Gill – 4/25/2006

��2$��#�$88�F�2��2��

� ��$��$��6�2#�� B#��E��66��6��6�2#��6

� ��9��$��C��6�2#��6��$��< #��6��2��$��E��#��

16 - Chris Gill – 4/25/2006

��5��6�� .5��#�� #��H��#��2, ��/ ��

< .=2=��M�5�� 8< ��6��2��25��,��2#�2�/��

� �� < .=2=��'=)�'=G< .�6��5��

� �� < .=2=�� ,�� /�.M�CMG..< ��6��5��2��2��#2��5��6�2#��

� �� < .=2=��8��2��.��,�8��/�J��.M�< .�6��6�2#��5��6< &�� 2 ��3

17 - Chris Gill – 4/25/2006

��5��2.A��

� ��6��5��,��2/� ��$��#�� 6��A��$5�� ,��/��6�2#��$

< .=2=��6��6�#��=� ��#��6�2#��6�$��

< .=2=��#��E��$��,��/��< ��2�6��$��$��2��

Heads-UpDisplay

GPS AirframeRateGenerator

18 - Chris Gill – 4/25/2006

��5�= $��6�2#��

� $��6�2#��< ��$>��$��

� #�� FF��; F��2< "��

� ��2C��2�� #��6��=��C=��6��,�=2=��A3��9�/

� ��6�2#��< �5��#��66��< !��#��5��2��$�#��6��A��$��< 4��9��2��K��L��< 4��#��5��6�2#��E��

19 - Chris Gill – 4/25/2006

��5�= $��6�2#��.A��

� ��6��6��$��6�2#��< 4��A��5��

� ��6$��#��6��6��66�� #��2��

< "��#8�G=(�:E�"4�()) �� ('G7��< ��F��#AG=1='*��74��F��#A��

� �#�� FF�6��$��6�2#�� 66��2��$6��A��

< .A��#��8��)=1='C��'=1='C��.(=1='

20 - Chris Gill – 4/25/2006

��6��$

� 3��#��6��#��< ��5�='))��6��< G��6�2��#��

� 3��6��#��< ��5��

< ��5��6�2��#��

� �66��#��< F��2 FF��2��

� $�� /�� < ; F��2��

� ��!

0.1

1

10

100

1000

0 5 10 15 20 25 30 35

Tim

e (m

sec)

Samples

Dynamic RT-CIAODynamic CIAOStatic RT-CIAO

Static CIAO

21 - Chris Gill – 4/25/2006

��5��

� ��5��6�2#��G�� 2��#��6��66��< '))�5�=')��6��

� ��2�5��< ��6��9��2��6��#��5��

< G��6�2��#��6��5��

0.1

1

10

100

1000

0 5 10 15 20 25 30 35

Tim

e (m

sec)

Samples


Static CIAO

Configuring RT-CORBA features

22 - Chris Gill – 4/25/2006

:��

� :��2��

� ��6�2#��2��A��5��< ��$< ��5��

� F��5�=��9��#��6��66��

� ��6��#��< ��?��2��6��$

0.1

1

10

100

1000

0 20 40 60 80 100 120 140

Tim

e (m

sec)

Samples


Static CIAO

23 - Chris Gill – 4/25/2006

�8��5�="�8� ��6�2#��

� �8��?��6�2#��2?�"�8� ��6��< �#��6�2#��6��A��$C��66��2��6��$< �� ,.A��8��6��/5�=�DD ,!�N��/��

Create home

Createcomponentfactory

Createcomponentimpl

Createsupport for facet,receptacle and equivalentinterface

Init Receptacle,EventSupplier &EventSink

Createconnection

Installhome

Createcomponent

Register component(e.g. with a naming

service)

CIAO PRISM

Create homeexecutor

Create homeservant

Register with POAand create objectreference to home

C1

C2

C3

C4

C1.1

C1.2

C1.3

P1

P2

P3

P4

P5

24 - Chris Gill – 4/25/2006

�8��5�="�8� ��6�2#��.A��

� "��6��< ��('')�GG&%� .��< "�O1')()) :E��C('G �� < �A3��9�(=1=G< "��A=1,��/5��6�8��C��6�2#��

� :�2��#��#��#��9��#��< (��#��A3��9�tickGet()< 1)��#��A3��9�sysTimestamp()

1 2 3 4 5 6

7 8 9101112

AB

12x

6x

8x

2x

9x

3x

10x

4x

11x

5x

7x

1x

Eth

ern

et

A

12x

6x

8x

2x

9x

3x

10x

4x

11x

5x

7x

1x

C ��

��

25 - Chris Gill – 4/25/2006

"�8� C�8��:��

� "�8� ��< �DD��H��

� ��$�� H��E��

� �8��< �DD��H��P< P��#��E��

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 0.5 1 1.5 2 2.5 3

Freq

uenc

y

Creation Time (msec)

PRISMCIAO

home activation, etc.

26 - Chris Gill – 4/25/2006

"�8� C�8��

� �2��DD5�=��66��

� ��A��5��8��6�2#��

� ��#��< 6��#��6��

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 0.5 1 1.5 2 2.5 3 3.5 4

Freq

uenc

y


PRISMCIAO

Bounded by 4 msec

component

activation, etc.

27 - Chris Gill – 4/25/2006

"�8� C�8��.��

� F��A��5��6�2#��

� �2��6��DD5�=��66��

� ��66��6��6��A��$

0

0.1

0.2

0.3

0.4

0.5

0.6

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2Fr

eque

ncy


PRISMCIAO

CORBA connection

setup cost

28 - Chris Gill – 4/25/2006

��2$��#�$88��#��$

� ��2�5��6�2#��< �5��C6��#��5��

� �� FF��2��2��< ��$��5��< 8��2��; F��2@

� "�8� >�8��66�� 6��A��$��< �DD��5�=��< 8��2��A�#��6��H��$��@

� ��6�2#��5��#�� .< 8�� $��>��6�2#��6��< ��CC��#��=��=�#��=��#C ��=��

29 - Chris Gill – 4/25/2006

��2$��#�$888��'=G

� ��#�� "�#22��$��#��2� ��66��6��A��$��5��

30 - Chris Gill – 4/25/2006

��5�� 5��#��6��2��2��

< ��#��#��6�� 8=�=��2��#��2��#��B#��5�� $��#��#��2��2��=

< 8��2��#22��C�$��#��2�� 2��2��

< !��A��6�$��6��< "��5��6��#��5��< "��5��66��2��#��6��

31 - Chris Gill – 4/25/2006

��'=G8��

� 8��6 ��#��< ��$��2��

� ��5��6��#��$�5�� 5�=��#��$��#�� 6��

� $��#��2��5��6��9< !��A��6��#��< �� #��

� ��9�< J#��6$��6��2��2��#��< ��#��2��B#��

32 - Chris Gill – 4/25/2006

��'=G��

� ��#��Q ��#��#��$�� #��2��2��Q 2�5��$��2��#��2��$� F��#��6�A��#��Q ��#��#��$�#��2� $��#��Q ��6��#��2��$

Object (Servant)

IDLStubs

IDLSkeletons

ORB Core

DynamicScheduler

BSS-A

ESS-A

Client

Service Context

Schedulingsegment

A

ObjectAdapterDynamic

Scheduler

BSS-B

ESS-B

Service Context

Schedulingsegment

B

1 Distributable thread

2

Current locus of execution3

B: MUF

A: EDFA: EDF

Segment scheduling policies4

55

33 - Chris Gill – 4/25/2006

8��G ��#��

� 3��$G��$��5��#��5�#��9��< �#��5�,��A�/6��$��< ��#2��66��#��#��2��

� ��#��< 3��9��2��66��$��#2��#��2��

BSS - A

BSS - B

ESS - A

ESS - B

Host 1 Host 2 Host 3

2 - WayInvocation

2 - WayInvocation

DT1

BSS - C

ESS - C

DT2

BSS - D

ESS - B

BSS - E

ESS - E

DT3

34 - Chris Gill – 4/25/2006

��2 ��#��

� ��#��66��$�< ��2��#��#��< ��#��2��spawn() ��< ��#��9��2��$��#�,��$/��5��

� -��#��#��2��

Host 2

BSS - A

ESS - A

1 - WayInvocation

Host 3

DT3DT4

Host 1

spawn ()DT1

DT2

35 - Chris Gill – 4/25/2006

��#��"��.A�� #��#��5��< ��6��#��

< ��4��.��< 3��8�"��B#��< ��6�8�"��B#��< 3��8�"��$��< ��6�8�"��$

� 8��#��#��2��6��#��< ��,��#��/��#��$��#��C��$

Object(Servant)

IDLStubs

IDLSkeletons

ORB Core

DynamicScheduler

in args

out args + return value

Operation ()

BSSorSpawn

ESS

USS

Client

ServiceContext

12

3

4

1. BSS - RTScheduling::Current::begin_scheduling_segment() orRTScheduling::Current::spawn()

2. USS - RTScheduling::Current::update_scheduling_segment()3. ESS - RTScheduling::Current::end_scheduling_segment()4. send_request() interceptor call5. receive_request() interceptor call6. send_reply() interceptor call7. receive_reply() interceptor call

7

5

6 ObjectAdapter

36 - Chris Gill – 4/25/2006

��#��2

CV

CV

1510

Ready Queue of Distributable Threads

+ 8

1510 8

New Distributable Thread

Ready Queue of Distributable Threads

CV

CV

CV

CV

CV

CV - Condition VariableImportance

- Distributable Thread

� ��6��I�6��#�� 9�B#�#��2��6�� 5��'�'��#�� 2��#��

37 - Chris Gill – 4/25/2006

� ��6��#��2

� ��#��6��

� -��$��

� ��C��66��6��$��#��2��,�=2=��#��#��2/

��C��#��2��9

38 - Chris Gill – 4/25/2006

��8��$��8��#��

Host 1

RTCORBA 2.0Scheduler

Host 2

RTCORBA 2.0Scheduler

DT<GUID, TID>

<GUID, TID>

Binding of a single DT totwo different OS threads

DT carries schedulingparameters with it

� ��66��6��< ��2��2��6��#��< ��6�2#��2��#��2��5��$< �#��2��6��66��6��A��#��

Can cancelfrom eitherendsystem

39 - Chris Gill – 4/25/2006

��6��2�,��/.A�� #��#��6��2�

< �5��9��2�62�� 5��66��#�� :��5��#��$�� #��#��<GUID,tid> �� 3��#��@

H o s t 1 H o s t 2

O ST h r e a d

1

D T 1

t s s _ w r i t e

t s s _ r e a d

O ST h r e a d

2

O ST h r e a d

1

D T 2

40 - Chris Gill – 4/25/2006

��.#��9�TSS Key Create:

0

500

1000

1500

2000

2500

3000

3500

4000

1 51 101 151 201 251 301 351 401 451 501Number of Keys Created

Tim

e(n

sec)

EmulatedNative OS

TSS Write/Read:

0

500

1000

1500

2000

2500

3000

1 101 201 301 401 501 601 701 801 901 1001Number of Successive Iterations

Tim

e(n

sec)

Emulated WriteEmulated ReadNative OS WriteNative OS Read

� "��#��9��< ��#��G=*�:E"1�('G7��('G ��$

< ��:��O=%��< ��$< ��C��$��9�$

� 4��2��$�69�$��< ��$��#��69�$��.��

< .#��RG#��9�$��

� F��2��#��R'=(#��R=(#��

41 - Chris Gill – 4/25/2006

��#��

� ��A��#��5�� "��$��6��

< ��$��?��#��K��9L< ��6��

� ��#��< ��5�9��5��#��< ��A��#��2��,��#��#��/

B S S - A

c a n c e l D T

P r o c e s s t h ec a n c e l a t n e x t

s c h e d u l i n g p o i n t

P r o p a g a t ec a n c e l

H e a d o f D T

H o s t 1 H o s t 2 H o s t 3

D T c a n c e l l e d

42 - Chris Gill – 4/25/2006

��2$��#�$888��#��$

� ��'=G��2�5��6�� $��#��2�6��#�� 2��6��2��

< #��2��6��6�� '=G��

< ��#��6��6��$�5��< ��CC��#��=��=�#��=��#C ��=��

43 - Chris Gill – 4/25/2006

��#��2��9�� 5��2��2��66�

< ��6$P< ��

� �6��$��< 8��$��C��2#�2��$< ��6�2#��#��< "��E��J��

� :��5��?��5��5��$��2< �5��#��A��H#�2��3��

� 3��#2��5��2�6�� 5��2��6��#�2��2��

� ��9�$��?��5��#��$��< ��$��5��2��< ��$��5��2��

44 - Chris Gill – 4/25/2006

!�� 8�6��

� �5��#�$< ��=��=�#��=��#CR��2��C" !C��MS3��=��6

� ��6��< ��=��=�#��=��#CR��2��C" !C��)1S��=��6

� ��'=G< ��=��=�#��=��#CR��2��C" !CM��S��'=G=��6< ��=��=�#��=��#CR��2��C" !C��)(S �.�=��6

� $��#��2< ��=��=�#��=��#CR��2��C" !C�$��=��6< ��=��=�#��=��#CR��2��C" !C��S��=��6< ��=��=�#��=��#CR��2��C" !C��)(S2��#��=��6< ��=��=�#��=��#CR��2��C" !C��)(S �� =��6

� ��6�2#��< ��=��=�#��=��#CR��2��C" !C��)1S��=��6< ��=��=�#��=��#CR��2��C" !C��)1S��=��6

Hyun-Sik ShimTelecommunication R&D Center

Applied Technology Lab.

SAMSUNG ELECTRONICS CO., LTD.

Robotics/2006-04-10

Sensing

Processing Action

Conventional Robot

URC : Ubiquitous Robotic Companion

The main approach of URC is to distribute these functional components through the network, and moreover, to fully utilize external sensors and external processing servers.

The URC server plays an important role with the URC infrastructure in providing functions of various technical components required by URC robots or clients.

Clu

ster

ing

Serv

ice

URC Main ASR

TTS coordinator

Face Recognition

Motion Detect

Agent

Load ReportLoad Information

URC protocolDialog

Action/Emotion

Remote Monitoring

RSS

SMS Transmit

MO Receving

Authenticationprofile

Speech/soundprofile

Videoprofile

Robot Control/Monitoringprofile

Contents profile

Streaming profile

Call profile

E-mail POP3

CP Connectivity

Call

Streaming

Sync

TTS

Encodingg Mobile Encoding

CAMUS(Context Aware Middleware for URC System)

RTP/RTCP

CAMUS protocol

SIP protocol

URC contents protocol

The protocol that the component named ‘URC Main’ adapts, is URC protocol within URC serverMainly, It used by URC robots or URC Clients.In order for other server system (ex. CAMUS) in the URC server group to use main function, URC protocol has to be utilized. The URC client/server communication protocol is the application protocol of TCP protocol.

Ping HTTP Telnet FTP URCProtocol

traceroute DNS SNMP NFS

TCP UDP

ICMP IP IGMP

ARP Data Link RARP

media

URC framingFraming of URC message adapts an binary format for the efficiency andnumerous data contained in the URC messages borrows the data format of UDR (URC protocol Data Representation)

URC encodingURC messages are encoded with “little-endian” format.

TYPE Corresponding to C++ DESCRIPTION

byte char 1-byte integer or character

short short 2-byte integer

integer int 4-byte integer

float float 4-byte single-precision floating point

double double 8-byte double-precision floating point

string[N] char [N] Fixed-length string data

string<M> char [] Variable-length char arrary

opaque[N] char [N] Fixed-length opaque data ( binary data )

opaque<M> char [] Variable-length opaque data

T[N] T [N] Array[N] of type T

T<M> T [] Variable-length array of type T

structure struct structure

URC authenticationEvery URC robot and URC client pass through authentication process to be identified into users and robots and then grant themselves of the necessary rights.Pre-registered ROBOT ID(MAC address) identifies URC robots and URC clients authenticate themselves with user ID and password.

URC robot ACK (acknowledgement)Most jobs done by robots are relatively time-consuming.

moving, gesture, TTS speakingServer must be acknowledged with the start and the end of the job in the form of events in that the synchronizations of URC robots match with other functions. The URC server then matches the synchronizations of the jobs through ACK.

HB (Heartbeat) MechanismURC robots simultaneously start their connection and keep this condition as long as the URC robot connects with URC server. QoS not guaranteed at commercial networkProblem

Disconnection by abnormal network environmentsIn that case, it is important to swiftly grasp the situation and to address the right direction.URC protocol defines HB (Heartbeat) protocol amongst URC robot/client and URC server to manage abnormal situations.

To monitor the connection between URC server and URC robots on aconsistent basis

URC Message URC Common header messageURC message body

URC common header message

URC common headerURC message body (payload)

URC message format

URC Heartbeat Message

URC Request Message

URC Response Message

URC Event Notification Message

The URC heartbeat message is periodically exchanged between URC robot and URC server to tackle abnormal situations found both in wireless and wired connection

URC Profile (Total : 178 messages)The URC profile is the unit function of URC robot and URC server in the URC infrastructure.A profile consists of functions supplied by the profile and events.

URC Server Profile (61 messages)URC server profiles provide the interface for numerous functions such as URC server’s recognition functions (such as speech or image recognition).

System , Authentication profileRemote, Event profileASR (Auto Speech Recognition), TTS profileFace Recognition, Motion Detection profileLocalization, Contents profileSMS, Real time recording profileMpeg4 Play, VOD Play-list profileReservation Recording profile

URC Common Robot Profiles (68 messages) URC common robot profiles support the interface of functions that all URC robots should provide.

System, Move profileNavigation ProfileEPD (End Point Detection), ASR profileSound, Vision profileMotion, Sensor profile

URC Robot Specific Profiles (49 messages)The URC robot specific profile provides the interface of its characteristic functions.

Text Display, Possible Output Notification profile Action-Emotion, Service Notification profile

API using URC protocol is embodied in Linux, Windows, Win CE, JAVA platforms

• The three types of robot systems using URC protocol as well as server have been installed and carrying out services using BcN.• BcN Network – VDSL, Cable, FTTH network• 5 companies – Samsung Elec., Yujin Robotics, Hanwool Robotics, IOTeK, Izirobotics.

2005.10.1-12.31 : 64 households in the Seoul/Kyung-gi provisions

–

There are two URC protocol standardizations, which were submitted to TTA (Telecommunication Technology Association of Korea) standardization workgroup PG413 (Intelligent Service Robot Project Group), as standardizations.

URC Client/Server transport protocolPayload message format of URC Client/Server transport protocol

We plan to improve URC protocol based on URC experimental field services results, and expand the profiles for increasing number of new services and robots.

UDP/HTTPCooperation protocol for multi-robotsFault-tolerant Communication

We plant to develop standard Interface between Server and Robot supported by various languages (JAVA, C/C++, C#)

Thank you

1/[email protected] OMG Meeting St-Louis, April 2006 - GostaiGostai

Universal Real-time Behavior Interface

Jean-Christophe BaillieENSTA / Gostai

URBI: a Universal Platform for Personal RoboticsURBI: a Universal Platform for Personal Robotics

AldebaranAldebaranRoboticsRobotics

Robotics/2006-04-11


Personal Robotics in 2006We are at the very beginning of « Personal Robotics »: leisure robots, companion-robots,

assistant-robots, vacuum cleaner robots, medical support or assistance to senior citizens…

Strong similarities exist with the beginning of the

Personal Computers industry in the 1980’s:

huge potential.

No universal platform currently exists as a

standard to control these robots.

There is a need.


PLAN

What is URBI?Technical Part: inside URBIComponents as ObjectsUsage examplesCurrent status & Conclusion

PLANPLAN

What is What is URBI?URBI?TechnicalTechnical Part:Part: insideinside URBIURBIComponents as Components as ObjectsObjectsUsageUsage examplesexamplesCurrent status Current status & Conclusion& Conclusion


WHAT IS URBI?WHAT IS URBI?WHAT IS URBI?


URBI is a complete solution to URBI is a complete solution to control robotscontrol robots..The base of the system is a The base of the system is a newnew Interface LanguageInterface Language..

FlexibilityFlexibilityIndependent of the robot, OS, platform, interfaced with many languages

(C++, Java, Matlab…), Client/Server architecture.

ParallelismParallelismParallel processing of commands, concurrent variable access policies, event

based programming, task scheduling, … many new powerful concepts oriented towards parallel programming and Artificial Intelligence

SimplicitySimplicity

Easy to understand, but with advanced capabilities for demandingapplications. URBI is used as well by Research Labs and by 12 years old kids as a hobby.

ModularityModularity

Software components can be transparently plugged in the language to extend it, as internal new objects or as external objects running on different computers (DOM). The user do not see the difference.

URBI Key Features


URBI Engine: based on a client/server approach

URBIEngine(server)

URBImodules

(remote)

super calculator

or, simply onboard

Mac OSX, Intel or standard

Windows, Linux, … commands

messages

URBI Module

(plugin)


Frequently Asked Questions

Why a script language? C++ is better and faster!

C++ (or Java, Matlab…) is strongly interfaced with URBI with C++ components. URBI orchestrates several objects in a flexible and dynamic reconfigurable way, at runtime, with almost no speed overhead. CPU demanding code should be in C++ objects, not in URBI.The script language is the glue between components, and that’s the way of modern modular programming.

Why yet another script language? What about python?

URBI is different from python or LUA, because it integrates parallelism and event-based programming in the language semantics. This is a fundamental innovation and a need for complex AI & Robotics. It also trivially allow distributed remote objects with its client/server architecture.

Why a central server? What if it fails?

There are already many central systems that the system depends on: the OS, the hardware drivers. The key point is to have a robust and bullet-proof system, plus a recovery mechanism in the (rare) case of kernel panic. Think about apache or X. Being central (+script based) brings powerful ways to control your objects and to have them cooperate in a flexible manner.


TECHNICAL PART

Inside URBI

TECHNICAL PARTTECHNICAL PART

InsideInside URBIURBI


Objects to control hardware

URBI can be seen as a driver:Every sensor, motor, camera or physical hardware in the

robot is an object.

micro

gripL

legR3

legRF3

headPan

micro

An URBI object is similar to a C++ object: it has methods and properties.By convention, the val property is related to the device value

(telnet session, port 54000, with Aibo ERS7)

headPan = 15; // or headPan.val = 15headPan;[136901543:notag] 15.1030265089 accelX;[136901543:notag] 0.002938829104

(telnet session, port 54000, with Aibo ERS7)

headPan = 15; // or headPan.val = 15headPan;[136901543:notag] 15.1030265089 accelX;[136901543:notag] 0.002938829104

camera;[145879854:notag] BIN 5347 jpeg 208 160############# 5347 bytes ###########

speaker = bin 54112 wav 2 16000 16;####### 54112 bytes #####

camera;[145879854:notag] BIN 5347 jpeg 208 160############# 5347 bytes ###########

speaker = bin 54112 wav 2 16000 16;####### 54112 bytes #####


Messages and tags

headTilt;[136901543:notag] 15.1030265089headTilt;[136901543:notag] 15.1030265089

Time stamp (ms) Command tag Message content

mytag: headTilt;[136901543:mytag] 15.1030265089mytag: headTilt;[136901543:mytag] 15.1030265089

custom tag: useful to know who is sending what and to control running commands.Any command or group of commands can be prefixed by a tag.This is one of the most powerful features in URBI, crucial to handle parallelism properly

All messages from the server are composed with the same standard structure:

the command to the server:

the message from the server:


Advanced Tagging

mytag: {command1;if (distance < 50)

sometag: command2;

while (index < 10) {ping;index++;

};...

};

mytag: {command1;if (distance < 50)

sometag: command2;

while (index < 10) {ping;index++;

};...

};

stop / block / freeze

stop mytag;

block mytag;unblock mytag;

freeze mytag;unfreeze mytag;

Stops the commandsStops the commands

kills any new command with tag "mytag"kills any new command with tag "mytag"

freezes any running or new commandfreezes any running or new command

From another client or from

other commandsrunning in

parallel


Commands can be executed in serial or parallel mode:

Set headPan to 15 and neck to 30 at the same time

Set headPan to 15 and after, set neck to 30.

A B

AB

A B

AB

A | BB.Start == A.end

A & BB.Start == A.start

A ; BB.Start >= A.end

A , BB.Start >= A.start

Operators , and ; are also available and have a semantics identical to & and | except thatthey have looser constraints:

gap

gap

headPan = 15 & neck = 30;headPan = 15 & neck = 30;

headPan = 15 | neck = 30;headPan = 15 | neck = 30;

NB: Brackets can be used to group commands, like in C:

{ headPan = 15 | headTilt = 23 time:1000 } & neck = 10;{ headPan = 15 | headTilt = 23 time:1000 } & neck = 10;

Parallelism


Complex Assignments

Numerical assignments can be specified via “modifiers”

Simple assignment:

headPan = -2;headPan = -2;

headPan = 15 time:5s;headPan = 15 time:5s;

5000ms

-2

15

headPan = 15 speed:0.34;headPan = 15 speed:0.34;

speed = 0.34 unit/s-2

15

headPan = 15 accel:0.02;headPan = 15 accel:0.02;

accel = 0.02 unit/s²

-2

15

headPan = -2 sin:1s ampli:3,headPan = -2 sin:1s ampli:3,

1000ms

-2

6 units

This command never terminates

Any function can be assigned as time parameterized trajectory with the function modifier (v2.0):

headPan = function(t):sqr(t)+sin(3*t+pi);headPan = function(t):sqr(t)+sin(3*t+pi);

put the command in background


NB: this is also true for sound devices => simple multiplexer

Blending modes

Conflicting assignments can occur from several clients or inside the same program.x=1 & x=5

How to handle it?

neck.val->blend = add;neck.val->blend = add; Each assignment occurs at the same time and is added to the others=> Used to superimpose sinuses in Fourier decomposition

neck.val->blend = mix;neck.val->blend = mix;

neck.val->blend = queue;

Like add, but they are averaged instead of added

neck.val->blend = queue; Each assignement occurs only when the others are finished

neck.val->blend = discard;neck.val->blend = discard; Each conflicting assignment is ignored

neck.val->blend = cancel;neck.val->blend = cancel;

neck.val->blend = normal;

Each new assignment terminate any other pending assignment

neck.val->blend = normal; The latest assignment has the focus, be the others run in background

Blending modes:

variable->blend = …

variable "property"


Usual OOP features are available:

class motor {var val;function switchon();event overheat;

};

legRF1 = new motor("xx24");legRF2 = new motor("xx27");legRF3 = new motor("xx789");

// broadcast groupinggroup legRF {

legRF1, legRF2, legRF3};

Usual OOP features are available:motor

legRF

head

legs

tail legRF1 legRF2 legRF3

URBI multiple parallel launch going downward:broadcasting.

function motor.switchon() {echo “on “+val;

};

legRF.switchon(); broadcast switchon()gets motor.switchon()

legRF1.switchon() &legRF2.switchon() &legRF3.switchon();

Usual virtual method search going upward

function motor.switchon() {echo “on “+val;

};

legRF2.switchon(); gets motor.switchon

subclassing and multiple inheritance possible

Objects: OOP and Broadcasting


C-like Features

Function definition

Functions can be defined on devices or virtualdevices:

Control structures:

Standard control structures are available andsome more specific to URBI:

function robot.walk (x,y) {… /* walk code*/

};

function add (x,y) {return x+y

};

function fibo(n) {if (n<2) return 1else {a = fibo(n-1);b = fibo(n-2);return a+b

}};

function robot.walk (x,y) {… /* walk code*/

};

function add (x,y) {return x+y

};

function fibo(n) {if (n<2) return 1else {a = fibo(n-1);b = fibo(n-2);return a+b

}};

usage:robot.walk (14,255);myresult = fibo(10);robot.process_mystring("bonjour");

robot.walk (14,255);myresult = fibo(10);robot.process_mystring("bonjour");

no semicolon

// the classical for loopfor (i=0;i<10;i++)

echo i;

// soft tests : must be true for 3mswhile (headsensor > 0) {

instructions…}

// loop 10 timesloopn (10) legLF1 = legRF1;

// Funny average calculation with for&avg = 0;avg->blend = mix;for& (i=0;i<10;i++)

avg = tab[i];

// the classical for loopfor (i=0;i<10;i++)

echo i;

// soft tests : must be true for 3mswhile (headsensor > 0) {

instructions…}

// loop 10 timesloopn (10) legLF1 = legRF1;

// Funny average calculation with for&avg = 0;avg->blend = mix;for& (i=0;i<10;i++)

avg = tab[i];


test = true;

test = false;

Instruction AInstruction B

Event catching

Several event catching mechanisms are available:

at (test) { at (test) {instructionsA; instructionsA;

}; }onleave {instructionsB;

};

at (test) { at (test) {instructionsA; instructionsA;

}; }onleave {instructionsB;

};

whenever (test) { whenever (test) {instructionsA; instructionsA;

}; }else {instructionsB;

};

whenever (test) { whenever (test) {instructionsA; instructionsA;

}; }else {instructionsB;

};

waituntil (test);waituntil (test); Terminates only when test becomestrue.=> If given a number, the waitcommand pauses for this nb of ms.

usage: waituntil (test) | instructions…waituntil (test) | instructions…

test = true;

test = false;

Instruction AInstruction B


Event catching (2)

You can control the lifespan of a command:

timeout (time)command;

//exampletimeout(10s) robot.walk();

timeout (time)command;

//exampletimeout(10s) robot.walk();

command will be executed untiltime is over.

This command runs in the background.

stopif (test)command;

//examplestopif(headSensor) loop legRF1 = legLF1;

stopif (test)command;

//examplestopif(headSensor) loop legRF1 = legLF1;

command will be executed untilthe test becomes true.

This command runs in the background.

freezeif (test)command;

//examplefreezeif(!ball.visible) balltracking();

freezeif (test)command;

//examplefreezeif(!ball.visible) balltracking();

command will be executed untilthe test becomes true, then it isfreezed. When test becomes falseagain, it is unfreezed.

Also runs in the background.


Event catching(3)

You can emit your own events with the emit function:

emit myevent;

emit myevent (1,"hello");

emit myevent;

emit myevent (1,"hello");

This creates an spiking event with or without parameters.

at (myevent) ...

whenever (myevent (x,y)) echo x+y;

at (myevent (1,s)) echo s;...

at (myevent) ...

whenever (myevent (x,y)) echo x+y;

at (myevent (1,s)) echo s;...

You can catch events with a simple test. If there are parameters, you getthem together with the event and youcan filter on the base of thoseparameters value.

emit(2s) myevent;

emit() myevent (1,"hello");

emit(2s) myevent;

emit() myevent (1,"hello");

This will add a duration to then event. Possibly, no time limit.

every(2s) commands;

every(2s) emit myevent;

every(2s) commands;

every(2s) emit myevent;

The every command starts thecommand at given time intervals. It can be used to create « pulsingevents »


Multicore IntegrationN

etwork Layer

URBICode

Client2

URBICode

Client1

URBICode

Client3…

URBICommands

=Micro-threads

(logical thread)

Core2

CoreCore22

Core1

CoreCore11

Core3

CoreCore33

PhysicalThread

PhysicalPhysicalThreadThread

PhysicalThread


PhysicalThread


PhysicalThread


PhysicalThread


PhysicalThread


URBISchedulerURBI

Scheduler

Synchronisation

Automatic load balancing of parallel commands on a variable number of cores and threads, with real-time scheduling capabilities (currently in development, v.2 only)

OSOS HardwareHardware

URBIKernelURBIURBI

KernelKernel


COMPONENTSCOMPONENTSCOMPONENTS


URBI as a Middleware

The creation of modules extends the objects available in the robot by pluging external C++ classes in the URBI language (Java and other language plugin in progress)

Example of URBI modules: ball => ball.x, ball.y, ball.visiblevoice => voice.say(“hello”), voice.hear(x)

URBIas a

central hub

URBI ServerURBI ServerURBI ServerURBI ServerURBI ServerURBI ServerURBI ModuleURBI ModuleURBI ModuleURBI Module

CORBA ModuleCORBA ModuleCORBA ModuleCORBA Module

Other Module?…Other Module?…rOther Module?Other Module?……

OffboardOffboardOffboard

URBI ServerURBI ServerURBI ServerURBI Server

URBI ModuleURBI ModuleURBI ModuleURBI Module


Other Module?…Other Module?…rOther Module?Other Module?……

OnboardOnboard

ball = new objectDetector(100,23,123,…);


URBI ServerURBI ServerURBI ServerURBI ServerURBI ModuleURBI ModuleURBI ModuleURBI Module


Other ModuleOther ModulerOther ModuleOther Module

Proxy ServerProxy ServerProxy ServerProxy Server

ProxyProxy

KernelKernel pluginsplugins

URBI ServerURBI ServerURBI ServerURBI ServerIntegrated

URBI ModuleIntegrated

URBI ModuleIntegratedIntegrated

URBI ModuleURBI Module

With the UObject Architecture: the same C++ code for all integration possibilities

URBI as a Middleware (2)

mirroring


How to use URBI?

URBI ServerURBI ServerURBI Server

// C++ code with liburbi C++

main() {UClient * client = new UClient("myrobot.ensta.fr");int pos;

pos = complex_calculation(x,y);client->send(“headPan.val = %d;”,pos);

}

C++ clientC++ client

URBI.INIonboard scripts

URBI.INIonboard scripts

URBI.INIURBI.INIonboard scriptsonboard scripts

// C++ object inherit fro UObjectUStart(ball);

class ball : UObject{ball(string);

UVar x,y;. . .

};

Remote/Plugged C++ ModuleRemote/Plugged C++ Module

// Java code with liburbi Java

import liburbi.UClient;

robotC = new UClient(robotname);robotC.send("motor on;");robotC.setCallback(image, "cam");

Java clientJava client

headPan.val = 15;headPan.val;[136901543:notag] 15.1030265089...

telnet ortelnet or urbilaburbilab clientclient

other integrated clients(matlab, python, . . .)

•• simple commandssimple commands•• functions definitionfunctions definition•• complex scriptscomplex scriptsLiburbi

UObject


Plugged components extends the objects available in the system and URBI is used to control and coordinate them in a parallel,

event-driven way.

The architecture is open, we can integrate CORBA or other DOM, interface objects from many languages (C++, Java, Matlab, python…), adapt to existing standards or push towards their

creation.

URBI aims at being a unifying tool bringing flexibility


USAGE EXAMPLESUSAGE EXAMPLESUSAGE EXAMPLES


Examples

legR3

headPan

camera

// Ball tracking program:

whenever (ball.visible) {headPan = headPan + camera.xfov * ball.x&headTilt = headTilt + camera.yfov * ball.y

};

// Ball tracking program:

whenever (ball.visible) {headPan = headPan + camera.xfov * ball.x&headTilt = headTilt + camera.yfov * ball.y

};

// Get up on the Aibo

getup: {{ leg2 = 90 time:2s &leg3 = 0 time:2s } |

leg1 = 90 time:1s |leg2 = 10 time:1s |{ leg1 = -10 time:2s &leg3 = 90 time:2s }

};

// Get up on the Aibo

getup: {{ leg2 = 90 time:2s &leg3 = 0 time:2s } |

leg1 = 90 time:1s |leg2 = 10 time:1s |{ leg1 = -10 time:2s &leg3 = 90 time:2s }

};

// Event detection

at (headSensor ~ 2s)speaker.play("hello.wav");

at (distance < 40)emit collision;

...

// Event detection

at (headSensor ~ 2s)speaker.play("hello.wav");

at (distance < 40)emit collision;

...

ball detectioncomponent


// Tracking statefunction tracking() {

whenever (ball.visible) {headPan = headPan + camera.xfov * ball.x &headTilt = headTilt + camera.yfov * ball.y

}};

// Searching statefunction searching() {

period = 10s;{ headPan’n = 0.5 smooth:1s &

headTilt’n = 1 smooth:1s } |{ headPan’n = 0.5 sin:period ampli:0.5 &

headTilt’n = 0.5 cos:period ampli:0.5 }};

// Tracking statefunction tracking() {

whenever (ball.visible) {headPan = headPan + camera.xfov * ball.x &headTilt = headTilt + camera.yfov * ball.y

}};

// Searching statefunction searching() {

period = 10s;{ headPan’n = 0.5 smooth:1s &

headTilt’n = 1 smooth:1s } |{ headPan’n = 0.5 sin:period ampli:0.5 &

headTilt’n = 0.5 cos:period ampli:0.5 }};

Behavior exampleThis example shows how to write behavior graphswith URBI:

Trackball

Searchball

ball.visible == false

ball.visible == truespeaker = found;

speaker = lost;

// Transitionstrack_transition:

at (ball.visible ~ 400ms) {stop search;speaker = found;track: tracking();

};

search_transition:at (!ball.visible ~ 400ms) {

stop track;speaker = lost;search: searching();

};

// Transitionstrack_transition:

at (ball.visible ~ 400ms) {stop search;speaker = found;track: tracking();

};

search_transition:at (!ball.visible ~ 400ms) {

stop track;speaker = lost;search: searching();

};


state 1

state 2

state 3state 4

Finite State Machines (another way to do behavior graphs)

cond1

cond4

cond3

cond2 Action1

Action2

Action4

Action3

function state2.init() {

state2.tag1:at (cond1) { action1|emit go_state4; stop state2};

state2.tag2:at (cond2) {action2|emit go_state3; stop state2};

state2.main: loop { ... };};

at (go_state2) state2: state2.init();at (go_state4) state4: state4.init();


state2.tag1:at (cond1) { action1|emit go_state4; stop state2};

state2.tag2:at (cond2) {action2|emit go_state3; stop state2};

state2.main: loop { ... };};

at (go_state2) state2: state2.init();at (go_state4) state4: state4.init();

state 2cond1

Action1

cond2Action2

Local event gate


emit() in_state2;state2.main: loop {

...}

};

state2.tag1: at (in_state2 && cond1) { action1 |state4: state4.init() ; stop state2 };

state2.tag2: at (in_state2 && cond2) {action2 |state3: state3.init() ; stop state2 };


emit() in_state2;state2.main: loop {

...}

};

state2.tag1: at (in_state2 && cond1) { action1 |state4: state4.init() ; stop state2 };

state2.tag2: at (in_state2 && cond2) {action2 |state3: state3.init() ; stop state2 };

Separated

Integrated

freeze state2.tag2;


CONCLUSIONCONCLUSIONCONCLUSION


Summary

• Simple to use by non experts and experts alike, but yet very powerful• Extensible and flexible• Strong industrial commitment: backward compatibility with new versions, open interface and protocols, active partnership policy to increase the number of URBI-compatible components• Innovative technology to handle parallelism• Already seven compatible robots, keeps increasing• Community of users and reusability of components between different platforms

Key Benefits


A spin-off from the ENSTA Cognitive Robotics Lab (Paris, France) has been created to promote URBI:

We are looking for partners developing components, tools, who are integrating systems or developing standards.

Current status

All Rights Reserved, Copyright Fujitsu Laboratories Ltd. 2006

Fujitsu’s Robotics Research and Standardization Activities

Toshihiko MoritaFujitsu Laboratories Ltd.

April 25, 2006

OMG Technical Meeting – Robotics DTF

robotics/2006robotics/2006--0404--1212


OutlineOutline

Use of robotics technologyNeed for standardization Standardization activities

Robot Services Initiative RT vision component


Use of Robotics Technology


19801980 19901990 20002000

FA robots Hazardous environment and outer space

Human-friendly robots

Micro-arm ('81)

M6 ('83)

Dual-armed robot ('93)

ETS-VII ('96)

Robot fornuclearpower plants('83-'91)

Nursing robots ('98)

Humanoid robot ('00)

HRP project ('98-'03)

“Uncle Touch”('99)


Humanoids for Research Purposes: HOAP(Humanoid for Open Architecture Platforms)

HOAP-1 (2001.9)

HOAP-3 (2005.7)

HOAP-2 (2003.8)

Standing on its head

Tai Chi

- Latest robots (1) -


Cell phone

At a remote location

Intruder detection

Appliance control

Home camera

Home

Remote operation

Camera visuals

MARON-1 (2002)

(Mobile Agent Robot Of the Next-generation)Home Robot: MARON-1



Service Robot “ ”Assisting people in offices and public facilities

Transport of objects

Security patrol

Guidance and escort

Various applications based on

a common platform

(exciting nova on network)



Hardware Specifications

Head (2 DOF) LEDs

4 microphones

Wheels(2 DOF)

Arm (5 DOF)

Hand (1 DOF)

Speaker

LCD monitor

6 cameras

Sensors

HeightWidthWeightSpeedLoad

Battery

1300 mm 560 mm 50 kg Max. 3 km/hr Max. 10 kg Nickel-Hydridenon-contact


FeaturesAutonomous navigation using 3D vision User-friendly information provision via network

• Voice, touch panel LCD monitor, and gesture Safety

• Approved by Safety Engineering Lab (NPO)

Application fields Shopping malls Exhibition and tourist facilities AirportsInternet data centers (IDCs)


-1/41-

Standardization of Device Interfaces

for Home Service Robot

2006. 04. 24.

Embedded hardware component research team Intelligent robot research division

ETRI

H.C. Shin

robotics/2006-04-13

-2/18-

Table of Contents

Introduction

Mission of My Team

Standardization of Robot Device Interface

Conclusion

-3/18-

Introduction

We are …Embedded hardware component research team / Intelligent robot research division / ETRI

-4/18-

Introduction

We are developing …

LEGO-type embedded systems for low cost, popularized home service robot– F/W, Control S/W, BSP on Embedded Linux System

Robot core chipsets and SoC (System-on-a-Chip)

Network robot system integration

Robot service technology (Robot telephone, Robot Videophone, Robot TV, …etc.)

-5/18-

Mission of Our Team

We are developing embedded systems for low cost, popularized intelligent home service robot

MIM_T (Multi-modal Interface Module_Tiny) :For Robot Application

– Brain: Low-end Embedded MPU(350MHz), embedded linux

– Eye: MPEG4/H.263 H/W Encoder (CIF, max.30fps)

– Mouth: Narrow/Wideband Speech I/O

– Ear: Sound localization from 8 channel microphones

– Network I/F : Wireless LAN, WiBro (Future)

– Interfaces for robot hardware devices(RS232, USB, LCD, Zigbee, CAN, etc.)

For Videophone Application– Acoustic Echo Canceller for Loud Speaker Phone

-6/18-

MRM (Multimedia Retrieval service Module)

For Robot Application– Brain:Middle-end Embedded MPU(500MHz), embedded linux

– Eye: JPEG (max.10fps)

– Expression: MPEG-2/4, DivX3/4/5, WMV9, H.263 H/W Decoder (DVD Quality), Stereo MP3 Decoder

– Network I/F : Wireless LAN, WiBro (Future)

– Interfaces for robot hardware devices(RS232, USB, LCD, Zigbee, CAN, etc.)

For Internet Phone Application– VoIP:G.711 A/u Law PCM 64Kpbs

– Acoustic Echo Canceller for Loud Speaker Phone

Mission of Our Team

-7/18-

URC (Ubiquitous Robotic Companion)

For low cost, popularized home service robot

Mobile Robot Client- Minimum embedded processor- Minimum sensor- Minimum actuator

Tele-operation Server- Navigation- Face recognition- Voice recognition- Text to Speech- Multimedia content handling- Etc.

…

Wireless LAN

Mission of Our Team

AP

AP AP AP

Internet

-8/18-

Wever C1Home Security with sensor network (provides video & audio stream, sensor information to remote user)

MIM_T (Zigbee sensor network,wireless LAN) + 2 wheels

Mission of Our Team

-9/18-

Wever Prototype 1

Tele-operated intelligent mobile robot with minimum embedded processors

Mission of Our Team

-10/18-

Embedded Main BoardMIM_T / MRM

Mobile Base Controller

IR Sensor Array LocomotionController

CAN2.0BCAN2.0B

USB2.0Microphone

Standard3.5mm

SpeakerStandard3.5mm

LCD DisplayVGA

CMOS CameraOV9650

Wireless LANIEEE802.11g

USB2.0/Ethernet

Arm Controller

Pan-tilt Controller

RS232

RS232

Motor

Motor

RS485

RS485

Motor

Motor

RS485

RS485

Motor Motor

Motor Driver

RS485

Wever Prototype 1 hardware configuration

Mission of Our Team

-11/18-


Personal Computer = + A company CPU+ B company graphic card+ C company memory+ etc.

Home Service Robot = + X company arm+ Y company eye+ Z company brain+ etc.

Now… Future…

-12/18-

Robot device integration is important & hard

We want …

Standardized robot devices like general PC device

Robot device manager like Plug & Play Device Manager of Microsoft Windows


-13/18-


TinyHeavy

Vision camera Microphone On/offswitch

Proximitysensor

Arm & leg Wheel On/off actuatorPan & tilt Display

Touchsensor

Robot needs various devices!

-14/18-

Robot hardware devices can be classified into

General PC devices (vision camera, audio I/O, LCD display, etc.)

They have already de facto standard

Sensors and actuators

IEEE 1451

IEEE 1451” Standard for a Smart Transducer Interface for Sensors and Actuators “IEEE 1451.0 Protocols & Format

IEEE 1451.1 Object Model

IEEE 1451.2 Interface (now revising for RS- 232, RS-485 and USB)

IEEE 1451.3 Local Network

IEEE 1451.4 Analog & TEDS (Transducer Electronic Data Sheets)

IEEE 1451.5 Wireless

IEEE 1451.6 CANopen-based transducer network


-15/18-

We are trying to develop PMI (Physical Media independent Interface)

PMI has classified device interfaces

Upper layer applications can access hardware devices through each standardized interface

Upper Layer Applications


…

Physical Media independent Interface

VideoIn/out

Interface

SoundIn/out

Interface

SensorIn

Interface

ActuatorOut

Interface…

-16/18-

LCD DisplayVision Camera

Microphone, Etc.

PC I/F

Sensor, Actuator

IEEE 1451

USB, RS232CAN, ZigBee

VGA, Etc.

PC I/F, IEEE1451

USB, RS232CAN, ZigBee

Etc.

Upper Layer Applications

Robot Main Board

Devices based onStandard Smart Sensor & Actuator

PMI

VGA,RS232,USB, Etc.

General PC Devices


Device ConnectionManagement Layer

Device DataManagement Layer

-17/18-

A

standardsmart

actuatorstandard

smartsensor

PMI

standardsmart

actuatorstandard

smartactuator standard

smartactuator

UpperLayer

(Applications)

Arm

con

trol

ler

B

D

E

PM

I

C


IEEE

145

1

…

standardsmart

actuatorstandard

smartactuator standard

smartactuator

F

…

Arm controller(Application)

-18/18-

Conclusion

Robot hardware devices can classified into General PC devices de facto standard interface

Sensors and actuators IEEE 1451 interface

Suggested Physical Media independent Interface for home service robot device can help robot developers and users

Voice Interface Standardization Items for Network Robot in Noisy Environments

Voice Interface Standardization Items for Voice Interface Standardization Items for Network Robot in Noisy EnvironmentsNetwork Robot in Noisy Environments

A Response to Robotic System RFI April, 2006

A Response to Robotic System RFI A Response to Robotic System RFI April, 2006

Telecommunication R&D CenterApplied Technology Lab.

SAMSUNG ELECTRONICS CO., LTD.

robotics/2006-04-14

4 Standardization items

3 Needs for Standardization

1 Purpose of Presentation

ContentsContents

5 Conclusion

2 Network Robot

Purpose of Presentation

• To propose the needs for Robotic System Standards with an emphasis on Voice Interface.

- Necessity of enactment of standardization (for both network and standalone type of robots)

- Description of the item list that can be standardized accordingly.

Network Robot

• Network robots allocate their functions through the network and the server connected to the network. - The robots alone are limited to provide techniques, expenses

as well as resources.- External signals that robots receive are analyzed and responded by

the network robot servers. - The role of a robot is as an interface between robots and users.

• The most desirable interface is a voice interface (Speech Recognition).- Robots filter out the user’s voice signals and transfer these signals

to the server that leads the recognition processing.

NoiseSuppressing

Module

command

response

Network Server

Voice signal

wireless

Recogitionresults

SpeechRecognition

Module

Network Robot using voice interface

Network Robot using voice interface

• The factors affecting the recognition capability are- background noises from numerous directions - neighboring human voice- noise from radio, TV.

Network RobotNetwork Robot

Radio, TV, TV

neighboring human voice

Needs for Standardization

• The standardization of voice interface for robotic applications would

1. Reduce the uncertainties of robot’s voice recognitionperformances in noisy environment.

2. Prevent investment overlap and cut down on theproduction cost.

3. Make system alterations and functional addition easy,when a new technique is added or the performance isenhanced.

4. Help establish an improved system in a short period of time for mass production of robots.

Standardization items- overview

• The standardization below are required in order to produce effective robots.

Standardization items 1

Item 1. Mic and Array Characteristics for network robot - Stipulations for a microphone’s capability and directional distinctions

to input the voice signal. - Beam-pattern for beamforming process for acquiring user’s voice- Optimal numbers and the locations of internally fitted microphones


Item 2. Speech recognition performance guideline - Speech recognition rate and SNR improvement

Sample Table fromTable from

‘‘PerformancePerformanceevaluation sheet evaluation sheet in AURORA2, 3 DBin AURORA2, 3 DB’’


Item 3. Input/Output parameter for communicationbetween server and network robot

• Parameter format of voice input/output- voice codec parameter applied to PCM voice data

• The feature extracting methods: - sampling rate standard of voice signals- feature extraction parameters (frame size, filter coefficient, step size)

• The method of transmission between server and robot terminal: - standardization of framing, bit-stream composition, error protection - decoding/error correction of transmitted data to the server

<Example><Example>Standard ofStandard ofETSI advancedETSI advancedFeature extractionFeature extraction


0.2

0.4

0.6

0.8

1

30

210

60

240

90

270

120

300

150

330

180 0

0.2

0.4

0.6

0.8

1

30

210

60

240

90

270

120

300

150

330

180 0

0.2

0.4

0.6

0.8

1

30

210

60

240

90

270

120

300

150

330

180 0

0.2

0.4

0.6

0.8

1

30

210

60

240

90

270

120

300

150

330

180 0

400Hz 800Hz 1600Hz 3200Hz

Item 4. Resource portion for network robot- Stipulate the processing speed of voice signals of robots- Suggest upper bound of memory occupied by voice signal processing

Conclusion

• The benefit and effect of technology development based on these standardized guideline.

1. Application of the best possible solution through regular upgrade on the system.

2. Application and instant use of various novel noise reduction techniques.3. Simple maintenance and repair based on construction of

standardized production system. 4. Establish an improved system in a short period of time for mass

production of robots. 5. Standardized robots from different company will be compatible with

each other’s network server. 6. Minimize the production rate of inferior robots and supply of quality

guaranteed robots. 7. Guarantee of speech recognition rate for the produced robots.

Thank you for your attention.

Home Robot Navigationin SAIT

Seok-Won Bang & Yeon-Ho Kim

APRIL 2006Interaction Lab

SAIT(Samsung Advanced Institute of Technology)

robotics/2006-04-15

Brief History of SAMSUNG Home Service RobotBrief History of SAMSUNG Home Service Robot: 1999~2003: 1999~2003

1999.11: BANGGARSpeech Recognition/Synthesis, Face Recognition, Navigation using a camera mounted on the ceiling

2000.11: BANGGAR IICamera-phone, remote monitoring, Multi-face Detection

2002. 4: SHR-00Vacuum Cleaning, Tele-presence

2002. 10 : APRILEmotional Motion, Sound Localization

2003. 1 : SAEBOM (Software System)Aiming Dialogue Skill of 4 Years Old Children

BANGGAR(1999)

SHR-00(2002)

APRIL(2003)

Brief History of SAMSUNG Home Service RobotBrief History of SAMSUNG Home Service Robot: 2003~Present: 2003~Present

2003.10: SHR-50Navigation using Markers on Ceiling

2003.5 : CRUBO (VACUUM ROBOT)Navigation using Markers on Ceiling

2004.7: MOBILE AIR-PURIFIERNavigation including Wall Following Motion

2004.11: SHR-100*Navigation using Natural Image Features on CeilingCall & Come using Sound Localization Technique User Following using Structured Light Sensor

2005.9~: PREMIUM VACCUM ROBOTNavigation using Range SensorsPrecise Wall Following Motion fo1r Corner Cleaning

SHR-50(2003) CRUBO(2003)

SHR-100(2004)

MOBILE AIR-PURIFIER(2004)

* SHR100 is developed with Samsung Mechatronics Center

Robot’sPosition

Speaker’sPosition

User’sPosition

Self-Localization Call & Come User-Following

CONTEXTCONTEXT--AWARE TECHNOLOGIESAWARE TECHNOLOGIESFOR HOME SERVICE ROBOT AT SAITFOR HOME SERVICE ROBOT AT SAIT

Recognizing Position of Robots and Humans

Based on the work in 2004

SLAM : Simultaneous Localization And Map-building •Use only natural image features on ceiling without any artificial markers•Feature extraction : robust to light condition•Distance estimation : structured Laser light, low cost

Localization accuracy : position error < 15cm, orientation error < 3 degree

SELFSELF--LOCALIZATIONLOCALIZATION

CALL & COMECALL & COME

Call & Come exploits video and audio signals together•Stop Position : 0.5~1.0m in front of user (95%)•Speaker’s Orientation Detection: Analysis of audio signals from 8 microphones

Detection Range < 5m, Voice Level > 7dBHuman Detection : AdaBoost algorithm with video signals

Use of Front camera and structured lightMaximum following speed : 1.5m/secControl distance : 1mUpper body Tracking : particle filter and mean shift algorithmLeg detection : arc pattern extraction from structured light sensor

USER FOLLOWINGUSER FOLLOWING

LOCALIZATION & NAVIGATION LOCALIZATION & NAVIGATION FOR HOME SERVICE ROBOT AT SAITFOR HOME SERVICE ROBOT AT SAIT

Feature Map

Final MapWall Map

Thank You!

Copyright 2006 Systems Engineering Consultants Co., Ltd. All rights reserved.

The worldThe world‘‘s first humanoid robot s first humanoid robot to be harmonized with the family to be harmonized with the family

Walking Internet Walking Internet Radio !!Radio !!

’’

Creation of the robot entertainmentCreation of the robot entertainmentthat anyone can enjoy in a home !!that anyone can enjoy in a home !!

ITR =ITR = IInntterneternet RRenaissanceenaissanceandand

IInntterneternet RRobotobot

ITR Server

RTML

RTML

Choice and play your favorite ITR programs !!

Choice and play your favorite ITR programs !!

RTML:Robot Transaction Markup Language

Internet

Singing!Dancing!

Mobile PhoneITR

Movie1 - Comic Story with a Witty Endinghttp://pc.watch.impress.co.jp/docs/2006/0404/speecys01.wmv

Movie2 – English Educationhttp://pc.watch.impress.co.jp/docs/2006/0404/speecys02.wmv

Movie3 – Music & Dancehttp://pc.watch.impress.co.jp/docs/2006/0404/speecys03.wmv

Internet

RTML Player

Mobile Phone

RTML Player

ITR ServerITR Server

Download Contents

Select ContentsRegister user information

Download ContentsNotify status

Contents Server

DeviceControlDeviceControl

UserManagement

UserManagement

NotificationService

NotificationService

Communication& Mail

Communication& Mail

Cooperatew/z Mobile Phone

Cooperatew/z Mobile Phone

DRM &AccountingSystem

DRM &AccountingSystem

MemoryTendency

TimeRegion

MemoryTendency

TimeRegion

ContentsNavigatorContentsNavigator

Contents Server

Device

Mobile Phone

OS

Web Browser

Linux(FedoraCore)

Web Service(AXIS)

Web Server ITR ServerJava

Device Driver

SpeecysOS

ITR engine

Communication Module ITR server

Linux(FedoraCore)

Web Service(Apache)

Contents ServerJava

Contents Server

HTTP+SSL

HTTP/SOAP+SSL

HTTP/SOAP+SSL

Linux(FedoraCore)

Web Service(Apache)

Contents ServerJava

Contents Server

HTTP/SOAP+SSL

Contents Scenario

Sound data

Motion data

Contents (SYGSA)

Contents Scenario

Sound data

Motion data

Contents (SYGSA)

Link

–

–

–

–

–

–

–

–

–

–

“

’’

Developer’sRelease

Developer’sRelease

MajorReleaseMajor

Release

100Contents

100Contents

300Contents

300Contents

50Contents

50Contents

UpgradeReleaseUpgradeRelease

200Contentss

200Contents

http://www.robonica.net/archives/log/eid164.html

For the social safety and developmentFor the social safety and developmentRealtime@netRealtime@net

http://www.sec.co.jphttp://www.sec.co.jpEE--mail:mail: [email protected]@sec.co.jp

OMG Robotics Task ForceRobotic Services WG

April 2006Saint Louis, MO, USA

robotics/2006-04-17

Mission Statement• The goal of the Robotics Services WG is :

– Establish a clear definition of Functional Services in Robotic Systems

– Identify and categorize services commonly used in robotic application and the technologies involved

– Define standard interfaces that expose these technologies to robotic application developers

– Study other existing related standards and coordinate with them

– Coordinate with other groups within the OMG Robotics Task Force to keep specification consistent

RoadmapItem Status St Louis

April 2006BostonJune 2006

AnaheimSept. 2006

WashingtonDec. 2006

SW CoastMarch 2006

Robotic Service WG

Ongoing

Chartering

Other services ??

LocalizationService

Ongoing

RFP1st draft

RFPDraft

Revision

RFP

(User Identification)Service

Proposed Discussion

RFPdrafting

DraftRevision

RFP

Schedule this week

• Wednesday 16:00 – 18:00Topic : Localization Service

1. Localization Service scope definition2. Identification of Requirements

• Thursday 10:00 – 12:00Topic : Localization Service

1. Localization Service scope definition2. Identification of Requirements

Election of co-chairs

• Candidates are :– Dr Chi– Lemaire

• Newly elected co-chairs :

��

��

��

��

� �� !��

��"��#��$

��

� ��%��&�#� ��#��#�� !��'�()*� ��&�� +��+��"+

�� ,��-�)�� .+/0

� (� ��&�#� ��#��&��!��#��,��1��+

��1�� &��0�#��"+�� +��+��!��!��$

� 2��!��#��!��,��-�)�� 3+�0

�� !��"��

3$ 2�!��!��()

�$ 2�!�� &��

4$ 2�&��,��0

�$ 2�!��!��5�2��3$ 6��7�8�

.$ 2�&��(��!��3$ 9��!��&��"��

�$ ��!��"��

��#$��%��"��

3$ �� &��,)9991��0��"��3$ ��)999+3�.3

�$ (��#��)999+3.::

4$ ��"�&��-� ��3$ 3�.3��;

�$ 3.::��26;�,��<)��0

�$ )=-��1��&��3$ 9��!��&��"��

�$ ��!��!��"��3$ ��&��"��

��%��

��

�� !"��# #��$��%&! #��$��%&! %&!

!"��# #��$��%&! #��$��%&! %&!

!� '��!�(��)��"�#�*��+��$��#��

� ��#��

� ��#��

,��#-��"�*�"�%� ��(�#�$�� $�"�

� ��#��

� ��#��

��&#��'��

� 6�� >��>� ��,� ��?0

� @��1��+)�,9��)0

� <�#� ��+�� >��>� ��,� ��?0

� @��1��+)�,9��)0

��

� (�� !��!��1�" ��

� ��

� A��B��1��!�� #��"B��'��"��"��C ��D*��"��#� ��#��$�

OMG Robotics DTFInfrastructure WG progress report

Rick Warren (RTI)Noriaki Ando (AIST)

robotics/2006-04-19

2

Mission Statement• The purpose of the Infrastructure Working Group of the

Robotics Domain Task Force is to standardize fundamental models, common facilities, and middleware to support the development and integration of a broad range of robotics applications.

• This working group should collaborate with other groups within OMG.

– Common facilities• Fundamental services general to wide range of robotics

applications.

3

Concerns and Prioritization

Deployment & Configuration• Resource management• Event management• Data distribution• Behavior of Control Systems

4

Roadmap

• Outline/framework RFP in Boston (June)

• Draft RFP in Anaheim (Sep.)

• Review RFP in Washington D.C. (Dec.)

• Second review RFP (Mar.)

• Issue RFP (Mar.)

5

Today’s meeting (14:00-18:00)

Topic: DC (Deployment & Configuration)• Presentation

– Jaesoo Lee’s (Seoul National University)• Is there *part* of DC should go in RTC?• DC RFP discussion.• Unification progress update

• RTC RFP discussion (open)

6

Selection Chairs

• Candidates– Saehwa Kim– Rick Warren– Noriaki Ando

• Newly elected co-chairs

–––

–

–

–

robotics/2006-04-20

2006.4.26 Robotics DTF, OMG TM, St. Louis 1

Contact Report

ORiN Forum http://www.orin.jp/

Chair: Makoto MizukawaShibaura Institute of Technology

Open Resource Interface for the Network /Open Robot Interface for the Network

robotics/2006-04-21


applications

ORiN

FA devices/Robot controllers

Open Resource Interface for the Network/Open Robot Interface for the Network

Provider

ORiNORiN


ORiN: Summary

API

DeviceInterface

ApplicationIndependentInterface

Device IndependentInterface


………

……..

Machine Machine ToolTool

ROBOTROBOT PLCPLC OperationOperationPanelPanel

Close dependency on Devices/ Networks/ Protocols-> One-off/ Order-made

-> Low Reliability-> Poor Maintenance

ORiN: Summary

Before

……..

ORiN platform

……..

Machine Machine ToolTool

ROBOTROBOT PLCPLC OperationOperationPanelPanel

ProductionManagement

ProcessManagement

OperationMonitoring

TroubleShooting

AfterIndependency on Devices/

Networks/ Protocols-> Standard Products

-> High Reliability-> Good Maintenance


Scope

ORiN proposes

•the application program interface,•the provider interface for linking controllers and•the schema definition specification for defining robots using common formats,

for realizing unified type applications for production systems containing industrial robots.


ORiN System Configuration

Standard APIStandard API

Standard Controller APIStandard Controller API

Data SchemaData Schema

Component StructureComponent Structure


ORiN : Features

Framework and Interface StandardsApplication Program InterfaceRobot/Device Controller InterfaceDevice Profiling Schema

UsingDistributed ObjectDevice Profiling using XML

ProvidingInteroperabilityWeb Service capability

FrameworkFramework

Application layerORiN Service Layer

Controller Layer

Engine RRD

Provider


Schedules

2006Jul 15,16 ISO TC184/SC2

NWIP DraftComments Revision

2007Jan., VotingMar. Voting Result

Approved Project Starts


Japan Robot Association

ORiN forum

Open Resource Interface for the Network /Open Robot Interface for the Network

http://www.orin.jp/


••Robot Access Object (RAO)Robot Access Object (RAO)a middleware that provides standard program interface and services to robot controllerbased on the distributed object model

Key Technologies for Open Robot ModelKey Technologies for Open Robot Model

••Robot Resource Definition Format(RRD)Robot Resource Definition Format(RRD)a data schema that provides standard format for data from/to robot controllerbased on the eXtensible Markup Language (XML)

•Robot Access Protocol(RAP)standard protocol in the Internet using http and XML to allow data-exchange over firewalls

RTC RFP SubmissionRTC RFP Submission

Progress updateProgress update

robotics/2006-04-22 and mars/2006-04-07

BackgroundBackground

Robotics Technology Component (RTC) Robotics Technology Component (RTC) RFP (closed Feb 06)RFP (closed Feb 06)

Separate proposals submitted by AIST & RTISeparate proposals submitted by AIST & RTICurrently working towards a single proposal Currently working towards a single proposal that unifies the 2 conceptsthat unifies the 2 conceptsRevised submission due in Jun 06Revised submission due in Jun 06

Main IssuesMain Issues

RTC specification consists of 3 partsRTC specification consists of 3 partsCore component modelCore component modelExecution semanticsExecution semanticsIntrospection partIntrospection part

Part I: Core Component ModelPart I: Core Component Model

RT core component (now RT core component (now LwRTCLwRTC) is ) is minimal conformance point minimal conformance point

UML component definitionUML component definitionPortsPorts

Lifecycle (or Activity)Lifecycle (or Activity)StatesStates

Simple lifecycleSimple lifecycleExtended by optional profiles (next slide)Extended by optional profiles (next slide)

Part II: Execution SemanticsPart II: Execution Semantics

Execution semantics defined on top of Execution semantics defined on top of LwRTCLwRTC

Basic semantics are extended by different Basic semantics are extended by different behavioral profilesbehavioral profiles

StimulusStimulus--response (response (i.e.i.e., event, event--driven)driven)DataData--flow (flow (i.e.i.e., periodic), periodic)MultiMulti--raterateMultiMulti--modalmodal

Part III: IntrospectionPart III: Introspection

Introspection contained within the RTC Introspection contained within the RTC specificationspecification

Defines introspective API based on SDODefines introspective API based on SDO

Summary Report of Robotic Systems RFI responses

Tetsuo KOTOKURobotics Domain Task Force

robotics/2006-04-23 and mars/2006-04-15

RFI response presentations in St. Louis• “Communication protocol for the URC robot and server”

(Hyun-Sik Shim, Samsung Electronics)• “Fujitsu’s robotics research and standardization activites”

(Toshihiko Morita, Fujitsu)• “Standardization of device interfaces for home service

robot” (Ho-Chul Shin, ETRI)• “Voice interface standardization items network robot in

noisy environments” (Soon-Hyuk Hong, SamsungElectronics)

• “Home robot navigation in SAIT” (Seok-Won Bang and Yeon-Ho Kim, Samsung Advanced Institute of Technology)

• “ITR – Internet Renaissance ~ The world’s first humanoid robot to be harmonized with the family~” (Hiroyuki Nakamoto, Systems Engineering Consultants)

RFI Responses• 1st Batch: 9 presentations in Burlingame

(RTI, Systronix, SNU, ETRI * 2, NEC, NTT, ATR, Toshiba)

• 2nd Batch: 14 presentations in Tampa(Hitachi, ADA Software, SEC, Mayekawa MFG, ETRI*3, Tsukuba Univ., AIST, Coroware, IHI, PrismTech, THALES, Toshiba)

• 3rd Batch: 6 presentations in St. Louis(Samsung*2, Fujitsu, ETRI, SAIT, SEC)

Total: 29 presentations

Chartering Working Groups

3 working Group was chartered in St. Louis• Service WG • Profile WG• Infrastructure WG

Initial roadmap:5 potential RFPs [robotics/2006-04-08]

Robotics Services WG Mission Statement

• The goal of the Robotics Services WG is :– Establish a clear definition of Robotic service – Identify and categorize services commonly

used in robotic application and the technologies involved

– Define standard interfaces that expose these technologies to robotic application developers

– Coordinate with other groups within the OMG Robotics Task Force to keep specification consistent

Robotics Services WGElection of Chairs

• Co-chairs :– Soo-Young Chi (ETRI)– Olivier Lemaire (JARA/AIST)

Profile WG Mission StatementApplication Programmer's View

1. Define scope and model of API2. Define typical devices3. Device hierarchies (like class hierarchies)4. Define interfaces & Data structures

1. Consider standards such as JAUS5. Device Profiles

1. Enumeration of available resources2. Resource configuration and capabilities

Physical Resource View1. Apply relevant standards (IEEE, etc) to robotics

1. Smart sensors IEEE-14512. Precision networked clock IEEE-15883. Arrange presentations on the above at OMG meetings

1. 1451 in Anaheim?2. 1588 in Wash DC? (near NIST)

2. I/O point tagging, provides:1. Enumeration of available resources2. Storage of configuration and capabilities

1. on the actual device or as close to it as possible

Profile WGElection of Chairs

• Co-chairs :– Bruce Boyes (Systronix)– Seung-Ik Lee (ETRI)

Infrastructure WG Mission Statement

• The purpose of the Infrastructure Working Group ofthe Robotics Domain Task Force is to standardize fundamental models, common facilities, and middleware to support the development and integration of a broad range of robotics applications.

• This working group should collaborate with other groups within OMG.

– Common facilities• Fundamental services general to wide range of robotics

applications.

Infrastructure WGSelection Chairs

• Co-chairs:– Saehwa Kim (Seoul National Univ.)– Rick Warren (RTI)– Noriaki Ando (AIST)

Robotics-DTFDate: Friday, 28th April, 2006 Chair: Tetsuo Kotoku, YunKoo Chung, Hung PhamGroup URL: http://robotics.omg.org/Group email: [email protected]

Highlights from this Meeting:Robotics/SDO Joint Plenary (Tue. & Wed.):

– 6 RFI response presentations(Samsung Electronics(2), ETRi, SAIT, SEC )

– 2 Special Talks• Chris Gill(Washington U.) [robotics/06-04-09],

• Jean-Christophe Baillie(ENSTA/UEI Lab) [robotics/06-04-11]

Joint Meeting with MARS-PTF (Thu.):– Robotics RFI Summary Report

robotics/2006-04-24

Robotics-DTFDate: Friday, 28th April, 2006 Chair: Tetsuo Kotoku, YunKoo Chung, Hung PhamGroup URL: http://robotics.omg.org/Group email: [email protected]

Working Group activities & Reports– 3 WGs(Service, Profile, Infrastructure) were

discussed– 5 Roadmaps were discussed.– Missions and co-chairs of WGs were approved.Future deliverables (In-Process):– Roadmaps from WGs.Next Meeting (Boston, USA):– Roadmap discussions from WGs– RFP drafts discussion– Contact report