Mercurial > hg > Members > taiki > slides
view inteligent_robot/slide/robot_soccor.html @ 3:fea44bb81877 default tip
many change
| author | taiki |
|---|---|
| date | Tue, 10 Dec 2013 15:31:33 +0900 |
| parents | |
| children |
line wrap: on
line source
<!-- Google IO 2012 HTML5 Slide Template Authors: Eric Bidelman <ebidel@gmail.com> Luke Mahé <lukem@google.com> URL: https://code.google.com/p/io-2012-slides --> <!DOCTYPE html> <html> <head> <title>Presentation</title> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="chrome=1"> <!--<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0">--> <!--<meta name="viewport" content="width=device-width, initial-scale=1.0">--> <!--This one seems to work all the time, but really small on ipad--> <!--<meta name="viewport" content="initial-scale=0.4">--> <meta name="apple-mobile-web-app-capable" content="yes"> <link rel="stylesheet" media="all" href="css/default.css"> <link rel="stylesheet" media="only screen and (max-device-width: 480px)" href="../io2012slides/theme/css/phone.css"> <base target="_blank"> <!-- This amazingness opens all links in a new tab. --> <script data-main="../io2012slides/js/slides" src="../io2012slides/js/require-1.0.8.min.js"></script> </head> <body style="opacity: 0"> <slides class="layout-widescreen"> <!-- <slide class="logoslide nobackground"> <article class="flexbox vcenter"> <span><img src="../io2012slides/images/google_developers_logo.png"></span> </article> </slide> --> <slide class="title-slide segue nobackground"> <aside class="gdbar"><img src="../images/concurrent.png"></aside> <!-- The content of this hgroup is replaced programmatically through the slide_config.json. --> <hgroup class="auto-fadein"> <h1 data-config-title><!-- populated from slide_config.json --></h1> <h2 data-config-subtitle><!-- populated from slide_config.json --></h2> <p data-config-presenter><!-- populated from slide_config.json --></p> </hgroup> </slide> <!-- 248 ページ--> <slide> <hgroup> <h2>State Machine Composition</h2> </hgroup> <article> <h3>Hybrid automata by parallel composition</h3> <ul> <li>can be used for specifying larger systems (multi-agent systems)</li> <li>hybrid automaton is given for each part of the system</li> <li>the different parts may occur via shared variables and synchronization labels</li> <li>obtained from the different parts using a product construction of the participating automata</li> <li>the different automata are interleaved</li> <li>As a result of the parallel composition a new automaton called <font color=#ff0000>composed automaton</font> is created</li> </ul> </article> </slide> <slide> <hgroup> <h2>State Machine Composition</h2> </hgroup> <article> <h3>composed automata</h3> <ul> <li> which captures the behavior of the entire system</li> <li>the composed automata are given to a model checker that checks the reachability of a certain state</li> </ul> </article> </slide> <slide> <hgroup> <h2>State Machine Composition</h2> </hgroup> <article> <h3>composed automata</h3> <ul> <li>advantage to do this during the verification process, instead of constructing the parallel composition before involving in the verification phase</li> <li>the composition of hybrid automata H1 and H2 can be defined in terms of synchronized or interleaved regions of the regions produced from run of both H1 and H2.</li> </ul> </article> </slide> <slide> <hgroup> <h2>State Machine Composition</h2> </hgroup> <article> <h3>the composition of hybrid automata</h3> <ul> <li>the composition procedure, compound regions are constructed</li> <li>consists of a conjunction of<br> a region Γ1 = ⟨q1, V1, T⟩ from H1<br> another region Γ2 = ⟨q2, V2, T⟩ from H2. </li> <li>each compound region takes the form Λ = ⟨(q1, V1), (q2, V2), T⟩ <br>(shortly written as Λ = ⟨Γ1, Γ2, T⟩), </li> <li>which represents the reached region at both control locations q1 and q2 the during a time interval T. </li> </ul> </article> </slide> <slide> <hgroup> <h2>State Machine Composition</h2> </hgroup> <article> <h3>the composition of hybrid automata</h3> <ul> <li>composed automata can be defined as the sequence ∑H1◦H2 = Λ0,Λ1,... of compound regions</li> </ul> <h3>if one of the following holds, Λ1 = ⟨Γ1, γ1, T1⟩ and Λ2 = ⟨Γ2, γ2, T2⟩ (written as Λ1<img src="robot_soccor/a_arrow.png">Λ2)</h3> <ul> <li>a∈ Event H1 ∩ Event H2 is a joint event,Γ1<img src="robot_soccor/a_arrow.png">Γ2,and γ1<img src="robot_soccor/a_arrow.png">γ2.In this case,we say that the region Γ1 is synchronized with the region γ1.</li> <li>a ∈ Event H1 \ Event H2 (respectively a ∈ Event H2 \ Event H1 ), Γ1<img src="robot_soccor/a_arrow.png">Γ2 and γ1 → γ2, such that both γ1 and γ2 have the same control location</li> </ul> </article> </slide> <!--249ページ --> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>Use constraint logic program</h3> <ul> <li>the syntax and semantics of hybrid automata, described previously, as a constraint logic program (CLP)</li> <li>hybrid automata can be described as a constraint system, where the constraints represent the possible <br>flows <br>invariants <br>transitions</li> <li>constraints can be used to characterize certain parts of the state space</li> <li>similarities in operational semantics between CLP and hybrid automata</li> </ul> <h3>Ieally, state transition systems → logic program</h3> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>Implementation</h3> <ul> <li>using ECLiPse Prolog</li> <li>follows the definitions of both the formal syntax and semantics of hybrid automata</li> <li>primarily begin with modeling the locations and their constraints</li> </ul> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>Implementation</h3> <pre> %%% automaton(+Location,?Vars,+Vars0,+T0,?Time) %%% models invariant and flow inside location automaton(Location,Vars,Vars0,T0,Time):- Flow(Vars), Inv(Vars),Time $>=T0. </pre> <ul> <li>Vars = Var0 + c · (Time − T0) in case of a linear hybrid automaton</li> <li>Var0+c·(Time−T0) ≤ Vars ≤ Var0+c·(Time−T0) in case of a rectangular hybrid automaton</li> <li>Vars = Var0 − c2/c1 + c2/c1 · exp(c1 · (Time − T0)) in case of a non-linear hybrid automaton</li> </ul> </article> </slide> <!-- 250ページ --> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>civlians</h3> <ul> <li>Vars and Time holds the reached valuations of the variables together with the reached time respectively</li> <li>example showing the concrete implementation of the location injured in the automaton Civilians</li> </ul> <pre> civilians(injured,[W],[W0],T0,Time):- W $= W0-(Time-T0), W $>=0, Time $>=T0. </pre> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>hybrid automaton has two kinds of transitions:</h3> <ul> <li>1.continuous transitions: capturing the continuous evolution of variables</li> <li>2.discrete transitions: capturing the changes of location</li> <li>evolves with either discrete or continuous transitions according to the constraints appearing during the run</li> </ul> <pre> %%% evolve(+Automaton,+State,-Nextstate,+T0,+Time,?Event) evolve(Automaton,(L1,Var1),(L2,Var2),T0,Time,Event) :- continuous(Automaton,(L1,Var1),(L1,Var2),T0,Time,Event); discrete(Automaton,(L1,Var1),(L2,Var2),T0,Time,Event). </pre> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>When a discrete/continuous transition occurs</h3> <ul> <li>gives rise to updating the initial variables from Var1 into Var2, where Var1 and Var2 are the initial variables of locations L1 and L2 respectively</li> <li><p>a delay transition is taken using the predicate continuous.</p></li> <li><p>However, this can be handled efficiently as an interval constraint that bounds the set of infinite reachable state as a finite interval</p></li> </ul> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>Event_Automaton[1]</h3> <ul> <li>each automaton is augmented with a set events called Event_Automaton</li> <li>Example:this set of events of the automaton FirebrigadeMain is denoted as {reported, emergency}</li> <li>For this reason, each transition is augmented with the variable "Event"</li> <li>The variable "Event" is used to define the parallel composition from the automata individuals sharing the same event</li> <li>The variable "Event" ranges over symbolic domains and guarantees </li> <!-- <li>simbolic domains and guarantees whenever an automaton generates an event, the corresponding synchronized automata have to be taken into consideration simultaneously.</li> --> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>Event_Automaton[2]</h3> <ul> <li>It should be mentioned that the declaration of automata events must be provided in the modeling example.</li> </ul> <h3>For instance, the declaration of the possible events domain</h3> <pre> :- local domain(events(emergency,reported,hlep,burn)). </pre> <p>The domains of events are declared symbolically to capture the set of all possible events applicable to the underlying modeled system.</p> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>Event_Automaton[3]</h3> <ul> </ul> <pre> Event &:: events, Event &= domain_value. </pre> <ul> <li>The variable "Event" is declared with domain values defined by "events"</li> <li>The variable "Event" is initialized with a specific value from its domain</li> <li>The & symbol is a constraint relation for symbolic domains (library sd in ECLiPSe Prolog).</li> </ul> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>discrete</h3> <pre> %%% discrete(+Automaton,+State1,-State2,+IntTime,-Time,-Event) discrete(Automaton,(Loc1,Var1),(Loc2,Var2),T0,Time,Event):- automaton,(Loc1,Var1,Var,T0,Time), jump(Var), reset(Var2), Event &::events,Event &=domain_value. </pre> <ul> <li>"domain_value" must be a member in Event_Automaton</li> <li>when the "discrete" predicate is fired, the automaton generates an event by constraining the variable "Event" to the suitable value from its domain</li> </ul> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>discrete</h3> <ul> <li>The concrete implementation of the "discrete" predicate between locations "no fire" and "burning" in automaton "fire"</li> </ul> <pre> discrete(fire,(no_fire,[B0,N0]),(burning,[BB0,NN0]),T0,Time,Event):- fire(no_fire,[B0,N0],[BB0,NN0],T0,Time), BB0 $=3, NN0 $=120, Event &::events, Event &=burn. </pre> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>driver</h3> <ul> <li>Once the locations and transition rules have been modeled, a state machine needs to be implemented in order to execute the model</li> <li>"driver" is a state machine</li> <li>state machine is responsible to generate and control the behaviors of the concurrent hybrid automata</li> <li>driver takes the starting state for each participating automaton</li> <li>driver takes the starting time T0 as begin of the execution, followed by the list of reached regions </li> <li>reached regions is needed for the purpose of the verification</li> <li>during the course of the execution of the driver, there is a symbolic domain variable Event shared among automata</li> <li>automata is used by the appropriate solver to ensure that only one event is generated at a time</li> </ul> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>driver[2]</h3> <ul> <li>when an automaton generates an event, due to a discrete transition of one of the predicates "evolve" of the concurrent automata</li> <li>the symbolic domain solver will exclude all the domain of values of the other automata that are not coincident with the generated event</li> </ul> </article> </slide> <!-- 252 ページから --> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>driver[3]</h3> <ul> <li>Since each automaton generates an event by a discrete step at the end of its continuous evolution</li> <li>then the precedence of events that appear during the run is important to both composition and the verification process</li> <li>obvious way to deal with this precedence is to use constraints on the time of the generated events</li> </ul> <h3>constraint the execution of each automaton with a shared variable "Time"</h3> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>driver</h3> <ul> <!-- <li>The constraint solver, in turn, binds this variable with the minimum execution time among the automata</li> --> <li>variable "Time" eventually holds the minimum time needed to generated an event</li> <li>The previous computation partitions the state space into regions</li> <li>where the transition from one region to another depends on the minimum time needed to generate an event</li> </ul> <h3>this shows how the automata composition can be implicitly constructed efficiently on the fly</h3> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>driver of behavior</h3> <ul> <li>the driver computes the set of reached regions until fixed regions are obtained</li> <li>if the reached region is not contained in the list of the previously reached regions<br> This is computed by checking, in each iteration of driver</li> <li>For this purpose, the last argument of the driver holds for the list of these regions.</li> </ul> </article> </slide> <slide> <hgroup> <h2>Constraint-Based Modeling</h2> </hgroup> <article> <h3>driver and verification</h3> <ul> <li>Reachable regions should contain only those variables</li> <li>Variables are important for the verification of a given property</li> <li> the last argument list of the predicate driver can be expanded or shrunk as needed to contain the significant variables</li> <li>As soon as the driver has been built, the complete model should be invoked for the purpose of execution and hence verification</li> </ul> <h3> the predicate runmodel is implemented to invoke the driver with the initial states of the hybrid automata. </h3> <pre> runmodel(Reached) :- driver((idle,[wlMax,0,0]),(injured,[10]),(no_fire,0),0,Reached,[]). </pre> </article> </slide> <!-- <slide> <hgroup> <h2>Verification as Reachability Analysis[1/5]</h2> </hgroup> <article> <h3>Execute constraint-based specification</h3> <ul> <li>Specification can be used to verify properties of a multi-agent system</li> <li>One can check properties on states using reachability analysis</li> <ul> <li>compute the state space of the automaton under consideration by using the predicate driver</li> <li>search for status that satisfy or contradict given properties</li> </ul> </li> <li>done with the help of standard Prolog predicates like member/2 and append/3</li> </ul> </article> </slide> <slide> <hgroup> <h2>Verification as Reachability Analysis[2/5]</h2> </hgroup> <article> <h3>In terms of CLP</h3> <ul> <li>state is reached iff the constraint solver succeeds in finding a satisfiable solu- tion for the constraints representing the intended state</li> <li>assuming that Reached represents the set of all reachable states computed by the CLP model from an initial state, then the reachability analysis can be generally specified, using CLP, by checking whether Reached |= Ψ holds</li> <li>where Ψ is the constraint predicate that describes a property of interest</li> </ul> </article> </slide> <slide> <hgroup> <h2>Verification as Reachability Analysis[3/5]</h2> </hgroup> <article> <ul> <li>Other properties concerning the reachability of certain states can be verified similarly</li> <li>constraint solvers can be used to reason about the reachability of interesting properties within a region, like properties of the variables that model the continuous dynamics of a model</li> <li>For example, we can reason about the water level of the firebrigade after putting out the fire</li> </ul> </article> </slide> <slide> <hgroup> <h2>Verification as Reachability Analysis[4/5]</h2> </hgroup> <article> <h3>Verification tools</h3> <ul> Example <li>Finding the time delay between events is possible within the framework<br> both the events and time are recorded at reached regions</li> <li> to find a condition on a certain variable<br> which is necessary to to reach a particular state</li> </ul> <h3>The experiments have been compared with HyTech</h3> <ul> <li>one of the most well-known tools for the verifica- tion of hybrid automata</li> <li>tackles verification similarly based on reachability analysis</li> <li>however, the automata working in parallel are composed before they are involved in the verification phase</li> </ul> </article> </slide> <slide> <hgroup> <h2>Verification as Reachability Analysis[5/5]</h2> </hgroup> <article> <h3>Experimental results</h3> <ul> <li>With respect to the expressiveness, our approach is more powerful</li> <li>Because HyTech can not deal directly with non-linear hybrid automata</li> <li>The continuous dynamics of non-linear hybrid automata have to be approximated in a linear form, before applying the model checking</li> <li>HyTech cannot verify simple properties that depend on the occurrence of events</li> <li>despite of the fact that events are used to synchronize the automata</li> <li>HyTech is able to verify time properties of events</li> <li>however, this can be checked only after augmenting the original automata with an extra automaton</li> <li>Its functionality is to observe the model without changing its behavior and to record the time of occurring events</li> </ul> <h3>In contrast to our framework, verifying this type of properties can be checked without any extra automaton, since the events and time are recorded in the reached regions<h3> </article> </slide> --> <slide> <hgroup> <h2>Hybrid Statecharts[1/3]</h2> </hgroup> <article> <h3>FSMs (Finite State Machines)</h3> <ul> <li>describe complex systems using FSMs</li> <li>Statecharts have been introduced to overcome the limitations of traditional FSM</li> <li>The most important extension is hierarchy, or what is called hierarchical FSM</li> <li> Such a hierarchy has descriptive advantages over ordinary FSM in a sense that hierar- chy of states offers a convenient structuring mechanism that allows us to specify systems with different levels of view</li> <li>statecharts have become part of the Unified modeling language (UML)</li> </ul> </article> </slide> <slide> <hgroup> <h2>Hybrid Statecharts[2/3]</h2> </hgroup> <article> <h3>Statechart</h3> <ul> <li>description of complex reactive systems</li> <li>to extend statecharts with continuous actions inside states</li> <li>This extension allows complex/multi-agent systems to be modeled with different levels of abstraction and provides a formal way to analyze the dynamical behavior of the modeled systems</li> <li>There are two possibilities of combination <ul> <li>namely combining statecharts with differential equations<li> <li>extending hybrid automata with hierarchy<li> </ul> </li> <li>both terms hierarchical hybrid automata (HHA) and hybrid statecharts can be used interchangeably</li> </ul> </article> </slide> <slide> <hgroup> <h2>Hybrid Statecharts[3/3]</h2> </hgroup> <article> <h3>The specification of fire brigade agent</h3> <ul> <li>the main control structure (Firebrigade- Main)</li> <li>rescue sub-system (FirebrigadeRSS) <ul> <li>records the detected civilians</li> </ul> <li>the fire brigade, the model should include a fire station, whose responsibility to inform and assign a fire brigade to a fire as soon as a fire alarm received</li> <li>the top level which in turn comprises at the lower level <ul> <li>Fire</li> <li>Civilians</li> <li>Firestation</li ><li>Firebrigade</li> </ul> <li>lower level, which is FirebrigadeMain, and FirebrigadeRSS</li> </ul> </article> </slide> <slide> <hgroup> <h2>Formal Hierarchy[1/3]</h2> </hgroup> <article> <ul> <li>Hierarchical hybrid automata, locations are generalized into a set Q of locations <ul>Set Q of locations partitioned into three disjoint sets <li>Q_simple: simple</li> <li>Q_comp: composite</li> <li>Q_conc: concrrent</li> </ul> </li> <li>There is one designated start state</li> <li>start state is the topmost location in the hierarchy</li> <li>In essence, the locations of plain hybrid automata correspond to simple location in the hybrid FSM</li> </ul> </article> </slide> <slide> <hgroup> <h2>Formal Hierarchy[2/3]</h2> </hgroup> <article> <h3>The specification of fire brigade agent</h3> <img width=600 src="robot_soccor/ResucureScenario.png"> </article> </slide> <slide> <hgroup> <h2>Hybrid Statecharts[3/3]</h2> </hgroup> <article> <h3>The specification of fire brigade agent</h3> <img width=600 src="robot_soccor/FirebrigedeAgent.png"> </article> </slide> <!-- <slide> <hgroup> <h2></h2> </hgroup> <article> </article> </slide> --> <slide class="backdrop"></slide> </slides> <script> var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-XXXXXXXX-1']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); </script> <!--[if IE]> <script src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script> <script>CFInstall.check({mode: 'overlay'});</script> <![endif]--> </body> </html>