Control Systems
Introduction:
I've created a number of control systems over my career. Most of them have controlled moving vehicles, like airplanes or rockets. But some have controlled other systems.
The U.S. Navy's Sensor Driven Airborne Replanner
In 1989 I was part of a very small team that developed the world's
first fully autonomous UAV control system. The system was called the
Sensor Driven Airborne Replanner (SDAR). At that time, the Navy was
flying Pioneer UAVs (the airplane in the masthead at the top of the
page) off of the battleship USS Wisconsin, BB-64.
The UAVs were used for artillery spotting and over-the-horizon
search for enemy ships. At that time, the UAVs were controlled
through a continuous radio uplink to the aircraft. The aircraft
operated a continuous radio downlink to carry both data and video
back to the operators. Nearly all UAVs are still operated this way.
The problem with this technique is illustrated in the figure to the
right. (Click on any image on the page for a larger version.) The
radio links are susceptible to jamming, act as beacons
announcing the ship's presence,
and as localizers for any radiation-seeking weapon. We figured
out how to embody the intelligence of the ship-based mission-planner,
pilot and camera operator into the aircraft, eliminating the need
for both the control and data links, so that the UAV could operate
covertly. We did it by creating a control system
that could fly the aircraft as well as any pilot, topping that off
with a real-time artificial intelligence (AI) system that
could make high-level decisions, replanning the UAV's mission as data came in.
With this kind of intelligence on board, the UAV could fly a complete
mission autonomously and covertly, collecting the mission planner's
desired data without any input or contact from the surface.
The SDAR system was essentially a heirarchy of feedback control systems. At the base, connecting the SDAR system to the aircraft, I created a bank angle-, altitude- and airspeed-command autopilot. This is what flew the aircraft. Above it, we wrote a set of heading-, course- and track-command navigational control algorithms. These allowed us to, for example, command the airplane to fly a track between two points. Finally, on top, we had the artificial intelligence system, which took in sensor data, made decisions on what to do next to perform the mission and then sent guidance commands to the navigation algorithms.
For more detailed information on the system, here are a few papers I've written on the system plus a video of SDAR in action.
A paper I wrote for a computer programming conference that describes
the SDAR system and what it does.
A white paper showing SDAR flying a simulated mission. This paper
goes into good detail on how SDAR works its way through a mission.
A paper on the hardware-in-the-loop simulation that I wrote for
the development of the SDAR system in the lab.
A video of the SDAR system flying a simulated mission.
Analytical Methods, Inc.
At AMI I designed a GN&C system for a collapsible-wing, man-portable UAV. The control system is NATO STANAG-4586 compatible, its Vehicle Specific Module making it controllable from any STANAG-compatible ground station. Most UAVs aren't really designed, as we think of it in the Engineering sense. Instead, they're built using intuition, trial and error in someone's garage and work as well as can be expected. At AMI, they have airplane design experts, and they applied their talents to this UAV, designing its airframe just as thoroughly and carefully as one would design any other aircraft. I'm not at liberty to say much about the system, other than it was a beautiful design and that it will serve its customers just as they desire. Here is part of the description of the system from the CTTSO's solicitation:
R2655 Enhanced Collapsible-Wing Micro Tactical Unmanned Aerial System
Develop a single-man portable and operable Enhanced Collapsible-Wing Micro Tactical Unmanned Aerial System (ECMTUAS) with a secure Mobile Ad Hoc Network (MANET) digital data-link and software-based C2 capable of hand-launch and internal transport in a man-portable canister. The ECMTAUS shall have an endurance of 60 (threshold), 180 (objective) minutes in the operational configuration that has the greatest power draw. The ECMTAUS shall have a minimum dash speed of 55 knots. The ECMTAUS airframe shall not exceed four (threshold), two (objective) pounds in weight; the transportation canister shall not exceed seven (threshold), five (objective) inches in diameter and 35 (threshold), 30 (objective) inches in length. The ECMTUAS shall be able to launch within 30 (threshold), 10 (objective) seconds of removal from its canister...
And here is a link to the solicitation for the system in the Defense Systems Journal
Masten Space Systems
At Masten Space Systems, I developed Guidance, Navigation and
Control (GN&C) systems for the
company's vertical takeoff/vertical landing rockets.
Masten's vehicles are designed to take small payloads to high
altitude, where they can be outside most of the Earth's
atmosphere and where they can experience a short period of
near-zero-g flight. Upon reentry, the rocket can relight its engine,
right itself, make a controlled descent under rocket power and return
itself and the payload back the launch point, for a soft landing.
Masten's rockets have no aerodynamic control surfaces, and so all
control over the vehicle is exerted by vectoring the thrust of the
single, gimballed engine. I developed a new set of control laws
for Masten's "Xaero" vehicle. With those new laws in place,
the vehicle exhibited improved accuracy in its position and velocity
control during autonomous flight.
MCI Site Controller
MCI's Site Controller is a mission-critical system that is located
in every phone network hub around the world.
Its job is to control and communicate with the network equipment
that forms the backbone of the telecommunications network. The diagram
at the right shows how the system fits in. The central piece of equipment
in the phone system is the Digital Cross Connect (DXC). This
is the machine that connects disparate phone lines to form an
end-to-end, continuous connection. Every network hub, or
"site", has one or more DXCs located inside of it. In addition, line
monitoring units (LMUs), which sample the digital signals passing back
and forth, are placed on each digital phone line entering the site.
The Site Controller communicates with and controls the DXCs and LMUs
in real time. Upstream systems, whose jobs involve provisioning the
phone network, collecting performance information and collecting
alarms, do all of their work through the Site Controller. These
systems open a session with the Site Controller and then send commands
to schedule performance reports and manipulate the DXCs or LMUs.
The Site Controller complies by remembering what each session has
requested, sending commands to the network equipment, collecting
data at appropriate intervals, and sending that data to the upstream
systems.
I created four Site Controller releases. For Release 11.0, I gave the system the ability to operate E1 (European standard) Line Monitoring Units. MCI was very good at recognizing critical systems and allocating resources to ensure their dependability. Each release of the Site Controller underwent three separate and increasingly stressful test regimens. First, our local, System Test group wrung it out in our local lab. If it passed their tests, it went to the Network Equipment Lab (NEL) in Richardson, TX, where it was stressed under a full load of site equipment carrying synthesized traffic. If it passed NEL's testing, it went to a single site in the field, under the watchful eye of the Field Verification Office (FVO), where it worked under real conditions with equipment carrying live traffic. If it passed FVO, it was released to the field. After the System Test people finished their examination of Release 11.0, I found myself greeted in the hallway with congratulations and handshakes. They were able to find 6 minor issues with the system. They were used to a typical count in the twenties. With those errors fixed, The release passed through both NEL and FVO without a single additional issue coming to light. For Release 12.0, I gave the system the ability to operate the Alcatel 1633 DXC. It passed through all testing without a single issue arising. For Release 13.0 I gave the system the ability to be reconfigured on the fly. And for Release 14.0, I gave the system the ability to operate the Alcatel 1631SX DXC. When I created that release, the 1631SX was still under final development, and so we didn't have one to work with. Its design was final, however, and so I wrote a program that turned a PC into a hardware emulator of the DXC. Using it, I was able to complete development of Release 14.0 very quickly, before the hardware was released. Releases 13.0 and 14.0 also passed through all testing without a single error being found. I was very pleased to receive a note of commendation from the System Test group for my work.