The document introduces the Dynamic Deployment and Configuration Standard for Robotic Technology Component (DDC4RTC). It describes DDC4RTC's motivation to standardize deployment of RTC-based systems. DDC4RTC extends existing RTC and DEPL specifications by adding a Component Data Model, ApplicationSupervisor service, and SupervisorFSM to enable dynamic configuration of distributed RTC-based robotic systems.
Getting clocks to agree on the time is tricky. Getting them to agree on the time better than 100 nanoseconds is even trickier.
In this talk I will provide an introduction to the basic principles of the Precision Time Protocol (PTP) and how it can be used to precisely synchronize computers over a LAN.
http://www.nycbug.org/index.cgi?action=view&id=10361
Bachelor Thesis Presentation: Analysis and Simulation Of Channel Switching In...Laili Aidi
This thesis discusses how to build a mobile TV service system that has the ability to do fast channel switching mechanism. The simulation is done by analyzing the system objectively and subjectively. and compared with the mechanism without fast channel switching. From the results of the analysis, it was found that fast channel switching mechanism capable of minimizing delays and improving the user experience to make the channel switch, compared with the mechanism without fast channel switching
Getting clocks to agree on the time is tricky. Getting them to agree on the time better than 100 nanoseconds is even trickier.
In this talk I will provide an introduction to the basic principles of the Precision Time Protocol (PTP) and how it can be used to precisely synchronize computers over a LAN.
http://www.nycbug.org/index.cgi?action=view&id=10361
Bachelor Thesis Presentation: Analysis and Simulation Of Channel Switching In...Laili Aidi
This thesis discusses how to build a mobile TV service system that has the ability to do fast channel switching mechanism. The simulation is done by analyzing the system objectively and subjectively. and compared with the mechanism without fast channel switching. From the results of the analysis, it was found that fast channel switching mechanism capable of minimizing delays and improving the user experience to make the channel switch, compared with the mechanism without fast channel switching
In the ”Internet of Things” (IoT) vision the physical world blends with virtual one, while machine-to-machine interaction improve our daily life. Clearly, how these virtual objects are exposed to us is critical, so that their user interface must be designed to support the easiness of usage that is driven by the users’ needs, which is different from what machines requires. These two requirements must be solved, and an integrated solution should emerge, if we want to bring the IoT to the 50 billions network that is predicted to became in the next years.
In this talk, you will see how these requirements cannot be met by the same communication protocol, as the user interfaces dictates a way of communication that is no suitable for the "machines". We will analyze what are the state-of-art protocols for both machines and users, and finally we will propose a solution to solve this problem.
Building a multi protocol broker for the internet of things using nodejsMatteo Collina
Have you ever wondered how to interconnect your apps with physical things? Have you ever felt that the request/response pattern of HTTP is not enough? What about a binary protocol? In this talk you will discover the internal of the open source QEST broker, a Node.js-based broker for the Internet of Things that implements a classic publish/subscribe pattern, while making it accessible from HTTP and MQTT, an ultra-fast binary protocol.
Making things that works with us codemotionMatteo Collina
In the ”Internet of Things” (IoT) vision the physical world blends with virtual one, while machine-to-machine interaction improve our daily life. Clearly, how these virtual objects are exposed to us is critical, so that their user interface must be designed to support the easiness of usage that is driven by the users’ needs, which is different from what machines requires. These two requirements must be solved, and an integrated solution should emerge, if we want to bring the IoT to the 50 billions network that is predicted to became in the next years.
In this talk, you will see how these requirements cannot be met by the same communication protocol, as the user interfaces dictates a way of communication that is no suitable for the "machines". We will analyze what are the state-of-art protocols for both machines and users, and finally we will propose a solution to solve this problem.
In the ”Internet of Things” (IoT) vision the physical world blends with virtual one, while machine-to-machine interaction improve our daily life. Clearly, how these virtual objects are exposed to us is critical, so that their user interface must be designed to support the easiness of usage that is driven by the users’ needs, which is different from what machines requires. These two requirements must be solved, and an integrated solution should emerge, if we want to bring the IoT to the 50 billions network that is predicted to became in the next years.
In this talk, you will see how these requirements cannot be met by the same communication protocol, as the user interfaces dictates a way of communication that is no suitable for the "machines". We will analyze what are the state-of-art protocols for both machines and users, and finally we will propose a solution to solve this problem.
Building a multi protocol broker for the internet of things using nodejsMatteo Collina
Have you ever wondered how to interconnect your apps with physical things? Have you ever felt that the request/response pattern of HTTP is not enough? What about a binary protocol? In this talk you will discover the internal of the open source QEST broker, a Node.js-based broker for the Internet of Things that implements a classic publish/subscribe pattern, while making it accessible from HTTP and MQTT, an ultra-fast binary protocol.
Making things that works with us codemotionMatteo Collina
In the ”Internet of Things” (IoT) vision the physical world blends with virtual one, while machine-to-machine interaction improve our daily life. Clearly, how these virtual objects are exposed to us is critical, so that their user interface must be designed to support the easiness of usage that is driven by the users’ needs, which is different from what machines requires. These two requirements must be solved, and an integrated solution should emerge, if we want to bring the IoT to the 50 billions network that is predicted to became in the next years.
In this talk, you will see how these requirements cannot be met by the same communication protocol, as the user interfaces dictates a way of communication that is no suitable for the "machines". We will analyze what are the state-of-art protocols for both machines and users, and finally we will propose a solution to solve this problem.
DivConq's Common Transfer Protocol is a protocol that supports remote calls for both small messages and large files over various network layers - including accelerated transfers over UDP.
Classification of EEG P300 ERPs using Riemannian Geometry and Quantum ComputingAntonAndreev13
This is a presentation I recently gave on classification of EEG P300 ERPs using Riemannian Geometry and Quantum Computing. It is a quick introduction to both of them. It describes how to prepare your data using Riemannian Geometry and how to build a Quantum Kernel using a Quantum Feature Map.
1. Dynamic Deployment and Configuration Standard
for Robotic Technology Component:
DDC4RTC
Noriaki Ando, AIST (DDC4RTC FTF Co-chair)
Seungwoog Jung, ETRI (DDC4RTC FTF Co-chair)
2. Overview
• RTC specification and its implementation
• Motivation
• DDC4RTC specification
– RTC Specific features
– ApplicationSupervisor
• Conclusion
2
3. OMG RTC Family
Name Vendor Feature
OpenRTM-aist AIST C++, Python, Java
OpenRTM.NET SEC .NET(C#,VB,C++/CLI, F#, etc..)
miniRTC, SEC RTC implementation for CAN ・ ZigBee based
microRTC systems
RTMSafety SEC, AIST Functional safety standard (IEC61508) capable
RTM implementation
RTC CANOpen SIT, CiA Standard for RTC mapping to CANOpen by CiA
(Can in automation) and implementation by SIT
PALRO Fuji Soft C++ PSM implementation for small humanoid
robot
OPRoS ETRI Developed by Korean national project
GostaiRTC GOSTAI, THALES C++ PSM implementation on URBI
Honda R&D RTM Honda R&D C++, Python. FSM Component.
3
4. Background
• Component model
standard and
implementations
OMG RTC
– OpenRTM-aist and Standard
OPRoS AIST
• No deployment
standard for RTC ETRI
Same component
model,
but no interoperability
between system
description
4
5. Motivation
RTC RTC RTC • Many RTCs are
camera0 camera1 camera2
window0 RTC window1 RTC
distributed spatially
door0
RTC
• Systems would be
RTC
light1 constructed as RTCs
RTC
tv0
aggregation
RTC
RTC RTC
RTC
• System structure
bed_room0 robot0 robot0 living_room0
should be changed
System
Bed Room Reconfiguration Living Room
window0 camera0 door0 tv0 camera1 camera2 window1
RTC RTC RTC RTC RTC RTC RTC
according to the
monitoring
RTC
navigation
RTC
robot0
RTC
robot0
RTC navigation
RTC
monitoring
RTC
environmental
changes in run-time
bed_room0 living_room0
Room monitoring application Robot navigation application Interactive service application
5
6. DDC4RTC Specification
• RFP: Minneapolis meeting, Jun. 2010
– mars/10-06-16 (Deployment and Dynamic Configuration (DDC) of Robotic Technology
Components (DDC4RTC) RFP
• Submitters: ETRI, AIST
• Initial Submissions: Santa Clara Meeting Dec. 2010
• Approved by AB and TC: Jun. 2012
DEPL + SupervisorFSM = DDC4RTC
RTC
• DEPL: Deployment and Configuration of Component-based
Distributed Applications Specification
• RTC: Robotic Technology Component specification
7. DDC4RTC Packages
pkg DDC 4RTC
DDC 4RTC E x t e r n a l M o d e ls
• Consists of four C om pon e ntDa ta Mo de l
C om pon e ntDa ta Mode l
packages < < im p o r t > >
(fro m D E P L )
– Component Data Model
C om pon e ntMa na g e m e ntMod e l
C om p one ntMa na ge m e n tMode l
– Component < < im p o r t > >
(fro m D E P L )
Management Model
T a rg e t D a t a M o d e l
– Execution Data Model (fro m D E P L )
T a rg e t M a n a g e m e n t M o d e l
– Execution Management E x e c u t io n D a t a M o d e l
Model (fro m D E P L )
E x e c u t io n D a t a M o d e l
< < im p o r t > >
• Each package inherits E x e c u t io n M a n a g e m e n t M o d e l (fro m D E P L )
same name package of < < im p o r t > >
E x e c u t io n M a n a g e m e n t M o d e l
DEPL specification. (fro m D E P L )
( f r o m M o d e l) ( f r o m M o d e l)
8. Component Data Model
Port in DEPL and Port in RTC
Port models in DEPL and RTC are different
9. Application Supervisor
SupervisorFSM
State A State B
State C
SupervisorFSM
ApplicationSupervisor Service Description
RTC based Systems
9
11. Conclusion
• A dynamic deployment and configuration
standard: DDC4RTC was introduced.
– Now finalization phase in OMG
– FTF report will be submitted next June?, and the
specification will be in public 2014.
• It is based on DEPL and RTC specifications in
OMG.
• SupervisorFSM and ApplicationSupervisor is
added for dynamic systems
• By reusing existing standard specification, most of
parts could be shared and extension parts could
be minimized.
11