Graphics Reference
In-Depth Information
5.3.1 i imPlementing Pid c ontRol foR R endeRing P Rocess
With reference to Figure 5.2, the implementation of a PID controller-based render-
ing system follows the same design with the controller block represented by a PID
controller. The plant handles the rendering process. The procedure for obtaining the
rendering process model is described in Chapters 3 and 4.
In this section, we discuss the introduction of a PID controller in a simulation
environment and also use the controller in the rendering process. Figure 5.5 shows
the design of the closed-loop PID control system adopted in this research. At the
output, the numerical value of the frame rate is tapped and sent to a comparator that
computes the difference between this output and a predefined frame rate. The error
data are sent to the PID controller.
With reference to Equation (5.2), the control action is computed based on the e ( n )
input and the PID controller's internal structure parameters (gain values). The con-
trol action generated by the controller regulates the input to the plant such that the
frame rate eventually tracks the predefined target.
As mentioned in Section 5.2, it is common for other non-rendering processes to
co-exist in the same computing environment. Processes from the operating system
kernel may create minor disturbances of rendering because they share memory and
CPU resources. Even though the modelling process for the rendering application
does not account for such disturbances, the PID control action is expected to nullify
them and continue to keep the frame rate stable.
If a large disturbance is introduced into the system through some unknown pro-
cess, the rendering application may suffer a huge momentary fluctuation in its frame
rate. In this case, the PID controller may not be able to correct the error and thus
allow the rendering process to swing beyond the controllable operating range.
We constructed the PID control system for the rendering process in MATLAB
as shown in Figure 5.5. The key components are the PID controller block, the plant
block, and the interlinking communication channels. In a simulation environment,
we assume that the data transfer has zero latency because the control system is exe-
cuted by the same computer in the same memory space. However, when the plant
model is swapped with the actual rendering process, this assumption may not be
suitable because of network latency and communication overhead that can affect the
performance of the control system.
The difference between the two simulation environments is that both the plant
and the controller run on the same computer. The second environment has both func-
tions reside in different computers connected via a local area network (LAN). The
communication blocks in the control system use the transmission control protocol
(TCP) to send packet data over the network from the source to the destination loca-
tion between the controller and plant. This network communication protocol was
selected because of the guaranteed delivery mechanism to ensure that data streams
between the plant and controller will not be dropped for every rendered frame.
In addition to the mutual loading problem caused by the plant and controller pro-
cesses, the Windows operating system poses the limitation of multitasking in the
graphical user interface (GUI) environment. This limitation prevents one applica-
tion window from receiving prioritised CPU time if it does not receive the focus
Search WWH ::




Custom Search