Using different Models of Computation for distributed control

Using different Models of Computation for distributed control: the Robot Diffusion Problem Sarah Bergbreiter Mentors: Bruno Sinopoli, Alessandro Pinto (Thanks!)

Outline • What is a good Model of Computation for distributed control? • Robot Diffusion as an example of distributed control • Modeling and Simulation using Esterel • Discussion and Future Work

Platform-Based Design Concepts • We have already completed the bottom triangle (Robot Platform) – internal workings of sensors and actuators are isolated from the robot application – an API including functionality of motors (speed, direction, turning) and sensors (distance, etc. ) presented to control programs • Now we would like a method of completing the top triangle FUNCTIONAL DESCRIPTION ? PLATFORM API HARDWARE ARCHITECTURE

Why should we use a specific Model of Computation? • Distributed control problems involve – complex timing – many interconnected components that may need to communicate • Classical control does not deal effectively with these issues • Mo. C is a formal framework that allows – Verification – Code Synthesis • Abstraction, Abstraction.

Synchronous v. Asynchronous Models • Synchronous Models – shared “global” clock – often easier to model and verify – more difficult to apply to distributed systems • Asynchronous Models – no shared notion of time – more difficult to model – natural for distributed systems

So what’s the question? • For a distributed system, it is easier to model and verify properties of the system using a synchronous Mo. C. • However, the distributed system is naturally asynchronous • Solution is to add another layer • If I model my system with a synchronous Mo. C, how do important control properties such as stability hold up under the transition to an asynchronous Mo. C? SYNCHRONOUS FUNCTIONAL DESC. What happens here? GALS PLATFORM HARDWARE ARCHITECTURE

What is Robot Diffusion and Why do we care? • Given n robots in a bounded area A, the robots should try to maximize their distances between each other • Lots of extensions to this definition (maintain communication network, maximize sensor coverage, etc. ) • Useful for distributing sensors to maximize coverage, mapping applications, etc.

Robot Diffusion Distributed Controller 30 + K _ _ l + _ + l . . . FEEDBACK AND CONTROL LOOP T -------z-1 ROBOT MOTOR K T -------z-1 DISTANCE SENSOR

Robot Diffusion Distributed Controller • Assuming a stable system, the steady state positions for each robot are: robot 1: 0 robot 2: 1/l robot 3: 2/l. . . robot. N: (N-1)/l

Stability Analysis for a 3 -car Synchronous System (zero-delay) Sampling Time * System Gain K*T Find the eigenvalues of the closed loop equation y[k+1] = A y[k] + B u[k] Stability region decreases as number of robots or delay in feedback path increases (by simulation) STABLE REGION Feedback Gain l

Modeling in Esterel: Functional Model robot 1 robot 2 get. Distance . . . robot. N set. Speed set. Dir Note: As expected, the functional model includes no details of implementation. We are not constrained on how each robot finds the distance to its neighbor or on what kind of robot platform we use. module robot 1: input front. Distance 1(double), rear. Distance 1(double); output set. Speed 1(double), set. Dir 1(integer); output get. Distance; constant GAIN = 0. 2 : double; var speed : = 0. 0 : double, dir : = 1 : integer in loop emit get. Distance 1; emit set. Speed 1(speed); emit set. Dir 1(dir); [await front. Distance 1 || await rear. Distance 1]; speed : = GAIN*(? front. Distance 1 - ? rear. Distance 1); if speed >= 0. 0 then dir: =1 else dir: =-1 end if end loop end var end module

Simulation of System in Esterel Master Code ROBOT 1 DISTANCE COMM – performs integration and senses distance information ROBOT 2 . . . ROBOTN functional • Master code is used to provide the environment for the C code obtained from Esterel (esterel –A <modulenames>. strl) VIRTUAL MOTOR architecture • Asynchrony is simulated by including a random delay between when a message should be sent to when it is actually sent

Simulation Results % of Unstable Attempts STABLE UNSTABLE Increasing Asynchrony % msgs delayed

Discussion and Future Work • Mo. Cs provide a new method of approaching distributed control problems • We would prefer to model our systems in the synchronous domain to allow for easier modeling and verifiability, but distributed systems are naturally asynchronous • This project has shown that while the synchronously modeled system may hold key control properties (stability), these properties may no longer hold as the hardware platform becomes more asynchronous • For future work: – theoretical results on the stability of the system with varying degrees of asynchrony – code generation for the Cots. Bots platform from Esterel (based on Tiny. OS)