Search NASA⌕ Search

SEARCH · Search NASA

Results for “virtual control interface”

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 145 records · Page 8

APOLLO: a facility-scale differentiable virtual accelerator for Fermilab

As the design complexity of modern accelerators grows, there is more interest in using advanced simulations that have fast execution time or yield additional insights like gradients. The FAST/IOTA facility has been working on implementing and experimentally validating an end-to-end digital twin that is both fast and gradient-aware, allowing for rapid prototyping of new software and experiments with minimal beam time costs. Our framework integrates physics and ML codes for linac and ring simulation through a set of generic interfaces between surrogate and physics-based sections. To reproduce device inputs and outputs, system state is exposed as a deterministic discrete event simulator. Because Fermilab is undergoing control system transition, both EPICS and ACNET frontends are supported. Recently, we have begun transitioning to a new community lattice standard, PALS, as well as developing standardized infrastructure for data ingest and normalization to prepare for model calibration during FAST proton injector commissioning. We discuss implementation details as well as challenges, and future plans to extend modelling to main complex proton accelerators like PIPII and Booster.

Kuklev, Nikita [Fermilab]↗

An open control sequence specification to scale building demand flexibility via analytics software

For over two decades, researchers and practitioners have showcased the ability of large commercial buildings to provide grid services by shedding or shifting load. Various utility demand response (DR) and virtual power plant (VPP) programs throughout the United States are presently utilizing these demand-side resources. However, growth of these programs have been limited, in part due to the high cost necessary to integrate the DR control strategies into the building automation system (BAS). Implementing these strategies involves adjusting control sequences, necessitating dozens of hours of customized programming per building, limiting their adoption to large organizations and progressive owners. Recent efforts by researchers and industry have demonstrated the capability of energy management and information systems (EMIS), originally designed for fault detection and diagnostics, to interface with existing BAS and perform supervisory control to optimize building operations. While these approaches are quickly being adopted by industry, demand flexibility (DF) control strategies remain limited in product offerings. One of the challenges is the lack of documented best-practice DF sequences, despite the rich literature on field implementations. This paper develops a new open-specification for a zone-based temperature adjustment shed strategy for commercial building HVAC systems, describing the specification’s implementation in two EMIS tools in both experimental and field settings. Both implementations successfully reduced electric load by at least 40% on average during the called event, while maintaining temperature limits. This study’s detailed process from specification to deployment shows the potential for scalability as well as highlights challenges related to integration with heterogeneous BAS products.

Granderson, Jessica↗

Technology transfer of operator-in-the-loop simulation

The technology developed for operator-in-the-loop simulation in space teleoperation has been applied to Caterpillar's backhoe, wheel loader, and off-highway truck. On an SGI workstation, the simulation integrates computer modeling of kinematics and dynamics, real-time computational and visualization, and an interface with the operator through the operator's console. The console is interfaced with the workstation through an IBM-PC in which the operator's commands were digitized and sent through an RS-232 serial port. The simulation gave visual feedback adequate for the operator in the loop, with the camera's field of vision projected on a large screen in multiple view windows. The view control can emulate either stationary or moving cameras. This simulator created an innovative engineering design environment by integrating computer software and hardware with the human operator's interactions. The backhoe simulation has been adopted by Caterpillar in building a virtual reality tool for backhoe design.

Yae, K. H.↗

The Electron Spectro-Microscopy (ESM) Beamline at NSLS-II

Photoelectron spectroscopy is a primary tool for the study of the electronic structure of materials and the chemical composition of surfaces. High-resolution angle-resolved photoemission spectroscopy (ARPES) has the unique ability to map the energy bands in momentum space. Furthermore, going beyond the single particle picture, the self-energy corrections caused by correlations in solids can be extracted from the analysis of the emission line shape. The current level of refinement, in terms of energy and angular resolution (ΔE < 1 meV, Δθ < 0.1°), makes the technique sensitive to the lowest energy excitations and the dynamics of electrons, which in turn virtually determine all the macroscopic properties of any system and govern the chemical, electrical, magnetic, and physical processes. Similarly important, X-ray photoelectron microscopy (XPEEM), combined with the low-energy electron microscopy (LEEM), is indispensable in probing the complexity of chemical, structural, electronic and magnetic properties of surfaces and shallow interfaces, with the spatial resolution of few tens of nanometer (nm). The Electron-Spectro-Microscopy beamline (ESM) has been recently commissioned at NSLS-II and is now in operation. The primary spectroscopic technique is photoemission, performed over a wide energy range with control of light polarization and in a variety of flux/resolution conditions. The beamline has two experimental end stations that allow to perform ARPES and XPEEM/LEEM, separately. The ARPES end station focuses on high energy-resolution work, with spot-size of a few microns. The XPEEM/LEEM end station is a full-field microscope (XPEEM) operating either with the synchrotron generated X-rays (XPEEM), or with an internal electron gun (LEEM). Spatial resolution is crucial in studies of newly synthesized complex materials since they are often initially available only as small specimens (typically micron size). Furthermore, chemical inhomogeneities on surfaces are often an integral part of surface chemical processes. Finally, the ESM beamline with X-ray spots of few microns is optimized to study the electronic structure of novel materials with microscopy capabilities.

47 OTHER INSTRUMENTATION↗

Deep Space Network Antenna Logic Controller

The Antenna Logic Controller (ALC) software controls and monitors the motion control equipment of the 4,000-metric-ton structure of the Deep Space Network 70-meter antenna. This program coordinates the control of 42 hydraulic pumps, while monitoring several interlocks for personnel and equipment safety. Remote operation of the ALC runs via the Antenna Monitor & Control (AMC) computer, which orchestrates the tracking functions of the entire antenna. This software provides a graphical user interface for local control, monitoring, and identification of faults as well as, at a high level, providing for the digital control of the axis brakes so that the servo of the AMC may control the motion of the antenna. Specific functions of the ALC also include routines for startup in cold weather, controlled shutdown for both normal and fault situations, and pump switching on failure. The increased monitoring, the ability to trend key performance characteristics, the improved fault detection and recovery, the centralization of all control at a single panel, and the simplification of the user interface have all reduced the required workforce to run 70-meter antennas. The ALC also increases the antenna availability by reducing the time required to start up the antenna, to diagnose faults, and by providing additional insight into the performance of key parameters that aid in preventive maintenance to avoid key element failure. The ALC User Display (AUD) is a graphical user interface with hierarchical display structure, which provides high-level status information to the operation of the ALC, as well as detailed information for virtually all aspects of the ALC via drill-down displays. The operational status of an item, be it a function or assembly, is shown in the higher-level display. By pressing the item on the display screen, a new screen opens to show more detail of the function/assembly. Navigation tools and the map button allow immediate access to all screens.

Ahlstrom, Harlow↗

Standardizing UI/UX across accelerator labs

During February 26–28, 2025, the first-ever particle accelerator user interface/user experience (UI/UX) workshop was held at SLAC. Attendees had backgrounds ranging from software development to control systems management and human factors (HF) science. The workshop began with participants discussing the current state of UI/UX procedures and practices at their respective laboratories to share experiences and learn from one another. Additional discussions focused on how to effectively integrate UI/UX best practices into actionable goals for developers, managers, and operators when working on new or existing interfaces. The goal of the working group is to create a website that will guide developers, managers, scientists, and end users at accelerator laboratories in incorporating UI/UX best practices into software development. The working group continues to meet virtually toward this goal, and is planning a second workshop for next year.

Tran, Tiffany [SLAC]↗

Incorporating Speech Recognition into a Natural User Interface

The Augmented/ Virtual Reality (AVR) Lab has been working to study the applicability of recent virtual and augmented reality hardware and software to KSC operations. This includes the Oculus Rift, HTC Vive, Microsoft HoloLens, and Unity game engine. My project in this lab is to integrate voice recognition and voice commands into an easy to modify system that can be added to an existing portion of a Natural User Interface (NUI). A NUI is an intuitive and simple to use interface incorporating visual, touch, and speech recognition. The inclusion of speech recognition capability will allow users to perform actions or make inquiries using only their voice. The simplicity of needing only to speak to control an on-screen object or enact some digital action means that any user can quickly become accustomed to using this system. Multiple programs were tested for use in a speech command and recognition system. Sphinx4 translates speech to text using a Hidden Markov Model (HMM) based Language Model, an Acoustic Model, and a word Dictionary running on Java. PocketSphinx had similar functionality to Sphinx4 but instead ran on C. However, neither of these programs were ideal as building a Java or C wrapper slowed performance. The most ideal speech recognition system tested was the Unity Engine Grammar Recognizer. A Context Free Grammar (CFG) structure is written in an XML file to specify the structure of phrases and words that will be recognized by Unity Grammar Recognizer. Using Speech Recognition Grammar Specification (SRGS) 1.0 makes modifying the recognized combinations of words and phrases very simple and quick to do. With SRGS 1.0, semantic information can also be added to the XML file, which allows for even more control over how spoken words and phrases are interpreted by Unity. Additionally, using a CFG with SRGS 1.0 produces a Finite State Machine (FSM) functionality limiting the potential for incorrectly heard words or phrases. The purpose of my project was to investigate options for a Speech Recognition System. To that end I attempted to integrate Sphinx4 into a user interface. Sphinx4 had great accuracy and is the only free program able to perform offline speech dictation. However it had a limited dictionary of words that could be recognized, single syllable words were almost impossible for it to hear, and since it ran on Java it could not be integrated into the Unity based NUI. PocketSphinx ran much faster than Sphinx4 which would've made it ideal as a plugin to the Unity NUI, unfortunately creating a C# wrapper for the C code made the program unusable with Unity due to the wrapper slowing code execution and class files becoming unreachable. Unity Grammar Recognizer is the ideal speech recognition interface, it is flexible in recognizing multiple variations of the same command. It is also the most accurate program in recognizing speech due to using an XML grammar to specify speech structure instead of relying solely on a Dictionary and Language model. The Unity Grammar Recognizer will be used with the NUI for these reasons as well as being written in C# which further simplifies the incorporation.

Chapa, Nicholas↗

APOLLO: a facility-scale differentiable virtual accelerator at Fermilab FAST/IOTA

As the design complexity of modern accelerators grows, there is more interest in using advanced simulations that have fast execution time or yield additional insights like gradients. The FAST/IOTA facility has been working on implementing and experimentally validating an end-to-end digital twin that is both fast and gradient-aware, allowing for rapid prototyping of new software and experiments with minimal beam time costs. Our framework integrates physics and ML codes for linac and ring simulation through a set of generic interfaces between surrogate and physics-based sections. To reproduce device inputs and outputs, system state is exposed as a deterministic event loop in a specialized discrete event simulator architecture. Because Fermilab is undergoing control system transition, several APIs were implemented as final user interfaces - a fully asynchronous EPICS soft IOC, a gRPC-based Data Pool Manager (DPM), and legacy ACNET protocols. We discuss implementation details as well as challenges handling live data assimilation and future plans to extend modelling to main complex proton accelerators like PIPII and Booster.

Kuklev, Nikita [Fermilab]↗

Virtual Satellite

Virtual Satellite (VirtualSat) is a computer program that creates an environment that facilitates the development, verification, and validation of flight software for a single spacecraft or for multiple spacecraft flying in formation. In this environment, enhanced functionality and autonomy of navigation, guidance, and control systems of a spacecraft are provided by a virtual satellite that is, a computational model that simulates the dynamic behavior of the spacecraft. Within this environment, it is possible to execute any associated software, the development of which could benefit from knowledge of, and possible interaction (typically, exchange of data) with, the virtual satellite. Examples of associated software include programs for simulating spacecraft power and thermal- management systems. This environment is independent of the flight hardware that will eventually host the flight software, making it possible to develop the software simultaneously with, or even before, the hardware is delivered. Optionally, by use of interfaces included in VirtualSat, hardware can be used instead of simulated. The flight software, coded in the C or C++ programming language, is compilable and loadable into VirtualSat without any special modifications. Thus, VirtualSat can serve as a relatively inexpensive software test-bed for development test, integration, and post-launch maintenance of spacecraft flight software.

Hammrs, Stephan R.↗

X-HAB 2020: AR Field Treks Summary and Conclusions

As part of the FY20 X-Hab Challenge, BLiSS sought to create an Augmented Reality (AR) toolkit to help with analog field trek operations under the supervision of the Solar System Exploration Research Virtual Institute (SSERVI). These treks are operational and technical demonstrations at space-like destinations on Earth to test current extra-vehicular activity (EVA) techniques. While BLiSS as an organization has experience studying operational tasks such as this, it has never developed AR software at this scale. For that reason, another team at the University was brought on to work in parallel. The Collaborative Lab for Advancing Work in Space (CLAWS) is a veteran group of the NASA Spacesuit User Interface Technologies for Students (SUITS) challenge in which Hololens displays for astronauts are created within a year. The operational and technological pairing was ideally suited for tackling this problem. The team divided its responsibilities so that BLiSS would handle the research required to shape the project. As this deliverable had an end user, it was decided that interviewing these field geologists and operations specialists would provide the best insight. These interviews paired with literature review would reveal niche applications for AR that remained within feasible bounds. These science-driven EVAs in unknown terrain require more flexible tools than the current generation of EVA assistants. Rather than focus on sequential instructions, there instead needs to be a broad toolkit that's only called upon in specific instances. This AR Toolkit for Lunar Astronauts and Scientists (ATLAS) became the development goal of the project: create a non-intrusive assembly of tools that could be accessed in AR on the field. The current ATLAS design makes use of a geospatially and temporally annotated eld note system called GeoNotes. This allows for data to be collected and coordinated in a way that's synchronized across time, space, and different users. A Mission Control Center (MCC) and Mobile Support Equipment (MSE) were all needed to transport the AR headset into the field with the user. A network infrastructure was designed and set up within the University to enable this functionality. The software is based on a Protocol-Module structure that allows for modular development of each capability. A Protocol Manager coordinates different protocols that make use of modules. Each module tackles a different individual task while the protocol puts each one to use. The protocol manager coordinates when these are called to be used. This software is hosted on a head-mounted display (HMD) with the MCC acting as support from afar. While the software would be unit-tested at each level and each hardware component verified, a final demonstration would serve to prove the system's capabilities: an analog field trek. The team would prepare to support a user in a remote location from the MCC back at the University. A local area near campus would be tested before going out to do sample field geology further away. This unfortunately became impossible with the arrival of COVID-19. Access to all of the facilities to complete the project as planned were shut down. Our team was scattered across the globe and forced to complete the rest virtually. Adjustments were made to produce a small virtual concept in Adobe XD in the meantime. Even digital surveys were created based on the NASA task-load index (TLX) originally intended for testing actual users. The goal shifted towards completing software and getting feedback on the user interfaces (UI) and user experiences (UX). This team has reformed in response to COVID and its focus has shifted to what can be done remotely. There is still an intention to finish the original deliverable described in this report. The work has been expanded beyond the original X-Hab challenge and has instead become its own research e ort to be continued afterwards. This report collects the processes and knowledge gained from a year of studying and working at this problem with two teams. It should preserve it for the time until the world returns to normal and work can resume. CLAWS will be taking over full responsibility from that point forward, eventually surpassing the original needs of the project. While this document captures the work done towards an eventual end, the CLAWS team has written their own proposal alongside it. It outlines a new future for ATLAS beyond X-Hab, BLiSS, and hopefully beyond COVID-19. This project began as a vague goal hoping to place a new technology into the unique setting of exploration science. The project has since comfortably taken root and will hopefully bloom over the next year.

Alex Sena↗

Integration of the Shuttle RMS/CBM Positioning Virtual Environment Simulation

Constructing the International Space Station, or other structures, in space presents a number of problems. In particular, payload restrictions for the Space Shuttle and other launch mechanisms prohibit assembly of large space-based structures on Earth. Instead, a number of smaller modules must be boosted into orbit separately and then assembled to form the final structure. The assembly process is difficult, as docking interfaces such as Common Berthing Mechanisms (CBMS) must be precisely positioned relative to each other to be within the "capture envelope" (approximately +/- 1 inch and +/- 0.3 degrees from the nominal position) and attach properly. In the case of the Space Station, the docking mechanisms are to be positioned robotically by an astronaut using the 55-foot-long Remote Manipulator System (RMS) robot arm. Unfortunately, direct visual or video observation of the placement process is difficult or impossible in many scenarios. One method that has been tested for aligning the CBMs uses a boresighted camera mounted on one CBM to view a standard target on the opposing CBM. While this method might be sufficient to achieve proper positioning with considerable effort, it does not provide a high level of confidence that the mechanisms have been placed within capture range of each other. It also does nothing to address the risk of inadvertent contact between the CBMS, which could result in RMS control software errors. In general, constraining the operator to a single viewpoint with few, if any, depth cues makes the task much more difficult than it would be if the target could be viewed in three-dimensional space from various viewpoints. The actual work area could be viewed by an astronaut during EVA; however, it would be extremely impractical to have an astronaut control the RMS while spacewalking. On the other hand, a view of the RMS and CBMs to be positioned in a virtual environment aboard the Space Shuttle orbiter or Space Station could provide similar benefits more safely and conveniently with little additional cost. In order to render and view the RMS and CBMs in a virtual world, the position and orientation of the end effector in three-dimensional space must be known with a high degree of accuracy. A precision video alignment sensor has been developed which can determine the position and orientation of the controlled element relative to the target CBM within approximately one-sixteenth inch and 0.07 angular degrees. Such a sensor could replace or augment the boresighted camera mentioned above. The computer system used to render the virtual world and the position tracking systems which might be used to monitor the user's movements (in order to adjust the viewpoint in virtual space) are small enough to carry to orbit. Thus, such a system would be feasible for use in constructing structures in space.

Dumas, Joseph D.↗

Gesture-Based Robot Control with Variable Autonomy from the JPL Biosleeve

This paper presents a new gesture-based human interface for natural robot control. Detailed activity of the user's hand and arm is acquired via a novel device, called the BioSleeve, which packages dry-contact surface electromyography (EMG) and an inertial measurement unit (IMU) into a sleeve worn on the forearm. The BioSleeve's accompanying algorithms can reliably decode as many as sixteen discrete hand gestures and estimate the continuous orientation of the forearm. These gestures and positions are mapped to robot commands that, to varying degrees, integrate with the robot's perception of its environment and its ability to complete tasks autonomously. This flexible approach enables, for example, supervisory point-to-goal commands, virtual joystick for guarded teleoperation, and high degree of freedom mimicked manipulation, all from a single device. The BioSleeve is meant for portable field use; unlike other gesture recognition systems, use of the BioSleeve for robot control is invariant to lighting conditions, occlusions, and the human-robot spatial relationship and does not encumber the user's hands. The BioSleeve control approach has been implemented on three robot types, and we present proof-of-principle demonstrations with mobile ground robots, manipulation robots, and prosthetic hands.

BioSleeve↗

Interface for Physics Simulation Engines

DSS-Prototyper is an open-source, realtime 3D virtual environment software that supports design simulation for the new Vision for Space Exploration (VSE). This is a simulation of NASA's proposed Robotic Lunar Exploration Program, second mission (RLEP2). It simulates the Lunar Surface Access Module (LSAM), which is designed to carry up to four astronauts to the lunar surface for durations of a week or longer. This simulation shows the virtual vehicle making approaches and landings on a variety of lunar terrains. The physics of the descent engine thrust vector, production of dust, and the dynamics of the suspension are all modeled in this set of simulations. The RLEP2 simulations are drivable (by keyboard or joystick) virtual rovers with controls for speed and motor torque, and can be articulated into higher or lower centers of gravity (depending on driving hazards) to enable drill placement. Gravity also can be set to lunar, terrestrial, or zero-g. This software has been used to support NASA's Marshall Space Flight Center in simulations of proposed vehicles for robotically exploring the lunar surface for water ice, and could be used to model all other aspects of the VSE from the Ares launch vehicles and Crew Exploration Vehicle (CEV) to the International Space Station (ISS). This simulator may be installed and operated on any Windows PC with an installed 3D graphics card.

Damer, Bruce↗

NASA Alternative Orion Small Cell Battery Design Support

The NASA Orion Crew Module Reference Design was produced to address large scale thermal runaway (TR) hazard with specific safety controls for the Orion Spacecraft. The design presented provides the description of a full scale battery design reference for implementation as a drop in replacement to meet all spacecraft energy requirements with compatible 120 Vdc electrical and mechanical interface using small cell technology (18650) packaging. The 32V SuperBrick incorporates unique support features and an electrical bus bar arrangement that allows cells negative can insertion into heat sink that is compressively coupled to the battery enclosure to promote good thermal management. The housing design also provides an internal flame suppression "filter tray" and positive venting path internal to the enclosure to allow hot effluent ejecta to escape in the event of single cell TR. Virtual cells (14P Banks) that are supported to provide cell spacing with interstitial materials to prevent side can failures that can produce cell to cell TR propagation. These features were successfully test in four separate TR run with the full scale DTA1 test article in February 2016. Successfully Completed Test Objectives - Four separate TR test runs with Full-Scale DTA1 housing with Two SuperBricks, Two SuperBrick Emulators All Tests resulted in "clean" gas with less than 6 C rise at Battery vent All Tests resulted in less than 2 C temperature rise on cold-plate outlet All Tests resulted in less than 6 psi pressure rise in the battery housing Test Run 1 -One neighbor cell TR, highest remaining neighbor 139 C. Ejecta shorted to bus caused prolonged additional heating, One shorted cell did experience TR after 12 minutes, remaining cells had adequate thermal margin Test Run 2 - No cell to cell propagation, highest neighbor cell 112 C; Test Run 3 - No cell to cell propagation, highest neighbor cell 96 C; Test Run 4 - No cell to cell propagation, highest neighbor cell 101 C; Primary TR testing and analysis were completed and reviewed for endorsement by NASA Engineering and Safety Center team members. All Key Test Objectives were met and the small cell design alternative was demonstrated and selected to be a feasible drop in replacement for the MPCV Orion CM Battery for EM2 mission.

Haynes, Chuck↗

Synthetic Vision for Lunar and Planetary Landing Vehicles

The Crew Vehicle Interface (CVI) group of the Integrated Intelligent Flight Deck Technologies (IIFDT) has done extensive research in the area of Synthetic Vision (SV), and has shown that SV technology can substantially enhance flight crew situation awareness, reduce pilot workload, promote flight path control precision and improve aviation safety. SV technology is being extended to evaluate its utility for lunar and planetary exploration vehicles. SV may hold significant potential for many lunar and planetary missions since the SV presentation provides a computer-generated view of the terrain and other significant environment characteristics independent of the outside visibility conditions, window locations, or vehicle attributes. SV allows unconstrained control of the computer-generated scene lighting, terrain coloring, and virtual camera angles which may provide invaluable visual cues to pilots/astronauts and in addition, important vehicle state information may be conformally displayed on the view such as forward and down velocities, altitude, and fuel remaining to enhance trajectory control and vehicle system status. This paper discusses preliminary SV concepts for tactical and strategic displays for a lunar landing vehicle. The technical challenges and potential solutions to SV applications for the lunar landing mission are explored, including the requirements for high resolution terrain lunar maps and an accurate position and orientation of the vehicle that is essential in providing lunar Synthetic Vision System (SVS) cockpit displays. The paper also discusses the technical challenge of creating an accurate synthetic terrain portrayal using an ellipsoid lunar digital elevation model which eliminates projection errors and can be efficiently rendered in real-time.

Williams, Steven P.↗

White Paper for Virtual Control Room

The Virtual Control Room (VCR) Proof of Concept (PoC) project is the result of an award given by the Fourth Annual NASA T&I Labs Challenge Project Call. This paper will outline the work done over the award period to build and enhance the capabilities of the Augmented/Virtual Reality (AVR) Lab at NASA's Kennedy Space Center (KSC) to create the VCR.

Virtual Reality↗

Research and Development of The Immersive Simulations and Engineering Environment

March of 2018 marked the conclusion of the primary updates to the immersive Simulations and Engineering Environment (iSEE) at Kennedy Space Center (KSC). Many of the problems that had arisen during the previous semester have been addressed and rectified. These included the malfunction to one of the lab's primary routers, the inefficiency of the capture environment, and various interface issues in the analysis software, Jack. This semester was primarily research and development oriented with some focus on implementation of the new hardware and software that was received last semester. The new computers and cameras that arrived sometime during the winter were installed, and the lab received its second operation opportunity. The second operation was a major milestone for the lab, both in terms of what the abilities were and what can be learned from its use. The operation performed was a virtual simulation of a critical task that would occur, if it should be needed, in the Multi Payload Processing Facility. It was done to gather human factors data on its safety and process controls. The technicians were able to come to a number of conclusions about how to perform their task as a result of utilizing iSEE. Another key breakthrough this semester was the introduction to Jack Script, a scripting language built into our analysis software that further extend Jack capabilities. In addition to the aforementioned, many preparations were made for family day, an exposition for KSC families to come out and tour the spaceport. Due to family day being moved to the spring, the video made last fall had to be updated with recent environment changes in preparation for the Family Day demonstrations.

Motion Capture↗

Object-based task-level control: A hierarchical control architecture for remote operation of space robots

Expanding man's presence in space requires capable, dexterous robots capable of being controlled from the Earth. Traditional 'hand-in-glove' control paradigms require the human operator to directly control virtually every aspect of the robot's operation. While the human provides excellent judgment and perception, human interaction is limited by low bandwidth, delayed communications. These delays make 'hand-in-glove' operation from Earth impractical. In order to alleviate many of the problems inherent to remote operation, Stanford University's Aerospace Robotics Laboratory (ARL) has developed the Object-Based Task-Level Control architecture. Object-Based Task-Level Control (OBTLC) removes the burden of teleoperation from the human operator and enables execution of tasks not possible with current techniques. OBTLC is a hierarchical approach to control where the human operator is able to specify high-level, object-related tasks through an intuitive graphical user interface. Infrequent task-level command replace constant joystick operations, eliminating communications bandwidth and time delay problems. The details of robot control and task execution are handled entirely by the robot and computer control system. The ARL has implemented the OBTLC architecture on a set of Free-Flying Space Robots. The capability of the OBTLC architecture has been demonstrated by controlling the ARL Free-Flying Space Robots from NASA Ames Research Center.

Stevens, H. D.↗