Alright. Okay. Hello everyone. Thank you so much for being here. My name is Harish. Every time though, I'm an assistant professor in the School of Interactive Computing here. My Labs name is structured techniques for algorithmic robotics. So today I wanted to talk to you all about some of these structured methods we have been developing for robots that like to get along. So let me begin with a high-level overview of what we tried to do in the lab. So we specifically looked to enable reliability and collaborative characteristics and robots. So the idea is to help robots learn to operate in dynamic and unstructured environments while being able to collaborate with the humans in that enlightenment, also other robots in that environment. You might wonder, what's the point of doing this? It turns out there are lots of different applications that these kinds of techniques are very helpful. You can think about manufacturing settings, defense, assistive, robotics, even autonomous driving for that matter. You can also ask the question of, okay, these are the settings. This is the goal. What's so hard about accomplishing this goal, it's done so again, given these settings that are different types of challenges that you would space. One is that unfortunately I do not work in computer vision, which means I cannot download terabytes of data from the Internet and just use it for my robots. So there is a lot of cost associated with collecting data for robotics. Especially good data if you want good data. So there is sparsity in data. There's also a lot of task variability, right? If your task is not going to change, probably we can say that arguably we have solved robotics, but the problem is tasks change all the time. So we need our algorithms to help the robots adapt constantly changing, slight, even slight variations in desks. And of course, there's huge amount of uncertainty because no matter how expensive are sensors that the kind of information that we would get would be highly uncertain. Also, the amount of knowledge we will have about any given domain will also be uncertain. There are safety constraints. Again, if I misclassify an image, I don't know how much that would cost, but if robot hits someone, on the other hand, that could be problematic, right? So we should worry about those as well. So we need some sort of guarantees on robot behavior and some amount of predictability in what robot will end up doing. And finally, robots have to work with users, which means that users will have their own preferences of how they like things to be done, right? As a user of the robot, you want the robot to satisfy some amount of preferences or be cognizant of your preferences. And of course, I don't have to tell the audience here. You're all familiar with humans. And humans can be somewhat difficult to work with, right? So we have to take that into account as well. So what does it take? If we want this for robots? We believe that our three specific capabilities that are necessary, right? Not that I'm saying necessary and not sufficient. So first is reliability. What I mean by that is, whatever the peach robots, what are the skills the robot learns? The idea is to have the robot so reliably executed it despite the challenges I suggested. Second is awareness. And here what I mean by awarenesses, being aware of its environment, that there are other agents, whether be it humans or other robots. So it's not enough for the robot to be reliable or know how to do a task, it needs to adapt itself given that it's going to be situated in an environment with other agents or other robots. And finally, you can think of coordination as one layer of abstraction up that let's say your robot knows how to do things reliably. It knows how to adapt itself when there are other agents. Now you need to think about if there is a team of different robots and humans for that matter, how do they come together? How should you design algorithms such that robots, robots will be able to leverage their individual strengths. We have specifically in the liability in our lab, we tend to focus on manipulation because that's where our expertise is. But typically we double-up algorithms that are application agnostic in the space. Similarly, you can take skills from there and you can think about if you're operating in close proximity with humans, how exactly do you adapt the same skills? And finally, in coordination, we tried to double up high level algorithms that will help these robots coordinate with other agents. So basically looking at heterogeneous team, how do we get there? So these are the tools to be used. Typically, part of it is machine learning, part of it is dynamics and control. The reason for doing this is that robots are physical systems. We have been studying them for a few centuries now. There's no reason to throw away the knowledge that we have. On the other hand, we can't specify everything, right? Because as I mentioned that lots of challenges, some amount of challenges needs to be solved by learning. So in our lab, what we tried to do is combine the best or try to combine the best of both worlds. And that's where its structure comes in. So let me take a second and talk to you about what I mean by structured methods. So I tend to see this as a spectrum. On the one hand, you have analytical hand design methods. They are very easy to understand. You know exactly what will happen if you put them on a robot, right? On the other hand, you have learning from scratch. This means that the human need not have any expertise. Presumably the robot will be able to learn all the skills by itself. But the chances are you can't say much about what the robot will end up doing. Structured methods fall in the middle, somewhere on this spectrum. Excuse me. And what I mean by structured learning is that this might look like you limit your hypothesis space when you're learning. It might look like you are constraining the output of the model. Or it might look like you'd have modular design for a complex problem. And some modules are handled sign and some modules are learned. But of course, the primary challenges that you have to be on this big spectrum, right? So that's where our researchers today start. I'm going to focus on coordination parts. Specifically the kinds of methods we have been doubling for heterogeneous multiagent teams. There are a number of questions we are interested here, and each of these questions are at different layers, if you will. The first question is, of course, how do we even represent these kinds of systems? Let's say you have different kinds of robots. You have different kinds of humans. How do you represent the mathematically so we can compute, do computations on them, right? Second is about coalition formation problems that we deal with the question of how should you form subgroups within the team that you have if you want multiple things to happen at the same time. Of course, there are learning problems of how do we coordinate without explicitly designed specifications. We can ask that question and try to see if the teams can figure it out with some amount of, of course, scaffolding in place. We can also think about metal coordination, meaning there are several problems within coordination, which I'll talk about in a bit. The question is about, how do you coordinate among the subproblems that are about coordination. And finally, there is robustness and resilience. Basically, robustness is about the known uncertainties that you have in your system. How do you manage them? And finally, there is the resilience that things could go wrong and you don't know that ahead of time. How do you deal with it and adapt? So yet again, if the focus of today's talk is gonna be more on here. The last time I gave this talk, I spoke more about the modelling, coalition formation and learning. So today we'll focus on these three bullets. Why particularly heterogeneous teams within the coordination, right? So again, we even within this multi-agency coordination space, using heterogeneous teams have a lot of different uses, starting from environmental monitoring, agricultural robotics that house automation, defense, again, construction robots, and even very precision medicine. Medicine perhaps. So let me first talk about what we call simultaneous multi-level coordination. This is what I'm calling matter coordination. Of course I get to speak here, but this work was done by Andrew and Glenn. Maybe they are here. So this was their work that they tried to look at the problem of if I have multiple levels of coordination in a heterogeneous multiagent Team. How do I play with them at the same time? So like I said, there are four different levels or four different questions you can think about. The first question is about what, what should the team do in order to get to your goal state? The second question is about the allocation of who should do it. And the third is about when it needs to happen. And finally, how is about the motion planning aspect of it, right? So these are the four different problems in cooperative systems. You can also think about now the intersections. You can plot them. I put them on a Venn diagram and ask, how do these intersections work, done so vivid studying these intersections for a very long time, right? Just as an example, here are a few different intersections that are well-studied. You can think about temporal planing value only think about what and when. You can think about task and motion planning, value, think about what and how you have multi-valued routing problems that you think about how and who. Of course. So on many intersections, I don't want to list all of them, but you get the point. In this work. What we wanted to Louis, what if we looked at all of them at the same time, right? So we tried to define this problem. We called it staff STC, which stands for simultaneous task allocation. Planning with spatial temporal constraints. Allocation and planning is there. Spatial temporal constraint is what exactly will take it off? The motion planning part of you and scheduling part of it. The key idea here is we take these four modules and the interleaved execution. So that's the key idea here, right? So we call our method graphically recursive, simultaneous task allocation and planning and scheduling, right? So as you can see, there are the four layers here. And the architecture or the structure here, is that how we compose their execution. Typically what people do is they solve the planning problem and then give it to task allocation and figured it out, and then do the scheduling. And finally, once all of this done, you do motion planning. So we were able to show in our work that if you do that, you're going to have a lot of issues like backtracking. You will be very inefficient. Instead, we tried to do an interleaved execution. The army would do task planning, acids unfolding. It's gonna check with task allocation. And as task allocation is unfolding, it's going to check with scheduling and so on and so forth. This should remind you of a structure that you're familiar with, the Russian Doll. So that's exactly how this execution works. So the biggest one would be the task planning and then you keep checking down the road. So you might think that this is, this could be potentially inefficient because at every step in the planning, you end up checking with all the layers beneath it, right? But don't sell. This has a lot of benefits. One is that it, one is that we have agent agnostic planning, meaning when we do planning. Save the planet. Don't worry about who's going to do the job, just worry about what needs to happen. And then task allocation rate is about, can I somehow find someone to do it, right? Similarly, we can also do task allocation in an isolated fashion instead of allocating for every task at the same time, we do it one at a time. And we also have constraints that say that if you have a number of tasks and they all have certain requirements you need to satisfy. We can have constraints that say that you need to satisfy those constraints whatever the requirements are. Similarly, you can have constraints on space as well as time. You can satisfy those as well. What this ends up doing is that it ends up lot of backtracking. At every step. You are ensuring that whatever your plan is, is compatible with the three layers below, whatever your allocation is, it compatible with the two layers below and so on and so forth. Right? Now some of you might be asking about the uncertainty brown that I mentioned. Of course, all of the things that I talked about in the previous slide basically says that here is how I'm going to structure my solvent problem-solving and then I'm going to implement it. But it doesn't take into account uncertainty that assumes everything is deterministic, right? Basically what Yoda says, but Heisenberg will not agree with that, right? So what did we do? We double double method, we call risk of our task allocation, that we take into account the fact that there's going to be uncertainty in your particular situation. So what is the scope of uncertainty we're considering? Be considered basically looking at uncertainty that comes from our modeling itself. Meaning if we model groups, let's say you model all the ground vehicles as one group and you try to reason about it, you are going to have uncertainty in variations within your ground vehicles or within your aerial vehicles. So you want to take that into account. If there are humans in your team, then that's going to complicate this issue further, nor do humans are going to be identical. So you're going to have uncertainty there. You can also have environmental influence that it's causing uncertainty. But of course we have to make some assumptions here. So these are the two key assumptions that we made. One is that we assume we have a model of this uncertainty, right? So that's what we're going to use to represent the problem. When second is that we assume task success depends on meeting or exceeding a certain requirement. So think about, let's say multiple robots need to carry a table. If they don't have the collective payload, they're just not gonna be able to do it. So that's a good example of a task that you need to satisfy certain requirements. Of course, if you have more collective payload, it's not going to be used, but it's not going to be detrimental to you. So what are our options here? There are lots of methods that does risk-neutral methods basically that says, Just don't worry about the risk, right? Don't worry about the uncertainty. Just do the allocation. You just worry about the expected payoff. Don't worry about what could go wrong and the tails. So you can exploit the redundancy as well. So you can say, I will throw a lot of robots at it. Some robots failed. I don't care, right? There is strength in numbers. There's also risk averse approaches would say, we need to carefully account for risk. And then it says, you have to avoid risk at all costs, right? So that's gonna be very conservative. That are also methods that do a wide knee case. What Neil worst-case scenarios. So for example, conditional value at risk does exactly that. It's a little bit less conservative. But of course it relies on the use of specifying how risk-tolerant than they are. But you could ask yourself the question of, is it always better to minimize risk? Turns out it's not. So in 1980, instead of, ecologists study this, study, this bodes behavior. This is a yellow eyes junk or I think maybe I'm mispronouncing your name. I'm not a bird watcher unfortunately. So let's say there are two sources for the bird to get at seeds from or Valium feeds, right? So say it's deterministic. It always has the same amount of seeds whenever it goes there, but the need of the bird is not satisfied by its just below, let's say it needs a 100 seats. It only has a disease every time it goes through. On the other hand, you have source B, which is stochastic, meaning 50% of the time the bird visits that it has more than necessary, maybe 150 seats, but 50% of the time, there are zeros. It's clearly this is a more risky situation than this one is. In this kind of circumstance, they were able to see that the boats consistently preferred to take risks. Because think about the options. You have. This option, you don't have as much risk, but you're not meeting your needs. Eventually the board will die. The board might as well take its chances. That's exactly what we tried to do in risk adaptive task delegation applied to evaluate, then, is it a good idea to take risks and then not so, right? So in dire circumstances, it's beneficial to take risks and in other circumstances where safer options that are available, you don't have to take risk, right? So that's exactly the idea here. So it ends up switching between two regimes, risk averse three G, and a risk-seeking regime. In the risk averse regime, of course, the idea is that you can worry about maximizing the expected payoff and you can minimize your risk. And the risk seeking regime is you take risk, meaning you want to maximize your variance because there'll be some chance that you will be able to meet your requirements. So we tried to, of course, compare this with different baselines that we have risk-neutral one's risk averse one, and the risk adaptive one we have. And what we could see is consistently in circumstances where there is a chance for you to not meet your requirements, risk adaptive methods consistently perform really well, which means that this can set up the metro, is able to choose when to take risks and when not. Okay, finally, we can also ask this question of what if something unexpected happens. One of the key assumptions I talked about is that we have a model of cadenza entity, but you might not always have models of uncertainty. Things could go wrong. What do you do then? So we tried to double up an algorithm we call dynamic task allegation for that, here the idea is if something goes wrong, you want to be able to quickly region radio of solutions or adapt to what's going on. So we considered many types of disturbances that could occur to the system. For example, task requirements could go up or down. Agent capabilities could change task execution. Good time changed many different ones. And what we tried to do is what we call targeted repair. The key idea is you recognize what has happened and you've identified which parts of the solution now becomes stale and which parts of the solution are still intact. So the only repair, the parts that are now still reuse, the parts that are still good. This is because of the inherent structure that we have in the model that I presented before. We did a lot of comparisons to see if this actually works. Dance are targeted or bad is significantly faster than recomputing your solutions from scratch. But it's still generate solutions that are of the same quality. So basically you're getting improvements in computation without sacrificing quality. So let me conclude by answering one final question. You could also wonder, what if I don't know how to specify these problems? Whatever they may be deterministic or nondeterministic. So we tried to solve a bunch of learning problems here. We keep the structure and don'ts out when we combine these structures with Lani, It's also beneficial. You can try to do adaptive teaming that you can adapt your agents to new situations that you will lose a team member. Are you getting a team member? You can also invert paid preferences, maybe not all trades. And finally, even if your data is suboptimal, what can you do about it? But that let me again mentioned the students who do this work and my awesome collaborators. And I will stop here. Thank you. Absolutely. That's a great question. The question was about what sort of tasks we used for these valuations. So we tried to create a variety of simulated disaster response or emergency response type situations. We used a bunch of math from RoboCup rescue for example. And then we would spawn these different sizes of problems, very often, several tens of agents. And then we would study these across different sizes. So that's how we evaluated it. Yeah.