SEARCH · Search NASA
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.
This Firmware Requirements Document specifies the functional, performance, and interface requirements of the firmware. It also specifies the major characteristics, implementation constraints, and design goals of the firmware.
This document is the Firmware Test Report for the firmware to be used in the Earth Observing System (EOS) Advanced Microwave Sounding Unit-A (AMSU-A) instrument. It describes the firmware results of the Formal Qualification Test (FQT)/Demonstrations conducted on Mar. 21, 1997, Apr. 8, 1998, and July 14, 1998, for the EOS/AMSU-A instrument.
This is the final submittal of the Earth Observing System/Advanced Microwave Sounding Unit-A Firmware Version Description Document. Its purpose is to provide a precise description of the particular version of the firmware being released. This description also defines the version of the requirements and design applicable to this version.
The Automated Reconfigurable Mission Adaptive Digital Assembly Systems (ARMADAS) project, under development at NASA Ames Research Center, has demonstrated on-ground autonomous robotic assembly of extensive digital structures, and it is now moving forward towards in-space demonstration. The ARMADAS system comprises of the operation software, the operation user interface (opsUI), and a swarm of robots. The robotic system consists of a multitude of collaborative agents specifically designed to transport, place and bolt the building blocks, called voxels (volumetric pixels). This paper focuses on the bolting robot, referred to as Mobile Metamaterial Internal Co-Integrator (MMIC-I). MMIC-I is a battery-powered crawling robot. It navigates the structure through extension, contraction and gripping. Two distinct controller boards operate the robot's two symmetric modules, referred to as module A and B. Board A is the master board: it coordinates motion planning and motion primitives execution, hosts the WiFi client, performs periodic self-assessment and system idle check and triggers faults if anomalies are detected. Board B periodically sends a heartbeat to board A, through a wired communication channel that uses the Serial protocol. Additionally, board A's WiFi client receives heartbeat packet requests or motion/bolting commands from a dedicated server board, and acknowledges reception sending back a response heartbeat packet containing information about the overall robot status, e. g. electrical current and voltage values, target and actual angles, operating mode, fault status. Whenever a motion command is sent, the motion planning section of the firmware determines the current robot configuration, using Inertial Measurement Unit readings and the motors Pulse Width Modulation values. Afterwards, it calculates the list of primitives needed to reach the target state, and controls their execution in the proper order. MMIC-I can receive and execute motion and bolting commands only when it is in operational mode. MMIC-I has three operating modes: standby, operational and safed. Standby mode is automatically entered upon startup. While in standby mode, all motors are powered off, and the only accepted commands are the ones relative to a change of mode and heartbeat packet request. Fault detection causes the robot to automatically enter safed or standby mode. Whenever the detected fault occurs within a motion and requires immediate intervention, e. g. an over-current situation, the robot enters safed mode. Safed mode powers off all motors except for the locomotion module, thus preventing the robot from collapsing. Conversely, when the detected fault doesn't require immediate intervention (low battery warning, for instance), the robot enters standby mode after completing the ongoing motion. This paper provides a detailed discussion of MMIC-I's firmware architecture. It accurately describes the implementation approach for each module: sensor data reading, motor control and actuation, WiFi server-client communication, intra-boards Serial communication, operating modes and autonomous fault detection, motion planning, coordination and execution, etc. Moreover, in support of the software description, this paper includes a thorough characterization of MMIC-I's hardware and avionics.
Most manufacturing processes require physical pointwise positioning of the components or tools from one location to another. Typical mechanical systems utilize either stop-and-go or fixed feed-rate procession to accomplish the task. The first approach achieves positional accuracy but prolongs overall time and increases wear on the mechanical system. The second approach sustains the throughput but compromises positional accuracy. A computer firmware approach has been developed to optimize this point wise mechanism by utilizing programmable interrupt controls to synchronize engineering processes 'on the fly'. This principle has been implemented in an eddy current imaging system to demonstrate the improvement. Software programs were developed that enable a mechanical controller card to transmit interrupts to a system controller as a trigger signal to initiate an eddy current data acquisition routine. The advantages are: (1) optimized manufacturing processes, (2) increased throughput of the system, (3) improved positional accuracy, and (4) reduced wear and tear on the mechanical system.
This document defines the test environment, test objectives, schedule, and data recording and analysis for the EOS/AMSU-A firmware formal qualification tests.
The Mobile Metamaterial Internal Co-Integrator (MMIC-I) is a structure assembly and servicing robot for in-space servicing, assembly, and manufacturing of primary structures and infrastructure. MMIC-I is a battery-powered crawling robot that can travel through periodic structures such as trusses and open framework mechanical metamaterials. It does this through sequences of component extension, contraction, and gripping. This paper provides a detailed discussion of MMIC-I’s lightweight and rapidly developed firmware architecture, to enable demonstration of robot locomotion, secondary operations, and communications with a central command source. The rationale for the lightweight rapid development approach is to allow for assessment of long term system requirements in parallel with the mechatronics development, including optimization of system and subsystem power densities, to inform a future choice of flight ready software frameworks. MMIC-I system computing and I/O requirements are much lower than what is provided by proven baseline computing hardware for existing flight ready software frameworks such as the core Flight System, F prime, and the Robot Operating System. Development of earth gravity ground demonstration of the robotic systems is greatly benefited by limited power and mass factors for computing hardware. Here, we implement inter-process communication, commanding, and telemetry with the Espressif ESP32 module running the Arduino OS.
Data-processing system exploits high speeds inherent in optical elements. Instruction sets for different computer operations reside on different external memory chips. Laser diodes activated for each operation generate light, reflected by holographic optical element to designated receptors in arithmetic and logic unit. Pattern of light beams embodies instruction set at given instant. With potential ability to reprogram in real time, conceptual system applicable to task-driven programming or artificial intelligence.
LIDAR systems that maintain a constant beam spot size on a retroreflector in order to increase the accuracy of bearing and ranging data must use a software controlled variable position lens. These systems periodically update the estimated range and set the position of the focusing lens accordingly. In order to precisely calculate the r NOHD for such a system, the software method for setting the variable position lens and gaussian laser propagation can be used to calculate the irradiance at any point given the range estimation. NASA s Space Shuttle LIDAR, called the Trajectory Control Sensor (TCS), uses this configuration. Analytical tools were developed using Excel and VBA to determine the radiant energy to the International Space Station (ISS) crewmembers eyes while viewing the shuttle on approach and departure. Various viewing scenarios are considered including the use of through-the-lens imaging optics and the window transmissivity at the TCS wavelength. The methodology incorporates the TCS system control logic, gaussian laser propagation, potential failure mode end states, and guidance from American National Standard for the Safe Use of Lasers (ANSI Z136.1-2007). This approach can be adapted for laser safety analyses of similar LIDAR systems.
Explore the source record for details and available documents.
The development, deployment, operation and maintenance of Integrated Systems Health Management (ISHM) applications require the storage and processing of tremendous amounts of low-level data. This data must be shared in a secure and cost-effective manner between developers, and processed within several heterogeneous architectures. Modern database technology allows this data to be organized efficiently, while ensuring the integrity and security of the data. The extensibility and interoperability of the current database technologies also allows for the creation of an associated support database system. A support database system provides additional capabilities by building applications on top of the database structure. These applications can then be used to support the various technologies in an ISHM architecture. This presentation and paper propose a detailed structure and application description for a support database system, called the Health Assessment Database System (HADS). The HADS provides a shared context for organizing and distributing data as well as a definition of the applications that provide the required data-driven support to ISHM. This approach provides another powerful tool for ISHM developers, while also enabling novel functionality. This functionality includes: automated firmware updating and deployment, algorithm development assistance and electronic datasheet generation. The architecture for the HADS has been developed as part of the ISHM toolset at Stennis Space Center for rocket engine testing. A detailed implementation has begun for the Methane Thruster Testbed Project (MTTP) in order to assist in developing health assessment and anomaly detection algorithms for ISHM. The structure of this implementation is shown in Figure 1. The database structure consists of three primary components: the system hierarchy model, the historical data archive and the firmware codebase. The system hierarchy model replicates the physical relationships between system elements to provide the logical context for the database. The historical data archive provides a common repository for sensor data that can be shared between developers and applications. The firmware codebase is used by the developer to organize the intelligent element firmware into atomic units which can be assembled into complete firmware for specific elements.
The attitude control system (ACS) microprocessor development work spanned three main design areas: hardware and instruction set, ACS firmware, and hardware firmware verification testing. The processor hardware utilizes two parallel 4 bit microprocessors. The firmware includes data processing for five sensors, four attitude control laws, and telemetry and commands.
Firmware for implementing a digital phasemeter within a field-programmable gate array (FPGA) has been devised. In the original application of this firmware, the phase that one seeks to measure is the difference between the phases of two nominally-equal-frequency heterodyne signals generated by two interferometers. In that application, zero-crossing detectors convert the heterodyne signals to trains of rectangular pulses, the two pulse trains are fed to a fringe counter (the major part of the phasemeter) controlled by a clock signal having a frequency greater than the heterodyne frequency, and the fringe counter computes a time-averaged estimate of the difference between the phases of the two pulse trains. The firmware also does the following: Causes the FPGA to compute the frequencies of the input signals; Causes the FPGA to implement an Ethernet (or equivalent) transmitter for readout of phase and frequency values; and Provides data for use in diagnosis of communication failures. The readout rate can be set, by programming, to a value between 250 Hz and 1 kHz. Network addresses can be programmed by the user.
The Portable Radio Science Receiver (PRSR) is a suitcase-sized open-loop digital receiver designed to be small and easy to transport so that it can be deployed quickly and easily anywhere in the world. The PRSR digitizes, downconverts, and filters using custom hardware, firmware, and software. Up to 16 channels can be independently configured and recorded with a total data rate of up to 256 Mbps. The design and implementation of the system's hardware, firmware, and software is described. To minimize costs and time to deployment, our design leveraged elements of the hardware, firmware, and software designs from the existing full-sized operational (non-portable) Radio Science Receivers (RSR) and Wideband VLBI Science Receivers (WVSR), which have successfully supported flagship NASA deep space missions at all Deep Space Network (DSN) sites. We discuss a demonstration of the PRSR using VLBI, with one part per billion angular resolution: 1 nano-radian / 200 ?as synthesized beam. This is the highest resolution astronomical instrument ever operated solely from the Southern Hemisphere. Preliminary results from two sites are presented, including the European Space Agency (ESA) sites at Cebreros, Spain and Malargue, Argentina. Malargue's South American location is of special interest because it greatly improves the geometric coverage for spacecraft navigation in the Southern Hemisphere and will for the first time provide coverage to the 1/4 of the range of declination that has been excluded from reference frame work at Ka-band.
In 2010, the Robonaut Project embarked on a multi‐phase mission to perform technology demonstrations on‐board the International Space Station (ISS), showcasing state of the art robotics technologies through the use of Robonaut 2 (R2). This phased approach implements a strategy that allows for the use of ISS as a test bed during early development to both demonstrate capability and test technology while still making advancements in the earth based laboratories for future testing and operations in space. While R2 was performing experimental trials onboard the ISS during the first phase, engineers were actively designing for Phase 2, Intra‐Vehicular Activity (IVA) Mobility, that utilizes a set of zero‐g climbing legs outfitted with grippers to grasp handrails and seat tracks. In addition to affixing the new climbing legs to the existing R2 torso, it became clear that upgrades to the torso to both physically accommodate the climbing legs and to expand processing power and capabilities of the robot were required. In addition to these upgrades, a new safety architecture was also implemented in order to account for the expanded capabilities of the robot. The IVA climbing legs not only needed to attach structurally to the R2 torso on ISS, but also required power and data connections that did not exist in the upper body. The climbing legs were outfitted with a blind mate adapter and coarse alignment guides for easy installation, but the upper body required extensive rewiring to accommodate the power and data connections. This was achieved by mounting a custom adapter plate to the torso and routing the additional wiring through the waist joint to connect to the new set of processors. In addition to the power and data channels, the integrated unit also required updated electronics boards, additional sensors and updated processors to accommodate a new operating system, software platform, and custom control system. In order to perform the unprecedented task of building a robot in space, extensive practice sessions and meticulous procedures were required. Since crew training time is at a premium, the R2 team took a skills‐based training approach to ensure the astronauts were proficient with a basic skill set while refining the detailed procedures over several practice sessions and simulations. In addition to the crew activities, meticulous ground procedures were required in order to upgrade firmware on the upper body motor drivers. The new firmware for the IVA mobility unit needed to be deployed using the old software system. This also provided an opportunity to upgrade the upper body joints with new software and allowed for limited insight into the success of the updates. Complete verification that the updated firmware was successfully loaded was not confirmed until the rewiring of the upper body torso was complete.
This thesis discusses the development of firmware for the 68HC11 gripper controller. A general description of the software and hardware interfaces is given. The C library interface for the gripper is then described and followed by a detailed discussion of the software architecture of the firmware. A procedure to assemble and download 68HC11 programs is presented in the form of a tutorial. The tools used to implement this environment are then described. Finally, the implementation of the configuration management scheme used to manage all CIRSSE software is presented.
The speed of growth in high technology differs for software, hardware and firmware. Hardware innovations come in leaps, as opposed to the gradual improvements in software and firmware technologies. This inhibits the full utilization of the hardware advances and reduces the cost benefit ratio of high technology ventures. The Microelectronics Systems Branch has committed its resources to use the look ahead technique whereby the technology is researched in its use, current development track and its future capabilities. This knowledge is used to meet the requirements of the space program not only in the nineties but also through 2005. This paper illustrates Analytical Hierarchy Process techniques used effectively and very successfully to support projects reusing systems with predicted enhancements.
The Global Positioning System Subsystem (GPS) for International Space Station (ISS) was activated April 12,2002 following the installation of the SO truss segment that included the GPS antennas on Shuttle mission STS-110. The ISS GPS receiver became the primary source for position, velocity, and attitude information for ISS two days after activation. The GPS receiver also provides a time reference for manual control of ISS time, and will be used for automatic time updates after problems are resolved with the output from the receiver. After two years of on-orbit experience, the GPS continues to be used as the primary navigation source for ISS; however, enough problems have surfaced that the firmware in the GPS attitude code has had to be totally rewritten and new algorithms developed, the firmware that processed the time output from the GPS receiver had to be rewritten, while the GPS navigation code has had minor revisions. The factors contributing to the delivery of a GPS receiver for use on ISS that requires extensive operator intervention to function are discussed. Observations from two years worth of GPS solutions will also be discussed. The technical solutions to the anomalous GPS receiver behavior will be discussed.