Hello, it’s time for my yearly post! The goal of this one is to be a handy reference for behavior cloning as applied to manipulation – something I’ve been spending quite a bit of time on over the past 6-9 months. The field has been progressing at an absurdly rapid pace of late (somehow we’re at a point where robots can do laundry), so I thought it’d be a good exercise to summarize where we’re at right now and how we got here (at least from my perspective and based on what I’ve read so far). I’m hoping this becomes a useful resource for any manipulation enthusiasts stumbling upon it, and of course, for future me as well!

Legged robot research has been an active area of study since the late nineties. Let’s take a look at how we can generate walking trajectories for bipedal robots, using some of these ideas.

The Objective: Implement a quick and dirty way of generating walking trajectories
Constraints: Do it quickly. Minimize sophistication. Anything goes!

What this post will cover:

1. Overview of the minimal set of ideas required to develop walking algorithms
2. Computation of bipedal joint trajectories for a simple walking gait

What will not be covered:

Let’s take a look at how we can set up a framework for streamlined simulation and hardware control of a manipulator. The robot under consideration is Ufactory’s Lite6 manipulator and the simulation/setup tool used is Drake.

All the code used in this post can be found in my repo. But before we start, some explanations are in order.

Lite6?

The Lite6 is one of the more economical (not to be confused with cheap) manipulators one can buy, especially for personal research where you’re not going to be spending tens of thousands of dollars on some of the more well established robots out there. It’s well built, has surprisingly good specifications for the price point, and comes with an integrated controller. You can get a parallel and vacuum gripper for it, but also comes with hardware interfaces that can support custom grippers. The product is well supported and their API (python and C++) is easy to use. The main pain point is its parallel gripper, which can only open by 1.6 cm. This severely limits the type of objects you can pick/place, but luckily for us, pick and place is only a small part of robotic manipulation!

TrajOpt [1] is an optimization based approach for motion planning. More specifically, it uses a sequential convex optimization procedure along with a formulation of collision constraints to find locally optimal planning trajectories, even for robotic systems that have a large number of degrees of freedom.

This post will go into the details of the optimization part, and give an outline of how it can be implemented. My implementation can be found here

In this post, we take a look at this $[1]$ paper, which introduces a simple, yet interesting approach to solving a multi-vehicle path planning problem.

My implementation of the algorithm that was used to evaluate its performance and generate all the results in this post can be found here

$\newcommand{\ith}{i^{th}}$ $\newcommand{\pth}{p^{th}}$ $\newcommand{\qth}{q^{th}}$ $\newcommand{\lth}{l^{th}}$ $\newcommand{\MR}{\mathbb{R}}$ $\newcommand{\xpi}{x_{pi}}$ $\newcommand{\ypi}{y_{pi}}$ $\newcommand{\xqi}{x_{qi}}$ $\newcommand{\yqi}{y_{qi}}$ $\newcommand{\xmin}{x_{min}}$ $\newcommand{\xmax}{x_{max}}$ $\newcommand{\ymin}{y_{min}}$ $\newcommand{\ymax}{y_{max}}$ $\newcommand{\xlmin}{x_{l,min}}$ $\newcommand{\xlmax}{x_{l,max}}$ $\newcommand{\ylmin}{y_{l,min}}$ $\newcommand{\ylmax}{y_{l,max}}$ $\newcommand{\xlimin}{x_{li,min}}$ $\newcommand{\xlimax}{x_{li,max}}$ $\newcommand{\ylimin}{y_{li,min}}$ $\newcommand{\ylimax}{y_{li,max}}$ $\newcommand{\cplx}{c_{pl,x}}$ $\newcommand{\cply}{c_{pl,y}}$ $\newcommand{\dpqx}{d_{pq,x}}$ $\newcommand{\dpqy}{d_{pq,y}}$ $\newcommand{\tpli}{t_{pli}}$ $\newcommand{\spi}{s_{pi}}$ $\newcommand{\spij}{s_{pij}}$ $\newcommand{\spinext}{s_{p,i+1}}$ $\newcommand{\spn}{s_{pN}}$ $\newcommand{\spf}{s_{pf}}$ $\newcommand{\wpi}{w_{pi}}$ $\newcommand{\wpij}{w_{pij}}$ $\newcommand{\wpn}{w_{pN}}$ $\newcommand{\upi}{u_{pi}}$ $\newcommand{\upik}{u_{pik}}$ $\newcommand{\vpi}{v_{pi}}$ $\newcommand{\vpik}{v_{pik}}$ $\newcommand{\Ap}{A_{p}}$ $\newcommand{\Bp}{B_{p}}$ $\newcommand{\qp}{q_{p}}$ $\newcommand{\rp}{r_{p}}$ $\newcommand{\pp}{p_{p}}$

$\newcommand{\Dt}{\Delta t}$

We take a look at the implicit or backward Euler integration scheme for computing numerical solutions of ordinary differential equations. We will go over the process of integrating using the backward Euler method and make comparisons to the more well known forward Euler method.

Numerical integration is extremely important when it comes to simulating real world physical systems. For robotic systems, we usually have a continuous time state dynamics that tells us how the system behaves upon the application of a certain control signal.

In this post, we take a look at some characteristics of injective linear transformations. Let $T$ be a linear transformation from some vector space $V$ to another vector space $W$, both defined over a field $F$. $T$ being injective, means that no two vectors in $V$ can be mapped to the same vector in $W$. We have a one-to-one mapping between the vectors in $V$ and their images in $W$.

We look into the problem of expressing a vector $p$, whose coordinates relative to some basis is known, through the coordinates relative to a different basis.

Let’s assume that $p$ lies in an $n$ dimensional vector space $V$ defined over the field $F$. Let $A$ and $B$ be two different sets of basis vectors containing the vectors $\set{\alpha_1, \ldots, \alpha_n}$ and $\set{\beta_1, \ldots, \beta_n}$ respectively.

Let $p_A$ represent the coordinates of $p$ with respect to the basis $A$. Now, how do we go about computing $p_B$?

Let $V$ be a finite dimensional vector space over the field $F$, with $\dim{V} = n$.
We also define the ordered basis for $V$ to be $B = \set{\beta_1, \ldots, \beta_n}$.

Consider a subspace $U$ of the vector space $V \subseteq U$. Naturally, we have $\dim{U} \leq \dim{V}$.

This is because for any $\alpha \in U$, we have $\alpha \in V$, which can then be expressed as a linear combination of the basis vectors in $B$. Hence, we don’t require more than $n$ linearly independent vectors to represent any vector in $U$.