In this section we will discuss several of the key details involved in the creation of our closed-loop wireless control system.  We first aim to address the question of why wireless control is difficult, as well as the strategies we propose in order to make it a viable control solution.  In addition, we will discuss the hardware and software used in our controller implementation, as well as the characteristics of the system to be controlled.

Basic Layout

    Viewed in a traditional feedback control arrangement, the CLOWN setup takes the following form.

Note that there is no physical connection between the Controller (on the left) and the Actuator/Sensor (on the right).  The delay involved in the transfer of data can be seen to act in both the forward and feedback loops.  For linear systems, however, we can see that this is equivalent to having the round-trip delay (forward plus feedback) in the feedback loop, with an additional "forward delay" placed just before the output.  This equivalent representation may be helpful in understanding the effects of the time delay, which we will look at next.

Sampling, Communication, and the Resulting Feedback Delay

    One of the most prominent difficulties in performing closed-loop wireless control stems from the significant delays in wireless communications.  Compared with wired information transfer, which typically consists of simply applying voltages to a communication wire, wireless communication is much slower and generally less reliable.  Thus, the presence of long communication delays in a closed-loop wireless control system is a problem that must be addressed.  This problem actually hinders achievable controller bandwidth in two distinct ways.  First, it requires the sampling period of the controller to be at least as long as the round-trip communication time of the system (actuator to controller, and then back).  In the case of our wireless network cards this translates into about 4ms, yielding 250Hz as a cap on achievable closed-loop control rates.  A second and less obvious effect is that the feedback received by the controller is actually one sampling period late compared to what would be seen in a standard control application.  This has the effect of further doubling the effective sampling period of the controller.  A time line detailing the operation of a wireless control system is helpful in understanding the above-mentioned challenges.

    In the above diagram the Actuator/Sensor events are plotted on the top line versus the Controller events on the bottom line.  F and C stand for feedback and control, respectively.  Timing is dictated by the Actuator/Sensor, which initiates each cycle by sending feedback at the desired sampling interval.  The Controller simply waits until feedback is received, at which time it immediately responds with a control signal.  In this way, synchronization comes naturally as long as the Actuator/Sensor's sampling interval is at least as long as the round-trip communication time.  In the diagram above, the control loop begins by first starting the Actuator.  Feedback F0 is sent to the controller which computes a control action C1 that is immediately sent back to the actuator.  The actuator receives C1 and holds it for execution until the sampling period has elapsed and Actuator iteration 1 is reached.  After execution, a new feedback F1 is sent back to the controller in a new control loop cycle continuing the cycle.  F2 shows the effect of a lost feedback communication.  Since no feedback is received by the controller, no control action is sent and whatever strategy for lost packets is implemented occurs at the actuator (0 control, zero order hold, etc.)  Synchronization is maintained since the actuator counter automatically sends another feedback to to controller at the next sampling instant.

    Since the wireless network cards used in this project are not capable of sending and receiving at the same time, it is clear that the round-trip delay limits the closed-loop sampling rate of the system.  In addition, the scheme used here automatically introduces a one sampling period delay between when feedback data is measured and when the resulting control action can potentially be executed.  Such feedback delays can be quite hazardous to closed-loop stability, and they generally require a reduction in controller bandwidth so as to maintain the desired stability margins.  We see that both problems caused by communication delays are indeed troublesome, and thus need to be addressed if a wireless controller is to be effective.

   A second problem with wireless communication stems from the unreliable nature of this method of data transfer.  Wireless networks have a propensity for losing data; a problem known a packet loss.  When a packet of data is lost, the data could be re-sent, but this would require additional time.  In a real-time control application there is little margin for this type of error, so such a system is bound to experience loss of unrecoverable data.  Consequently, it is critical that the Controller and Actuator/Sensor implement strategies that make the system robust to such loss of data.  The type of procedures that promote robustness to data loss will be discussed in later sections.

Hardware and Software Solutions

    For the computational hardware of both the Controller and Actuator/Sensor, we originally chose notebook computers.  The combination of processing power and versatility made the choice of PC's more attractive than other DSP-based solutions.  Since one of the key advantages of wireless control systems is their mobility, the choice of notebook a PC for the control module was natural.  After much discussion, we chose to run the Windows 2000 operating system on these machines.  We also considered using RTLinux so as to achieve hard real-time execution.  This option was temporarily passed over in favor of implementing VenturCOM's RTX as a real-time kernel under Windows.  Unfortunately, we soon found that neither of the above solutions easily lend themselves to real-time wireless communication.  VenturCOM's RTX cannot support any PCMCIA devices and would require custom drivers for any wireless network cards.  For notebook computers, this is a serious problem.  As of the time of our research, the versions of RTLinux that support SimuLinux (which is like WinCon for the Linux OS) do not support TCP/IP communications in real-time threads, so going that route would not help to achieve real-time performance.  Since the achievable sampling rates are limited by the speed of network communications to ~250Hz, we opted not to use either real-time operating system, and we found that sufficient performance can be obtained under Windows 2000 with the use of an external timer.  A further benefit of this decision is that by developing our work for the Windows platform it should be usable for a much larger audience.  For creating user-friendly control loops, we chose the popular MATLAB/Simulink software package.  In addition, Microsoft Visual C++ 6.0 plays a part in the communication of control.  These communications are performed using the Windows Sockets API over a peer-to-peer wireless network (consisting of the Controller and Actuator/Sensor computers only).  For network hardware, each computer is equipped with a 802.11b wireless network card.  These are rated at 11Mbps, but more than throughput we are concerned with communication delays, which seem to be about 2ms for a one-way communication.  In the control of a physical system, we are using some custom-made DAC, timer, and encoder components.  This rounds out the list of the necessary hardware and software components.  Next we will discuss how it fits together in our wireless control application.

Current System

   The Controller runs as a Simulink block diagram that uses C S-functions for communication, and the Actuator application is written entirely in C but made to compile with MATLAB.  This allows the network communication code (written in C) to be encapsulated in the Controller's Simulink diagram as well as directly into the Actuator code.  These communications are thus made transparent, allowing controller design to be performed with all the convenience of Simulink block diagrams.  Upon reaching this stage in the project, we took some time to examine the achievable performance of our wireless control system by applying it to the control of a virtual plant.  The system proved to be a useful test bed for the effects of network delay and packet loss on a wireless control system.  Finally, we added in the daughter board that serves as a timer, reads encoders, and outputs the desired control voltages to our plant.  In the summer of 2002 we put the system components together so as to achieve closed-loop wireless control of a physical plant.  

The Plant

   The next stage in this project was to apply our closed-loop wireless controller in the balancing of an inverted Furuta pendulum.  A Furuta pendulum is a simple variation of a classical inverted pendulum in which the freely-rotating pendulum link is controlled through actuation of the rotating arm to which it connects.  This system has been widely studied and the balancing of the pendulum link in the unstable vertical position is well understood.  As an inherently unstable system, this plant tests the ability of our wireless control system to stabilize such a plant and can give a clear measure of robustness to problems such as network delays and the loss of data.  To make things a little more interesting, the Furuta pendulum created for this project has been carefully constructed so as to follow the CLOWN theme.  The finished product, consisting of a 17" Krusty the Clown doll capable of balancing a pendulum on his hand, can be seen in the figure below. 

In addition to the obvious entertainment value of the plant we've come to refer to as "Furuta Krusty," the addition of a non-rigid doll body to the classical Furuta pendulum also creates some interesting challenges in the realm of control (such as resonant oscillatory modes of the doll head).  This plant was first controlled using a traditional wired setup at 200Hz (as shown in this video clip).  It has since been united with the wireless control system that inspired its design, and the results are quite good (video clip in QuickTime or AVI format).

Controller Design

   Stabilization of the Furuta pendulum in the inverted position is based on LQR state feedback controller design.  Measurements of angular position for the arm and pendulum are sent from the Actuator to the Controller, along with the time at which the measurements were taken.  From this data, that Controller calculates the corresponding velocities which are used in the state feedback control.  By simply applying wireless feedback control in this way, however, we were not able to achieve acceptable stability.  After having limited success with attempts at basic friction compensation, we moved on to the use of a cogging map.  This provides a correlation between motor position and the required input voltage to produce movement in either direction.  Use of this cogging map as a feed-forward term in the controller allowed great improvement in performance.  Further robustness was achieved by adding a second control law which is designed for catching rather than fine position control.  Switching between these controllers allows the best of both worlds:  tight control of arm position as well as the ability to stabilize the pendulum even when subject to large external disturbances.  Finally, we added a swing-up controller which allows the pendulum to be brought from any state into the inverted position.  Swing-up is based on a modification of the energy control method.  In addition to adding energy until the pendulum has the necessary amount to swing into the inverted position, we added terms to dampen arm movements and keep the arm near the position where stabilization is desired.  Further work with compensation for delays and lost packets is underway.