Search NASA⌕ Search

SEARCH · Search NASA

Results for “COMMAND SYSTEM”

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 685 records · Page 38

Spacelab 2 infrared telescope cryogenic system

The paper discusses the development of a cryogenic helium system to provide cooling to a scanning infrared telescope for the Spacelab 2 mission. The infrared optical/detector system and related electronics are being developed by the Smithsonian Astrophysical Observatory and the University of Arizona. A superfluid helium dewar and porous plug phase separator permit gas cooling of the infrared focal plane assembly to about 2.5 K, and of the two telescope sections to 8 K and 60 K. The design of the cryogenic system,including a commandable vacuum cover, and the prelaunch liquid helium servicing and maintenance approach were discussed. It is concluded that the system will satisfy the Infrared Telescope requirements, and the superfluid helium system shall be capable of satisfying cryogenic helium cooled requirements for the next several years.

Urban, E. W.↗

Smart command recognizer (SCR) - For development, test, and implementation of speech commands

The SCR, a rapid prototyping system for the development, testing, and implementation of speech commands in a flight simulator or test aircraft, is described. A single unit performs all functions needed during these three phases of system development, while the use of common software and speech command data structure files greatly reduces the preparation time for successive development phases. As a smart peripheral to a simulation or flight host computer, the SCR interprets the pilot's spoken input and passes command codes to the simulation or flight computer.

Simpson, Carol A.↗

AIROscope: Ames infrared balloon-borne telescope

A balloon-borne telescope system designed for astronomical observations at infrared wavelengths is discussed. The telescope is gyro-stabilized with updated pointing information derived from television, star tracker, or ground commands. The television system furnishes both course and fine acquisition after initial orientation using a pair of fluxgate servo compasses. Command and control is by a UHF link with 256 commands available. Scientific and engineering data are telemetered to the ground station via narrow band F.M. in the L band. The ground station displays all scientific, engineering and status information during the flights and records the command and telemetry digital bit stream for detailed analysis. The AIROscope telescope has a 28-inch diameter primary mirror and Dall-Kirkham optics. The beam is modulated by oscillating a secondary mirror at 11 or 25 Hz with provision for left or right beam fixed positions by command.

Koontz, O. L.↗

Configurable Multi-Purpose Processor

Advancements in technology have allowed the miniaturization of systems used in aerospace vehicles. This technology is driven by the need for next-generation systems that provide reliable, responsive, and cost-effective range operations while providing increased capabilities such as simultaneous mission support, increased launch trajectories, improved launch, and landing opportunities, etc. Leveraging the newest technologies, the command and telemetry processor (CTP) concept provides for a compact, flexible, and integrated solution for flight command and telemetry systems and range systems. The CTP is a relatively small circuit board that serves as a processing platform for high dynamic, high vibration environments. The CTP can be reconfigured and reprogrammed, allowing it to be adapted for many different applications. The design is centered around a configurable field-programmable gate array (FPGA) device that contains numerous logic cells that can be used to implement traditional integrated circuits. The FPGA contains two PowerPC processors running the Vx-Works real-time operating system and are used to execute software programs specific to each application. The CTP was designed and developed specifically to provide telemetry functions; namely, the command processing, telemetry processing, and GPS metric tracking of a flight vehicle. However, it can be used as a general-purpose processor board to perform numerous functions implemented in either hardware or software using the FPGA s processors and/or logic cells. Functionally, the CTP was designed for range safety applications where it would ultimately become part of a vehicle s flight termination system. Consequently, the major functions of the CTP are to perform the forward link command processing, GPS metric tracking, return link telemetry data processing, error detection and correction, data encryption/ decryption, and initiate flight termination action commands. Also, the CTP had to be designed to survive and operate in a launch environment. Additionally, the CTP was designed to interface with the WFF (Wallops Flight Facility) custom-designed transceiver board which is used in the Low Cost TDRSS Transceiver (LCT2) also developed by WFF. The LCT2 s transceiver board demodulates commands received from the ground via the forward link and sends them to the CTP, where they are processed. The CTP inputs and processes data from the inertial measurement unit (IMU) and the GPS receiver board, generates status data, and then sends the data to the transceiver board where it is modulated and sent to the ground via the return link. Overall, the CTP has combined processing with the ability to interface to a GPS receiver, an IMU, and a pulse code modulation (PCM) communication link, while providing the capability to support common interfaces including Ethernet and serial interfaces boarding a relatively small-sized, lightweight package.

Valencia, J. Emilio↗

Range and mission scheduling automation using combined AI and operations research techniques

Ground-based systems for Satellite Command, Control, and Communications (C3) operations require a method for planning, scheduling and assigning the range resources such as: antenna systems scattered around the world, communications systems, and personnel. The method must accommodate user priorities, last minute changes, maintenance requirements, and exceptions from nominal requirements. Described are computer programs which solve 24 hour scheduling problems, using heuristic algorithms and a real time interactive scheduling process.

Arbabi, Mansur↗

Evaluation of Open-Source Hard Real Time Software Packages

Reliable software is, at times, hard to find. No piece of software can be guaranteed to work in every situation that may arise during its use here at Glenn Research Center or in space. The job of the Software Assurance (SA) group in the Risk Management Office is to rigorously test the software in an effort to ensure it matches the contract specifications. In some cases the SA team also researches new alternatives for selected software packages. This testing and research is an integral part of the department of Safety and Mission Assurance. Real Time operation in reference to a computer system is a particular style of handing the timing and manner with which inputs and outputs are handled. A real time system executes these commands and appropriate processing within a defined timing constraint. Within this definition there are two other classifications of real time systems: hard and soft. A soft real time system is one in which if the particular timing constraints are not rigidly met there will be no critical results. On the other hand, a hard real time system is one in which if the timing constraints are not met the results could be catastrophic. An example of a soft real time system is a DVD decoder. If the particular piece of data from the input is not decoded and displayed to the screen at exactly the correct moment nothing critical will become of it, the user may not even notice it. However, a hard real time system is needed to control the timing of fuel injections or steering on the Space Shuttle; a delay of even a fraction of a second could be catastrophic in such a complex system. The current real time system employed by most NASA projects is Wind River's VxWorks operating system. This is a proprietary operating system that can be configured to work with many of NASA s needs and it provides very accurate and reliable hard real time performance. The down side is that since it is a proprietary operating system it is also costly to implement. The prospect of replacing this somewhat costly implementation is the focus of one of the SA group s current research projects. The explosion of open source software in the last ten years has led to the development of a multitude of software solutions which were once only produced by major corporations. The benefits of these open projects include faster release and bug patching cycles as well as inexpensive if not free software solutions. The main packages for hard real time solutions under Linux are Real Time Application Interface (RTAI) and two varieties of Real Time Linux (RTL), RTLFree and RTLPro. During my time here at NASA I have been testing various hard real time solutions operating as layers on the Linux Operating System. All testing is being run on an Intel SBC 2590 which is a common embedded hardware platform. The test plan was provided to me by the Software Assurance group at the start of my internship and my job has been to test the systems by developing and executing the test cases on the hardware. These tests are constructed so that the Software Assurance group can get hard test data for a comparison between the open source and proprietary implementations of hard real time solutions.

Mattei, Nicholas S.↗

Command and data handling of science signals on Spacelab

The Orbiter Avionics and the Spacelab Command and Data Management System (CDMS) combine to provide a relatively complete command, control, and data handling service to the instrument complement during a Shuttle Sortie Mission. The Spacelab CDMS services the instruments and the Orbiter in turn services the Spacelab. The CDMS computer system includes three computers, two I/O units, a mass memory, and a variable number of remote acquisition units. Attention is given to the CDMS high rate multiplexer, CDMS tape recorders, closed circuit television for the visual monitoring of payload bay and cabin area activities, methods of science data acquisition, questions of transmission and recording, CDMS experiment computer usage, and experiment electronics.

Mccain, H. G.↗

SRMS Assisted Docking and Undocking for the Orbiter Repair Maneuver

As part of the Orbiter Repair Maneuver (ORM) planned for Return to Flight (RTF) operations, the Shuttle Remote Manipulator System (SRMS) must undock the Orbiter, maneuver it through a complex trajectory at extremely low rates, present it to an EVA crewman at the end of the Space Station Remote Manipulator System to perform the Thermal Protection System (TPS) repair, and then retrace back through the trajectory to dock the Orbiter with the Orbiter Docking System (ODS). The initial and final segments of this operation involve the interaction between the SRMS, ISS, Orbiter and ODS. Previously, a technique entitled "SRMS assisted docking" for installation of a payload to the ODS had been developed and was utilized for the Russian provided Docking Module on STS-74 during Shuttle-Mir missions and both the Node 1 and FGB elements on STS-88/Flight 2A. This procedure consisted of the SRMS grappling the respective payload, maneuvering it to a pre-install position inches above the ODS Androgynous Peripheral Attachment System (APAS) ring, commanding the SRMS into Test mode (which allows brakes-off motion of the joints), and then down-firing Primary Reaction Control System (PRCS) jets in order to effect a capture of the APAS latches. Once a successful capture had been achieved, then the AP AS was operated through its nominal retraction sequence to complete the mating sequence. While this technique can once again be used for the tail end docking portion of the ORM, the initial undocking of the orbiter and ISS vehicles with the assistance of the SRMS has yet to be attempted on orbit. The objective here is to determine the most efficient means to separate or extract the vehicles. Two techniques were analyzed in support of RTF: (1) the 'nominal' demating from the mated interface, and (2) the SRMS performing the operation (either in an active or passive fashion). In the first operation, the demating process would replicate standard undocking operations, with the exception that the SRMS is allowed to arrest the resulting motion. The second operation would be to extend the APAS ring to a ready to dock position, open the capture latches, and then detach the vehicles using the SRMS either actively or passively. In the active case, the APAS ring is extended and latched, and the SRMS is commanded to pull the two interfaces apart (assuming that the effective pull force of the SRMS can overcome the spec values of the combined latch resistance). In the passive case, the SRMS brakes are engaged and the AP AS mechanism is commanded to retract, pulling the two interfaces apart. Since the emphasis of both STS-74 and STS-88 had solely been on the installation operation, as opposed to the separation operation, two new models required development and incorporation within simulation tools designed to analyze those scenarios. These enhancements included: (1) a detailed demating dynamics model to characterize the pusher spring characteristics during undocking, and (2) contact and mechanical system modeling of the back side of the latches to represent unlatching dynamics. This paper first provides an overview of the Monte-Carlo screening analysis for the installation (both nominal and contingency), including the variation of separation distance, misalignment conditions, SRMS joint/brake parameter characteristics, and PRCS jet combinations and corresponding thrust durations. The resulting 'optimum' solution is presented based on trade studies between predicted capture success and integrated system loads. This paper then discusses the upgrades to the APAS math model associated with the new SRMS assisted undocking technique and reviews simulation results for various options investigated for either the active and passive separation of the ISS from the Orbiter.

Space Station Remote Manipulator System↗

Situation Awareness of Onboard System Autonomy

We have developed intelligent agent software for onboard system autonomy. Our approach is to provide control agents that automate crew and vehicle systems, and operations assistants that aid humans in working with these autonomous systems. We use the 3 Tier control architecture to develop the control agent software that automates system reconfiguration and routine fault management. We use the Distributed Collaboration and Interaction (DCI) System to develop the operations assistants that provide human services, including situation summarization, event notification, activity management, and support for manual commanding of autonomous system. In this paper we describe how the operations assistants aid situation awareness of the autonomous control agents. We also describe our evaluation of the DCI System to support control engineers during a ground test at Johnson Space Center (JSC) of the Post Processing System (PPS) for regenerative water recovery.

Schreckenghost, Debra↗

Program Assists Satellite Designers

Annapolis, Maryland-based designAmerica Inc., a small aerospace company specializing in the development and delivery of ground control systems for satellites and instrumentation, assisted Goddard Space Flight Center in the development of the ASIST software, a real-time command and control system for spacecraft development, integration, and operations. It was designed to be fully functional across a broad spectrum of satellites and instrumentation, while also being user friendly. The company now has rights to commercial use of the program and is offering it to government and industry satellite designers.

Source record↗

Unit Testing and Remote Display Development

The Kennedy Space Center is currently undergoing an extremely interesting transitional phase. The final Space Shuttle mission, STS-135, was completed in July of 2011. NASA is now approaching a new era of space exploration. The development of the Orion Multi- Purpose Crew Vehicle (MPCV) and the Space Launch System (SLS) launch vehicle that will launch the Orion are currently in progress. An important part of this transition involves replacing the Launch Processing System (LPS) which was previously used to process and launch Space Shuttles and their associated hardware. NASA is creating the Spaceport Command and Control System (SCCS) to replace the LPS. The SCCS will be much simpler to maintain and improve during the lifetime of the spaceflight program that it will support. The Launch Control System (LCS) is a portion of the SCCS that will be responsible for launching the rockets and spacecraft. The Integrated Launch Operations Applications (ILOA) group of SCCS is responsible for creating displays and scripts, both remote and local, that will be used to monitor and control hardware and systems needed to launch a spacecraft. It is crucial that the software contained within be thoroughly tested to ensure that it functions as intended. Unit tests must be written in Application Control Language (ACL), the scripting language used by LCS. These unit tests must ensure complete code coverage to safely guarantee there are no bugs or any kind of issue with the software.

LCS↗

Investigation of techniques for improving Saturn 5 RF tracking and ranging systems

Results of theoretical analyses of 12 problems are presented and comparisons of theoretical and experimental results are given. The investigations covered were: (1) techniques for improving the Saturn radar altimeter, (2) performance of the phase lock loop of the offset Doppler transponder, (3) signal processing equipment design for an orbital altitude radar return experiment, (4) spectral studies of signals present in the command and communication system (CCS) up-link transmitter, (5) intermodulation in the CCS down-link data demodulators, (6) error rate performance of the CCS transponder command demodulator, (7) flame attenuation effects on telemetry transmissions during Saturn launches, (8) design of a digital television system which converts a standard monochrome picture to a slow-scan picture, (9) methods of obtaining an additional CCS 72-kilobit/sec telemetry channel, (10) computation of the CCS S-band down-link spectra, (11) modeling of portions of the communications systems, and (12) modeling of a telemetry transmitter.

Walsh, J. R., Jr.↗

Experimental object-level strategic control with cooperating manipulators

This article presents the high-level control module and user interface of the Dynamic and Strategic Control of Cooperating Manipulators (DASCCOM) project at Stanford University's Aerospace Robotics Laboratory. In addition to cooperative dynamic control, DASCCOM incorporates real-time vision-ased feedback, a novel strategic programming technique, and an iconic 'object-only' graphical user interface. By focusing on the vertical integration problem, we are examining not only these subsystems, but also their interfaces and interactions. The control system implements a multilevel hierarchical structure interconnected via a real-time network. At the highest level, a mouse-driven graphical user interface allows an operator to direct the activities of the system conceptually. Strategic command is provided by an event-driven finite state machine. This methodology provides a powerful yet flexible technique for managing concurrent system interactions. The dynamic controller implements object impedance control - an extension of Neville Hogan's impedance control concept to cooperative multiple-arm manipulation of a single object. This article concentrates on user interfacing techniques and strategic programming capabilities. These modules allow the user to directly specify conceptual object relationships. Experimental results are presented, showing the system locating and identifying a moving object, 'catching' it, and performing a simple cooperative assembly. Each of these operations is executed autonomously, with only object-level task-specification direction from a remote operator.

Schneider, Stanley A.↗

Determining Availability Characteristics of DSN Data Systems Using Discrepancy Report Data

A reasonably economical way was developed to determine availability characteristics of Deep Space Network (DSN) data systems, subsystems, and assemblies using the DSN discrepancy report (DR) data base and DSN operating schedule and history data bases. Operating mean time between failures (OMTBF), operating mean time to restore service (OMTTRS), and operating functional availability (OFA) can be computed by year, by system, by subsystem, by assembly, and by station. The effort required to produce the desired reports is described, specific data on the telemetry, command, and tracking systems are presented, and major contributors to system outages are identified. Future improvements in preparing and analyzing DR data are also outlined to enhance their use in correcting conditions that lead to outages.

Ruskin, A. M.↗

Simulation of 4D RNAV in the terminal area

A terminal area control concept based on 4D RNAV (3D plus time) has been developed to take full advantage of STOL aircrafts' unique performance capabilities. The 4D RNAV concept involves an airborne system, a ground system and a protocol for information exchange between aircraft and ground. The function of the airborne system is to synthesize the curved three dimensional (3D) flight path, to predict and control the landing time (4D) and to generate flight director or autopilot commands. The airborne system assumes the ground system will specify the 3D path and assign a conflict-free landing time. A real time simulation of this concept has been developed to evaluate its effectiveness for terminal areas control of STOL aicraft. Key elements of the simulation are a computer graphics traffic display, a scheduling display and a keyboard language for issuing controller commands to simulated aircraft. Initial results and planned experiments are described.

Tobias, L.↗

Robotics

Lunar robotic functions include: 1. Transport of crew and payloads on the surface of the moon; 2. Offloading payloads from a lunar lander; 3. Handling the deployment of surface systems; with 4. Human commanding of these functions from inside a lunar vehicle, habitat, or extravehicular (space walk), with Earth-based supervision. The systems that will perform these functions may not look like robots from science fiction. In fact, robotic functions may be automated trucks, cranes and winches. Use of this equipment prior to the crew s arrival or in the potentially long periods without crews on the surface, will require that these systems be computer controlled machines. The public release of NASA's Exploration plans at the 2nd Space Exploration Conference (Houston, December 2006) included a lunar outpost with as many as four unique mobility chassis designs. The sequence of lander offloading tasks involved as many as ten payloads, each with a unique set of geometry, mass and interface requirements. This plan was refined during a second phase study concluded in August 2007. Among the many improvements to the exploration plan were a reduction in the number of unique mobility chassis designs and a reduction in unique payload specifications. As the lunar surface system payloads have matured, so have the mobility and offloading functional requirements. While the architecture work continues, the community can expect to see functional requirements in the areas of surface mobility, surface handling, and human-systems interaction as follows: Surface Mobility 1. Transport crew on the lunar surface, accelerating construction tasks, expanding the crew s sphere of influence for scientific exploration, and providing a rapid return to an ascent module in an emergency. The crew transport can be with an un-pressurized rover, a small pressurized rover, or a larger mobile habitat. 2. Transport Extra-Vehicular Activity (EVA) equipment and construction payloads. 3. Transport habitats and power modules over long distances, pre-positioning them for the arrival of crew on a subsequent lander. Surface Handling 1. Offload surface system payloads from the lander, breaking launch restraints and power/data connections. Payloads may be offloaded to a wheeled vehicle for transport. 2. Deploy payloads from a wheeled vehicle at a field site, placing the payloads in their final use site on the ground or mating them with existing surface systems. 3. Support regolith collection, site preparation, berm construction, or other civil engineering tasks using tools and implements attached to rovers. Human-Systems Interaction 1. Provide a safe command and control interface for suited EVA to ride on and drive the vehicles, making sure that the systems are also safe for working near dismounted crew. 2. Provide an effective control system for IV crew to tele-operate vehicles, cranes and other equipment from inside the surface habitats with evolving independence from Earth. .. Provide a supervisory system that allows machines to be commanded from the ground, working across the Earth-Lunar time delays on the order of 5-10 seconds (round trip) to support operations when crew are not resident on the surface. Technology Development Needs 1. Surface vehicles that can dock, align and mate with outpost equipment such as landers, habitats and fluid/power interfaces. 2. Long life motors, drive trains, seals, motor electronics, sensors, processors, cable harnesses, and dash board displays. 3. Active suspension control, localization, high speed obstacle avoidance, and safety systems for operating near dismounted crew. 4. High specific energy and specific power batteries that are safe, rechargeable, and long lived.

Ambrose, Robert O.↗

A smart telerobotic system driven by monocular vision

A robotic system that accepts autonomously generated motion and control commands is described. The system provides images from the monocular vision of a camera mounted on a robot's end effector, eliminating the need for traditional guidance targets that must be predetermined and specifically identified. The telerobotic vision system presents different views of the targeted object relative to the camera, based on a single camera image and knowledge of the target's solid geometry.

Defigueiredo, R. J. P.↗

SMC Message Browser Projects

I work directly with the System Monitoring and Control (SMC) software engineers who develop, test and release custom and commercial software in support of the Kennedy Space Center Spaceport Command and Control System. (SCCS). SMC uses Commercial Off-The-Shelf (COTS) Enterprise Management Systems (EMS) software which provides a centralized subsystem for configuring, monitoring, and controlling SCCS hardware and software used in the Control Rooms. There are multiple projects being worked on using the COTS EMS software. I am currently working with the HP Operations Manager for UNIX (OMU) software which allows Master Console Operators (MCO) to access, view and interpret messages regarding the status of the SCCS hardware and software. The OMU message browser gets cluttered with messages which can make it difficult for the MCO to manage. My main project involves determining ways to reduce the number of messages being displayed in the OMU message browser. I plan to accomplish this task in two different ways: (1) by correlating multiple messages into one single message being displayed and (2) to create policies that will determine the significance of each message and whether or not it needs to be displayed to the MCO. The core idea is to lessen the number of messages being sent to the OMU message browser so the MCO can more effectively use it.

OMU↗