Welcome to our exploration of the Computer Science module for the Introduction to Robotics course. My name is B. Ravindiran, and I'm a faculty member in the Computer Science Department at IIT Madras. Over the next few weeks, we'll be diving deep into how robotic systems perceive their environments using sensors and how they interact with those environments through actuators.
Sensors are the eyes and ears of a robot, allowing them to gather information about their surroundings. You've likely encountered various types already, from ultrasound and infrared sensors to cameras and even simple bump sensors. Some robots can gather sensory information that is even richer and more detailed than what a human typically experiences, which presents its own unique set of challenges in processing and utilizing that data effectively.
Actuators, on the other hand, are the robotic equivalents of muscles, enabling movement and interaction. These can range from wheels on a mobile robot to the complex limbs of a humanoid robot or the articulated arms found on factory assembly lines. The choice of actuator is heavily dependent on the specific task and environment the robot is designed for, as they are primarily used to manipulate the world around them.
At its core, robotics involves a system that perceives its environment through sensors and then acts upon that environment using its actuators. What makes the algorithmic side of robotics particularly fascinating and challenging is the inherent uncertainty associated with both sensing and actuation. You can't assume a robot perfectly knows its position or the precise outcome of its actions based solely on sensor readings.
This uncertainty stems from two primary sources. First, sensory information is often incomplete. Imagine an ultrasound sensor array that provides distance readings in eight different directions. While this tells you where the nearest obstacle is in each of those directions, it's usually insufficient for precise self-localization within a room. You might know there's something in front of you, but not exactly where you are in the grand scheme of the room.
The second reason for sensor unreliability is the presence of various disturbances and noise sources. The electronics and mechanics within a sensor can introduce their own stochastic variations. This means that even if you take a measurement from the exact same spot multiple times, you might get slightly different readings. The sensor itself isn't perfectly deterministic.
Furthermore, the environment itself is subject to stochastic disturbances. If you're trying to measure the distance to a wall, someone could momentarily walk in front of it. If your measurement happens to coincide with that brief obstruction, you'll get a reading that's much shorter than the actual distance to the wall. It's often impractical to model every single one of these unmodeled environmental disturbances, so we tend to group them under the umbrella term "noise" or "stochasticity."
This uncertainty isn't limited to just figuring out where the robot is. Anyone who's tinkered with even a simple line-following robot knows that actuators, like the gears that turn wheels, aren't perfectly accurate. It takes considerable calibration to determine how far a robot will actually move when you command it to travel a specific distance, say one meter.
And again, there are numerous sources of noise that can affect actuator performance. A gear might slip slightly during movement, and its behavior can vary depending on factors like lubrication. So, the accuracy of an actuator's action – whether it does precisely what you intended – is never fully guaranteed. We have to account for these inaccuracies and noise in our control systems.
I remember a story from when we were working with a simple robotic platform. The goal was to keep a ball in the center of the platform. The platform itself had multiple degrees of freedom, allowing us to tilt it in the X and Y directions. We developed a seemingly robust controller and began executing it.
However, after some time, the controller started to fail. We were quite puzzled, as it worked perfectly at first and then inexplicably began to falter. It turned out that the gear assembly we were using had high-quality plastic gears that started to wear down after several hours of operation. This wear meant the controller needed adjustment, but we had no way of accurately measuring the gear wear itself.
Because we couldn't model this degradation, our otherwise good controller kept failing intermittently. We attempted to redesign it based on the measurements we could make, but even that solution proved unstable over time. These kinds of complications highlight the pervasive nature of uncertainty in robotics.
So, over the next few weeks, we'll be focusing on how to build robotic systems that can robustly handle this kind of noise and uncertainty. Many of you might recognize this area as Probabilistic Robotics or Probabilistic Algorithms for Robotics. The primary textbook we'll be referencing is also titled "Probabilistic Robotics," which delves into these issues in great detail.
Given the extensive nature of this textbook, we won't be able to cover every single topic within it during our limited time. Instead, I'll be touching upon key areas and presenting representative approaches. In some cases, we'll go into considerable detail, while in others, we'll focus on building intuition at a higher level. This approach will equip you to pursue further study either by reading the book or by taking more advanced courses.
Remember, this is an introductory course, and we're already packing in a significant amount of material. Our first major topic will be recursive state estimation. Within this broad area, we'll explore various approaches, focusing on Gaussian filters, which make certain assumptions about the system, and nonparametric filters, which allow us to move away from those specific assumptions.
We'll also examine motion models, which account for noise in the robot's movement, and sensing models, which address noise in the sensor readings. For both motion and sensing, I'll present specific examples to illustrate the general principles. Following that, we'll tackle two related problems: mapping, which involves understanding the robot's environment, and briefly, learning in robotics, with a particular focus on reinforcement learning.
Let's begin by focusing on the problem of recursive state estimation. This is a fundamental challenge in robotics. Consider a robot operating in a complex environment filled with static obstacles and dynamic, moving obstacles like people. The robot receives input from a wide array of sensors.
You can see a ring of sonar sensors, a camera on top, and bump sensors that detect contact. This rich sensory input provides the robot with a wealth of data. With this data, the robot must determine its precise location within its environment, essentially building or maintaining a world model and figuring out where it fits within that model.
This involves understanding not just its X and Y coordinates within a room, but also its orientation – the direction it's facing, its velocity, acceleration, and if it has an articulated arm, the precise angles of its various joints. All of this information is crucial for the robot to decide its next course of action.
This collection of information, the data the robot needs to reliably make decisions and behave appropriately in its environment, is what we refer to as its "state" or "state variables." Often, this state information isn't directly measurable. For instance, even with GPS, which is often unreliable indoors, you might only get a rough idea of your location, not its precise position relative to nearby obstacles or other people.
Therefore, we need a mechanism that can process all available sensory data – sonar, visual information, whatever we have – to accurately infer the robot's state. This inference process is a significant challenge. The problem of recursive state estimation can be framed like this: given all the sensory information available and knowledge of the actions the robot has taken, can we determine its current state?
It's called "recursive" because we start with an initial estimate of the robot's state, then it takes an action, and subsequently, it gathers new measurements of its environment. Using the previous estimate, the new measurements, and the action taken, we refine our understanding of the robot's current state. This iterative refinement is the essence of recursion in this context.
If you begin with a very noisy initial estimate of your state, performing a few iterations of this recursive estimation process will typically lead to a much more refined and accurate understanding of your location, orientation, and other relevant state variables. This improved accuracy allows the robot to make increasingly better decisions over time.
Let's formalize this a bit further before moving on to the algorithms for state estimation in the next lecture. The state itself can comprise many variables. Here, we denote the history of states from time 0 to time t as x0 to xt. Each of these 'x' variables can include a multitude of components.
For example, the robot's pose or location in the world is described by its X, Y, and theta coordinates. If we're in a 3D environment, it would be X, Y, Z, and theta. Another component of the state is the configuration of its actuators – how much a wheel has turned, the angles of various motors, or in the case of robotic arms, the relative angles of its limbs.
It's important to remember that each state variable, like x0, can be a complex vector with many dimensions, and the same applies to x1, x2, and so on. Beyond the robot's own configuration, the state can also include the locations of surrounding objects – a table, a wall, and so forth. These object locations might be static, forming part of a map, or they could be dynamic, in which case they need to be part of the robot's state itself.
If these objects are moving, their velocities are also crucial state information, requiring continuous updates to their positions and speeds. Additionally, the robot's internal state might include things like battery life, time until the next service is needed, or the wear on its motors and gears.
There's a wide variety of information that could be necessary for a robot to make informed decisions about its behavior and achieve its goals. A state representation is considered "complete" if it contains all the information needed for decision-making. We will also assume that the state possesses what's known as the Markov property.
The Markov property essentially means that the current state, xt, contains all the necessary information to predict future states without needing to consider the entire history of past states (x0 through xt-1). Similarly, the current state doesn't depend on past actions (u) or past observations (z), beyond what's encapsulated in xt itself.
This simplification is crucial. It means we don't need to worry about every single detail of the past – all the preceding states, actions, and measurements – if we know the current state. This assumption allows us to build more manageable and efficient models.
To make this more formal, let's consider the interaction components. We'll use 'z' to represent measurement data. This could be anything from camera images and ultrasound sensor outputs to bump sensor readings, wheel encoder data indicating distance traveled, or tachometer readings showing motor speed. Any of these can be part of a measurement vector.
Measurements are time-stamped. So, z1 represents the set of measurements taken at time 1, z2 at time 2, and so on, up to zt. Each of these 'z' can, in itself, be a set of readings. We will also denote 'u' as the control actions the robot can perform.
These actions could involve moving the robot's wheels, manipulating objects, or adjusting the angles of its joints. The granularity of these actions can vary widely, from a simple grasp to complex joint movements. Importantly, the robot doesn't have to perform all possible actions at every time step.
So, we have a sequence of actions: u1 is the action taken at time 1, u2 at time 2, up to ut. A common notational convention is that the state at time 0 is denoted as x0. Then, we take action u1, which leads us to state x1. This forms the basis of our dynamic model.
We start in a known state, x0, and then perform an action, u1. This action moves the robot to a new state, x1, which we don't precisely know. All we get from the robot's perspective is a set of measurements, which we label as z1. These measurements are taken *in* state x1.
Therefore, our state notation runs from x0 to xt, while actions are denoted from u1 to ut, and measurements from z1 to zt. If we need to refer to the entire sequence of states from time 0 up to time t, we can use the notation x0 colon t. Similarly, x0 colon t-1 would refer to all states up to, but not including, xt. We'll use similar notation for actions and measurements.
Now that we have notations for x, u, and z, we need to model the robot system itself. This is what we call a dynamical stochastic system, and it's described by two key sets of probabilities: state transition probabilities and measurement probabilities.
The state transition probabilities tell us how the robot's state changes over time based on its actions. Specifically, given a history of states (x0 to xt-1), actions (u1 to ut), and past measurements (z1 to zt-1), what is the probability of being in a particular state xt?
Let's consider a simplified example. Imagine the state variable indicates whether the robot is inside a room or not. If previously it was outside the room, and its action is to "enter the room," the probability of now being inside the room should be quite high. However, there's always a chance it might not enter – perhaps the door is closed or too narrow. So, the probability might be something like 0.9.
Now, recall the Markov property. It states that the current state depends only on the immediately preceding state and the action taken. This simplifies our state transition probability significantly. Instead of considering the entire history of states, actions, and observations, we only need the previous state, xt-1, and the current action, ut.
When we are in state xt-1 and take action ut, we transition to state xt. This state transition probability, P(xt | xt-1, ut), tells us the likelihood of moving from one state to another given a specific action.
You might wonder why the measurement zt doesn't appear in this state transition probability. The reason is that zt doesn't *cause* the state transition. While zt is crucial for *estimating* xt, it's the action ut that directly influences the transition from xt-1 to xt. The state transition probabilities and measurement probabilities describe the system's dynamics, not the estimation process itself.
Therefore, in the state transition probability, P(xt | xt-1, ut), we don't include zt. This is a fundamental assumption we'll carry forward: most of our development will assume a Markovian system. Now, let's turn to the second key component: the measurement probability.
The measurement probability, P(zt | x0:t, u1:t, z1:t-1), tells us the likelihood of observing a specific measurement zt, given the entire history of states, actions, and past measurements. This essentially describes what the robot will "see" or measure given its history.
Again, thanks to the Markov property, this can be greatly simplified. The measurement zt at time t is assumed to depend only on the current state xt. The action ut that led to xt, as well as all previous states, actions, and measurements, become irrelevant once we know xt.
This is because the effect of ut on zt is already captured in xt. Therefore, the measurement probability simplifies to P(zt | xt). This means the probability of observing a particular measurement is directly related to the robot's current state.
So, we've now formalized our system dynamics using two core equations: the state transition probability, P(xt | xt-1, ut), and the measurement probability, P(zt | xt). These two relationships are foundational and will be repeatedly used as we derive various estimation techniques in the upcoming lectures. Thank you.
