140 likes | 166 Views
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
E N D
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
FUNCTIONAL DESCRIPTION PLATFORM API HARDWARE ARCHITECTURE 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 ?
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 • MoC is a formal framework that allows • Verification • Code Synthesis • Abstraction, Abstraction, Abstraction.
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 Synchronous v. Asynchronous Models
So what’s the question? • For a distributed system, it is easier to model and verify properties of the system using a synchronous MoC. • However, the distributed system is naturally asynchronous • Solution is to add another layer • If I model my system with a synchronous MoC, how do important control properties such as stability hold up under the transition to an asynchronous MoC? SYNCHRONOUS FUNCTIONAL DESC. What happens here? GALS PLATFORM HARDWARE ARCHITECTURE
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. What is Robot Diffusion and Why do we care?
ROBOT MOTOR + T -------- z - 1 K 30 _ l + FEEDBACK AND CONTROL LOOP . . . _ l + T -------- z - 1 K _ DISTANCE SENSOR Robot Diffusion Distributed Controller
Robot Diffusion Distributed Controller • Assuming a stable system, the steady state positions for each robot are: robot1: 0 robot2: 1/l robot3: 2/l ... robotN: (N-1)/l
Stability Analysis for a 3-car Synchronous System (zero-delay) 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) Sampling Time * System Gain K*T STABLE REGION Feedback Gain l
getDistanceDistance robot1 robot2 . . . robotN setSpeed setDir Modeling in Esterel: Functional Model module robot1: input frontDistance1(double), rearDistance1(double); output setSpeed1(double), setDir1(integer); output getDistance; constant GAIN = 0.2 : double; var speed := 0.0 : double, dir := 1 : integer in loop emit getDistance1; emit setSpeed1(speed); emit setDir1(dir); [await frontDistance1 || await rearDistance1]; speed := GAIN*(?frontDistance1 - ?rearDistance1); if speed >= 0.0 then dir:=1 else dir:=-1 end if end loop end var end module 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.
Simulation of System in Esterel • Master code is used to provide the environment for the C code obtained from Esterel (esterel –A <modulenames>.strl) • performs integration and senses distance information • Asynchrony is simulated by including a random delay between when a message should be sent to when it is actually sent Master Code ROBOT1 DISTANCE COMM ROBOT2 . . . ROBOTN VIRTUAL MOTOR functional architecture
% of Unstable Attempts STABLE % msgs delayed Simulation Results UNSTABLE Increasing Asynchrony
Discussion and Future Work • MoCs 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 CotsBots platform from Esterel (based on TinyOS)