7
$\begingroup$

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.

$\endgroup$
5
$\begingroup$

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.

| improve this answer | |
$\endgroup$
  • $\begingroup$ "Control is closed loop, planning (motion, trajectory or any other planning) is not (it is open loop)" does the planner in for example an autonomous vehicle not replan frequently from new sensor measurements? Can you explain a little more how planning is open loop. $\endgroup$ – Lubed Up Slug Dec 17 '19 at 5:04
  • $\begingroup$ I edited the answer $\endgroup$ – 50k4 Dec 17 '19 at 10:04
  • $\begingroup$ I see you define closed loop as using the error between a reference signal and the output signal of the plant. I just use it to mean any time information flows back from the output signal but perhaps that isn't quite right. Thanks for the clarification $\endgroup$ – Lubed Up Slug Dec 30 '19 at 19:01
1
$\begingroup$

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.

enter image description here

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.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.