Motion Planning vs. Control

Question

Often I see positions for robotics companies split into planning and controls engineers.

But motion planning and controls seem to have a lot of overlap.

As I understand in motion planning the planner produces a trajectory. But to make sure the trajectory is feasible the planner must also take into consideration information about the dynamics of the system and can output controls as well.

Similarly methods like MPC and optimal control output a trajectory of states and times with the controls. In fact in any control paradigm where you have a model or simulator you can produce a trajectory of states from your control inputs and initial condition.

Thus I have 4 questions:

1. How does motion planning differ from controls?
2. On a robotics team what is the problem the planning team seeks to solve? Once they solve it, what information do they give to the control module?
3. On a robotics team what is the problem the control team seeks to solve? How do they use the information from the planning module?
4. What sort of experience/classes do people on planning teams have? There's plenty of classes on control at my university but I have never seen any about planning. I took a robotics class this semester and it doesn't cover planning in depth and none of the syllabi for other robotics classes cover planning for more than a lecture.

Note here I'm assuming that the planning team works on motion planning instead of path planning. If they work on path planning then I understand 2 and 3.

Answer 1

There is a saying in software engineering which states that your company structure is reflected in your software architecture (I cannot recall the exact phrase). This is true for a robot control software stack also.

1. Control is closed loop, planning (motion, trajectory or any other planning) is not (it is open loop). In a closed loop solution (i assume in all cases but it might be just the majority of cases) an error signal is built from the setpoint signal and a measured signal. The controller tries to minimize this error. In a planning problem the planner can receive an input (e.g.) current position, but the output is a "plan" how to get to the next point (and the problem is not formulated as how to minimize the distance to the next point, but how to build an polynomial which connects the points smoothly). It is open loop because the output of the planner is not in direct relation to its input. It does not want to minimize an error, all controllers (again I assume all controllers, there might be exceptions) try to minimize an error signal built as a difference between the setpoint and a current measured value. You can definitely build a closed loop controller which minimizes the distance to the next point and therefore generates a trajectory implicitly, but the goal of the trajectory planner is to respect geometrical constraints through planning which a controller could not respect (or only through a more complicated approach then the planner/controller). To have a very simplistic summary, the trajectory planner interpolates between the waypoints while respecting geometrical (and kinematic) constraints, while the controller follows the trajectory given by the series of interpolated points (not the far away waypoints).

2. In the application program of an industrial robot (manipulator) the waypoints for a motion are defined and the type of motion is specified. e.g. linear motion from the current pose to pose (x, y, z, a ,b,c). moreover, usually motions are flowed by other motion command, e.g. linear motion, circular motion, linear motion, spline motion, each with their own waypoints (an optionally target velocities and accelerations). Trajectory planning takes these motion types and waypoints and defines a (hopefully) smooth spline (incl. rounded edges if needed/allowed) and adds the velocity and acceleration components. Basically from a vector based description of the path (waypoints and target velocities and accelerations) you get a time dependent (smooth) curve, which respects the dynamic limits of the robot. Motion planning is sometimes used as a synonym of trajectory planning, sometimes it includes both path planning and trajectory planning. Path planning would find those waypoints, which I assumed where given in the application program. The planner might get the dynamic limits of the robot as parameters from the controls team (but usually there is a specification from which both teams work form)

3. The controls team is concerned mainly with designing, implementing and tuning control loops in order to get the best possible performance out of the hardware. They need to be prepared to get any trajectory and execute it (or stop with an error). After the controls module is finished the dynamic limits of the robot set (however, there is a design specification for target dynamic performance which the control team is seaking to accomplish). The control software module gets the curve from the trajectory planner.

4. CNC controllers are similar to robotics controllers, an in depth understanding of CNC controllers offers a good insight into robot controllers. Otherwise SE cannot comment on what classes are offered at your university and their technical depth. Maybe look trajectory planning topics, path generation, robot control systems, motion control. Otherwise differential equations, differential geometry, curves (polynome-, akima-, b-splines, bessier curves, lines, circles, polylines), interpolation, numerical optimisation, physics of motion, kinematics, higher order kinematics, differential kinematics are some of the topics needed for trajectory planning. Furthermore software engineering (mostly C/C++ related) topics are important for the implementation. The book Numerical Recipes comes into mind, with 1 relevant chapter about interpolation and one about ordinary differential equations.

Answer 2

I can speak to space robotics, and military-type robotics, and some commercial robots, but there isn't really a "typical" robot yet.

How does motion planning differ from controls?

A drunk person can plan a path or sequence of motions, but cannot follow it well. A drunk person has motion and path planning but suffers poor control (esp poor reaction time which creates a time-delay system which is notoriously difficult to control). Google maps gives you a plan, but your brain determines the motions (change lanes!) and your hands on the wheel gives the controls.

On the mars rovers, the scientists give the plan (go there), the rover drivers determine the motions (drive along this curve) but the rover determines the controls (the wheel speeds) ... often. Sometimes the rover drives determine even the wheel speeds / turns.

On a robotics team what is the problem the planning team seeks to solve? Once they solve it, what information do they give to the control module?

A planning team usually determines first actions (e.g., I should now mow the lawn), then motions (Mowing the lawn should mean turning on the mower and then outputting a sequence of waypoints that, if navigated to in straight lines, will cover all the un-cut grass.) Then, the output to one control module is those lines between waypoints, and the output from that module is wheel speeds.

On a robotics team what is the problem the control team seeks to solve? How do they use the information from the planning module?

It usually looks like this:

1: Goal (mow) -> 2. Actions (turn on blades, drive over all grass) -> 3. Discrete Path (seq of waypoints that covers the grass) -> 4. Continuous path (the curved path the robot can actually follow) -> 5. Wheel speeds to follow that path. Note, sometimes static obstacles are introduced at stage 3, and moving obstacles are considered at stage 4-5. This is just my experience.

Note, 4 and 5 are frequently recalculated based on where the robot is, 3 is infrequently recalculated if ever, and 1 or 2 are sometimes never recalculated (they may be hard-coded). 3-4 are sometimes called motion planning, and 5 is sometimes called controls. It's best to draw this pipeline out for each use case and get specific as quickly as possible.

What sort of experience/classes do people on planning teams have?

Typically, they may have heard of RRTs, MPC, PID loops, LQR, Visibility Graphs / Roadmap methods, velocity obstacles, artificial potential fields, and so on. If you want to work at stage 1/2 above, you should learn more about traditional AI and activity planning, which is better characterized as planning and scheduling. Decision trees, Game trees, classical dependency graphs and job-shop type problems, even vehicle routing literature fits here.

Answer 3

I would answer your first question. I would say motion planning can be treated as a higher-level control. You can think about motion planning problems as a subclass of optimal control problems (OCP).

1. You have some goals, e.g. you want to reach a place ASAP, this gives you a cost function.
2. Your vehicle has its governing dynamics, as well as state and input constraints.
3. You want to avoid obstacles, either static or dynamic, these are some constraints.

In practice, there are many applications using MPC/LQR to deal with the planning problems to generate a feasible trajectory, which is then tracked by the low-lever controller.

You might also have seen some algorithms used in motion planning, e.g sampling-based methods like A*, RRT. These methods can also be regarded as a way to solve the optimal control problem by using heuristics or sampling. Other algorithms like Artificial Potential Field can be viewed as constructing a Lyapunov function if you're familiar with some control theoty. As you go deeper, you will find more interesting connections between planning and control :)