Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Commanding”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,099 records · Page 61

Replacement Sequence of Events Generator

The soeWINDOW program automates the generation of an ITAR (International Traffic in Arms Regulations)-compliant sub-RSOE (Replacement Sequence of Events) by extracting a specified temporal window from an RSOE while maintaining page header information. RSOEs contain a significant amount of information that is not ITAR-compliant, yet that foreign partners need to see for command details to their instrument, as well as the surrounding commands that provide context for validation. soeWINDOW can serve as an example of how command support products can be made ITAR-compliant for future missions. This software is a Perl script intended for use in the mission operations UNIX environment. It is designed for use to support the MRO (Mars Reconnaissance Orbiter) instrument team. The tool also provides automated DOM (Distributed Object Manager) storage into the special ITAR-okay DOM collection, and can be used for creating focused RSOEs for product review by any of the MRO teams.

Fisher, Forest↗

Apollo Recovery Operations

Objectives include: a) Describe the organization of recovery force command and control and landing areas; b) Describe the function and timeline use of the Earth Landing System (ELS); c) Describe Stable 1 vs Stable 2 landing configurations and the function of the Command Module Uprighting System; d) Explain the activities of the helicopter and swimmer teams in egress and recovery of the crew; e)Explain the activities of the swimmer teams and primary recovery ship in recovery of the Command Module; and f) Describe several landing incidents that occurred during Apollo.

Interbartolo, Michael↗

Maneuver Automation Software

The Maneuver Automation Software (MAS) automates the process of generating commands for maneuvers to keep the spacecraft of the Cassini-Huygens mission on a predetermined prime mission trajectory. Before MAS became available, a team of approximately 10 members had to work about two weeks to design, test, and implement each maneuver in a process that involved running many maneuver-related application programs and then serially handing off data products to other parts of the team. MAS enables a three-member team to design, test, and implement a maneuver in about one-half hour after Navigation has process-tracking data. MAS accepts more than 60 parameters and 22 files as input directly from users. MAS consists of Practical Extraction and Reporting Language (PERL) scripts that link, sequence, and execute the maneuver- related application programs: "Pushing a single button" on a graphical user interface causes MAS to run navigation programs that design a maneuver; programs that create sequences of commands to execute the maneuver on the spacecraft; and a program that generates predictions about maneuver performance and generates reports and other files that enable users to quickly review and verify the maneuver design. MAS can also generate presentation materials, initiate electronic command request forms, and archive all data products for future reference.

Uffelman, Hal↗

Monitoring Disasters by Use of Instrumented Robotic Aircraft

Efforts are under way to develop data-acquisition, data-processing, and data-communication systems for monitoring disasters over large geographic areas by use of uninhabited aerial systems (UAS) robotic aircraft that are typically piloted by remote control. As integral parts of advanced, comprehensive disaster- management programs, these systems would provide (1) real-time data that would be used to coordinate responses to current disasters and (2) recorded data that would be used to model disasters for the purpose of mitigating the effects of future disasters and planning responses to them. The basic idea is to equip UAS with sensors (e.g., conventional video cameras and/or multispectral imaging instruments) and to fly them over disaster areas, where they could transmit data by radio to command centers. Transmission could occur along direct line-of-sight paths and/or along over-the-horizon paths by relay via spacecraft in orbit around the Earth. The initial focus is on demonstrating systems for monitoring wildfires; other disasters to which these developments are expected to be applicable include floods, hurricanes, tornadoes, earthquakes, volcanic eruptions, leaks of toxic chemicals, and military attacks. The figure depicts a typical system for monitoring a wildfire. In this case, instruments aboard a UAS would generate calibrated thermal-infrared digital image data of terrain affected by a wildfire. The data would be sent by radio via satellite to a data-archive server and image-processing computers. In the image-processing computers, the data would be rapidly geo-rectified for processing by one or more of a large variety of geographic-information- system (GIS) and/or image-analysis software packages. After processing by this software, the data would be both stored in the archive and distributed through standard Internet connections to a disaster-mitigation center, an investigator, and/or command center at the scene of the fire. Ground assets (in this case, firefighters and/or firefighting equipment) would also be monitored in real time by use of Global Positioning System (GPS) units and radio communication links between the assets and the UAS. In this scenario, the UAS would serve as a data-relay station in the sky, sending packets of information concerning the locations of assets to the image-processing computer, wherein this information would be incorporated into the geo-rectified images and maps. Hence, the images and maps would enable command-center personnel to monitor locations of assets in real time and in relation to locations affected by the disaster. Optionally, in case of a disaster that disrupted communications, the UAS could be used as an airborne communication relay station to partly restore communications to the affected area. A prototype of a system of this type was demonstrated in a project denoted the First Response Experiment (Project FiRE). In this project, a controlled outdoor fire was observed by use of a thermal multispectral scanning imager on a UAS that delivered image data to a ground station via a satellite uplink/ downlink telemetry system. At the ground station, the image data were geo-rectified in nearly real time for distribution via the Internet to firefighting managers. Project FiRE was deemed a success in demonstrating several advances essential to the eventual success of the continuing development effort.

Wegener, Steven S.↗

Digital Camera Control for Faster Inspection

Digital Camera Control Software (DCCS) is a computer program for controlling a boom and a boom-mounted camera used to inspect the external surface of a space shuttle in orbit around the Earth. Running in a laptop computer in the space-shuttle crew cabin, DCCS commands integrated displays and controls. By means of a simple one-button command, a crewmember can view low- resolution images to quickly spot problem areas and can then cause a rapid transition to high- resolution images. The crewmember can command that camera settings apply to a specific small area of interest within the field of view of the camera so as to maximize image quality within that area. DCCS also provides critical high-resolution images to a ground screening team, which analyzes the images to assess damage (if any); in so doing, DCCS enables the team to clear initially suspect areas more quickly than would otherwise be possible and further saves time by minimizing the probability of re-imaging of areas already inspected. On the basis of experience with a previous version (2.0) of the software, the present version (3.0) incorporates a number of advanced imaging features that optimize crewmember capability and efficiency.

Brown, Katharine↗

Cooperative Three-Robot System for Traversing Steep Slopes

Teamed Robots for Exploration and Science in Steep Areas (TRESSA) is a system of three autonomous mobile robots that cooperate with each other to enable scientific exploration of steep terrain (slope angles up to 90 ). Originally intended for use in exploring steep slopes on Mars that are not accessible to lone wheeled robots (Mars Exploration Rovers), TRESSA and systems like TRESSA could also be used on Earth for performing rescues on steep slopes and for exploring steep slopes that are too remote or too dangerous to be explored by humans. TRESSA is modeled on safe human climbing of steep slopes, two key features of which are teamwork and safety tethers. Two of the autonomous robots, denoted Anchorbots, remain at the top of a slope; the third robot, denoted the Cliffbot, traverses the slope. The Cliffbot drives over the cliff edge supported by tethers, which are payed out from the Anchorbots (see figure). The Anchorbots autonomously control the tension in the tethers to counter the gravitational force on the Cliffbot. The tethers are payed out and reeled in as needed, keeping the body of the Cliffbot oriented approximately parallel to the local terrain surface and preventing wheel slip by controlling the speed of descent or ascent, thereby enabling the Cliffbot to drive freely up, down, or across the slope. Due to the interactive nature of the three-robot system, the robots must be very tightly coupled. To provide for this tight coupling, the TRESSA software architecture is built on a combination of (1) the multi-robot layered behavior-coordination architecture reported in "An Architecture for Controlling Multiple Robots" (NPO-30345), NASA Tech Briefs, Vol. 28, No. 10 (October 2004), page 65, and (2) the real-time control architecture reported in "Robot Electronics Architecture" (NPO-41784), NASA Tech Briefs, Vol. 32, No. 1 (January 2008), page 28. The combination architecture makes it possible to keep the three robots synchronized and coordinated, to use data from all three robots for decision- making at each step, and to control the physical connections among the robots. In addition, TRESSA (as in prior systems that have utilized this architecture) , incorporates a capability for deterministic response to unanticipated situations from yet another architecture reported in Control Architecture for Robotic Agent Command and Sensing (NPO-43635), NASA Tech Briefs, Vol. 32, No. 10 (October 2008), page 40. Tether tension control is a major consideration in the design and operation of TRESSA. Tension is measured by force sensors connected to each tether at the Cliffbot. The direction of the tension (both azimuth and elevation) is also measured. The tension controller combines a controller to counter gravitational force and an optional velocity controller that anticipates the motion of the Cliffbot. The gravity controller estimates the slope angle from the inclination of the tethers. This angle and the weight of the Cliffbot determine the total tension needed to counteract the weight of the Cliffbot. The total needed tension is broken into components for each Anchorbot. The difference between this needed tension and the tension measured at the Cliffbot constitutes an error signal that is provided to the gravity controller. The velocity controller computes the tether speed needed to produce the desired motion of the Cliffbot. Another major consideration in the design and operation of TRESSA is detection of faults. Each robot in the TRESSA system monitors its own performance and the performance of its teammates in order to detect any system faults and prevent unsafe conditions. At startup, communication links are tested and if any robot is not communicating, the system refuses to execute any motion commands. Prior to motion, the Anchorbots attempt to set tensions in the tethers at optimal levels for counteracting the weight of the Cliffbot; if either Anchorbot fails to reach its optimal tension level within a specified time, it sends message to the other robots and the commanded motion is not executed. If any mechanical error (e.g., stalling of a motor) is detected, the affected robot sends a message triggering stoppage of the current motion. Lastly, messages are passed among the robots at each time step (10 Hz) to share sensor information during operations. If messages from any robot cease for more than an allowable time interval, the other robots detect the communication loss and initiate stoppage.

Stroupe, Ashley↗

XML Flight/Ground Data Dictionary Management

A computer program generates Extensible Markup Language (XML) files that effect coupling between the command- and telemetry-handling software running aboard a spacecraft and the corresponding software running in ground support systems. The XML files are produced by use of information from the flight software and from flight-system engineering. The XML files are converted to legacy ground-system data formats for command and telemetry, transformed into Web-based and printed documentation, and used in developing new ground-system data-handling software. Previously, the information about telemetry and command was scattered in various paper documents that were not synchronized. The process of searching and reading the documents was time-consuming and introduced errors. In contrast, the XML files contain all of the information in one place. XML structures can evolve in such a manner as to enable the addition, to the XML files, of the metadata necessary to track the changes and the associated documentation. The use of this software has reduced the extent of manual operations in developing a ground data system, thereby saving considerable time and removing errors that previously arose in the translation and transcription of software information from the flight to the ground system.

Wright, Jesse↗

Adaptive Planning: Understanding Organizational Workload to Capability/ Capacity through Modeling and Simulation

In August 2003, the Secretary of Defense (SECDEF) established the Adaptive Planning (AP) initiative [1] with an objective of reducing the time necessary to develop and revise Combatant Commander (COCOM) contingency plans and increase SECDEF plan visibility. In addition to reducing the traditional plan development timeline from twenty-four months to less than twelve months (with a goal of six months)[2], AP increased plan visibility to Department of Defense (DoD) leadership through In-Progress Reviews (IPRs). The IPR process, as well as the increased number of campaign and contingency plans COCOMs had to develop, increased the workload while the number of planners remained fixed. Several efforts from collaborative planning tools to streamlined processes were initiated to compensate for the increased workload enabling COCOMS to better meet shorter planning timelines. This paper examines the Joint Strategic Capabilities Plan (JSCP) directed contingency planning and staffing requirements assigned to a combatant commander staff through the lens of modeling and simulation. The dynamics of developing a COCOM plan are captured with an ExtendSim [3] simulation. The resulting analysis provides a quantifiable means by which to measure a combatant commander staffs workload associated with development and staffing JSCP [4] directed contingency plans with COCOM capability/capacity. Modeling and simulation bring significant opportunities in measuring the sensitivity of key variables in the assessment of workload to capability/capacity analysis. Gaining an understanding of the relationship between plan complexity, number of plans, planning processes, and number of planners with time required for plan development provides valuable information to DoD leadership. Through modeling and simulation AP leadership can gain greater insight in making key decisions on knowing where to best allocate scarce resources in an effort to meet DoD planning objectives.

Hase, Chris↗

Use of Dynamic Models and Operational Architecture to Solve Complex Navy Challenges

The United States Navy established 8 Maritime Operations Centers (MOC) to enhance the command and control of forces at the operational level of warfare. Each MOC is a headquarters manned by qualified joint operational-level staffs, and enabled by globally interoperable C41 systems. To assess and refine MOC staffing, equipment, and schedules, a dynamic software model was developed. The model leverages pre-existing operational process architecture, joint military task lists that define activities and their precedence relations, as well as Navy documents that specify manning and roles per activity. The software model serves as a "computational wind-tunnel" in which to test a MOC on a mission, and to refine its structure, staffing, processes, and schedules. More generally, the model supports resource allocation decisions concerning Doctrine, Organization, Training, Material, Leadership, Personnel and Facilities (DOTMLPF) at MOCs around the world. A rapid prototype effort efficiently produced this software in less than five months, using an integrated process team consisting of MOC military and civilian staff, modeling experts, and software developers. The work reported here was conducted for Commander, United States Fleet Forces Command in Norfolk, Virginia, code N5-0LW (Operational Level of War) that facilitates the identification, consolidation, and prioritization of MOC capabilities requirements, and implementation and delivery of MOC solutions.

Grande, Darby↗

Automated Activation and Deactivation of a System Under Test

The MPLM Automated Activation/Deactivation application (MPLM means Multi-Purpose Logistic Module) was created with a three-fold purpose in mind: 1. To reduce the possibility of human error in issuing commands to, or interpreting telemetry from, the MPLM power, computer, and environmental control systems; 2. To reduce the amount of test time required for the repetitive activation/deactivation processes; and 3. To reduce the number of on-console personnel required for activation/ deactivation. All of these have been demonstrated with the release of the software. While some degree of automated end-item commanding had previously been performed for space-station hardware in the test environment, none approached the functionality and flexibility of this application. For MPLM activation, it provides mouse-click selection of the hardware complement to be activated, activates the desired hardware and verifies proper feedbacks, and alerts the user when telemetry indicates an error condition or manual intervention is required. For MPLM deactivation, the product senses which end items are active and deactivates them in the proper sequence. For historical purposes, an on-line log is maintained of commands issued and telemetry points monitored. The benefits of the MPLM Automated Activation/ Deactivation application were demonstrated with its first use in December 2002, when it flawlessly performed MPLM activation in 8 minutes (versus as much as 2.4 hours for previous manual activations), and performed MPLM deactivation in 3 minutes (versus 66 minutes for previous manual deactivations). The number of test team members required has dropped from eight to four, and in actuality the software can be operated by a sole (knowledgeable) system engineer.

Poff, Mark A.↗

Stability Properties and Cross Coupling Performance of the Control Allocation Scheme CAPIO

This paper presents a stability analysis and an application of a recently developed Control Allocator for recovery from Pilot Induced Oscillations (CAPIO). When actuators are rate-saturated due to either aggressive pilot commands, high gain ight control systems or some anomaly in the system, the effective delay in the control loop may increase. This effective delay increase manifests itself as a phase shift between the commanded and actual system signals and can instigate Pilot induced Oscillations (PIO). CAPIO reduces the e ective time delay by minimizing the phase shift between the commanded and the actual attitude accelerations. We present a stability analysis of CAPIO for a scalar system. In addition, we present simulation results for aircraft with cross-coupling which demonstrates the potential of CAPIO serving as an effective PIO handler in adverse conditions.

Yildiz, Yildiray↗

A Control Allocation Technique to Recover From Pilot-Induced Oscillations (CAPIO) Due to Actuator Rate Limiting

This paper proposes a control allocation technique that can help pilots recover from pilot induced oscillations (PIO). When actuators are rate-saturated due to aggressive pilot commands, high gain flight control systems or some anomaly in the system, the effective delay in the control loop may increase depending on the nature of the cause. This effective delay increase manifests itself as a phase shift between the commanded and actual system signals and can instigate PIOs. The proposed control allocator reduces the effective time delay by minimizing the phase shift between the commanded and the actual attitude accelerations. Simulation results are reported, which demonstrate phase shift minimization and recovery from PIOs. Conversion of the objective function to be minimized and constraints to a form that is suitable for implementation is given.

Yildiz, Yildiray↗

Improved Lunar Lander Handling Qualities Through Control Response Type and Display Enhancements

A piloted simulation that studied the handling qualities for a precision lunar landing task from final approach to touchdown is presented. A vehicle model based on NASA's Altair Lunar Lander was used to explore the design space around the nominal vehicle configuration to determine which combination of factors provides satisfactory pilot-vehicle performance and workload; details of the control and propulsion systems not available for that vehicle were derived from Apollo Lunar Module data. The experiment was conducted on a large motion base simulator. Eight Space Shuttle and Apollo pilot astronauts and three NASA test pilots served as evaluation pilots, providing Cooper-Harper ratings, Task Load Index ratings and qualitative comments. Each pilot flew seven combinations of control response types and three sets of displays, including two varieties of guidance and a nonguided approach. The response types included Rate Command with Attitude Hold, which was used in the original Apollo Moon landings, a Velocity Increment Command response type designed for up-and-away flight, three response types designed specifically for the vertical descent portion of the trajectory, and combinations of these. It was found that Velocity Increment Command significantly improved handling qualities when compared with the baseline Apollo design, receiving predominantly Level 1 ratings. This response type could be flown with or without explicit guidance cues, something that was very difficult with the baseline design, and resulted in approximately equivalent touchdown accuracies and propellant burn as the baseline response type. The response types designed to be used exclusively in the vertical descent portion of the trajectory did not improve handling qualities.

Mueller, Eric Richard↗

Verification of the Solar Dynamics Observatory High Gain Antenna Pointing Algorithm Using Flight Data

The Solar Dynamics Observatory (SDO) is a NASA spacecraft designed to study the Sun. It was launched on February 11, 2010 into a geosynchronous orbit, and uses a suite of attitude sensors and actuators to finely point the spacecraft at the Sun. SDO has three science instruments: the Atmospheric Imaging Assembly (AIA), the Helioseismic and Magnetic Imager (HMI), and the Extreme Ultraviolet Variability Experiment (EVE). SDO uses two High Gain Antennas (HGAs) to send science data to a dedicated ground station in White Sands, New Mexico. In order to meet the science data capture budget, the HGAs must be able to transmit data to the ground for a very large percentage of the time. Each HGA is a dual-axis antenna driven by stepper motors. Both antennas transmit data at all times, but only a single antenna is required in order to meet the transmission rate requirement. For portions of the year, one antenna or the other has an unobstructed view of the White Sands ground station. During other periods, however, the view from both antennas to the Earth is blocked for different portions of the day. During these times of blockage, the two HGAs take turns pointing to White Sands, with the other antenna pointing out to space. The HGAs handover White Sands transmission responsibilities to the unblocked antenna. There are two handover seasons per year, each lasting about 72 days, where the antennas hand off control every twelve hours. The non-tracking antenna slews back to the ground station by following a ground commanded trajectory and arrives approximately 5 minutes before the formerly tracking antenna slews away to point out into space. The SDO Attitude Control System (ACS) runs at 5 Hz, and the HGA Gimbal Control Electronics (GCE) run at 200 Hz. There are 40 opportunities for the gimbals to step each ACS cycle, with a hardware limitation of no more than one step every three GCE cycles. The ACS calculates the desired gimbal motion for tracking the ground station or for slewing, and sends the command to the GCE at 5 Hz. This command contains the number of gimbals steps for that ACS cycle, the direction of motion, the spacing of the steps, and the delay before taking the first step. The AIA and HMI instruments are sensitive to spacecraft jitter. Pre-flight analysis showed that jitter from the motion of the HGAs was a cause of concern. Three jitter mitigation techniques were developed to overcome the effects of jitter from different sources. The first method is the random step delay, which avoids gimbal steps hitting a cadence on a jitter-critical mode by pseudo-randomly delaying the first gimbal step in an ACS cycle. The second method of jitter mitigation is stagger stepping, which forbids the two antennas from taking steps during the same ACS cycle in order to avoid constructively adding jitter from two antennas. The third method is the inclusion of an instrument No Step Request (NSR), which allows the instruments to request a stoppage in gimbal stepping during the times when they are taking images. During the commissioning phase of the mission, a jitter test was performed onboard the spacecraft. Various sources of jitter, such as the reaction wheels, the High Gain Antenna motors, and the motion of the instrument filter wheels, were examined to determine the level of their effect on the instruments. During the HGA portion of the test, the jitter amplitudes from the single step of a gimbal were examined, as well as the amplitudes due to the execution of various gimbal rates. These jitter levels are compared with the gimbal jitter allocations for each instrument. Additionally, the jitter test provided insight into a readback delay that exists with the GCE. Pre-flight analysis suggested that gimbal steps scheduled to occur during the later portion of an ACS cycle would not be read during that cycle, resulting in a delay in the telemetered current gimbal position. Flight data from the jitter test confirmed this expectation. Analysis is presentehat shows the readback delay does not have a negative impact on gimbal control. The decision was made to consider implementing two of the jitter mitigation techniques on board the spacecraft: stagger stepping and the NSR. Flight data from two sets of handovers, one set without jitter mitigation and the other with mitigation enabled, were examined. The trajectory of the predicted handover was compared with the measured trajectory for the two cases, showing that tracking was not negatively impacted with the addition of the jitter mitigation techniques. Additionally, the individual gimbal steps were examined, and it was confirmed that the stagger stepping and NSRs worked as designed. An Image Quality Test was performed to determine the amount of cumulative jitter from the reaction wheels, HGAs, and instruments during various combinations of typical operations. In this paper, the flight results are examined from a test where the HGAs are following the path of a nominal handover with stagger stepping on and HMI NSRs enabled. In this case, the reaction wheels are moving at low speed and the instruments are taking pictures in their standard sequence. The flight data shows the level of jitter that the instruments see when their shutters are open. The HGA-induced jitter is well within the jitter requirement when the stagger step and NSR mitigation options are enabled. The SDO HGA pointing algorithm was designed to achieve nominal antenna pointing at the ground station, perform slews during handover season, and provide three HGA-induced jitter mitigation options without compromising pointing objectives. During the commissioning phase, flight data sets were collected to verify the HGA pointing algorithm and demonstrate its jitter mitigation capabilities.

Bourkland, Kristin L.↗

A Framework for Optimal Control Allocation with Structural Load Constraints

Conventional aircraft generally employ mixing algorithms or lookup tables to determine control surface deflections needed to achieve moments commanded by the flight control system. Control allocation is the problem of converting desired moments into control effector commands. Next generation aircraft may have many multipurpose, redundant control surfaces, adding considerable complexity to the control allocation problem. These issues can be addressed with optimal control allocation. Most optimal control allocation algorithms have control surface position and rate constraints. However, these constraints are insufficient to ensure that the aircraft's structural load limits will not be exceeded by commanded surface deflections. In this paper, a framework is proposed to enable a flight control system with optimal control allocation to incorporate real-time structural load feedback and structural load constraints. A proof of concept simulation that demonstrates the framework in a simulation of a generic transport aircraft is presented.

Frost, Susan A.↗

X-Band Acquisition Aid Software

The X-band Acquisition Aid (AAP) software is a low-cost acquisition aid for the Deep Space Network (DSN) antennas, and is used while acquiring a spacecraft shortly after it has launched. When enabled, the acquisition aid provides corrections to the antenna-predicted trajectory of the spacecraft to compensate for the variations that occur during the actual launch. The AAP software also provides the corrections to the antenna-predicted trajectory to the navigation team that uses the corrections to refine their model of the spacecraft in order to produce improved antenna-predicted trajectories for each spacecraft that passes over each complex. The software provides an automated Acquisition Aid receiver calibration, and provides graphical displays to the operator and remote viewers via an Ethernet connection. It has a Web server, and the remote workstations use the Firefox browser to view the displays. At any given time, only one operator can control any particular display in order to avoid conflicting commands from more than one control point. The configuration and control is accomplished solely via the graphical displays. The operator does not have to remember any commands. Only a few configuration parameters need to be changed, and can be saved to the appropriate spacecraft-dependent configuration file on the AAP s hard disk. AAP automates the calibration sequence by first commanding the antenna to the correct position, starting the receiver calibration sequence, and then providing the operator with the option of accepting or rejecting the new calibration parameters. If accepted, the new parameters are stored in the appropriate spacecraft-dependent configuration file. The calibration can be performed on the Sun, greatly expanding the window of opportunity for calibration. The spacecraft traditionally used for calibration is in view typically twice per day, and only for about ten minutes each pass.

Britcliffe, Michael J.↗

Sensitivity Analysis of Linear Programming and Quadratic Programming Algorithms for Control Allocation

The Next Generation (NextGen) transport aircraft configurations being investigated as part of the NASA Aeronautics Subsonic Fixed Wing Project have more control surfaces, or control effectors, than existing transport aircraft configurations. Conventional flight control is achieved through two symmetric elevators, two antisymmetric ailerons, and a rudder. The five effectors, reduced to three command variables, produce moments along the three main axes of the aircraft and enable the pilot to control the attitude and flight path of the aircraft. The NextGen aircraft will have additional redundant control effectors to control the three moments, creating a situation where the aircraft is over-actuated and where a simple relationship does not exist anymore between the required effector deflections and the desired moments. NextGen flight controllers will incorporate control allocation algorithms to determine the optimal effector commands and attain the desired moments, taking into account the effector limits. Approaches to solving the problem using linear programming and quadratic programming algorithms have been proposed and tested. It is of great interest to understand their relative advantages and disadvantages and how design parameters may affect their properties. In this paper, we investigate the sensitivity of the effector commands with respect to the desired moments and show on some examples that the solutions provided using the l2 norm of quadratic programming are less sensitive than those using the l1 norm of linear programming.

Frost, Susan A.↗

Reconfigurable Software for Controlling Formation Flying

Software for a system to control the trajectories of multiple spacecraft flying in formation is being developed to reflect underlying concepts of (1) a decentralized approach to guidance and control and (2) reconfigurability of the control system, including reconfigurability of the software and of control laws. The software is organized as a modular network of software tasks. The computational load for both determining relative trajectories and planning maneuvers is shared equally among all spacecraft in a cluster. The flexibility and robustness of the software are apparent in the fact that tasks can be added, removed, or replaced during flight. In a computational simulation of a representative formation-flying scenario, it was demonstrated that the following are among the services performed by the software: Uploading of commands from a ground station and distribution of the commands among the spacecraft, Autonomous initiation and reconfiguration of formations, Autonomous formation of teams through negotiations among the spacecraft, Working out details of high-level commands (e.g., shapes and sizes of geometrically complex formations), Implementation of a distributed guidance law providing autonomous optimization and assignment of target states, and Implementation of a decentralized, fuel-optimal, impulsive control law for planning maneuvers.

Mueller, Joseph B.↗