Design Lab 02: Sim City

The questions below are due on Thursday February 14, 2019; 09:55:00 PM.
 

Partners: You have not yet been assigned a partner for this lab.

Reticulating Splines...

 

Files

This lab description is available as a PDF file here. The code distribution may be downloaded (in zip format) here, or by running athrun 6.01 getFiles from an Athena machine or a 6.01 lab laptop.

Do this lab with your assigned partner.

Get today's files: Open a terminal window press Super+t where Super refers to the Super Key (with Windows symbol)) and run:

$ athrun 6.01 getFiles

to set up files for today's exercises in your Athena directory. These files are also available for download above.

1) Throwback Thursday

In Design Lab 1, you programmed the robot to keep itself a fixed distance from a wall using a proportional controller.

In Software Lab 2, you developed an LTI model of the "wall finding" robot using your physical intuition.

In today's lab, we will use a Python program for simulating arbitrary LTI systems (which you'll implement as part of this week's homeworks). We will compare the simulated results from our LTI model against results from running the real robot, and we will use this to analyze and improve upon our model, continuing into next week's software lab.

Since the robot system, like many real-world systems, is not actually quite linear, we will not be able to perfectly model its performance. Despite this, we hope to come up with a model that is useful ("close enough") in the sense that is helps us make design decisions about the real system.

2) Breaking It Down

Since the wall-finder is a pretty complicated system, we found it helpful to break it down into smaller systems, about which we can think more easily. We started by breaking the system down into two parts:

The controller represents our control scheme. In this application, it is, in some sense, the soar brain we wrote to control the robot. We will model the controller as taking in the error signal (E, which is the difference between the desired distance, D_d, and the actual distance as measured by the sonars, D_s) as input and yielding a commanded velocity, V_c, as output.

The plant represents the part of the system that we are controlling¹. In this application, the plant represents the robot's locomotion system. Unlike the controller, we do not have much say in how this system behaves; our job is to model, as accurately as possible, the actual physics of the plant we are given.

We then found that it was helpful to break the plant itself into two pieces: one that transformed velocity into position, and one that transformed position into the robot's sensed distance.

3) Simulation

One way to figure out how the model behaves would be to compute its response to a given input by hand. However, this can be tedious for complicated models, or even for simple models when dealing with large numbers of timesteps.

As such, we have provided a simulator that can compute the response of arbitrary LTI systems to arbitrary inputs (which you'll implement in this week's homeworks). Now we'll use this simulator to simulate the robot using the LTI model you built in Software Lab.

The simulator has the following form:

generic_lti_simulate(d_coeffs, c_coeffs, inputs, prev_inp, prev_out)

• d_coeffs and c_coeffs are the coefficient lists representing the difference equation we want to simulate, which represent the coefficients associated with the various terms in a difference equation expressed in the following form:

  y[n] = c_0 y[n-1] + c_1 y[n-2] + \ldots + c_{k-1} y[n-k] + d_0 x[n] + d_1 x[n-1] + \ldots + d_j x[n-j]

• inputs is a list of input values we want to give to the system, starting at time 0 ([x[0], x[1], x[2], \ldots])

• prev_inp is a list of input values received before time 0, [x[-1], x[-2], \ldots]. It should have one fewer element than d_coeffs (since d_coeffs includes a term associated with the current input).

• Similarly, prev_out is a list of output values before time 0, [y[-1], y[-2], \ldots]. It should have the same length as c_coeffs.

This function returns a list of the system's output values [y[0], y[1], y[2], \ldots] of the same length as the inputs list.

4) Testing

Test your wall finder model by simulating it using Python (you can add some code to the bottom of designLab02.py to do this).

We would like to simulate the behavior of the robot for a few different gains, with the following initial conditions:

• the robot starts out unmoving at a distance 0.8 meters from the wall
• the robot's desired distance is 0.5 meters from the wall
• the length of a discrete timestep is 0.1 seconds

Use the generic_lti_simulate function to predict how the robot will respond with these initial conditions, trying at least the gain magnitudes of 0.5, 1, 2, 5, and 10. For each of those values, run a simulation and generate a plot consisting of the first 200 samples of the robot's output. Save the plots you generate, as they will be used later in the lab.

You can generate a plot from a list of values by running:

import matplotlib.pyplot as plt

plt.plot(values)
plt.show()

5) Comparison

Now we would like to see just how well our model compares against the behavior of the real robot. We will do this by running the real robot under different conditions, and seeing how our model compares when it is simulated under the same conditions.

Use soar to run wallFinderBrain.py on the real robot. This brain will run the wall finder behavior from design lab 1. When stop is pressed, it will generate a plot.

There is a small bit of code near the end of the on_stop function that decides how to label the axes of the plot. Modify this code so that the axes have appropriate labels (including units).

Also note that you will need to fill in the d_coeffs and c_coeffs associated with your model. The other pieces that are passed to the simulator are computed for you.

Start the robot roughly .8 meters away from a bubble-wrapped foam-core board. Run the brain five times with these same inital conditions, and with gains of set to 0.5, 1, 2, 5, and 10. Each time, make sure that the trailing wheel of the robot is oriented such that it will not pivot when the robot starts moving forward. Save the plots generated by soar.

6) Hi-dee-ho, Here I Go

It looks like our model is missing something! In fact, we made at least one big assumption when putting together our model: we assumed that the robot is able to immediately set its velocity to match the commanded velocity from soar.

We can solve this problem by adding a new subsystem that transforms the robot's commanded velocity into the robot's actual velocity.

This new subsystem is a complicated system representing how the robot turns a commanded velocity into an actual velocity. The behavior of this system depends on many things, such as the software on the lab laptops, the communication link to the robot, the microcontroller inside the robot, and the characteristics of the motors that drive the robot. It is very difficult to reason about this system physically. Despite this, we would like to model it.

Importantly, what we care about in the signals and systems abstraction is: how does a system transform an input signal into an output signal? So even if we can't easily think about what is happening in the system, we can build a model that characterizes it. We will take a data-driven approach here; we will collect data from the robot and use that to inform our model.

6.1) Estimating Velocity

We would like to compare the robot's commanded velocity against its actual velocity. Unfortunately, the robot's actual velocity is not something we can measure directly. Instead, we can estimate the robot's velocity as a function of time from the robot's measured position.

We have provided a function estimate_velocities in dataCollectBrain.py to perform this estimation.

6.2) Gathering Data

Open the dataCollectBrain.py file from this week's code distribution, and look at its on_step function (which will be run once every 0.1 seconds from soar). This function does the following:

• Sets the robot's velocity as a function of the current time.
• Measures the robot's current position based on the robot's internal odometry, an estimate of position based on how far the wheels have turned (note that this is not using the sonars).
• Adds the current position to a global list of positions over time, and adds the commanded velocity to a global list of commanded velocities over time.

When the "stop" button is pressed, soar will use the estimate_velocities function described above to estimate the robot's actual velocity as a function of time. It will then generate a plot.

There is a small bit of code near the end of the on_stop function that decides how to label the axes of the plot. Modify this code so that the axes have appropriate labels (including units).

Use soar to run this brain on the real robot to generate a plot. Be sure to let the robot run through at least 3 "forward-and-back" cycles, and save the plot that soar produces!

6.3) Constructing the Model

Draw a block diagram for this subsystem in the handout, including labels for its input and output signals.

6.4) Putting It Together

Draw a block diagram for the entire updated wall finder system in the handout, labeling all of the signals discussed above (D_d, E, V_c (commanded velocity), V_a (actual velocity), P, and D_s). Also label the controller and plant. If you need extra scratch paper, please ask a staff member.

**If you finish early**, there are a few things you may wish to work on during the remaining lab time. In particular:

• You may wish to start on the homework exercise implementing generic_lti_simulator, or
• You may wish to work out the difference equation for your updated system and try it in the simulator (though we'll explore this more in software lab next week as well).

 

---

Footnotes

¹The term "plant" is a holdover from the early days of control theory. One of the first applications of this theory was in controlling processes in manufacturing plants, and the term has stuck around now to mean, more generally, the system we are controlling. It doesn't represent a leafy green thing in the system. (click to return to text)