efectos-discretizacion-polos-plano-z

Discretization effects and the z-plane

  • 5 min

The discretization effects are the dynamic changes that appear when executing a continuous control step by step inside a microcontroller.

In the previous article we saw how the Nyquist Theorem warned us about going blind (Aliasing effect) if we read the sensor too slowly. However, there is a much deeper and darker problem when we jump into the world of microcontrollers.

You design a PID on paper. You calculate your gains , , and . The Root Locus swears up and down that your poles are on the left and the system is super stable. You upload that code to your Arduino… and the robot goes up in flames. Why have the mathematics lied to us?

Today we’re going to give a quick intuition (without drowning in complex integrals) about what happens to the physics when time stops being continuous and starts moving in jumps.

The Zero-Order Hold (ZOH)

In the continuous world, if a motor needs to change its force, it does so smoothly. In the world of your microcontroller, you calculate an output (e.g., PWM at 120), send it to the driver, and that signal stays frozen until the loop comes back around and calculates a new value.

This effect is called the Zero-Order Hold (ZOH).

During those milliseconds when the signal is frozen, the robot keeps moving in the real physical world, but your code is doing absolutely nothing to adapt to this new position. Mathematically, this “freezing” acts exactly as if you had introduced a pure delay (Dead Time) into the system.

And if you remember our article on Bode plots… delay is the arch-enemy of the phase margin. The simple act of digitizing a control pushes the system towards instability.

From the s-plane to the z-plane

To analyze discrete systems, engineers abandon the Laplace Transform (the variable ) and use its digital equivalent: the Z-Transform (the variable ).

To relate a continuous mode to its sampled equivalent, we use the period T_s:

This exact mapping has a very useful visual consequence when we draw the stability map.

The stability boundary

In the continuous world (S-Plane), we said the frontier between life and death was the vertical axis. If a pole crossed into the right half-plane, the system would explode.

By applying z = e^{sT_s}, the left half-plane of Laplace transforms into the interior of a circle with radius 1: the unit circle. Therefore, a continuous pole with a negative real part becomes, through exact mapping, a discrete pole with a magnitude less than one, regardless of the sampling period.

Practical rule of digital control: A discrete LTI system is asymptotically stable if all its poles are strictly inside the unit circle, i.e., |z| < 1. Simple poles on the circle correspond to marginal stability; outside it, the response grows.

Euler’s approximation

In the PID programming article, we used simple approximations for the integral and derivative. If we also approximate the evolution of a continuous dynamic using Forward Euler, we replace the exact exponential mapping with a straight line:

Euler’s method does not use the exact exponential, but instead makes a “cheap” linear approximation:

This approximation may fail to preserve stability when the step size is too large.

Imagine we simulate the equation ẋ = -10x using Forward Euler. Its continuous pole is located at s = -10.

  • If your Arduino is super fast ( s): The digital pole sits at . It’s inside the Unit Circle. Stable.
  • If your Arduino is slow ( s): The digital pole goes to . It’s at the center. Perfect.
  • If you put delays in the code and the loop takes a long time ( s): The pole goes to .

-1.5 is outside the unit circle because its magnitude is greater than 1. The physical plant hasn’t become unstable: the numerical approximation with that step produces an unstable discrete model. The same risk appears when discretizing a controller without checking the complete loop result.

Why it matters when programming a control

At the code level on an Arduino or ESP32, we don’t usually pull out a notebook to calculate the Z-Transform of our convection oven. But this visual intuition gives you a “superpower” when debugging:

  1. If your robot oscillates almost sample by sample, there could be a discrete pole near -1 or outside the unit circle, but noise, saturation, or delays can also play a role. Reduce the period or the gains in a controlled manner and analyze the data before attributing it to a single cause.
  2. Methods like Forward Euler can be problematic with large steps. To discretize controllers we often consider alternatives such as the bilinear transformation or Tustin’s method, which maps the entire left half-plane inside the unit circle, although it introduces frequency warping.

With this, we definitively close the most mathematical and abstract block of digital control. We now understand why time is a critical factor and how it can destroy our stability from behind.