Accounting for Zero Order Hold

In our work, we've overlooked an important aspect of digital control systems, which gains importance as we try to control systems with greater time steps in between controller updates. Specifically, we have not taken into account the impact of the zero order hold. Here is a quote from Franklin, Powell, and Workman in the book Digital Control of Dynamic Systems:

"It is worthy to note that the single most important impact of implementing a control system digitally is the delay associated with the D/A converter. Each value of u(kT) is typically held constant until the next value is available from the computer. Thus, the continuous value of u(t) consists of steps that, on the average, lag u(kT) by T/2. If one simply incorporates this T/2 delay in a continuous analysis of a digital system, excellent agreement results for many reasonable sample rates."

These effects become less significant as the control update time step becomes smaller, but we want flexibility in the time step. This is shown by another quote:

"Many systems are originally conceived with fast sample rates, and the computer is specified and frozen early in the design cycle; however, as the designs evolve, more demands are placed on the system, and the only way to accommodate the increased computer load is to slow down the sample rate. Furthermore, for cost-sensitive digital systems, the best design is the one with the lowest cost computer that will do the required job."

With our system, updating the control input at intervals longer than 10 ms causes the system to crash. At 10 ms intervals, I would suspect that the controller will perform poorly and will be more susceptible to failure (especially if a packet is dropped). By accounting for the zero-order hold, I think that the controller can potentially run at a slower rates and still maintain good system performance. Also, perhaps we can use similar techniques to account for time delay caused by network circumstances.