2026 ECE 4550 — Control System Design Lab #7- Motion Planning and Trajectory-Tracking Control Georgi

2026 ECE 4550 — Control System Design Lab #7- Motion Planning and TrajectoryTracking Control Georgia institute of technology GEORGIA INSTITUTE OF TECHNOLOGY

SCHOOL of ELECTRICAL and COMPUTER ENGINEERING

ECE 4550 — Control System Design — Fall 2026 Lab #7: Motion Planning and Trajectory-Tracking Control

Contents 1 Background Material 1 1.1 Two Controller Architectures......................................................................................................2 1.2 Motion Planning...........................................................................................................................3 1.2.1 Plant Model Inversion.....................................................................................................3 1.2.2 Polynomial Trajectory.....................................................................................................4 2 Lab Assignment 4 2.1 Pre-Lab Preparation....................................................................................................................4 2.2 Tasks............................................................................................................................................5 2.2.1 Generation of Reference Trajectory...............................................................................6 2.2.2 Trajectory-Tracking Position Control............................................................................6

1

Background Material

In Lab 6, we successfully implemented a controller that enabled point-to-point positioning of a rotational motion plant. The plant was modeled, after parameter identification, in the form x˙ (t) = Ax(t) + Bu(t) y(t) = Cx(t).

(1)

This was a huge step forward, as we had to master the details of sensing and actuation with SPI serial communication, while also using a timer interrupt to facilitate the real-time solution of the differential equations that govern the controller’s regulator and estimator subsystems. However, in some ways, that lab experience revealed unresolved issues, such as how differently that system responded to small and large position command signals; small motions were handled well, but large motions saturated the actuator. A saturated actuator operates at its limit, which means it cannot provide a corrective response to a disturbance event; while the actuator is saturated, the system essentially functions in open-loop mode rather than in closed-loop mode.

This lab addresses the concern raised above, by focusing attention on two distinct elements of a control system that are designable; the control algorithm (our prior focus) and the reference signal generator (a new focus). It is possible to reuse the controller of Lab 6 as is, with a nicely shaped reference signal r so that large motions will not saturate the actuator. However, a better option is to use a redesigned controller that allows the plant to track reference trajectories satisfying x˙ ref (t) = Axref(t) + Buref(t) yref(t) = Cxref(t).

(2)

Reference trajectories designed using (2) have multiple benefits. These signals fully account for plant physics, so their use in a redesigned controller enables zero-error operation of the overall

system. Note that yref in (2) may be assigned to have a nice shape that avoids actuator saturation; the corresponding xref and uref in (2) are then derived using plant model inversion.

1.1

Two Controller Architectures

When a controller is interfaced to a plant, the option exists to use reference signals as inputs to the overall system to request a desired response from the plant. Two controller architectures of this type are shown in Figure 1. The first architecture is referred to as a command-following controller, because it causes the plant output y to approach a constant reference command r without error, using feedback; the governing equations for this architecture are u(t) = − K1 xˆ(t) − K2σ(t) xˆ˙ (t) = Axˆ(t) + Bu(t) − L (Cxˆ(t)

(3)

− y(t)) σ˙ (t) = y(t) − r(t).

The second architecture is referred to as a trajectory-tracking controller, because it causes the plant output y to approach a time-varying reference command yref without error, using a combination of feedback and feedforward; the governing equations for this architecture are u(t) = uref(t) − K1 (xˆ(t) − xref(t)) − K2σ(t) xˆ˙ (t) = Axˆ(t) + Bu(t) − L (Cxˆ(t)

(4)

− y(t)) σ˙ (t) = y(t) − yref(t).

These two architectures are similar, with (3) being a special case of (4), but they develop corrective actions differently. In (3), u responds to an error between r and y through the feedback term σ, but only after the error has occurred. In (4), u accommodates the need for the plant input to vary with time even under ideal zero-error conditions through feedforward term uref, reducing the role of estimated state feedback error xˆ − xref and measured output feedback error y − yref. w r

regulator

(σ)

u

plant

(x)

y Command-Following Controller: — constant w (unknown) — constant r — feedback only

estimator

( xˆ) xˆ w yref xref uref

regulator

(σ)

u

plant

(x) estimator

( xˆ) xˆ

y Trajectory-Tracking Controller: — constant w (unknown) — time-varying yref, xref, uref — feedback and feedforward

Figure 1: Two controller architectures with reference inputs.

As we consider the similarities and differences between these two architectures, it is useful to focus on the position control application and to keep the following points in mind:

• The motivation to guide the motions of positioning systems using time-varying trajectories has already been made clear in Lab 6, which used command-following control and an abrupt step change in reference input r. We were able to command small motions of π rad without saturating the actuator, but not large motions of 4π rad.

• When large travel distances are required, the preferred approach is to specify the desired motion in terms of a time-dependent formula, with motion parameters set to avoid actuator saturation while also emphasizing design goals such as reducing travel time or reducing energy consumption; such motion planning requires knowledge of plant physics.

• Although it is possible to feed a command-following controller a time-dependent r, accurate tracking would only be achieved for slowly varying r, due to the frequency response character- istics resulting from such a controller. If precise tracking is important, a trajectorytracking controller fed by time-dependent yref, xref and uref satisfying (2) is more appropriate.

For implementation, trajectory-tracking controller (4) must be approximated by a discrete-time counterpart and enhanced with anti-windup logic to guard against poor behavior in the event of actuator saturation. Using forward Euler approximation with update period T , this leads to u(kT ) = sat (uc(kT )) uc(kT ) = uref(t) − K1 (xˆ(k T ) − xref(kT )) − K2σ(kT ) xˆ(kT + T ) = xˆ(kT ) + T (Axˆ(kT ) + Bu(kT ) − L (Cxˆ(kT )

(5)

− y(kT ))) σ(kT + T ) = σ(kT ) + T (y(kT ) − yref(kT ) + κ (uc(kT ) − u(kT ))) where the ‘sat’ function clips uc at ±Umax and κ is the anti-windup gain. Lab 6 shows how regulator bandwidth λr determines K1, K2, and κ, and how estimator bandwidth λe determines L.

1.2 1.2.1

Motion Planning

Plant Model Inversion

The desired motion trajectory is naturally expressed in terms of position, velocity and acceleration, but the reference signals required for trajectory-tracking control may be somewhat different.

For Lab 6 and this lab, the design model of the plant has the input-output form y¨(t) + α y˙(t) = βu(t)

(6)

where y is position, y˙ is velocity, y¨ is acceleration and u is voltage; the state-space form (1) has 0 1 A = 0 −α

0 (7) β , C= 1 0 with position and velocity as state variables. Using this plant model, reference signals xref and uref may be derived from any specified position reference signal yref, and the result is ,

xref (t) =

B=

yref (t)

, u y˙ref(t)

ref (t) =

y¨ref (t) + α y˙ref(t) . β

(8)

The simple expressions in (8) represent a special case of plant model inversion satisfying (2); these

expressions are derived almost instantly by inspection, and this simplicity is the result of the plant having low order and no zeros. Note that (8) holds true for any choice of sufficiently smooth yref.

We will now consider how to express a specific choice of yref as an explicit function of time t.

1.2.2

Polynomial Trajectory

Point-to-point positioning is the type of motion required in many automation tasks, such as the pick and place operations encountered in robotic assembly machines. A single motion stroke begins with initial position yi at time ti, and ends with final position yf at time tf. A position trajectory for this single motion stroke may be defined by the piecewise-polynomial formula  y 2 3 4 5 yref(t) =  ct 0i + c1t + c2t + c3t + c4t + c5t tf]  yf

, t< , t ∈ [ti i,

(9)

, t > tf

where the six constant coefficients are chosen to impose six desired constraints at ti and tf: position constraints: velocity constraints: acceleration constraints:

yref(ti) = yi,

yref(tf) = yf

y˙ref(ti) = 0, y¨ref (ti ) = 0,

y˙ref(tf) = 0

(10)

y¨ref (tf ) = 0.

This motion plan is quite smooth, because yref and its first two time derivatives are continuous functions of t; this level of smoothness may be desired when commanding the motion of structures prone to vibration. The required coefficients are determined by solving the constraint system    ti 43 ti 54    i 2 ti 32 01 t1i 2t  y0i  t i 3t 4t 5t  cc10 i i i  0 2 6t 12t 2 20t 3  c2  0 10 tf t2 t3 i t4 i = 5 i   (11)  t f c3 yf     f f f    4  0 1 2tf 3t2f 4t3f  0 5tf   c4 0 0 2 6tf 12tf2 20t3f c5 0 which is fully specified by the given parameter set {ti, tf , yi, yf}. Solution of (11) is greatly simplified by assuming that ti = 0, in which case tf represents the duration of the single motion stroke. With this simplifying assumption, it can be shown that the solution of (11) is c0 = yi,

c1 = 0,

c2 = 0,

c3 = 10

yf − yi tf3

,

yf − yi c4 = −15 4 , tf

c5 = 6

yf − yi tf5

.

(12)

When commanding a sequence of multiple point-to-point motions, yref and its time derivatives may be computed from (9) using (12) provided that the microcontroller resets its representation of t to zero at the beginning of each motion stroke.

For a given motion stroke magnitude |yf − yi|, the motion stroke duration tf may be adjusted to plan for rapid repositioning without saturating the actuator. This reference trajectory tuning process links the plant inversion result (8) with the output trajectory selection (9). A significant benefit of motion planning has thus been revealed; e.g., the throughput of a robotic machine may be easily quantified without simulating the overall system consisting of plant and controller.

2

Lab Assignment

2.1

Pre-Lab Preparation Each individual student must work through the pre-lab activity and prepare a pre-lab

deliverable to be submitted by the beginning of the lab session. The pre-lab deliverable consists of a brief typed statement in response to the following pre-lab activity specification:

1. Read this entire document, and describe the overall purpose of this week’s project.

2. Interpret the rows of (11). Show that (12) solves (11) if ti = 0.

3. Labs 6 and 7 use different controllers (command-following and trajectory-tracking), yet their feedback gains (K1, K2, L, κ) are identical. Why is an identical choice of gains allowed?

4. Describe an application for which trajectory-tracking control would be favorable compared to command-following control, focusing on the size of the transient output error.

Please note that it is not essential to write application code prior to the lab session; the point of the pre-lab preparation is for you to arrive at the lab session with firm ideas regarding the tasks assigned in §2.2 and the high-level algorithms supporting those tasks.

2.2

Tasks

This lab project uses the QMS as the plant (first used in Lab 4), with an inertia disk attached to the rotor of the DC motor as a load. A framework of low-level functions has been developed for this plant for two purposes: to simplify the process of setting actuator commands and getting sensor measurements; and to enable experiment management from within Matlab using mode assignment and data transfer through a back-channel UART connection. This framework is described in another document which you should study. Specifications for this project are listed in Table 1.

Table 1: Specifications for the Experimental Tasks Parameter Data Log Length Timer ISR Period Actuator Saturation Limit Regulator Bandwidth Estimator Bandwidth

Symbol N T Umax λr λe

Value 2000 0.001 15.0 50.0 200.0

Units — s V rad/s rad/s

A simulation program, posted on Canvas, has been prepared to assist with your experimental efforts. The controller updates with period T , to be consistent with timer ISR based microcontroller implementation. However, plant dynamics must generally be integrated over time increments significantly smaller than T , to accurately account for fast plant eigenvalues and/or the piecewise- constant nature of the plant’s control input; hence, plant updates are computed with time increment h T . We will learn more about the accurate simulation of continuous-time plants with discrete- time controllers later this semester, but this simulation program introduces the concept.

The two main objectives for this simulation program are: (i) to demonstrate the computational flow of the reference trajectory generator and two variants of the controller (command following and trajectory tracking); (ii) to predict how both variants of the overall system might respond to a repre- sentative point-to-point positioning task with relatively large motion stroke. The predictions, shown in Figure 2, establish that the transient error between desired behavior and simulated behavior are large for command-following control (left column) but imperceptibly small for trajectory-tracking control (right column). Use this simulation program to identify issues with your implementation that require debugging, and/or to clarify the extent to which theory and practice agree.

2.2.1

Generation of Reference Trajectory

Develop code that generates reference trajectories as a real-time process, specifically the plant inverse trajectory (8) with desired position from (9). Use motion strokes with magnitude 6π rad and duration 0.25 s, toggling direction every 0.5 s, as in the simulation code, and use plant parameters from Lab 6. Perform data logging of yref (in rad) and uref (in V) over t ∈ [0, 2) (in s). Plot yref versus t in the top panel and uref versus t in the bottom panel. Compare your experimental plots with the provided simulation plots. Do not apply any voltage to the plant during this test.

2.2.2

Trajectory-Tracking Position Control

Develop code that implements two variants of the position controller defined by ( 5), using plant parameters and gain assignments from Lab 6, and yref defined by (9) with motion stroke parameters from Task 1. For command following, xref and uref are zero. For trajectory tracking, xref and uref are defined by (8). For each variant individually: perform data logging of yref and y (in rad) and uref and u (in V) over t ∈ [0, 2) (in s); plot yref with y versus t in the top panel and uref with u versus t in the bottom panel; and compare measurements with simulations.

Figure 2: Simulation of command following (left column) and trajectory tracking (right column).

GEORGIA INSTITUTE OF TECHNOLOGY

SCHOOL of ELECTRICAL and COMPUTER ENGINEERING

ECE 4550 — Control System Design — Fall 2025 Lab #7: Motion Planning and Trajectory-Tracking Control

INSTRUCTOR VERIFICATION PAGE LAB SECTION L01 L02 L03 L04

BEGIN DATE October 28 October 28 October 30 October 30

END DATE November 4 November 4 November 6 November 6

To be eligible for full credit, do the following (all students upload even if working in groups): 1. Upload your pre-lab deliverable to Canvas before lab session begins on begin date.

2. Upload your C and Matlab files to Canvas before lab session ends on end date.

3. Upload a scan of this verification page before lab session ends on end date.

Name #1: Name #2:

Checkpoint: Verify completion of the task assigned in §2.2.1.

Verified:

Date/Time:

Checkpoint: Verify completion of the task assigned in §2.2.2.

Verified:

Date/Time: