WEBVTT 00:00:01.580 --> 00:00:03.920 The following content is provided under a Creative 00:00:03.920 --> 00:00:05.340 Commons license. 00:00:05.340 --> 00:00:07.550 Your support will help MIT OpenCourseWare 00:00:07.550 --> 00:00:11.640 continue to offer high-quality educational resources for free. 00:00:11.640 --> 00:00:14.180 To make a donation or to view additional materials 00:00:14.180 --> 00:00:18.110 from hundreds of MIT courses visit MIT OpenCourseWare 00:00:18.110 --> 00:00:19.340 at ocw.MIT.edu. 00:00:21.455 --> 00:00:23.330 PROFESSOR: Self-driving cars are pretty cool. 00:00:23.330 --> 00:00:25.655 It's pretty hot nowadays, so we're going 00:00:25.655 --> 00:00:27.200 to use this as an example. 00:00:27.200 --> 00:00:31.850 And in the past we have seen how we can give an autonomous 00:00:31.850 --> 00:00:35.415 vehicle a goal-- some condition we want it to reach. 00:00:35.415 --> 00:00:36.956 For example, we might have a car that 00:00:36.956 --> 00:00:38.914 wants to pick up some passengers along the way, 00:00:38.914 --> 00:00:44.300 get to some destination, and maybe navigate some worlds. 00:00:44.300 --> 00:00:46.800 But let's consider that for something 00:00:46.800 --> 00:00:50.870 like a self-driving car, we also have a number of other goals 00:00:50.870 --> 00:00:54.590 or requirements that are sort of implicit along the way, in that 00:00:54.590 --> 00:00:57.690 we want our self-driving car to obey the rules of the road 00:00:57.690 --> 00:00:58.800 as it's driving. 00:00:58.800 --> 00:01:01.695 And these aren't just goal conditions 00:01:01.695 --> 00:01:04.565 which is a sort of single goal that you're trying to reach, 00:01:04.565 --> 00:01:06.190 but these are sort of goals that you're 00:01:06.190 --> 00:01:11.090 trying to maintain throughout the path that you're traveling. 00:01:11.090 --> 00:01:17.000 So one example of this is a traffic light. 00:01:17.000 --> 00:01:19.860 So maybe you guys can help me out with this. 00:01:19.860 --> 00:01:21.920 Just in plain English, how would you 00:01:21.920 --> 00:01:24.976 describe the rules of how you would 00:01:24.976 --> 00:01:30.110 want a car to behave when it comes across a traffic light? 00:01:30.110 --> 00:01:30.610 Anything? 00:01:30.610 --> 00:01:31.666 It's very simple. 00:01:31.666 --> 00:01:32.165 Yes? 00:01:32.165 --> 00:01:35.490 AUDIENCE: Slow down when you see yellow, stop when you see red, 00:01:35.490 --> 00:01:37.434 go if you see green. 00:01:37.434 --> 00:01:38.100 PROFESSOR: Yeah. 00:01:38.100 --> 00:01:43.600 So pretty much stop if you see red, go if you see green, 00:01:43.600 --> 00:01:46.950 and specifically, if you see red and you stop, 00:01:46.950 --> 00:01:48.606 you're going to want to stop until you 00:01:48.606 --> 00:01:51.410 see the green, at which point that sort of condition 00:01:51.410 --> 00:01:54.883 that you're stopping goes away, and you're able to move on. 00:02:01.140 --> 00:02:04.021 And in addition to things like obeying traffic lights, 00:02:04.021 --> 00:02:06.020 there might also be some other rules of the road 00:02:06.020 --> 00:02:07.970 that we want to follow. 00:02:07.970 --> 00:02:09.970 For example, we might want to always stay 00:02:09.970 --> 00:02:12.841 within the speed limit. 00:02:12.841 --> 00:02:15.340 And then there might also be some other practical conditions 00:02:15.340 --> 00:02:19.000 of driving down the road, which is that at some point 00:02:19.000 --> 00:02:20.275 we're going to need to refuel. 00:02:20.275 --> 00:02:21.766 And if we consider a car that might 00:02:21.766 --> 00:02:26.650 be driving for a really long time, one logical statement 00:02:26.650 --> 00:02:29.890 we could say about the path that this car takes, 00:02:29.890 --> 00:02:32.350 and the sequence of states that it goes through 00:02:32.350 --> 00:02:35.020 is that at every point in time we 00:02:35.020 --> 00:02:38.470 want the plan to have some future state when we are 00:02:38.470 --> 00:02:40.490 going to visit a gas station. 00:02:40.490 --> 00:02:42.990 So this isn't just a single goal that we're trying to reach, 00:02:42.990 --> 00:02:46.760 but over a very long time, even if we consider 00:02:46.760 --> 00:02:49.270 the car to be driving an infinite amount of time, 00:02:49.270 --> 00:02:51.340 at every point in the time, we're 00:02:51.340 --> 00:02:53.340 going to be thinking ahead that there's 00:02:53.340 --> 00:02:57.176 going to be some time when we reach a gas station and refuel. 00:03:01.300 --> 00:03:04.600 So these types of conditions, things 00:03:04.600 --> 00:03:07.750 like staying at a red light until it turns green, 00:03:07.750 --> 00:03:09.980 always staying within a certain speed limit, 00:03:09.980 --> 00:03:12.520 or always having some path in the future-- 00:03:12.520 --> 00:03:14.990 some state in the future when we reach a gas station, 00:03:14.990 --> 00:03:17.250 are things that we can express with a type of logic 00:03:17.250 --> 00:03:19.010 called temporal logic. 00:03:19.010 --> 00:03:20.560 And there are two things that we hope 00:03:20.560 --> 00:03:21.860 you're going to be able to do by the time you 00:03:21.860 --> 00:03:22.985 leave this lecture. 00:03:22.985 --> 00:03:27.820 The first is be able to model these temporally extended goals 00:03:27.820 --> 00:03:30.100 using a specific type of temporal logic called 00:03:30.100 --> 00:03:34.110 Linear Temporal Logic, or LTL. 00:03:34.110 --> 00:03:36.020 And secondly, we're going to hope 00:03:36.020 --> 00:03:39.100 that you'll be able to actually apply this to planning, create 00:03:39.100 --> 00:03:41.440 plans with these temporally extended goals, 00:03:41.440 --> 00:03:45.130 and in addition just sort of this regular planning 00:03:45.130 --> 00:03:47.190 we've been dealing with, actually incorporating 00:03:47.190 --> 00:03:50.320 this idea of preferences into your plans. 00:03:50.320 --> 00:03:55.630 So a preference basically is not a required condition, 00:03:55.630 --> 00:04:00.250 but a desired condition that you can use to select 00:04:00.250 --> 00:04:02.647 between alternative paths. 00:04:02.647 --> 00:04:05.230 So you know, you might have many different ways that you could 00:04:05.230 --> 00:04:07.390 reach your goal, but we can use some 00:04:07.390 --> 00:04:09.100 of these temporally extended goals, 00:04:09.100 --> 00:04:13.080 like maybe you prefer to break as few of the rules of the road 00:04:13.080 --> 00:04:18.459 as you can, and you can use those a preferences to choose 00:04:18.459 --> 00:04:21.315 between plans. 00:04:21.315 --> 00:04:22.937 So just as an outline, first we're 00:04:22.937 --> 00:04:24.520 just going to do a little introduction 00:04:24.520 --> 00:04:26.620 to linear temporal logic. 00:04:26.620 --> 00:04:28.200 We're going to talk about what this 00:04:28.200 --> 00:04:30.815 is-- what LTL is, why we want to use it, 00:04:30.815 --> 00:04:33.430 and we're going to go through the syntax and the semantics 00:04:33.430 --> 00:04:36.190 of different LTL operators. 00:04:36.190 --> 00:04:38.460 Then we're going to walk you through some example LTL 00:04:38.460 --> 00:04:41.490 problems, and actually talk about complications to plans-- 00:04:41.490 --> 00:04:45.025 how you create plans with these linear temporal logic 00:04:45.025 --> 00:04:47.044 and temporal goals. 00:04:47.044 --> 00:04:48.960 Finally we're going to incorporate preferences 00:04:48.960 --> 00:04:51.235 into this, talk about how you express preferences, 00:04:51.235 --> 00:04:53.110 and specifically talk about a language called 00:04:53.110 --> 00:04:57.220 LPP that allows you to plan with temporal logic and preferences. 00:05:00.650 --> 00:05:05.420 So now for the introduction to linear temporal logic. 00:05:05.420 --> 00:05:07.720 Temporal logic at its core is a formalism 00:05:07.720 --> 00:05:10.780 for specifying properties of a system that vary with time. 00:05:10.780 --> 00:05:13.640 So these aren't just conditions that 00:05:13.640 --> 00:05:15.410 are true at single state, which is 00:05:15.410 --> 00:05:17.950 what we've mostly been dealing with prepositional logic. 00:05:17.950 --> 00:05:24.320 Right, so we've been saying things like, condition A and B, 00:05:24.320 --> 00:05:26.410 but not C, are true at a given state, 00:05:26.410 --> 00:05:28.294 and that's prepositional logic. 00:05:28.294 --> 00:05:29.960 Temporal logic is sort of a layer on top 00:05:29.960 --> 00:05:31.960 of that, when we're dealing not just with what's 00:05:31.960 --> 00:05:34.690 true at a single state, but actually extending over time 00:05:34.690 --> 00:05:37.050 as the system moves through a sequence of states, 00:05:37.050 --> 00:05:39.525 and expressing properties on a temporal level. 00:05:42.990 --> 00:05:46.200 So you might have a system that can be represented as a state 00:05:46.200 --> 00:05:50.360 machine, and a [INAUDIBLE],, and it 00:05:50.360 --> 00:05:54.935 can go through a sequence of different states. 00:05:54.935 --> 00:05:57.310 And while you might be able to represent the whole system 00:05:57.310 --> 00:05:59.950 like this, if we actually execute the system 00:05:59.950 --> 00:06:03.045 we're going to get one path through the system. 00:06:03.045 --> 00:06:06.220 And that's often called a trace of the system, 00:06:06.220 --> 00:06:09.040 and you can also think of it as a timeline of the system. 00:06:09.040 --> 00:06:11.410 So one example timeline of this system 00:06:11.410 --> 00:06:13.480 is it might start in state A, and then 00:06:13.480 --> 00:06:17.340 go to state C, and then go to D, and keep looping around in D 00:06:17.340 --> 00:06:18.026 forever. 00:06:18.026 --> 00:06:20.539 So that's one trace, or one timeline of the system, 00:06:20.539 --> 00:06:22.330 and that's really just a sequence of states 00:06:22.330 --> 00:06:23.205 that it goes through. 00:06:25.932 --> 00:06:28.720 And in the past we've seen these in some of the problem sets. 00:06:28.720 --> 00:06:34.190 For example when we were modeling the warp reactor, 00:06:34.190 --> 00:06:36.180 we had the valves that could transition 00:06:36.180 --> 00:06:38.452 between open and closed states. 00:06:38.452 --> 00:06:41.380 It could also be the whole system-- 00:06:41.380 --> 00:06:44.380 the starship going through different planets, 00:06:44.380 --> 00:06:47.772 transitioning through a larger set of locations, 00:06:47.772 --> 00:06:49.480 picking up passengers, dropping them off. 00:06:49.480 --> 00:06:50.813 So these could be quite complex. 00:06:54.569 --> 00:06:59.310 And so as I said, previously in our problems 00:06:59.310 --> 00:07:01.845 that we've been modeling, we've been going through a system, 00:07:01.845 --> 00:07:04.940 and we've been searching for a single state that satisfies 00:07:04.940 --> 00:07:07.640 all of our goal conditions. 00:07:07.640 --> 00:07:10.130 Maybe we to reach [? Lavinia ?] and save 00:07:10.130 --> 00:07:12.280 a certain number of people. 00:07:12.280 --> 00:07:15.640 But with temporal logic, we can actually 00:07:15.640 --> 00:07:20.200 express goals that are satisfied over a number of states, 00:07:20.200 --> 00:07:24.959 and this allows us to do some more expressive goals 00:07:24.959 --> 00:07:26.500 than we could capture just by looking 00:07:26.500 --> 00:07:28.050 at a single state at the end. 00:07:32.460 --> 00:07:36.150 So for example, what if a problem 00:07:36.150 --> 00:07:38.630 requires some condition to be met 00:07:38.630 --> 00:07:40.465 until another condition is met? 00:07:40.465 --> 00:07:42.920 And for example, you know, when you see a red light, 00:07:42.920 --> 00:07:47.990 that implies that we should stop until we see a green light. 00:07:47.990 --> 00:07:51.350 And if we look at a timeline, or a trace of one 00:07:51.350 --> 00:07:54.160 of these systems, that might look something like this. 00:07:54.160 --> 00:07:56.610 So we're going along through our system, 00:07:56.610 --> 00:07:59.116 and at one of the states, we see the red light. 00:07:59.116 --> 00:08:02.960 So that adds this condition that we should stop. 00:08:02.960 --> 00:08:04.720 And then that condition will hold forever 00:08:04.720 --> 00:08:06.620 until we see a green light, at which point 00:08:06.620 --> 00:08:10.820 that condition is dropped, and we can keep moving on. 00:08:10.820 --> 00:08:13.400 Another example where we might want to use temporal logic 00:08:13.400 --> 00:08:16.130 is, what if our problem requires a condition 00:08:16.130 --> 00:08:18.094 to always eventually be met. 00:08:18.094 --> 00:08:20.510 And this is what I was talking about with the gas station. 00:08:20.510 --> 00:08:23.750 So we want to be going on forever, 00:08:23.750 --> 00:08:26.030 and there should always be some point in the future 00:08:26.030 --> 00:08:30.110 when we do have a state where we're at a gas station. 00:08:30.110 --> 00:08:34.309 So we might start our system at a certain state. 00:08:34.309 --> 00:08:37.060 And our plan says that at some point 00:08:37.060 --> 00:08:38.809 we do reach a gas station, so that's good. 00:08:38.809 --> 00:08:40.482 But then when we get to the next state, 00:08:40.482 --> 00:08:42.440 we also want it to be true that from that point 00:08:42.440 --> 00:08:46.370 on, we're going to reach another gas station, and after that, 00:08:46.370 --> 00:08:50.070 going on and on and on into the future. 00:08:50.070 --> 00:08:54.050 These are things that you can't express very easily 00:08:54.050 --> 00:08:56.550 with the types of logic that we've been dealing with before. 00:08:59.640 --> 00:09:02.230 So one important distinction that we should clear up 00:09:02.230 --> 00:09:05.920 before we really dive into the syntax of how 00:09:05.920 --> 00:09:08.420 these linear temporal logics work 00:09:08.420 --> 00:09:10.950 is the difference between branching time and linear time. 00:09:10.950 --> 00:09:13.480 They're really two different models of time 00:09:13.480 --> 00:09:14.725 that we can be working with. 00:09:14.725 --> 00:09:16.600 There's two different types of temporal logic 00:09:16.600 --> 00:09:20.080 that exist to express these different types of time. 00:09:20.080 --> 00:09:24.790 So linear time is more similar to the world 00:09:24.790 --> 00:09:27.920 that we live in, unless you're living in some sci-fi movie 00:09:27.920 --> 00:09:30.820 where time is branching into different realities, 00:09:30.820 --> 00:09:32.860 and all sorts of crazy stuff is going on. 00:09:32.860 --> 00:09:35.930 You can think of time as just this linear timeline. 00:09:35.930 --> 00:09:37.762 So right now, it's one future state 00:09:37.762 --> 00:09:39.740 that's going to happen for me. 00:09:39.740 --> 00:09:43.170 And you know, regardless of how many options I have, 00:09:43.170 --> 00:09:47.180 there's one realization of the time. 00:09:47.180 --> 00:09:50.890 And what this lets us do is that it gives us 00:09:50.890 --> 00:09:56.600 a single path for our system, and we can reason very exactly 00:09:56.600 --> 00:10:01.940 about the conditions that are met within that path. 00:10:01.940 --> 00:10:11.680 And this lets us describe what will always happen in a system. 00:10:11.680 --> 00:10:14.840 For example, we can guarantee that we always 00:10:14.840 --> 00:10:17.180 stop at a red light until we see a green light, 00:10:17.180 --> 00:10:23.080 or we always stay within the speed limit. 00:10:23.080 --> 00:10:26.820 This is contrasted with a different model of time, 00:10:26.820 --> 00:10:28.360 called branching time. 00:10:28.360 --> 00:10:32.190 And in this model of time, at each time instant, 00:10:32.190 --> 00:10:34.560 we consider all possible futures. 00:10:34.560 --> 00:10:38.020 So if we have multiple actions that we could perform 00:10:38.020 --> 00:10:40.570 at a given state, we're going to consider different timelines 00:10:40.570 --> 00:10:44.730 that branch off for each of those possible behaviors. 00:10:44.730 --> 00:10:48.750 And this results in alternate courses of time 00:10:48.750 --> 00:10:50.730 that we can reason about as a set. 00:10:50.730 --> 00:10:55.250 And instead of thinking about this as always conditions-- so, 00:10:55.250 --> 00:10:56.904 our path always does this-- we can 00:10:56.904 --> 00:10:58.585 think about this more in possibilities. 00:10:58.585 --> 00:11:01.650 And if we're using branching time, we can say, you know, 00:11:01.650 --> 00:11:04.290 at this state and time, there exists a future path 00:11:04.290 --> 00:11:07.860 in which we will always stay under the speed limit, 00:11:07.860 --> 00:11:11.680 or, at this point in time, all our future paths satisfy 00:11:11.680 --> 00:11:13.110 a certain condition. 00:11:13.110 --> 00:11:15.810 So whereas linear temporal logic is 00:11:15.810 --> 00:11:20.930 more about guaranteeing what will happen on a given path, 00:11:20.930 --> 00:11:22.980 branching time allows us to reason 00:11:22.980 --> 00:11:27.070 about what might possibly happen in the system. 00:11:27.070 --> 00:11:29.440 So for our purposes with planning, 00:11:29.440 --> 00:11:31.510 in part because it's more attractable, 00:11:31.510 --> 00:11:35.000 and in part because it gives us an exact analysis of a given 00:11:35.000 --> 00:11:37.384 path, we're going to be doing linear time, 00:11:37.384 --> 00:11:38.800 and for that reason, we use what's 00:11:38.800 --> 00:11:40.610 called linear temporal logic. 00:11:40.610 --> 00:11:42.985 There's a different type of temporal logic. 00:11:42.985 --> 00:11:47.255 There's one called CTL and CTL* that deal with branching time. 00:11:47.255 --> 00:11:49.240 And those are sort of an extension 00:11:49.240 --> 00:11:50.290 of linear temporal logic. 00:11:50.290 --> 00:11:52.750 They add a few other operators that 00:11:52.750 --> 00:11:55.411 allow you to reason over multiple paths. 00:11:55.411 --> 00:11:56.994 But for our purposes, we're just going 00:11:56.994 --> 00:12:00.818 to be using the linear time model. 00:12:00.818 --> 00:12:04.760 So kind of as a recap, what linear temporal logic 00:12:04.760 --> 00:12:05.910 involves-- 00:12:05.910 --> 00:12:08.490 we're using this linear time model. 00:12:08.490 --> 00:12:10.830 Another important distinction is that we're actually 00:12:10.830 --> 00:12:13.900 going to be talking about infinite sequences of states. 00:12:13.900 --> 00:12:18.090 So instead of us just reasoning up until a certain goal 00:12:18.090 --> 00:12:20.520 condition is met, we're thinking about systems 00:12:20.520 --> 00:12:24.000 that could theoretically keep transitioning over time, 00:12:24.000 --> 00:12:26.560 over and over and over into the future. 00:12:26.560 --> 00:12:28.490 So if you have one of these state machines, 00:12:28.490 --> 00:12:30.070 you could think, at each time step, 00:12:30.070 --> 00:12:31.860 it's going to visit the new state. 00:12:31.860 --> 00:12:33.360 And if you give it enough time, it's 00:12:33.360 --> 00:12:35.970 just going to generate an infinite sequence of states. 00:12:35.970 --> 00:12:37.800 And we can actually express properties 00:12:37.800 --> 00:12:40.290 that can hold over an infinite number of states, 00:12:40.290 --> 00:12:42.710 not just the discrete number of states 00:12:42.710 --> 00:12:46.300 that we might usually think of to reach a goal. 00:12:46.300 --> 00:12:48.390 And linear temporal logic can actually 00:12:48.390 --> 00:12:52.470 be modified to work with discrete set of states. 00:12:52.470 --> 00:12:56.490 It just requires an additional operator. 00:12:56.490 --> 00:12:59.330 But the ability to reason about infinite sequences of states 00:12:59.330 --> 00:13:03.615 gives us a lot of power in talking about guarantees 00:13:03.615 --> 00:13:05.680 for our system, regardless of how much time we're 00:13:05.680 --> 00:13:06.600 talking about it. 00:13:09.360 --> 00:13:11.730 Finally, all the operators we're going 00:13:11.730 --> 00:13:15.680 to be looking at in our logic system 00:13:15.680 --> 00:13:18.010 are what we call forward-looking conditions. 00:13:18.010 --> 00:13:21.169 So when we're given a state we're 00:13:21.169 --> 00:13:22.710 going to reasoning about what's going 00:13:22.710 --> 00:13:26.205 to happen in the future for a potentially infinite amount 00:13:26.205 --> 00:13:27.660 of time in the future. 00:13:27.660 --> 00:13:31.110 There's sort of a symmetric version of this logic that 00:13:31.110 --> 00:13:33.550 reasons about the past. 00:13:33.550 --> 00:13:36.570 So for example, we can say-- 00:13:36.570 --> 00:13:38.880 talk about guarantees that something will eventually 00:13:38.880 --> 00:13:40.472 happen in the future-- 00:13:40.472 --> 00:13:42.180 there's sort of a symmetric version where 00:13:42.180 --> 00:13:44.500 we can talk about, given a certain state, 00:13:44.500 --> 00:13:46.950 we can guarantee that something had eventually 00:13:46.950 --> 00:13:48.810 happened in the past. 00:13:48.810 --> 00:13:51.832 But for us in that we're going to focus on planning-- 00:13:51.832 --> 00:13:54.165 we're typically planning about what to do in the future, 00:13:54.165 --> 00:13:57.190 and it makes more sense for us to use this future of updating 00:13:57.190 --> 00:14:01.267 the set for operators. 00:14:01.267 --> 00:14:03.897 And so I guess one little nuance here 00:14:03.897 --> 00:14:05.897 that I sort of pointed out in the previous slide 00:14:05.897 --> 00:14:08.980 is that because we're using a linear model of time 00:14:08.980 --> 00:14:10.475 and not a branching model of time, 00:14:10.475 --> 00:14:12.940 we're going to be expressing properties that happen over 00:14:12.940 --> 00:14:16.430 a single path of states, and not properties that happen over 00:14:16.430 --> 00:14:17.584 several path of states. 00:14:22.260 --> 00:14:24.645 So finally I'm just going to talk about a couple 00:14:24.645 --> 00:14:28.580 of the main application for linear temporal logic 00:14:28.580 --> 00:14:31.530 before Ellie will dive in, and actually 00:14:31.530 --> 00:14:34.460 talk more about the semantics and syntax of how 00:14:34.460 --> 00:14:37.080 we use this logic. 00:14:37.080 --> 00:14:40.670 So the first menus is verification and model 00:14:40.670 --> 00:14:42.390 checking. 00:14:42.390 --> 00:14:45.990 We can use this linear temporal logic 00:14:45.990 --> 00:14:50.765 to create guarantees about a system, 00:14:50.765 --> 00:14:56.020 and formally verify it for a couple different properties. 00:14:56.020 --> 00:14:58.390 For example, we can talk about the safety of the system. 00:14:58.390 --> 00:15:01.160 We can say, over the course of this system, 00:15:01.160 --> 00:15:03.690 we guarantee that it will never enter 00:15:03.690 --> 00:15:05.664 a state of a certain condition. 00:15:05.664 --> 00:15:08.610 We could also talk about the maintenance of properties. 00:15:08.610 --> 00:15:11.830 So over the entire lifetime of this system, 00:15:11.830 --> 00:15:14.598 we guarantee that a certain condition will always hold. 00:15:18.190 --> 00:15:20.565 The other main application for temporal logic, 00:15:20.565 --> 00:15:24.260 the one that we're going to be focusing on, is for planning. 00:15:24.260 --> 00:15:26.460 And this planning using these temporally 00:15:26.460 --> 00:15:28.680 extended goals that I've been talking about, 00:15:28.680 --> 00:15:30.860 and it actually extends nicely to talking 00:15:30.860 --> 00:15:33.280 about temporally extended preferences. 00:15:33.280 --> 00:15:37.130 So this is given that we have a number of different paths 00:15:37.130 --> 00:15:39.570 that could reach a goal, we can actually look at all those 00:15:39.570 --> 00:15:43.860 and see which paths satisfy certain conditions 00:15:43.860 --> 00:15:48.030 over the sequence of states, and use those conditions 00:15:48.030 --> 00:15:51.400 as a way of choosing which ones we prefer. 00:15:51.400 --> 00:15:55.020 So with that, Ellie is now going to talk about some 00:15:55.020 --> 00:15:58.995 of the syntax of linear temporal logic. 00:16:02.771 --> 00:16:03.396 ELLIE: Hi guys. 00:16:03.396 --> 00:16:06.174 My name is Ellie, and I'm going to be talking 00:16:06.174 --> 00:16:10.220 about the syntax of LTL. 00:16:10.220 --> 00:16:14.250 So an LTL formula is a series of states. 00:16:14.250 --> 00:16:16.870 And at each state, you can have various propositions 00:16:16.870 --> 00:16:19.400 than can be either true or false. 00:16:19.400 --> 00:16:23.394 So for example-- is it OK if I erase this, Steve? 00:16:23.394 --> 00:16:23.894 STEVE: Yeah. 00:16:23.894 --> 00:16:24.394 Go ahead. 00:16:28.253 --> 00:16:33.640 ELLIE: So for example you can have a [INAUDIBLE] animation 00:16:33.640 --> 00:16:39.131 show that has a series of states that goes on to infinity. 00:16:39.131 --> 00:16:42.470 And at each state you can have propositions 00:16:42.470 --> 00:16:44.150 that are either true or false. 00:16:44.150 --> 00:16:45.900 So the traffic could be red could be 00:16:45.900 --> 00:16:47.120 an example for a proposition. 00:16:47.120 --> 00:16:53.024 We could be stopped, et cetera. 00:16:57.452 --> 00:16:59.710 And there's various logical operators 00:16:59.710 --> 00:17:01.760 that we can apply to these formulas-- 00:17:01.760 --> 00:17:04.540 these sets of states, and we can determine 00:17:04.540 --> 00:17:07.880 if these logical operators are either true or false 00:17:07.880 --> 00:17:14.079 about each set of states-- each formula. 00:17:14.079 --> 00:17:16.730 So there's the not operator, the or operator, the and, 00:17:16.730 --> 00:17:20.896 the implies, if and only and, and like I said, the state-- 00:17:20.896 --> 00:17:25.636 each proposition of [INAUDIBLE] can either be true or false. 00:17:25.636 --> 00:17:30.530 So just to go through some examples of these, 00:17:30.530 --> 00:17:34.315 the logical operator true says that-- 00:17:34.315 --> 00:17:38.160 essentially what the operator true says is it's not saying, 00:17:38.160 --> 00:17:39.940 oh, this state is true. 00:17:39.940 --> 00:17:41.570 The operator just true says that there 00:17:41.570 --> 00:17:43.180 are states for all infinity. 00:17:43.180 --> 00:17:44.990 So true is always true. 00:17:44.990 --> 00:17:47.500 So no matter what you had for your state here, 00:17:47.500 --> 00:17:50.490 the logical operator true holds. 00:17:50.490 --> 00:17:53.290 However, when you talk about the logical operator 00:17:53.290 --> 00:17:57.330 true with respect to a certain state or a certain proposition, 00:17:57.330 --> 00:17:59.130 then it can either be true or false. 00:17:59.130 --> 00:18:04.460 So for example, here, the logical operator red light 00:18:04.460 --> 00:18:08.100 is true at the first state. 00:18:08.100 --> 00:18:10.535 If this was green, then the logical operator red 00:18:10.535 --> 00:18:11.990 would be false at the first state. 00:18:11.990 --> 00:18:13.796 Does that make sense? 00:18:13.796 --> 00:18:16.060 All right. 00:18:16.060 --> 00:18:19.660 One important thing to note about the logical o operators 00:18:19.660 --> 00:18:23.580 is that they just apply to the very first state 00:18:23.580 --> 00:18:24.880 in your statement. 00:18:24.880 --> 00:18:26.840 So when we're discussing logical operators, 00:18:26.840 --> 00:18:29.290 we haven't gotten to the point where 00:18:29.290 --> 00:18:33.430 we can express temporal information 00:18:33.430 --> 00:18:34.900 about our sequence of states. 00:18:40.400 --> 00:18:42.400 The next operator is, not. 00:18:42.400 --> 00:18:46.120 So as you can see here, the traffic light 00:18:46.120 --> 00:18:48.200 is read at the first state. 00:18:48.200 --> 00:18:50.460 So the traffic light's not green. 00:18:50.460 --> 00:18:53.480 Hold, because the proposition green is not 00:18:53.480 --> 00:18:55.850 true at the first state. 00:18:55.850 --> 00:19:00.130 And the logical operator, and, at this first state 00:19:00.130 --> 00:19:03.350 is we're at the red light, and we're getting gas. 00:19:03.350 --> 00:19:06.606 And so both that we're at the red light 00:19:06.606 --> 00:19:08.814 and that we're getting gas holds for the first state. 00:19:12.272 --> 00:19:16.584 And then the operator, or, essentially says-- 00:19:16.584 --> 00:19:18.250 I guess a lot of this is probably review 00:19:18.250 --> 00:19:19.980 for you guys-- logical operators-- 00:19:19.980 --> 00:19:23.985 but essentially if you have red or green 00:19:23.985 --> 00:19:26.110 then you could either have the traffic light be red 00:19:26.110 --> 00:19:28.870 or the traffic light be green at the first state. 00:19:28.870 --> 00:19:31.547 And as long as one of those two hold, or both of them 00:19:31.547 --> 00:19:33.942 hold, then it's true. 00:19:33.942 --> 00:19:39.110 And one thing to note about or lies in if and only 00:19:39.110 --> 00:19:43.170 if these can be re-written with just the logical operators, 00:19:43.170 --> 00:19:44.700 and, and, not. 00:19:44.700 --> 00:19:47.830 So another way of expressing red and green 00:19:47.830 --> 00:19:52.010 is to say that you can't have the scenario where both is not 00:19:52.010 --> 00:19:54.180 red, and it's not green. 00:19:54.180 --> 00:19:56.350 And I'm not going to go over that for, implies, 00:19:56.350 --> 00:20:00.962 and, if and only if, just for the sake of time. 00:20:00.962 --> 00:20:04.091 So that's just a review of the logical operators, 00:20:04.091 --> 00:20:06.340 and now we're going to go into the temporal operators. 00:20:06.340 --> 00:20:09.490 So when we're talking about our autonomous car, 00:20:09.490 --> 00:20:12.360 what are some useful temporal operators? 00:20:12.360 --> 00:20:13.899 Because up until now, we just are 00:20:13.899 --> 00:20:16.065 describing of the first state in our sequence, which 00:20:16.065 --> 00:20:18.130 isn't really useful if we want to talk 00:20:18.130 --> 00:20:22.937 about the entire set of sequences [INAUDIBLE] states. 00:20:22.937 --> 00:20:25.270 So what do you guys think are some mutual things that we 00:20:25.270 --> 00:20:26.890 want to be able to describe? 00:20:26.890 --> 00:20:29.189 I know Ben touched on some of them at the beginning, 00:20:29.189 --> 00:20:30.980 but if you guys could recount some of them. 00:20:30.980 --> 00:20:31.480 Yes. 00:20:31.480 --> 00:20:32.847 AUDIENCE: State connection. 00:20:32.847 --> 00:20:33.430 ELLIE: Mm-hmm. 00:20:33.430 --> 00:20:34.830 State connections. 00:20:34.830 --> 00:20:38.510 So exactly. 00:20:38.510 --> 00:20:40.756 So if I'm in a state right now, might there 00:20:40.756 --> 00:20:42.130 be concerns about the next state? 00:20:42.130 --> 00:20:44.192 Is that kind of like what you're saying? 00:20:44.192 --> 00:20:44.691 Exactly. 00:20:44.691 --> 00:20:45.190 Yeah. 00:20:45.190 --> 00:20:47.399 So next is one of the things that we 00:20:47.399 --> 00:20:50.216 might be concerned about, the next state. 00:20:56.677 --> 00:21:00.156 Are there any other tings you guys can think of? 00:21:00.156 --> 00:21:01.647 AUDIENCE: Always or [INAUDIBLE] 00:21:01.647 --> 00:21:02.638 ELLIE: Yes, exactly. 00:21:02.638 --> 00:21:03.138 Always. 00:21:09.599 --> 00:21:16.485 So like Ben said, we always want to follow the speed limit. 00:21:16.485 --> 00:21:18.330 We always want to be under 35 miles an hour, 00:21:18.330 --> 00:21:20.332 or whatever the speed limit is. 00:21:20.332 --> 00:21:22.169 Anything else? 00:21:22.169 --> 00:21:22.835 AUDIENCE: Until. 00:21:22.835 --> 00:21:23.570 ELLIE: Until. 00:21:23.570 --> 00:21:24.640 Yep. 00:21:24.640 --> 00:21:27.470 So like he said, you want to be stopped 00:21:27.470 --> 00:21:29.995 until the light turns green. 00:21:29.995 --> 00:21:30.495 Yes. 00:21:30.495 --> 00:21:31.445 AUDIENCE: Eventually. 00:21:31.445 --> 00:21:31.920 ELLIE: Eventually. 00:21:31.920 --> 00:21:32.420 Yep. 00:21:32.420 --> 00:21:38.152 So we eventually want to get gas. 00:21:38.152 --> 00:21:42.982 And eventually. 00:21:42.982 --> 00:21:43.931 Any other things? 00:21:43.931 --> 00:21:44.431 Yes. 00:21:44.431 --> 00:21:45.397 AUDIENCE: At this state. 00:21:45.397 --> 00:21:45.880 ELLIE: At this state. 00:21:45.880 --> 00:21:46.380 Yep. 00:21:46.380 --> 00:21:49.824 And so, at this state, is kind of what the logical operators 00:21:49.824 --> 00:21:51.240 were doing at the beginning, but I 00:21:51.240 --> 00:21:53.580 agree that's something we have to be able to express. 00:21:53.580 --> 00:21:56.499 So that's not a specific temporal operator, 00:21:56.499 --> 00:21:58.040 but it's included in the logical one, 00:21:58.040 --> 00:22:00.330 so I'll just write it up here for you. 00:22:00.330 --> 00:22:01.627 AUDIENCE: Can I ask a question? 00:22:01.627 --> 00:22:02.210 ELLIE: Uh huh. 00:22:02.210 --> 00:22:03.668 AUDIENCE: So the logical operators, 00:22:03.668 --> 00:22:06.320 are they acting on the-- so they're acting for a state? 00:22:06.320 --> 00:22:08.844 They're not acting on the entire chain. 00:22:08.844 --> 00:22:10.010 ELLIE: They act for a state. 00:22:10.010 --> 00:22:14.460 And so if you just wrote the logical operators, 00:22:14.460 --> 00:22:16.200 just by the definition of LTL, it 00:22:16.200 --> 00:22:18.940 means let's just analyze the first state 00:22:18.940 --> 00:22:20.510 and see if it's true. 00:22:20.510 --> 00:22:22.760 And so it won't tell us anything about the third state 00:22:22.760 --> 00:22:25.160 or the fourth state or the second state, which is why we 00:22:25.160 --> 00:22:27.059 have to look at the next state. 00:22:27.059 --> 00:22:29.015 So yeah. 00:22:29.015 --> 00:22:32.438 Any other questions? 00:22:32.438 --> 00:22:34.883 OK. 00:22:34.883 --> 00:22:39.024 So like you said, next is an important one. 00:22:39.024 --> 00:22:43.748 So right here we consider OK, the next light will be green. 00:22:47.412 --> 00:22:50.750 And until is the one that she mentioned, 00:22:50.750 --> 00:23:00.050 so the light will be red until it becomes green eventually. 00:23:00.050 --> 00:23:02.880 So the light will eventually at some point in the future 00:23:02.880 --> 00:23:03.620 turn green. 00:23:03.620 --> 00:23:06.270 So you might be waiting at the red light for a long time, 00:23:06.270 --> 00:23:09.826 but eventually it's going to turn green for us. 00:23:09.826 --> 00:23:11.932 The light will always be red, so I 00:23:11.932 --> 00:23:14.720 guess you're stuck at the traffic light for a long time, 00:23:14.720 --> 00:23:18.660 or globally-- that's another name for always. 00:23:18.660 --> 00:23:25.040 And lastly, this on is a little bit less intuitive. 00:23:25.040 --> 00:23:27.370 So what this is saying is the light 00:23:27.370 --> 00:23:32.050 will always be red until another circumstance coincides 00:23:32.050 --> 00:23:33.542 with the same state. 00:23:33.542 --> 00:23:36.540 So the light will be always red until the car gets gas. 00:23:36.540 --> 00:23:40.520 And then after it gets its gas, then the red is released, 00:23:40.520 --> 00:23:43.670 and the light can be either green or red after that. 00:23:43.670 --> 00:23:49.100 So you have red red red red red until we have both red and gas. 00:23:49.100 --> 00:23:51.514 And then it can be green or it can be red [INAUDIBLE] 00:23:51.514 --> 00:23:52.930 it's not constrained to being red. 00:23:52.930 --> 00:23:53.864 Does that make sense? 00:23:53.864 --> 00:23:56.956 That one's a little bit less intuitive, so-- 00:23:56.956 --> 00:23:57.920 is that good? 00:24:01.294 --> 00:24:04.020 OK. 00:24:04.020 --> 00:24:04.520 All right. 00:24:04.520 --> 00:24:07.687 So now that we've gone over just the intuitive 00:24:07.687 --> 00:24:09.520 understanding of that, I'm going to give you 00:24:09.520 --> 00:24:12.138 the actual syntax for that. 00:24:12.138 --> 00:24:16.570 So x is representative of next. 00:24:16.570 --> 00:24:20.765 So in the first state, we don't care if p is true. 00:24:20.765 --> 00:24:22.370 p could be not true, p could be true. 00:24:22.370 --> 00:24:23.390 It doesn't matter. 00:24:23.390 --> 00:24:25.592 But in the second state, the next one 00:24:25.592 --> 00:24:29.610 up in the first state, p, has to hold in order for xp 00:24:29.610 --> 00:24:32.750 to be a true statement about our sequence of states. 00:24:32.750 --> 00:24:43.169 So what do you guys think if I wrote this? 00:24:43.169 --> 00:24:44.642 What would that mean? 00:24:49.061 --> 00:24:51.016 AUDIENCE: Different state [INAUDIBLE] 00:24:51.016 --> 00:24:51.516 ELLIE: Yep. 00:24:51.516 --> 00:24:53.355 So this one over here? 00:24:53.355 --> 00:24:53.980 AUDIENCE: Sure. 00:24:53.980 --> 00:24:54.636 [INAUDIBLE] 00:24:54.636 --> 00:24:55.136 ELLIE: Yeah. 00:24:55.136 --> 00:24:57.624 Perfect. 00:24:57.624 --> 00:24:58.124 All right. 00:24:58.124 --> 00:25:00.116 The until operator. 00:25:00.116 --> 00:25:04.650 The until operator essentially says, like Ben said, 00:25:04.650 --> 00:25:07.580 we're stopped until the light is green. 00:25:07.580 --> 00:25:11.402 So if you have p until w, you just p 00:25:11.402 --> 00:25:13.980 has to be true at every state until w, and after that point, 00:25:13.980 --> 00:25:16.110 p can be whatever it wants to be. 00:25:18.730 --> 00:25:21.340 p eventually, or future operator, 00:25:21.340 --> 00:25:26.198 says that at some point in the future we will get gas. 00:25:26.198 --> 00:25:27.600 However it's important to note-- 00:25:27.600 --> 00:25:29.600 I know when we talked about getting gas we said, 00:25:29.600 --> 00:25:32.840 oh, we have to always get gas at some point in the future, 00:25:32.840 --> 00:25:36.260 but the future eventually operator is just 00:25:36.260 --> 00:25:38.050 at one point in the future. 00:25:38.050 --> 00:25:40.240 So once you get gas, you don't have to get it again. 00:25:40.240 --> 00:25:40.750 Yes. 00:25:40.750 --> 00:25:42.208 AUDIENCE: On the previous slide you 00:25:42.208 --> 00:25:44.640 had a not at the bottom that said that w 00:25:44.640 --> 00:25:45.764 is required to become true. 00:25:45.764 --> 00:25:48.310 Does that mean an until operator also 00:25:48.310 --> 00:25:50.746 implies a future operator on w? 00:25:50.746 --> 00:25:51.246 ELLIE: Yeah. 00:25:51.246 --> 00:25:51.715 AUDIENCE: All right. 00:25:51.715 --> 00:25:52.215 [INAUDIBLE] 00:25:52.215 --> 00:25:53.591 ELLIE: Yep. 00:25:53.591 --> 00:25:55.565 But it's the added condition that p 00:25:55.565 --> 00:25:56.940 will be true until the w. 00:25:56.940 --> 00:25:59.475 AUDIENCE: But like whenever you use until, you say p 00:25:59.475 --> 00:26:02.940 until w that you'd also have to add 00:26:02.940 --> 00:26:04.791 at some point in the future [INAUDIBLE] 00:26:04.791 --> 00:26:05.291 ELLIE: Yeah. 00:26:05.291 --> 00:26:06.405 Yep, you're right. 00:26:08.816 --> 00:26:11.440 AUDIENCE: Well, I mean, it would be possible that this stays p, 00:26:11.440 --> 00:26:12.210 right? 00:26:12.210 --> 00:26:12.595 ELLIE: It could. 00:26:12.595 --> 00:26:13.094 Yeah. 00:26:13.094 --> 00:26:16.203 But then if your system-- that would be totally fine if you 00:26:16.203 --> 00:26:20.140 had your system just be p, but then the operator p until w 00:26:20.140 --> 00:26:23.770 wouldn't hold unless you had a w at some point in that sequence 00:26:23.770 --> 00:26:25.388 of p's. 00:26:25.388 --> 00:26:26.264 Does that make sense. 00:26:26.264 --> 00:26:26.888 AUDIENCE: Yeah. 00:26:26.888 --> 00:26:29.232 [INAUDIBLE] I guess it does if that's the way to do it, 00:26:29.232 --> 00:26:32.170 but it doesn't make sense [INAUDIBLE] it. 00:26:36.255 --> 00:26:37.796 ELLIE: So you're saying that we could 00:26:37.796 --> 00:26:39.355 have a bunch of p's, right? 00:26:39.355 --> 00:26:41.210 Is that what you're saying? 00:26:41.210 --> 00:26:46.009 And I'm saying that this is a fine state to have. 00:26:46.009 --> 00:26:47.300 You can have whatever you want. 00:26:47.300 --> 00:26:51.755 And we're just analyzing if a sentence is true about it. 00:26:51.755 --> 00:26:54.890 So this statement, it's not true-- 00:26:54.890 --> 00:26:55.660 or, sorry. 00:26:55.660 --> 00:27:03.010 I'm saying that it's not true that we have p and lw 00:27:03.010 --> 00:27:05.460 because there's no w in our state. 00:27:05.460 --> 00:27:10.070 But if we add in a w somewhere and we keep all the p's, then 00:27:10.070 --> 00:27:14.963 it's true because we have p up until we get to a w. 00:27:14.963 --> 00:27:15.909 Did that make sense? 00:27:15.909 --> 00:27:17.784 AUDIENCE: It made sense that that's the rule, 00:27:17.784 --> 00:27:19.497 but it doesn't make sense to me why. 00:27:19.497 --> 00:27:20.872 Because the statement [INAUDIBLE] 00:27:20.872 --> 00:27:22.850 true and if w never appears. 00:27:22.850 --> 00:27:26.280 You have p until w, which never happened. 00:27:26.280 --> 00:27:26.780 ELLIE: Yeah. 00:27:26.780 --> 00:27:29.759 If w never happened, then it wouldn't be true. 00:27:29.759 --> 00:27:32.050 AUDIENCE: I mean, technically, for the English language 00:27:32.050 --> 00:27:33.329 it would be true. 00:27:33.329 --> 00:27:34.495 AUDIENCE: I guess it's not-- 00:27:34.495 --> 00:27:37.094 AUDIENCE: If you have p out to infinity, 00:27:37.094 --> 00:27:39.120 and you never have w's. 00:27:39.120 --> 00:27:41.364 p until w is true. 00:27:41.364 --> 00:27:43.280 AUDIENCE: p until anything is true [INAUDIBLE] 00:27:43.280 --> 00:27:44.770 AUDIENCE: Like if you say that I'm 00:27:44.770 --> 00:27:46.830 hungry until I eat, and you never eat, 00:27:46.830 --> 00:27:48.125 then you will always be hungry. 00:27:48.125 --> 00:27:50.040 ELLIE: Oh, I see. 00:27:50.040 --> 00:27:51.845 So that makes sense in a logical sense, 00:27:51.845 --> 00:27:53.553 but that's not how it's described in LTL. 00:27:53.553 --> 00:27:55.303 PROFESSOR: There's also an operator that's 00:27:55.303 --> 00:27:57.850 sort of unofficial called the weak until, 00:27:57.850 --> 00:28:01.720 and that's sort of saying p until w, or always p. 00:28:01.720 --> 00:28:04.390 So that kind of gets rid of the condition 00:28:04.390 --> 00:28:05.740 that it reaches w at some point. 00:28:05.740 --> 00:28:07.593 AUDIENCE: It aligns more with the English, too. 00:28:07.593 --> 00:28:08.056 PROFESSOR: Yeah. 00:28:08.056 --> 00:28:08.520 ELLIE: Yeah. 00:28:08.520 --> 00:28:09.640 AUDIENCE: But just the until operator on its own 00:28:09.640 --> 00:28:11.860 is just sort of like a strong until. 00:28:11.860 --> 00:28:12.360 ELLIE: Yeah. 00:28:12.360 --> 00:28:13.111 PROFESSOR: So it adds the-- 00:28:13.111 --> 00:28:14.053 AUDIENCE: Yeah, that's fine. 00:28:14.053 --> 00:28:14.524 ELLIE: OK. 00:28:14.524 --> 00:28:16.024 PROFESSOR: This is the way it works. 00:28:16.024 --> 00:28:16.540 ELLIE: Yeah. 00:28:16.540 --> 00:28:18.410 Sometimes-- yeah, I get confused about this sometimes. 00:28:18.410 --> 00:28:20.030 I'll be like, why they necessarily 00:28:20.030 --> 00:28:21.930 [? chose any of these, ?] but, OK. 00:28:21.930 --> 00:28:24.076 And then the globally one, which we 00:28:24.076 --> 00:28:25.500 said-- this is the one that you were just describing here 00:28:25.500 --> 00:28:26.875 [INAUDIBLE] when you were talking 00:28:26.875 --> 00:28:30.295 about the p at every single state in the future. 00:28:30.295 --> 00:28:32.730 And then the release operator is you 00:28:32.730 --> 00:28:36.750 have to have p until you have w, but p and w also 00:28:36.750 --> 00:28:41.614 have to share the same state when they switch from-- 00:28:41.614 --> 00:28:46.110 so in until, you don't have to have the p here, 00:28:46.110 --> 00:28:48.940 but with release, you have to have the p and w occur 00:28:48.940 --> 00:28:50.522 in the same state. 00:28:50.522 --> 00:28:52.502 Does that make sense? 00:28:52.502 --> 00:28:53.002 Yes? 00:28:53.002 --> 00:28:53.502 OK. 00:28:57.466 --> 00:29:01.786 So just like before, operators can be described using not 00:29:01.786 --> 00:29:03.160 and and. 00:29:03.160 --> 00:29:06.030 The future, released, and the globally operators 00:29:06.030 --> 00:29:13.030 can also be described using other temporal operators. 00:29:13.030 --> 00:29:17.790 And so just as an exercise, can any of you guys tell me which-- 00:29:17.790 --> 00:29:20.170 these are not in order-- which of these line up 00:29:20.170 --> 00:29:23.720 with the other-- like, whichever ones they line up with. 00:29:23.720 --> 00:29:25.553 And I'll give you guys like three minutes 00:29:25.553 --> 00:29:28.178 to just think about it, and then we'll work through it together 00:29:28.178 --> 00:29:29.174 on the board. 00:30:53.336 --> 00:30:54.830 All right, so have any of you guys 00:30:54.830 --> 00:30:57.818 thought about which ones might correlate to which ones? 00:30:57.818 --> 00:31:00.804 Does anyone have any suggestions? 00:31:00.804 --> 00:31:01.304 Yes. 00:31:01.304 --> 00:31:02.798 AUDIENCE: The first one's the top one. 00:31:02.798 --> 00:31:04.089 ELLIE: This one is the top one. 00:31:04.089 --> 00:31:05.446 That's exactly right. 00:31:05.446 --> 00:31:10.870 So let's continue this state again. 00:31:10.870 --> 00:31:16.149 So the statement, true, doesn't say anything 00:31:16.149 --> 00:31:17.855 about what the propositions are. 00:31:17.855 --> 00:31:20.996 It's just something that's true for all states, right? 00:31:20.996 --> 00:31:23.129 So if we're saying, true until pi, 00:31:23.129 --> 00:31:24.670 that means that you can have whatever 00:31:24.670 --> 00:31:28.350 you want until p occurs. 00:31:28.350 --> 00:31:30.766 So does that make sense that, at some point in the future, 00:31:30.766 --> 00:31:36.590 p has to occur, exactly because we had the strong until, right. 00:31:36.590 --> 00:31:38.430 Does that make sense to everyone? 00:31:38.430 --> 00:31:40.280 You guys want to see some [INAUDIBLE]?? 00:31:40.280 --> 00:31:42.280 All right and now what about this one? 00:31:42.280 --> 00:31:46.460 We have not as not p. 00:31:46.460 --> 00:31:54.110 So this is saying that at some point, if you 00:31:54.110 --> 00:31:56.720 can't get a p set at some point in the future, 00:31:56.720 --> 00:31:57.830 you don't have p. 00:31:57.830 --> 00:32:00.360 So what do you think that would correspond to? 00:32:00.360 --> 00:32:02.312 If at some point in the future, you 00:32:02.312 --> 00:32:04.510 can't have the situation where there's not p. 00:32:04.510 --> 00:32:05.510 AUDIENCE: The third one. 00:32:05.510 --> 00:32:06.385 ELLIE: The third one? 00:32:06.385 --> 00:32:09.262 [INAUDIBLE] So that would be if you 00:32:09.262 --> 00:32:12.207 have p at every single state, then 00:32:12.207 --> 00:32:16.376 you would never have a situation where you don't have p, right? 00:32:16.376 --> 00:32:17.750 And so that leaves this last one. 00:32:20.262 --> 00:32:27.738 You don't have a scenario where you have not p until not w. 00:32:27.738 --> 00:32:33.686 So if you have not-- 00:32:33.686 --> 00:32:34.186 OK. 00:32:34.186 --> 00:32:36.170 It's still a little hard. 00:32:36.170 --> 00:32:40.650 But I'll come back to that one at the end, OK? 00:32:40.650 --> 00:32:44.878 But it's just important to remember that you can describe 00:32:44.878 --> 00:32:48.075 these operators with similar to them 00:32:48.075 --> 00:32:49.450 so that your planner doesn't have 00:32:49.450 --> 00:32:53.185 to deal with the global operator or these operators-- eventually 00:32:53.185 --> 00:32:58.200 operator, it can have less [INAUDIBLE] to deal with. 00:32:58.200 --> 00:33:00.140 So yeah, you guys were right. 00:33:00.140 --> 00:33:01.595 Perfect. 00:33:01.595 --> 00:33:04.600 And then this is just a recap of the different operators 00:33:04.600 --> 00:33:10.205 and the other ways that you can express them. 00:33:10.205 --> 00:33:12.950 And so there's a few more really cool things 00:33:12.950 --> 00:33:15.780 that you can do combining these different operators, 00:33:15.780 --> 00:33:19.090 and the first is that-- 00:33:19.090 --> 00:33:23.130 remember when Ben was describing that we need to get gas? 00:33:23.130 --> 00:33:25.090 And we need to get it in the future, 00:33:25.090 --> 00:33:26.838 but even after we get gas, we're going 00:33:26.838 --> 00:33:30.830 to have to get it again some time in the future. 00:33:30.830 --> 00:33:32.886 So it's important that we can describe something 00:33:32.886 --> 00:33:35.010 that happens infinitely often. 00:33:35.010 --> 00:33:38.680 And the way that we describe that is saying that we always 00:33:38.680 --> 00:33:44.660 have the scenario where you will eventually reach p. 00:33:44.660 --> 00:33:49.105 So I'm trying to think of another way to describe that, 00:33:49.105 --> 00:33:52.510 but does that make sense that right now in the future, 00:33:52.510 --> 00:33:53.782 I'm going to get gas. 00:33:53.782 --> 00:33:57.520 And even after I get that gas, I will eventually in the future 00:33:57.520 --> 00:34:00.177 also need to get gas again, because your car will always 00:34:00.177 --> 00:34:01.742 be needing to get gas. 00:34:01.742 --> 00:34:04.658 Does that make sense? 00:34:04.658 --> 00:34:05.630 Cool. 00:34:05.630 --> 00:34:08.580 And then eventually forever is another scenario 00:34:08.580 --> 00:34:11.067 that's important to describe. 00:34:11.067 --> 00:34:13.192 So let's say that the traffic light will eventually 00:34:13.192 --> 00:34:15.169 turn green forever. 00:34:15.169 --> 00:34:17.985 We need to be able to say that at some point in the future, 00:34:17.985 --> 00:34:21.126 although we don't know when, the traffic light will turn green. 00:34:21.126 --> 00:34:26.710 So the future operator says that at some point in the future, 00:34:26.710 --> 00:34:28.844 you will have something come true. 00:34:28.844 --> 00:34:34.570 And so at this state, p becomes true, but the global operators 00:34:34.570 --> 00:34:38.480 that happened from this state forever afterwards, 00:34:38.480 --> 00:34:43.690 which is saying that you eventually will always 00:34:43.690 --> 00:34:45.231 have this state B be true. 00:34:49.062 --> 00:34:50.687 Do you guys have any questions on that? 00:34:50.687 --> 00:34:52.111 Did I explain that good enough. 00:34:52.111 --> 00:34:54.610 AUDIENCE: It seems weird to me that the gas tank is becoming 00:34:54.610 --> 00:34:57.570 this occasional temporal operator instead of just 00:34:57.570 --> 00:34:59.420 like the state that we actually have gas, 00:34:59.420 --> 00:35:04.817 would just be the logical thing that [INAUDIBLE] 00:35:04.817 --> 00:35:05.650 ELLIE: Oh, yeah, I-- 00:35:05.650 --> 00:35:09.360 AUDIENCE: Why is the act of getting gas showing up here 00:35:09.360 --> 00:35:12.529 like that, versus just, you always need quantity of gas. 00:35:12.529 --> 00:35:13.320 ELLIE: That's true. 00:35:13.320 --> 00:35:14.880 We do always need some quantity of gas, 00:35:14.880 --> 00:35:16.671 and you would describe that, like you said, 00:35:16.671 --> 00:35:18.410 just with the always operator, but I 00:35:18.410 --> 00:35:19.861 guess my action of getting gas is 00:35:19.861 --> 00:35:22.350 I was thinking of actually driving up to the gas station 00:35:22.350 --> 00:35:24.760 and filling it up with gas. 00:35:24.760 --> 00:35:29.830 And if you didn't do that, you wouldn't 00:35:29.830 --> 00:35:31.952 be able to always have gas. 00:35:31.952 --> 00:35:33.766 Does that make sense? 00:35:33.766 --> 00:35:35.140 AUDIENCE: Right, so I would think 00:35:35.140 --> 00:35:38.062 that always having gas would make [INAUDIBLE] of you plan 00:35:38.062 --> 00:35:38.836 [INAUDIBLE] 00:35:38.836 --> 00:35:41.086 ELLIE: Yeah, and depending on how you make your model, 00:35:41.086 --> 00:35:43.040 you definitely could do that, and that definitely 00:35:43.040 --> 00:35:44.220 would satisfy the condition. 00:35:44.220 --> 00:35:45.080 [INTERPOSING VOICES] 00:35:45.080 --> 00:35:47.752 AUDIENCE: --the usual way to deal with it? 00:35:47.752 --> 00:35:49.460 ELLIE: Well, it depends on the situation. 00:35:49.460 --> 00:35:53.490 Maybe you [INAUDIBLE] want to say 00:35:53.490 --> 00:35:56.209 at some point in the future, the light will always be green, 00:35:56.209 --> 00:35:58.500 because you want to make sure that cars can go through, 00:35:58.500 --> 00:36:00.041 and there's a difference between red, 00:36:00.041 --> 00:36:02.097 and some point it will be green in the future. 00:36:02.097 --> 00:36:03.930 So it really depends on your model and how-- 00:36:03.930 --> 00:36:05.830 I think the way you're saying it, 00:36:05.830 --> 00:36:07.490 where you always want to have gas, 00:36:07.490 --> 00:36:13.692 and the proposition gas is how much gas you have in your tank, 00:36:13.692 --> 00:36:15.150 and if you have it or don't, then I 00:36:15.150 --> 00:36:16.730 think that that would be a really good way to model it, 00:36:16.730 --> 00:36:17.270 too. 00:36:17.270 --> 00:36:19.728 AUDIENCE: Because this way, if you said, I have to get gas. 00:36:19.728 --> 00:36:22.885 I planned it for next week, but I've run out of gas this week. 00:36:22.885 --> 00:36:25.592 Do you know what I mean, like, you have to somehow be tracking 00:36:25.592 --> 00:36:26.941 the quantity of gas also. 00:36:26.941 --> 00:36:27.566 ELLIE: I agree. 00:36:27.566 --> 00:36:28.080 I agree. 00:36:28.080 --> 00:36:30.890 I was just using it as an example to explain the concept, 00:36:30.890 --> 00:36:32.801 but I agree that that definitely probably 00:36:32.801 --> 00:36:34.092 could be better with more work. 00:36:34.092 --> 00:36:35.890 AUDIENCE: Well, I think in both cases 00:36:35.890 --> 00:36:39.460 what it could represent is having gas all the time, 00:36:39.460 --> 00:36:44.088 or explicitly saying that you're going to be in gas stations 00:36:44.088 --> 00:36:46.056 eventually-- 00:36:46.056 --> 00:36:48.024 always eventually. 00:36:48.024 --> 00:36:49.475 It depends on how-- 00:36:49.475 --> 00:36:53.260 maybe we'd want to always have gas from a station, 00:36:53.260 --> 00:36:55.290 and also getting gas from it. 00:36:55.290 --> 00:36:58.950 So depending on how you want to model it, but I think 00:36:58.950 --> 00:37:00.124 both will work. 00:37:03.980 --> 00:37:06.170 AUDIENCE: So infinite and often, doesn't really 00:37:06.170 --> 00:37:07.947 care about how frequently-- 00:37:07.947 --> 00:37:09.780 ELLIE: Yeah, it doesn't care how frequently. 00:37:09.780 --> 00:37:11.791 AUDIENCE: But [INAUDIBLE] for instance something 00:37:11.791 --> 00:37:13.950 that happens every 60 years. 00:37:13.950 --> 00:37:16.304 My system lifetime server is 30 years, 00:37:16.304 --> 00:37:17.970 which means something happens only once. 00:37:17.970 --> 00:37:20.573 So in this case, infinite and often, 00:37:20.573 --> 00:37:22.320 how can you filter a switch operator 00:37:22.320 --> 00:37:24.364 could be the same, right? 00:37:24.364 --> 00:37:26.547 ELLIE: Can you repeat that again [INAUDIBLE] 00:37:26.547 --> 00:37:28.005 AUDIENCE: So for instance something 00:37:28.005 --> 00:37:29.970 happens every 60 years. 00:37:29.970 --> 00:37:31.540 My system lifetime goes to 30 years. 00:37:31.540 --> 00:37:34.210 After 30 years, I have to get a re-up on the system. 00:37:34.210 --> 00:37:37.790 Then so during this [INAUDIBLE] only one thing happened. 00:37:37.790 --> 00:37:39.814 And so it happens off into infinity, 00:37:39.814 --> 00:37:41.230 but in the lifetime of the system, 00:37:41.230 --> 00:37:43.480 it only happened once, and therefore 00:37:43.480 --> 00:37:46.570 in this condition, the infinite and often should 00:37:46.570 --> 00:37:49.435 be set the same as the future, right, in the current state. 00:37:49.435 --> 00:37:50.810 Something happened in the future, 00:37:50.810 --> 00:37:53.960 I would say something could never happen again. 00:37:53.960 --> 00:37:55.200 ELLIE: Kind of. 00:37:55.200 --> 00:37:57.303 So when you're talking about a system that's 00:37:57.303 --> 00:38:02.320 dying after 30 years, the LTL doesn't actual model something 00:38:02.320 --> 00:38:03.294 that ends. 00:38:03.294 --> 00:38:05.070 It would model something to infinity, 00:38:05.070 --> 00:38:06.870 although there is an extension to LTL that 00:38:06.870 --> 00:38:12.590 can incorporate that into it, having it have an actual end 00:38:12.590 --> 00:38:13.335 goal state. 00:38:13.335 --> 00:38:16.430 And I think in that case, then infinitely often would 00:38:16.430 --> 00:38:19.384 be different, and would-- 00:38:19.384 --> 00:38:22.055 I don't know exactly how that would find that situation. 00:38:22.055 --> 00:38:23.052 Do you know, Ben? 00:38:23.052 --> 00:38:25.909 I know you had kind of-- 00:38:25.909 --> 00:38:28.450 BEN: So there's something called metric temporal logic, which 00:38:28.450 --> 00:38:31.704 associates a time scale of each of these operators. 00:38:31.704 --> 00:38:33.870 So I think you'd have to use that if you were trying 00:38:33.870 --> 00:38:37.210 to express that you had to always meet those conditions 00:38:37.210 --> 00:38:38.354 still within your lifetime. 00:38:38.354 --> 00:38:41.740 You could have some sort of qualifier to these operators 00:38:41.740 --> 00:38:44.730 to specify an actual time [INAUDIBLE] where that operator 00:38:44.730 --> 00:38:45.237 [INAUDIBLE] 00:38:45.237 --> 00:38:46.612 AUDIENCE: So which would you file 00:38:46.612 --> 00:38:48.608 for the instance infinitely often [INAUDIBLE] 00:38:48.608 --> 00:38:50.850 scenario something at a little bit more frequent 00:38:50.850 --> 00:38:53.230 of a general system by the time, right. 00:38:53.230 --> 00:38:56.290 Now we have something you know [INAUDIBLE] 100 years ago 00:38:56.290 --> 00:38:57.570 for years. 00:38:57.570 --> 00:39:00.362 BEN: You know, it's important that the LTL 00:39:00.362 --> 00:39:02.820 we're explaining here is only dealing with infinite states. 00:39:02.820 --> 00:39:04.575 So I agree, it's a little bit-- you 00:39:04.575 --> 00:39:06.200 have to think about that process of how 00:39:06.200 --> 00:39:09.219 do apply something that goes on forever to a real system. 00:39:09.219 --> 00:39:10.760 It obviously doesn't model correctly. 00:39:10.760 --> 00:39:12.259 AUDIENCE: There has to be a way to-- 00:39:12.259 --> 00:39:14.330 I mean the future thing, if he has a system that 00:39:14.330 --> 00:39:17.052 lasts 30 years, and you say future p, 00:39:17.052 --> 00:39:18.635 somewhere in your design of the system 00:39:18.635 --> 00:39:21.095 is going to say that the constraint on future p 00:39:21.095 --> 00:39:23.290 is that it has to happen within 30 years, right? 00:39:23.290 --> 00:39:25.793 Because future p here, for getting gas, 00:39:25.793 --> 00:39:27.750 has to happen before I run out of gas. 00:39:27.750 --> 00:39:30.350 It's not just-- this representation says it just 00:39:30.350 --> 00:39:33.554 happens in the future, but somewhere in your constraint 00:39:33.554 --> 00:39:35.362 checking, it's going to say, hey, we 00:39:35.362 --> 00:39:37.580 didn't get gas in this plan soon enough, right? 00:39:37.580 --> 00:39:38.195 ELLIE: Yeah. 00:39:38.195 --> 00:39:38.560 AUDIENCE: Somehow. 00:39:38.560 --> 00:39:40.018 ELLIE: Yes, that's definitely true. 00:39:40.018 --> 00:39:43.917 And these are just tools to help you model it, 00:39:43.917 --> 00:39:46.755 but it's definitely not the entire model of your system 00:39:46.755 --> 00:39:49.505 obviously, and so I agree that we definitely would 00:39:49.505 --> 00:39:50.671 have to incorporate that in. 00:39:50.671 --> 00:39:54.145 And for finance systems you have to account for that. 00:39:54.145 --> 00:39:56.270 And that's why they have the extension of LTL which 00:39:56.270 --> 00:39:59.520 is the finance systems, which we can certainly 00:39:59.520 --> 00:40:01.870 drop a link of of the papers, and where 00:40:01.870 --> 00:40:04.120 we got the information, to the class if you guys would 00:40:04.120 --> 00:40:06.514 like that. 00:40:06.514 --> 00:40:08.930 AUDIENCE: Yeah, I think you guys have done a very good job 00:40:08.930 --> 00:40:10.430 of answering the questions. 00:40:10.430 --> 00:40:13.005 The three extensions to LTL that I've 00:40:13.005 --> 00:40:14.880 found to be the most relevant kinds of things 00:40:14.880 --> 00:40:17.691 that we're doing is metric temporal logic, 00:40:17.691 --> 00:40:19.440 which is the first one that you mentioned, 00:40:19.440 --> 00:40:22.070 also to be able to have it over bounded time, which is related, 00:40:22.070 --> 00:40:22.820 and you mentioned. 00:40:22.820 --> 00:40:24.975 And then the last one is to deal with uncertainty, 00:40:24.975 --> 00:40:28.129 and is then a problem of linear temporal logic. 00:40:28.129 --> 00:40:28.629 ELLIE: OK. 00:40:28.629 --> 00:40:29.129 Cool. 00:40:29.129 --> 00:40:31.587 All right. 00:40:31.587 --> 00:40:34.545 So I meant to have this as two separate slides, 00:40:34.545 --> 00:40:39.490 but what are some true statements about LTL 00:40:39.490 --> 00:40:42.173 that you guys can tell me about to look at this, 00:40:42.173 --> 00:40:44.855 or do, and explain why if you look at it. 00:40:50.190 --> 00:40:54.235 OK, so why is the next red true? 00:40:54.235 --> 00:40:55.776 AUDIENCE: The next step is slow down. 00:40:55.776 --> 00:40:56.740 ELLIE: Yep, exactly. 00:40:56.740 --> 00:40:57.906 Because the next one is red. 00:40:57.906 --> 00:41:00.380 Why is it true that in the future, that it's green? 00:41:00.380 --> 00:41:01.766 [INAUDIBLE] 00:41:01.766 --> 00:41:03.731 Because in the future, it's green. 00:41:03.731 --> 00:41:06.612 And why is it true that there's red until green? 00:41:06.612 --> 00:41:09.438 AUDIENCE: It keeps being red until it's green. 00:41:09.438 --> 00:41:10.307 ELLIE: Exactly. 00:41:10.307 --> 00:41:11.890 So it makes sense that if all of these 00:41:11.890 --> 00:41:15.786 are true, that this culmination of the and statements 00:41:15.786 --> 00:41:17.510 between all of them is also true, right? 00:41:17.510 --> 00:41:19.618 And so you could do that with or as well, 00:41:19.618 --> 00:41:21.170 or you could do that with-- 00:41:21.170 --> 00:41:23.932 if you had sequences behind here, 00:41:23.932 --> 00:41:26.410 you could put a future around this whole thing, 00:41:26.410 --> 00:41:28.930 and it would be true that at some point in the future, 00:41:28.930 --> 00:41:30.084 all of this would hold. 00:41:30.084 --> 00:41:31.912 Does that make sense? 00:41:31.912 --> 00:41:32.826 Yes? 00:41:32.826 --> 00:41:33.740 OK. 00:41:33.740 --> 00:41:35.073 AUDIENCE: Why keep it red there? 00:41:35.073 --> 00:41:37.160 Your red is the next step. 00:41:37.160 --> 00:41:37.660 ELLIE: Yep. 00:41:37.660 --> 00:41:38.159 Exactly. 00:41:38.159 --> 00:41:41.330 I was just saying if you had more in the past, 00:41:41.330 --> 00:41:43.856 and you were considering it from the previous-- 00:41:43.856 --> 00:41:46.419 All right so now Nadia's going to talk 00:41:46.419 --> 00:41:48.726 about expressing LTL in PDDL3. 00:41:57.920 --> 00:42:03.270 So Ben and Ellie have guided through how 00:42:03.270 --> 00:42:05.768 expressive LTL formulation is. 00:42:05.768 --> 00:42:11.820 I'm going to formulate the LTL in a classical planner 00:42:11.820 --> 00:42:13.010 like PDDL3. 00:42:13.010 --> 00:42:19.340 Now I'm using PDDL3, which is an composed extension of PDDL2.2, 00:42:19.340 --> 00:42:26.170 which supports some of the LTL operators. 00:42:26.170 --> 00:42:29.670 So these are the basic operators that you 00:42:29.670 --> 00:42:31.920 can use to express the constraints 00:42:31.920 --> 00:42:34.230 and goals of your plan. 00:42:34.230 --> 00:42:37.875 So you have at end, always, sometimes, within, 00:42:37.875 --> 00:42:43.020 at-most-once, sometime-after, sometime-before, always-within, 00:42:43.020 --> 00:42:44.910 and hold-during. 00:42:44.910 --> 00:42:50.940 So again, now here is a numeric controls that you can specify, 00:42:50.940 --> 00:42:57.550 and the ellipses represents an already-existing [INAUDIBLE] 00:42:57.550 --> 00:42:58.050 goal. 00:42:58.050 --> 00:42:59.956 This is a goal description-- 00:42:59.956 --> 00:43:00.870 [INAUDIBLE] 00:43:00.870 --> 00:43:05.580 So some of the operators may look familiar to you, 00:43:05.580 --> 00:43:09.450 because they can also be used to express the constraint in STN, 00:43:09.450 --> 00:43:13.200 the Simple Temporal Network, that we learned in class. 00:43:13.200 --> 00:43:15.870 And there are some operators that 00:43:15.870 --> 00:43:19.450 are unique to LTL or other kinds, 00:43:19.450 --> 00:43:24.910 like metric temporal network, like always, for example. 00:43:24.910 --> 00:43:27.370 So now we are going to take a look 00:43:27.370 --> 00:43:35.144 at how you can express the operators using 00:43:35.144 --> 00:43:39.960 the PDDL3 language. 00:43:39.960 --> 00:43:44.090 So we can use, within one occurrence to the next, 00:43:44.090 --> 00:43:48.410 because there is no explicit next in the PDDL3. 00:43:48.410 --> 00:43:52.625 And you use always until to express until. 00:43:52.625 --> 00:43:56.220 And in the future, you use sometimes after, 00:43:56.220 --> 00:43:59.320 and globally, you can use always. 00:43:59.320 --> 00:44:02.130 And for release, since it can always 00:44:02.130 --> 00:44:09.930 be omega or always until omega when you see p. 00:44:09.930 --> 00:44:13.964 You can use all costs, too, although this [INAUDIBLE].. 00:44:17.380 --> 00:44:19.980 OK, let's see some examples. 00:44:19.980 --> 00:44:25.877 So if your goal is to have the traffic light turn 00:44:25.877 --> 00:44:29.110 red in the next state, you would want 00:44:29.110 --> 00:44:36.775 to formulate it using within one occurrence, 00:44:36.775 --> 00:44:38.260 the traffic light would turn red. 00:44:41.730 --> 00:44:45.320 And let's take a look at a more complicated example. 00:44:45.320 --> 00:44:49.290 So if you want to model a goal saying that the traffic 00:44:49.290 --> 00:44:56.558 light would be green until it turns red, at which point 00:44:56.558 --> 00:44:58.850 it would be red forever. 00:44:58.850 --> 00:45:03.862 So this is temporal logic of predicates 00:45:03.862 --> 00:45:08.046 that express this goal. 00:45:08.046 --> 00:45:13.800 And then if you want to model that using PDDL, 00:45:13.800 --> 00:45:15.580 there is a direct mapping. 00:45:15.580 --> 00:45:17.828 You can see the direct mapping between the predicates 00:45:17.828 --> 00:45:20.220 and the PDDL. 00:45:20.220 --> 00:45:25.740 So this is basically saying, it would always 00:45:25.740 --> 00:45:28.226 be green until it turns red. 00:45:28.226 --> 00:45:31.740 And turning red implies it will always turn red. 00:45:36.520 --> 00:45:42.640 So next, [? Arleese ?] will tell us how to map between the LTL 00:45:42.640 --> 00:45:44.795 to PDDL with a Buchi Automata which 00:45:44.795 --> 00:45:46.494 is a specialized automata. 00:45:50.752 --> 00:45:51.585 GUEST SPEAKER: Cool. 00:45:51.585 --> 00:45:54.880 So I'm [? Arleese. ?] I have bridged the gap between LTL 00:45:54.880 --> 00:45:56.404 and the planning world. 00:45:56.404 --> 00:45:58.434 So this is kind of the framework for how 00:45:58.434 --> 00:45:59.850 you would go from taking a problem 00:45:59.850 --> 00:46:03.000 with temporally extended goals all the way to a plan. 00:46:03.000 --> 00:46:05.376 So as you can kind of imagine from what 00:46:05.376 --> 00:46:07.040 Ben and Ellie were talking about, 00:46:07.040 --> 00:46:08.195 LTL is pretty expressive. 00:46:08.195 --> 00:46:10.236 You can express a lot of different types of goals 00:46:10.236 --> 00:46:14.170 that include more temporal properties than just a time 00:46:14.170 --> 00:46:17.140 window for a goal to be completed. 00:46:17.140 --> 00:46:19.196 So once we have a kind of defined problem 00:46:19.196 --> 00:46:21.140 with these temporary extended goals, 00:46:21.140 --> 00:46:26.021 then you want to model it in a language like LTL or PDDL. 00:46:26.021 --> 00:46:27.520 So if you have a language like PDDL, 00:46:27.520 --> 00:46:30.117 and you have a planner that can do an algorithm called 00:46:30.117 --> 00:46:32.200 progression, which I'll talk about a little later, 00:46:32.200 --> 00:46:34.770 you can go directly to a plan. 00:46:34.770 --> 00:46:38.503 Basically how progression works is it's kind of an algorithm 00:46:38.503 --> 00:46:40.670 that tells you when you're analyzing a state, 00:46:40.670 --> 00:46:43.370 and you're analyzing LTL-like formulas that 00:46:43.370 --> 00:46:47.360 are true in a specific state, how to push formulas 00:46:47.360 --> 00:46:50.087 that you need to evaluate later on to the next state, 00:46:50.087 --> 00:46:52.045 and how to keep track of things that you 00:46:52.045 --> 00:46:56.890 need to continue to evaluate for satisfaction in future states. 00:46:56.890 --> 00:47:00.375 Another way you can do this is by taking LTL formulations 00:47:00.375 --> 00:47:02.640 and translating them into Buchi Automata. 00:47:02.640 --> 00:47:05.710 So Buchi Automata are basically finite state machines 00:47:05.710 --> 00:47:10.530 that are extended to handle an infinite sequence of states. 00:47:10.530 --> 00:47:14.110 And I'll get into more about how Buchi Automata work. 00:47:14.110 --> 00:47:15.664 After you have a Buchi Automata, you 00:47:15.664 --> 00:47:17.620 can then translate that into PDDL2, 00:47:17.620 --> 00:47:19.304 which you guys are all familiar with, 00:47:19.304 --> 00:47:22.390 and then that PDDL2 can be used from the classical planner, 00:47:22.390 --> 00:47:23.582 and get a plan. 00:47:26.778 --> 00:47:28.528 So a little bit more about Buchi Automata. 00:47:28.528 --> 00:47:30.270 Again, like I said, it's an extension 00:47:30.270 --> 00:47:31.780 of a finite state machine. 00:47:31.780 --> 00:47:32.432 Oh, yes. 00:47:32.432 --> 00:47:34.973 AUDIENCE: Why would have a Buchi Automata when you could just 00:47:34.973 --> 00:47:38.925 use a planner that will go from PDDL3 straight to the plan? 00:47:38.925 --> 00:47:41.060 GUEST SPEAKER: I guess it just depends on how-- 00:47:41.060 --> 00:47:42.930 what kind of planners we have access to, 00:47:42.930 --> 00:47:44.320 what other systems you have. 00:47:44.320 --> 00:47:45.602 It's done both ways. 00:47:45.602 --> 00:47:47.951 So PDDL3 is still kind of new, and so there's not 00:47:47.951 --> 00:47:50.284 a lot of planners that actually have progression and can 00:47:50.284 --> 00:47:51.228 handle PDDL3. 00:47:54.060 --> 00:47:57.990 AUDIENCE: And it's also the case that the particular algorithms 00:47:57.990 --> 00:48:01.350 that are trying to either be verification or planning, maybe 00:48:01.350 --> 00:48:04.180 exploiting particular properties of the Buchi Automaton, 00:48:04.180 --> 00:48:06.384 as opposed to the properties of the native language. 00:48:09.287 --> 00:48:11.870 GUEST SPEAKER: So you guys are all familiar with regular state 00:48:11.870 --> 00:48:12.395 machines. 00:48:12.395 --> 00:48:14.822 Buchi Automata has a very similar formulation. 00:48:14.822 --> 00:48:17.210 Some slight differences-- you have a set of states, 00:48:17.210 --> 00:48:21.050 you have an initial state, and you have a transition relation, 00:48:21.050 --> 00:48:23.020 and then you have a set of accepting states. 00:48:23.020 --> 00:48:24.603 These accepting states are essentially 00:48:24.603 --> 00:48:27.545 what replaces finite states in the state machine. 00:48:27.545 --> 00:48:30.570 We also have a set of symbols that are again simply 00:48:30.570 --> 00:48:33.040 the transitions between states. 00:48:33.040 --> 00:48:35.630 So what an accepting state is, is a Buchi Automata 00:48:35.630 --> 00:48:39.810 can only be valid if the sequence of transitions 00:48:39.810 --> 00:48:42.954 visits an accepting state an infinite amount of times. 00:48:42.954 --> 00:48:44.974 So I'll get into a couple examples. 00:48:44.974 --> 00:48:48.660 So let's say you want to model the ticking-tocking of a clock. 00:48:48.660 --> 00:48:51.690 This is just a regular finite state machine. 00:48:51.690 --> 00:48:54.560 As you can see, after some number of ticks and tocks, 00:48:54.560 --> 00:48:56.630 you get into S2, and you're in S2 00:48:56.630 --> 00:48:59.350 because you can be in transition only [INAUDIBLE] 00:48:59.350 --> 00:49:01.900 So you're in S2 basically forever once you get to S2. 00:49:01.900 --> 00:49:03.920 So we can model this as a Buchi Automata 00:49:03.920 --> 00:49:07.970 by making S2 an accepted state. 00:49:07.970 --> 00:49:09.722 This example, making it a Buchi Automata, 00:49:09.722 --> 00:49:11.180 doesn't really do anything for you. 00:49:11.180 --> 00:49:14.030 It's just kind of to illustrate what the accepting state does. 00:49:14.030 --> 00:49:17.470 So the accepting words are a sequence of transitions. 00:49:17.470 --> 00:49:20.600 In this case it would be an infinite combination 00:49:20.600 --> 00:49:24.512 of ticks and tocks that would make this Buchi Automata valid. 00:49:24.512 --> 00:49:27.218 Does that make sense. 00:49:27.218 --> 00:49:30.401 Questions about that? 00:49:30.401 --> 00:49:31.900 Here's another example, for example, 00:49:31.900 --> 00:49:34.780 if I have changed what my accepting state was. 00:49:34.780 --> 00:49:36.516 So if our accepting state was S1, 00:49:36.516 --> 00:49:38.780 I now have to visit S1 an infinite amount of times 00:49:38.780 --> 00:49:40.980 for this Buchi Automata to be valid. 00:49:40.980 --> 00:49:43.620 That means the only valid sequence 00:49:43.620 --> 00:49:46.589 of transitions I could have is tock tick tick tick 00:49:46.589 --> 00:49:48.130 tick for an infinite amount of times. 00:49:48.130 --> 00:49:50.830 So you can kind of represent different things 00:49:50.830 --> 00:49:52.420 and different sequences of inputs 00:49:52.420 --> 00:49:55.030 you might want to have based on which accepting state you use. 00:49:57.596 --> 00:49:58.740 This is another example. 00:49:58.740 --> 00:50:01.920 If you wanted your clock to be tick tock tick tock tick tock, 00:50:01.920 --> 00:50:03.795 you can have more than one accepting state, 00:50:03.795 --> 00:50:08.030 and now I have to visit S0 and S1 an infinite amount of times 00:50:08.030 --> 00:50:11.620 if I want this Buchi Automata to be valid. 00:50:11.620 --> 00:50:13.800 So then the sequence of transitions I get 00:50:13.800 --> 00:50:15.772 is tick tock tick tock tick tock. 00:50:15.772 --> 00:50:17.938 Does anyone have any questions to really think about 00:50:17.938 --> 00:50:22.231 in general with Buchi Automata? 00:50:22.231 --> 00:50:24.620 OK. 00:50:24.620 --> 00:50:28.758 It might help to see how we model LTL as Buchi Automata. 00:50:28.758 --> 00:50:32.800 So here's an example of of these LTL formulas 00:50:32.800 --> 00:50:35.192 modeled as a Buchi Automata. 00:50:35.192 --> 00:50:36.660 I guess take a few minutes and see 00:50:36.660 --> 00:50:40.066 if you can get which one this one might be. 00:50:53.954 --> 00:50:55.450 AUDIENCE: [INAUDIBLE] 00:50:55.450 --> 00:50:56.590 GUEST SPEAKER: Yeah. 00:50:56.590 --> 00:50:59.620 Just so that everyone can kind of see that, and future events, 00:50:59.620 --> 00:51:01.865 we remember that means that eventually p 00:51:01.865 --> 00:51:04.540 has to be true at least once. 00:51:04.540 --> 00:51:09.740 So from any sort of input state, you go to S0, 00:51:09.740 --> 00:51:12.440 and then I do have amount p for some amount of time, 00:51:12.440 --> 00:51:15.674 but as soon as I have p, I have to get to p, 00:51:15.674 --> 00:51:17.340 because I have to be in my subject state 00:51:17.340 --> 00:51:18.506 an infinite amount of times. 00:51:18.506 --> 00:51:20.340 So I have to execute p at some point 00:51:20.340 --> 00:51:23.650 to get to my accepting state for this Buchi Automata 00:51:23.650 --> 00:51:24.212 to be valid. 00:51:24.212 --> 00:51:26.680 And then once I'm at S1, I can have 00:51:26.680 --> 00:51:28.050 any other amount of inputs. 00:51:28.050 --> 00:51:33.435 I'll always be in S1, and that's what the true label means. 00:51:33.435 --> 00:51:34.810 AUDIENCE: And it's also something 00:51:34.810 --> 00:51:36.351 stronger, right, which is you could-- 00:51:36.351 --> 00:51:37.875 it's eventually globally? 00:51:37.875 --> 00:51:40.150 GUEST SPEAKER: Right. 00:51:40.150 --> 00:51:45.730 Yeah, so actually in this case, after it gets here, 00:51:45.730 --> 00:51:46.990 my input could be anything. 00:51:46.990 --> 00:51:50.260 So this basically just says that for my initial state, 00:51:50.260 --> 00:51:52.046 I have to execute p at least once to get 00:51:52.046 --> 00:51:54.420 to this accepting state, and once I'm there, 00:51:54.420 --> 00:51:55.720 I can be there-- 00:51:55.720 --> 00:51:56.730 I'm always there. 00:51:56.730 --> 00:51:59.576 Any input will believe me in S1. 00:51:59.576 --> 00:52:02.455 AUDIENCE: So just to make this clear for myself and maybe 00:52:02.455 --> 00:52:04.730 for others, the data string executed 00:52:04.730 --> 00:52:09.390 that's at R state something that's on the loop. 00:52:09.390 --> 00:52:11.650 If you go from s0 to s0, that's essentially 00:52:11.650 --> 00:52:13.967 saying that one of the nodes is not p. 00:52:13.967 --> 00:52:17.250 If you go from s0 to s1, it's saying that one of the nodes 00:52:17.250 --> 00:52:18.134 is p. 00:52:18.134 --> 00:52:18.576 GUEST SPEAKER: Yeah. 00:52:18.576 --> 00:52:19.950 AUDIENCE: If you go from s1 to s1 00:52:19.950 --> 00:52:25.010 and take whatever it would be because you set it true. 00:52:25.010 --> 00:52:27.430 AUDIENCE: So if you put p where the true is right now, 00:52:27.430 --> 00:52:29.370 then you you won't have to go through. 00:52:29.370 --> 00:52:30.078 PROFESSOR: Right. 00:52:30.078 --> 00:52:32.020 That's what I missed. 00:52:32.020 --> 00:52:35.287 By the way, you guys have 25 more minutes. 00:52:37.604 --> 00:52:39.520 GUEST SPEAKER: So that's what we talked about. 00:52:39.520 --> 00:52:41.232 This is future. 00:52:41.232 --> 00:52:44.550 So the accepted sequence of propositions 00:52:44.550 --> 00:52:46.230 would be not to not p. 00:52:46.230 --> 00:52:47.600 Then you have p. 00:52:47.600 --> 00:52:49.450 Then it can be anything after you get to p. 00:52:49.450 --> 00:52:52.180 And then in this case, for Buchi Automata states, which 00:52:52.180 --> 00:52:54.980 are like [INAUDIBLE],, slightly different than the LTL states 00:52:54.980 --> 00:52:56.153 we've been talking about. 00:52:56.153 --> 00:52:57.350 In this case, you're in s0. 00:52:57.350 --> 00:52:59.716 And then once you get to s1, you're forever in s1. 00:53:03.470 --> 00:53:06.690 So globally, looks pretty similar to this. 00:53:06.690 --> 00:53:08.840 Take a few minutes to think about how 00:53:08.840 --> 00:53:11.950 I might change this Buchi Automata to [INAUDIBLE] 00:53:11.950 --> 00:53:21.845 globally after [INAUDIBLE] 00:53:21.845 --> 00:53:24.597 AUDIENCE: [INAUDIBLE] 00:53:24.597 --> 00:53:25.805 GUEST SPEAKER: Yeah, exactly. 00:53:29.290 --> 00:53:32.170 So you have initially, your first state by your n 00:53:32.170 --> 00:53:34.810 because p has to be true forever after you 00:53:34.810 --> 00:53:35.940 get to this first state. 00:53:35.940 --> 00:53:38.320 You have an accepting state in p. 00:53:38.320 --> 00:53:40.715 You can also model not p. 00:53:40.715 --> 00:53:42.090 If you want to, you can also just 00:53:42.090 --> 00:53:44.420 have this single see which would encapsulate 00:53:44.420 --> 00:53:47.552 exactly what Buchi is. 00:53:47.552 --> 00:53:50.940 This is how you go from LTL to Buchi Automata. 00:53:50.940 --> 00:53:54.304 In a real-world scenario, we have multiple LTL formulas all 00:53:54.304 --> 00:53:54.846 combined. 00:53:54.846 --> 00:53:57.220 You're Buchi Automata are going to look a little bit more 00:53:57.220 --> 00:53:58.930 complicated than this. 00:53:58.930 --> 00:54:02.290 Try multiple accepting states. 00:54:02.290 --> 00:54:04.800 There's a full weighted model of what 00:54:04.800 --> 00:54:07.150 an LTL is trying to represent. 00:54:09.826 --> 00:54:12.684 AUDIENCE: If we have the not p transition out of there, 00:54:12.684 --> 00:54:16.600 Like it's possible you can come into s0 to accept the Buchi 00:54:16.600 --> 00:54:19.465 Automata because it would go to s1, right? 00:54:19.465 --> 00:54:21.690 GUEST SPEAKER: Accepting a Buchi Automata after that, 00:54:21.690 --> 00:54:22.799 it's a little confusing. 00:54:22.799 --> 00:54:25.090 A Buchi Automata is only valid if the infinite sequence 00:54:25.090 --> 00:54:28.345 of states satisfies it. 00:54:28.345 --> 00:54:33.129 If I were to go the p instead of not p, 00:54:33.129 --> 00:54:36.456 my sequence would accept a transition of p, p, not p. 00:54:36.456 --> 00:54:38.810 Then that would not be a valid sequence 00:54:38.810 --> 00:54:41.214 of transition for this Buchi Automata 00:54:41.214 --> 00:54:43.380 because I'm transitioning out of my accepting state, 00:54:43.380 --> 00:54:46.240 which I need to have been in for at least the amount of times. 00:54:46.240 --> 00:54:49.346 And there's no way I can get back to success. 00:54:56.436 --> 00:54:59.700 Also, a more defined algorithm [INAUDIBLE] an intuitive way 00:54:59.700 --> 00:55:02.444 to build a Buchi Automata, or is an algorithm. 00:55:02.444 --> 00:55:04.110 The other one that's most popularly used 00:55:04.110 --> 00:55:05.830 was developed by [INAUDIBLE]. 00:55:05.830 --> 00:55:09.885 This is a pseudocode version of the algorithm. 00:55:09.885 --> 00:55:11.380 We go from LTL to Buchi. 00:55:11.380 --> 00:55:13.960 As you've noticed, it actually uses progression, 00:55:13.960 --> 00:55:18.990 which is something that planners that take PDDL use to generate 00:55:18.990 --> 00:55:20.210 plans. 00:55:20.210 --> 00:55:21.770 An important thing to note, which 00:55:21.770 --> 00:55:24.570 I won't go into too much detail, this algorithm 00:55:24.570 --> 00:55:26.250 generates a generalized Buchi Automata, 00:55:26.250 --> 00:55:30.019 which you then change to a simple Buchi Automata. 00:55:30.019 --> 00:55:32.060 The difference is, the generalized Buchi Automata 00:55:32.060 --> 00:55:35.940 has a set of sets of accepting states. 00:55:35.940 --> 00:55:39.200 For a generalized Buchi Automata to be accepted, 00:55:39.200 --> 00:55:41.325 you need to visit an accepting state 00:55:41.325 --> 00:55:43.393 in each one of those sets of accepting states. 00:55:43.393 --> 00:55:46.220 At least one of those states has to be listed. 00:55:46.220 --> 00:55:48.430 For a simple Buchi Automata, you only 00:55:48.430 --> 00:55:49.950 have one set of accepting states. 00:55:49.950 --> 00:55:52.855 And you can visit any one of those for the Buchi Automata 00:55:52.855 --> 00:55:54.255 to be valid. 00:55:54.255 --> 00:55:56.630 On the translation between those two is a little bit more 00:55:56.630 --> 00:55:57.640 complicated. 00:55:57.640 --> 00:56:00.052 We'll have paper in the preference that will 00:56:00.052 --> 00:56:01.465 walk through how to do that. 00:56:01.465 --> 00:56:04.291 But we're not going to do that now. 00:56:04.291 --> 00:56:07.800 This is a progression algorithm. 00:56:07.800 --> 00:56:12.260 Basically, it just tells you how if have a LTL formula f 00:56:12.260 --> 00:56:14.180 and some current state N-- 00:56:14.180 --> 00:56:16.776 and usually they involve some time step 00:56:16.776 --> 00:56:18.900 because we're in the real world and we can't really 00:56:18.900 --> 00:56:21.770 model infinite amount of time, and we 00:56:21.770 --> 00:56:23.890 have to make it discrete. 00:56:23.890 --> 00:56:28.125 So we have some time step, which means successive state. 00:56:28.125 --> 00:56:31.820 How do you push certain LTL formulas onto next states 00:56:31.820 --> 00:56:33.792 to be evaluated later? 00:56:33.792 --> 00:56:37.530 For example, I'll take this next f as an example. 00:56:37.530 --> 00:56:40.730 So if f was a next f of some LTL formula, 00:56:40.730 --> 00:56:44.936 you need to append that formula to the next state 00:56:44.936 --> 00:56:46.820 to be evaluated in the next state 00:56:46.820 --> 00:56:49.486 to see if that's going to be true or not. 00:56:49.486 --> 00:56:51.204 Similar things for LTL. 00:56:51.204 --> 00:56:54.770 And I won't go through this [INAUDIBLE] 00:56:54.770 --> 00:56:58.492 it's here for reference. 00:56:58.492 --> 00:57:00.950 The next step to this process is going from Buchi Automata, 00:57:00.950 --> 00:57:03.050 that's a PDDL2. 00:57:03.050 --> 00:57:04.465 This process is confusing. 00:57:04.465 --> 00:57:06.960 At least it is confusing for me to understand. 00:57:06.960 --> 00:57:09.440 The first thing I'll say is that Buchi states are not 00:57:09.440 --> 00:57:11.330 equivalent to traditional PDDL states. 00:57:11.330 --> 00:57:14.570 In a PDDL state, if you have two states, 00:57:14.570 --> 00:57:17.540 you have the same propositions that are true and false, 00:57:17.540 --> 00:57:18.902 those states are identical. 00:57:18.902 --> 00:57:23.133 In the Buchi Automata, that's not necessarily true. 00:57:23.133 --> 00:57:24.880 In the Buchi Automata you also have 00:57:24.880 --> 00:57:27.360 to encapsulate which transitions you can make out 00:57:27.360 --> 00:57:28.560 of each Buchi state. 00:57:28.560 --> 00:57:33.020 So s1 and s2 couldn't have the same set of propositions 00:57:33.020 --> 00:57:35.830 that are [INAUDIBLE] hold. 00:57:35.830 --> 00:57:37.290 But out of s1-- 00:57:37.290 --> 00:57:38.815 actually, back up. 00:57:38.815 --> 00:57:42.230 This is the Buchi Automata for FutureGlobally, 00:57:42.230 --> 00:57:44.480 which is what [INAUDIBLE] was talking about. 00:57:44.480 --> 00:57:46.760 So if I enter an f1, the star means 00:57:46.760 --> 00:57:52.560 I can have any transition that I want in s1. 00:57:52.560 --> 00:57:54.560 At some point, I make the transition p 00:57:54.560 --> 00:57:57.530 and whatever the s2, I have to take transition p forever. 00:58:00.240 --> 00:58:05.380 However, if I get a sequence of inputs, let's say I get p 00:58:05.380 --> 00:58:11.000 and then b, and p again, and then p again, 00:58:11.000 --> 00:58:12.730 it's not clear if I'm in s1 or s2 00:58:12.730 --> 00:58:16.070 because in s1 I can execute any kind of state I want. 00:58:16.070 --> 00:58:19.140 In s1 I can execute any transition I want in s1. 00:58:19.140 --> 00:58:21.500 2 I have to execute only p. 00:58:21.500 --> 00:58:25.560 So if I got a sequence of p's, I could be in either state. 00:58:25.560 --> 00:58:29.120 You need something else to activate PDDL2 to basically 00:58:29.120 --> 00:58:31.355 to determine which state you're and which transitions 00:58:31.355 --> 00:58:34.644 you can make from that state. 00:58:34.644 --> 00:58:37.074 Does that make sense to everyone? 00:58:40.490 --> 00:58:42.620 So there's two ways we can transform 00:58:42.620 --> 00:58:47.020 PDDL2 to encapsulate what a Buchi Automata encapsulates. 00:58:47.020 --> 00:58:48.650 The first thing is you can create 00:58:48.650 --> 00:58:51.640 new actions that can encapsulate the allowable transitions 00:58:51.640 --> 00:58:53.490 of each state. 00:58:53.490 --> 00:58:55.530 So basically, for every action you 00:58:55.530 --> 00:58:57.320 have in your traditional PDDL, you 00:58:57.320 --> 00:59:02.279 have create a repetitive action for each one of these states 00:59:02.279 --> 00:59:03.820 so you know exactly which transitions 00:59:03.820 --> 00:59:06.420 you can take out of that state. 00:59:06.420 --> 00:59:08.280 This can get long because you have 00:59:08.280 --> 00:59:10.940 to make a new action for every single one 00:59:10.940 --> 00:59:13.760 of these states for every action that you want to take. 00:59:13.760 --> 00:59:15.295 That is one way you can do it. 00:59:15.295 --> 00:59:19.186 Another way you can do it is introducing derived predicates. 00:59:19.186 --> 00:59:20.560 Derived predicates are predicates 00:59:20.560 --> 00:59:22.060 that don't depend the actions at all 00:59:22.060 --> 00:59:25.267 and just depend on some other formula in your plan. 00:59:25.267 --> 00:59:27.100 For example, we can have a derived predicate 00:59:27.100 --> 00:59:30.170 that explicitly tells you whether you're in s1 00:59:30.170 --> 00:59:31.540 or whether you're in s2. 00:59:31.540 --> 00:59:33.590 And you can use these predicates in your actions 00:59:33.590 --> 00:59:38.120 in PDDL2 to make sure, even though which state, x1 or x2, 00:59:38.120 --> 00:59:40.240 you're in in your Buchi Automata. 00:59:40.240 --> 00:59:42.080 And then, in your formulation of your plan, 00:59:42.080 --> 00:59:46.747 you set your final state to be one of the accepting states. 00:59:46.747 --> 00:59:48.830 I guess that answers one of the questions, though, 00:59:48.830 --> 00:59:51.800 how you go from being infinite to finite. 00:59:51.800 --> 00:59:53.570 The accepting state is usually what 00:59:53.570 --> 00:59:55.298 you place as your final state. 00:59:55.298 --> 00:59:57.006 AUDIENCE: Then in the derived predicates, 00:59:57.006 --> 00:59:59.437 you're purely in the pre-conditions? 00:59:59.437 --> 01:00:01.020 Or do they also appear in the effects. 01:00:01.020 --> 01:00:02.936 GUEST SPEAKER: They also appear in the effects 01:00:02.936 --> 01:00:07.610 because you need to know how to transition out of s1 to s2. 01:00:07.610 --> 01:00:10.520 So you'd likely have a derived predicate for both s1 01:00:10.520 --> 01:00:12.690 and a derived predicate for s2. 01:00:12.690 --> 01:00:16.572 And that is also a lot of work to add to the PDDL2 problem. 01:00:16.572 --> 01:00:18.600 But it's definitely shorter than the first way. 01:00:18.600 --> 01:00:20.350 And it definitely encapsulates everything, 01:00:20.350 --> 01:00:22.774 by the Buchi Automata [INAUDIBLE] 01:00:22.774 --> 01:00:26.040 Does anyone have any questions about that? 01:00:26.040 --> 01:00:27.916 AUDIENCE: So you're changing the action then? 01:00:27.916 --> 01:00:28.748 GUEST SPEAKER: Yeah. 01:00:28.748 --> 01:00:30.220 You're changing the action but you 01:00:30.220 --> 01:00:33.960 don't need make a new action for every state. 01:00:33.960 --> 01:00:38.030 In the first formulation, let's say 01:00:38.030 --> 01:00:40.799 I have some traditional action, like move blue block, 01:00:40.799 --> 01:00:41.340 or something. 01:00:41.340 --> 01:00:42.840 I have to create a move block action 01:00:42.840 --> 01:00:44.790 for each one of these states because I 01:00:44.790 --> 01:00:46.450 need to know exactly which transitions 01:00:46.450 --> 01:00:47.747 I can take out of that action. 01:00:47.747 --> 01:00:49.080 AUDIENCE: In the second example? 01:00:49.080 --> 01:00:50.579 GUEST SPEAKER: And in the second one 01:00:50.579 --> 01:00:52.710 I can just have one move block. 01:00:52.710 --> 01:00:55.050 But in my move block I'll have a derived predicate 01:00:55.050 --> 01:01:00.800 that tells me which state I'm in when I execute that action. 01:01:05.280 --> 01:01:07.210 The number of actions you have to write 01:01:07.210 --> 01:01:09.340 is less because you explicitly have 01:01:09.340 --> 01:01:14.533 predicates that are telling you which state that you're in. 01:01:14.533 --> 01:01:17.005 Now I'm going to hand it over to-- 01:01:17.005 --> 01:01:19.254 if there are no more questions-- hand it over to Mark. 01:01:19.254 --> 01:01:21.524 And he's going to talk about preferences. 01:01:25.172 --> 01:01:27.697 MARK: We're getting a little low on time. 01:01:27.697 --> 01:01:29.280 Now I'll transition to talking about-- 01:01:29.280 --> 01:01:31.370 we talked about temporally extended goals. 01:01:31.370 --> 01:01:34.230 We said that goals are things that always have to be true. 01:01:34.230 --> 01:01:35.860 So now let's talk about preferences. 01:01:35.860 --> 01:01:37.735 Preferences are things that don't necessarily 01:01:37.735 --> 01:01:41.470 have to be true, but are things that you'd like to be true. 01:01:41.470 --> 01:01:43.050 In the classical planning problem, 01:01:43.050 --> 01:01:44.750 we can formulate it like that. 01:01:44.750 --> 01:01:48.860 We can set a state S, set a state s0, a set of operators, 01:01:48.860 --> 01:01:50.220 and a set of goal states. 01:01:50.220 --> 01:01:52.980 The problem is transition from the initial states 01:01:52.980 --> 01:01:53.880 and any state. 01:01:53.880 --> 01:01:57.645 But those are goal states using the operators [INAUDIBLE] 01:01:57.645 --> 01:01:59.020 Preference based planning problem 01:01:59.020 --> 01:02:01.636 introduces a traditional field R, 01:02:01.636 --> 01:02:05.840 which is a partial or total relation expressing preferences 01:02:05.840 --> 01:02:06.942 between plans. 01:02:06.942 --> 01:02:10.490 And this is a little preference symbol right there. 01:02:10.490 --> 01:02:12.690 That tells you, if there are multiple plans 01:02:12.690 --> 01:02:14.590 you need to accomplish your goal, 01:02:14.590 --> 01:02:17.049 which one do you want to use. 01:02:17.049 --> 01:02:18.590 And again, preferences are properties 01:02:18.590 --> 01:02:20.506 that are desired but not necessarily required. 01:02:23.740 --> 01:02:25.770 There are two [INAUDIBLE] different types 01:02:25.770 --> 01:02:28.752 of preference languages, quantitative and qualitative. 01:02:28.752 --> 01:02:31.120 As you would expect, in quantitative languages, 01:02:31.120 --> 01:02:34.575 we actually assign a numeric value to the different plans 01:02:34.575 --> 01:02:36.190 in order to compare them. 01:02:36.190 --> 01:02:38.790 So these plans are a weight of four, and a weight of two, 01:02:38.790 --> 01:02:40.740 and that tells you which one to prefer. 01:02:40.740 --> 01:02:42.870 Here are some languages that do that. 01:02:42.870 --> 01:02:45.150 For qualitative languages, they actually 01:02:45.150 --> 01:02:48.420 just have a plan with this property 01:02:48.420 --> 01:02:51.810 is preferred to this other plan with this property. 01:02:51.810 --> 01:02:53.870 But we don't actually know any information that 01:02:53.870 --> 01:02:55.993 knows how much we prefer one to the other, 01:02:55.993 --> 01:02:56.951 or something like that. 01:02:56.951 --> 01:02:59.326 An important element of this is when 01:02:59.326 --> 01:03:02.250 you have quantitative languages, they're totally comparable. 01:03:02.250 --> 01:03:04.350 Any two sets of plans you can determine 01:03:04.350 --> 01:03:06.056 which one is preferred. 01:03:06.056 --> 01:03:07.430 Whereas in qualitative languages, 01:03:07.430 --> 01:03:09.638 you could have situations where plan one is preferred 01:03:09.638 --> 01:03:11.940 to plan two, and plan one is also preferred to plan 3, 01:03:11.940 --> 01:03:14.440 but that doesn't give you any information about whether plan 01:03:14.440 --> 01:03:16.938 two is preferred to plan three. 01:03:16.938 --> 01:03:21.210 So it's a little bit less expressive [INAUDIBLE].. 01:03:21.210 --> 01:03:24.972 To go into how you actually express preferences in PDDL3, 01:03:24.972 --> 01:03:26.930 like we talked about temporally extended goals, 01:03:26.930 --> 01:03:29.800 there is a PDDL3 syntax to do this. 01:03:29.800 --> 01:03:33.150 There's a preference label here that you can put on fluents 01:03:33.150 --> 01:03:36.647 to represent things you prefer. 01:03:36.647 --> 01:03:38.480 And then there's a function call is-violated 01:03:38.480 --> 01:03:40.940 that essentially returns the number of times 01:03:40.940 --> 01:03:43.990 that any fluent that has a preference label 01:03:43.990 --> 01:03:45.960 was not satisfied in your plan. 01:03:45.960 --> 01:03:47.707 For example, if you have a preference, 01:03:47.707 --> 01:03:49.710 "Traffic light is green until it turns red." 01:03:49.710 --> 01:03:51.620 Here's our PDDL3 template. 01:03:51.620 --> 01:03:54.378 It extended this kid's preference, 01:03:54.378 --> 01:03:57.030 in which we label it with a preference label here. 01:03:57.030 --> 01:03:58.830 And this is just a name. 01:03:58.830 --> 01:04:02.710 And then or plan tries to minimize the number of times 01:04:02.710 --> 01:04:04.990 that this preference is violated. 01:04:04.990 --> 01:04:08.460 That's one way to express preferences directly in PDDL3. 01:04:11.530 --> 01:04:13.950 So now we talk about LDP. 01:04:13.950 --> 01:04:16.620 LDP is a different language that is 01:04:16.620 --> 01:04:18.980 quite expressive in terms of types of preferences 01:04:18.980 --> 01:04:20.390 you can represent. 01:04:20.390 --> 01:04:22.210 It is a quantitative language, which 01:04:22.210 --> 01:04:25.660 means we're going to have weights for each of our plans 01:04:25.660 --> 01:04:26.999 to express our preferences. 01:04:26.999 --> 01:04:29.290 We can actually express the strength of the preference. 01:04:29.290 --> 01:04:33.736 So Goal A is preferred twice or three times as much as Goal B. 01:04:33.736 --> 01:04:36.456 It's an extension of an older language named PP. 01:04:36.456 --> 01:04:39.133 Here is the paper if you want to actually check out 01:04:39.133 --> 01:04:41.060 these details. 01:04:41.060 --> 01:04:43.180 The formulas are constructed hierarchically. 01:04:43.180 --> 01:04:45.920 I'll go through quickly how we actually construct 01:04:45.920 --> 01:04:47.670 these preference formulas. 01:04:47.670 --> 01:04:51.230 The lowest level is called a Basic Design Formula, or BDF. 01:04:51.230 --> 01:04:53.130 That just expresses our temporally extended 01:04:53.130 --> 01:04:53.810 proposition. 01:04:53.810 --> 01:04:55.645 So this is just a straight up LTL, 01:04:55.645 --> 01:04:57.436 basically, that we saw in the first section 01:04:57.436 --> 01:04:58.404 of the presentation. 01:04:58.404 --> 01:05:00.070 I'm going to use that I'm cooking dinner 01:05:00.070 --> 01:05:02.170 example for these slides. 01:05:02.170 --> 01:05:04.610 In this case, we always use the future operators. 01:05:04.610 --> 01:05:07.040 At some point, I might want to cook this program plan. 01:05:07.040 --> 01:05:10.160 Maybe I want to order takeout to eat dinner. 01:05:10.160 --> 01:05:12.770 And then I have some eating spaghetti or eating pizza. 01:05:12.770 --> 01:05:14.470 Those are two different things, two different options 01:05:14.470 --> 01:05:15.678 that I could have in my plan. 01:05:15.678 --> 01:05:17.481 I don't have to have either of those. 01:05:17.481 --> 01:05:19.766 Those are just options that I could have. 01:05:19.766 --> 01:05:21.070 That's the lowest level. 01:05:21.070 --> 01:05:24.590 The next level is called Atomic Preference Formulas, or APFs. 01:05:24.590 --> 01:05:27.670 There are where we express our preferences between the BDFs 01:05:27.670 --> 01:05:29.920 that we formed in the previous slide. 01:05:29.920 --> 01:05:31.729 So in this example I'm using weight, 01:05:31.729 --> 01:05:33.270 specifically to represent preference, 01:05:33.270 --> 01:05:35.870 with lower weight being preferred. 01:05:35.870 --> 01:05:39.292 Here we're saying, we prefer to cook over ordering takeout. 01:05:39.292 --> 01:05:40.750 This is you where you have to cook, 01:05:40.750 --> 01:05:42.748 this is where you have to order takeout. 01:05:42.748 --> 01:05:45.496 And we apply weights to those two expressions. 01:05:45.496 --> 01:05:47.120 The first one's preferred, and how much 01:05:47.120 --> 01:05:49.214 it is preferred over this plan. 01:05:49.214 --> 01:05:53.794 And here is you prefer to eat spaghetti over eating pizza. 01:05:53.794 --> 01:05:55.150 So that's the second level. 01:05:55.150 --> 01:05:59.060 Third levels called General Purpose Formulas, or GPS. 01:05:59.060 --> 01:06:01.420 These are where we can do conjunctions or disjunctions, 01:06:01.420 --> 01:06:04.200 or qualification of our previous formulas. 01:06:04.200 --> 01:06:07.110 So for example, if we want to say-- 01:06:07.110 --> 01:06:09.093 because in the previous slides we had two APFs. 01:06:09.093 --> 01:06:13.217 We had prefer to cook and prefer to eat spaghetti. 01:06:13.217 --> 01:06:14.800 And here we can express that we really 01:06:14.800 --> 01:06:19.040 don't care which one of these we want to satisfy. 01:06:19.040 --> 01:06:20.540 You can think of this as we actually 01:06:20.540 --> 01:06:23.010 tried to satisfy APF at the lowest weight. 01:06:23.010 --> 01:06:25.114 So if we have this "or" operating here, 01:06:25.114 --> 01:06:27.405 that means that our planner is going to try and satisfy 01:06:27.405 --> 01:06:29.515 the lowest weight among all these different options here, 01:06:29.515 --> 01:06:31.570 which means that he doesn't prefer to cook. 01:06:31.570 --> 01:06:33.610 That's its first goal. 01:06:33.610 --> 01:06:36.510 You can also use a handoff rigor, for example. 01:06:36.510 --> 01:06:38.620 And that's going to minimize the maximum weight 01:06:38.620 --> 01:06:40.160 against both of those options. 01:06:40.160 --> 01:06:42.076 Basically, what's it going to try and do-- 01:06:42.076 --> 01:06:44.230 oops-- what it's going to try and do 01:06:44.230 --> 01:06:47.600 is minimize the highest weight among these two options. 01:06:47.600 --> 01:06:52.059 So it's going to try and cook, and then it's 01:06:52.059 --> 01:06:53.850 going to try and eat spaghetti versus doing 01:06:53.850 --> 01:06:54.683 these other options. 01:06:58.100 --> 01:07:00.020 So those are GPFs. 01:07:00.020 --> 01:07:02.616 I'm now moving on to Aggregated Preference Formulas, which 01:07:02.616 --> 01:07:04.380 are the highest level. 01:07:04.380 --> 01:07:07.232 So with APFs, these define the order 01:07:07.232 --> 01:07:09.190 in which our different preferences are relaxed. 01:07:09.190 --> 01:07:10.965 You can, of course, express a lot of different preferences 01:07:10.965 --> 01:07:13.000 for your planner, but not all of them 01:07:13.000 --> 01:07:14.670 may be achievable, especially if you're 01:07:14.670 --> 01:07:17.170 trying to achieve a large number of preferences at the same. 01:07:17.170 --> 01:07:20.250 You may not actually be able to achieve all of those. 01:07:20.250 --> 01:07:23.670 So how do we produce our set in the correct order, 01:07:23.670 --> 01:07:25.980 in the preferred order so that our plan we end up with 01:07:25.980 --> 01:07:28.640 isn't even the most preferred plan? 01:07:28.640 --> 01:07:31.050 That's what APFs like to do. 01:07:31.050 --> 01:07:36.744 You can express, using this preference operator. 01:07:36.744 --> 01:07:38.660 First, I want to try and satisfy both of these 01:07:38.660 --> 01:07:40.550 in the previous slide. 01:07:40.550 --> 01:07:43.620 Then if I can't, I want to relax it so I only satisfy G2. 01:07:43.620 --> 01:07:45.250 And then if I can't do that, then I 01:07:45.250 --> 01:07:47.450 want to relax it so I only try and satisfy G1. 01:07:47.450 --> 01:07:50.760 So that gives us the order in which things are relaxed. 01:07:50.760 --> 01:07:53.456 It's important here that if you have these situations where 01:07:53.456 --> 01:07:55.080 you can't distinguish from one another, 01:07:55.080 --> 01:07:57.390 or you don't really care, we can establish some order. 01:07:57.390 --> 01:08:00.300 So at the very lowest type of level, 01:08:00.300 --> 01:08:02.425 we can sort them alphabetically, or something, just 01:08:02.425 --> 01:08:04.141 to provide some sort of order. 01:08:08.280 --> 01:08:11.330 This is just a review of what I've been talking about. 01:08:11.330 --> 01:08:13.590 BDFs are the lowest level, which express 01:08:13.590 --> 01:08:15.425 temporally extended propositions. 01:08:15.425 --> 01:08:18.840 We can apply preference to those using APFs. 01:08:18.840 --> 01:08:25.470 Then we can combine or join APFs using tell preference formulas. 01:08:25.470 --> 01:08:29.210 And finally, we can aggregate those preference formulas 01:08:29.210 --> 01:08:31.630 to determine the order in which you shouldn't 01:08:31.630 --> 01:08:35.810 relax the propositions to allow yourself to plan it right. 01:08:35.810 --> 01:08:39.260 So using this scheme in LPP, we're 01:08:39.260 --> 01:08:43.224 using both LTL syntax and rules that we talked about 01:08:43.224 --> 01:08:45.439 in the first section to express temporally extended 01:08:45.439 --> 01:08:46.750 preferences. 01:08:46.750 --> 01:08:50.222 The plans that's actually used to solve these types 01:08:50.222 --> 01:08:51.830 of problems is called P Plan. 01:08:51.830 --> 01:08:54.288 P Plans can actually handle templates, and the preferences, 01:08:54.288 --> 01:08:55.750 and a goal at the end, as well. 01:08:55.750 --> 01:08:58.281 And it does basically a best first search 01:08:58.281 --> 01:08:59.656 among all your different options. 01:08:59.656 --> 01:09:02.114 It's actually one of the planner that uses the left branch. 01:09:02.114 --> 01:09:04.700 But the one we showed uses progression to take 01:09:04.700 --> 01:09:06.947 LTL formulas at each point in the plan 01:09:06.947 --> 01:09:09.155 and determine whether you've satisfied those formulas 01:09:09.155 --> 01:09:09.655 or not. 01:09:09.655 --> 01:09:12.774 And if not, it will push them to the next state, 01:09:12.774 --> 01:09:15.149 so that in the next state you can evaluate whether you've 01:09:15.149 --> 01:09:16.460 satisfied those formulas. 01:09:16.460 --> 01:09:19.119 That's how it prunes the search space 01:09:19.119 --> 01:09:21.819 and tries to always find the most preferred plan to meet 01:09:21.819 --> 01:09:24.290 your goal. 01:09:24.290 --> 01:09:25.670 All right. 01:09:25.670 --> 01:09:28.500 So that's our presentation. 01:09:28.500 --> 01:09:29.990 Any questions from anyone? 01:09:35.974 --> 01:09:37.265 AUDIENCE: [INAUDIBLE] question. 01:09:37.265 --> 01:09:39.760 I have a question about [INAUDIBLE] presentation. 01:09:39.760 --> 01:09:43.819 You guys [INAUDIBLE] and then believes omega. 01:09:43.819 --> 01:09:46.688 Would you say that omega has to hold 01:09:46.688 --> 01:09:52.390 if p happens, and they have a conjunction in one state? 01:09:52.390 --> 01:09:55.620 ELLIE: Omega doesn't have to hold until we [INAUDIBLE].. 01:09:55.620 --> 01:09:59.250 Omega just has to hold at the last state of p. 01:09:59.250 --> 01:10:02.270 Essentially what it's saying is omega releases p. 01:10:02.270 --> 01:10:05.890 So once omega happened, p has to happen at the state. 01:10:05.890 --> 01:10:07.940 And the omega has to release p. 01:10:07.940 --> 01:10:10.280 Now it happens, so p, you can don't you want. 01:10:10.280 --> 01:10:12.454 You can be true, you can be false. 01:10:12.454 --> 01:10:13.120 AUDIENCE: Sorry. 01:10:13.120 --> 01:10:16.722 So p has to hold until omega happens. 01:10:16.722 --> 01:10:17.222 ELLIE: Yep. 01:10:17.222 --> 01:10:18.190 And then omega-- 01:10:18.190 --> 01:10:19.160 [INTERPOSING VOICES] 01:10:19.160 --> 01:10:22.847 AUDIENCE: So the definition is just switched to p [INAUDIBLE].. 01:10:22.847 --> 01:10:24.007 ELLIE: This is an occasion. 01:10:24.007 --> 01:10:25.340 Occasionally, you have pR omega. 01:10:29.384 --> 01:10:30.814 But like intuitively-- 01:10:30.814 --> 01:10:32.522 AUDIENCE: It's just the definition-- oh-- 01:10:32.522 --> 01:10:33.775 [INTERPOSING VOICES] 01:10:33.775 --> 01:10:35.900 AUDIENCE: That's all I was wondering because then I 01:10:35.900 --> 01:10:36.790 saw that and it was confusing. 01:10:36.790 --> 01:10:37.457 So that's all. 01:10:37.457 --> 01:10:37.959 OK, sorry. 01:10:37.959 --> 01:10:38.750 ELLIE: That's fine. 01:10:44.830 --> 01:10:48.540 MARK: Any other questions? 01:10:48.540 --> 01:10:50.580 AUDIENCE: Since there are multiple ways 01:10:50.580 --> 01:10:57.125 to express the same formula using the grammar, is there 01:10:57.125 --> 01:11:02.330 any notion of canonical forms, or a least complicated form, 01:11:02.330 --> 01:11:03.626 or something like that? 01:11:03.626 --> 01:11:04.810 MARK: Yeah, there is. 01:11:04.810 --> 01:11:10.560 Typically they actually-- let me find the slide. 01:11:10.560 --> 01:11:14.690 So to simplify the algorithms they typically apply 01:11:14.690 --> 01:11:16.812 the kind of reductions that we showed in the slide 01:11:16.812 --> 01:11:18.395 to reduce the release and the globally 01:11:18.395 --> 01:11:20.882 and the future down to just the [INAUDIBLE] of an x. 01:11:20.882 --> 01:11:22.465 Otherwise, your algorithms going to be 01:11:22.465 --> 01:11:24.831 able to handle fewer cases. 01:11:24.831 --> 01:11:26.330 And then they apply the usual rules, 01:11:26.330 --> 01:11:28.246 trying to push nots out to the left-hand side. 01:11:40.760 --> 01:11:41.852 All right. 01:11:41.852 --> 01:11:42.560 Thanks, everyone. 01:11:42.560 --> 01:11:44.410 [APPLAUSE]