Search NASA⌕ Search

SEARCH · Search NASA

Results for “execution control”

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 415 records · Page 23

Use of Design of Experiments in Determining Neural Network Architectures for Loss of Control Detection

Abstract—We describe empirical methods for selecting a neural network architecture to implement belief state inference on generic commercial transport aircraft. We highlight a case study on the planning, execution, and analysis of a set of experiments to determine the configurations of a conditional variational autoencoder (CVAE). Our main contribution is the application of a structured method that can be used for machine learning in many aerospace applications. This method optimizes the structure and training parameters of a neural network for belief state inference, using Design of Experiments (DOE) statistical methodologies. The motivation for this specific DOE analysis was to identify the appropriate hyperparameters for measuring the CVAE reconstruction probability and latent space, such that the measurements can be used to infer qualitative state changes for the aircraft. We demonstrate that this process yields information about a trained neural network’s utility for this specific application, along with a quantifiable range of certainty. We execute 84 experiments using loss-of-control flight maneuver data from the NASA T-2 aircraft, demonstrating that this empirical process allows us to construct cheap and simple models with specific attributes amenable to belief state inference in aerospace applications.

neural networks↗

Flight Path Control Error Analysis for the Helioswarm Observatory

The HelioSwarm Observatory requires specific geometries be formed by the nine satellites in the swarm to resolve different scales of solar wind turbulence. Maneuver execution and state estimation drive flight path control errors that could disrupt the swarm geometry. Using a Monte-Carlo analysis, flight path control errors for dispersed trajectories were generated and the impact to science performance and other mission constraints evaluated. The results highlight the unique aspects of swarm-type multi-satellite missions in terms of maneuver planning and error tolerance.

Stephen West↗

Flight Path Control Error Analysis for the Helioswarm Observatory

The HelioSwarm Observatory requires specific geometries be formed by the nine satellites in the swarm to resolve different scales of solar wind turbulence. Maneuver execution and state estimation drive flight path control errors that could disrupt the swarm geometry. Using a Monte-Carlo analysis, flight path control errors for dispersed trajectories were generated and the impact to science performance and other mission constraints evaluated. The results highlight the unique aspects of swarm-type multi-satellite missions in terms of maneuver planning and error tolerance.

Swarm↗

Engine structures modeling software system: Computer code. User's manual

ESMOSS is a specialized software system for the construction of geometric descriptive and discrete analytical models of engine parts, components and substructures which can be transferred to finite element analysis programs such as NASTRAN. The software architecture of ESMOSS is designed in modular form with a central executive module through which the user controls and directs the development of the analytical model. Modules consist of a geometric shape generator, a library of discretization procedures, interfacing modules to join both geometric and discrete models, a deck generator to produce input for NASTRAN and a 'recipe' processor which generates geometric models from parametric definitions. ESMOSS can be executed both in interactive and batch modes. Interactive mode is considered to be the default mode and that mode will be assumed in the discussion in this document unless stated otherwise.

Source record↗

Executing CLIPS expert systems in a distributed environment

This paper describes a framework for running cooperating agents in a distributed environment to support the Intelligent Computer Aided Design System (ICADS), a project in progress at the CAD Research Unit of the Design Institute at the California Polytechnic State University. Currently, the systems aids an architectural designer in creating a floor plan that satisfies some general architectural constraints and project specific requirements. At the core of ICADS is the Blackboard Control System. Connected to the blackboard are any number of domain experts called Intelligent Design Tools (IDT). The Blackboard Control System monitors the evolving design as it is being drawn and helps resolve conflicts from the domain experts. The user serves as a partner in this system by manipulating the floor plan in the CAD system and validating recommendations made by the domain experts. The primary components of the Blackboard Control System are two expert systems executed by a modified CLIPS shell. The first is the Message Handler. The second is the Conflict Resolver. The Conflict Resolver synthesizes the suggestions made by the domain experts, which can be either CLIPS expert systems, or compiled C programs. In DEMO1, the current ICADS prototype, the CLIPS domain expert systems are Acoustics, Lighting, Structural, and Thermal; the compiled C domain experts are the CAD system and the User Interface.

Taylor, James↗

Digital command system

The correct processing of the Digital Command System (DCS), which provides a limited real-time means of controlling specific flight program functions, was verified. The ability of the flight program to correctly read and process DCS commands was verified. Tests made by the flight program after reading the contents of the command decoder register to establish the validity of the received data were verified through the following: DCS mode command verification, DCS data command verification, DCS data validation, and DCS error message. The operation of the following DCS commands accepted and processed by the flight program was tested: time base update, navigation update, generalized switch selector, memory dump, terminate, execute generalized maneuver, return to nominal timeline, ECS water control valve logic inhibit, execute maneuver, execute alternate sequence, targeting load, ladder magnitude limit, S-IVB/IU de-orbit, compressed data dump, and remove inhibit on the extraction maneuver.

Source record↗

Analytical study of ride smoothing benefits of control system configurations optimized for pilot handling qualities

An analytical study was conducted to evaluate the relative improvements in aircraft ride qualities that resulted from utilizing several control law configurations that were optimized for pilot handling qualities only. The airplane configuration used was an executive jet transport in the approach configuration. The control law configurations included the basic system, a rate feedback system, three command augmentation systems (rate command, attitude command, and rate command/attitude hold), and a control wheel steering system. Both the longitudinal and lateral directional axes were evaluated. A representative example of each control law configuration was optimized for pilot handling qualities on a fixed base simulator. The root mean square airplane responses to turbulence were calculated, and predictions of ride quality ratings were computed by using three models available in the literature.

Powers, B. G.↗

Use of Design of Experiments and Rule-Based Inference in Determining Neural Network Architectures for Loss of Control Detection

In this work, we describe methods for selecting the neural network architectures and input spaces to implement belief state inference on generic commercial transport aircraft. First, we highlight a case study on the planning, execution, and analysis of a set of experiments to determine the configurations of a conditional variational autoencoder (CVAE). We present a structured method that can be used in a number of aerospace applications, to optimize the structure and training parameters of the CVAE for belief state inference, using Design of Experiments (DOE) statistical methodologies. The motivation for this specific DOE was to identify the appropriate hyperparameters for measuring the CVAE reconstruction probability and latent space, such that the measurements can be used to infer qualitative state changes for the aircraft. We demonstrate that this process yields information about a trained neural network’s utility for this specific application, along with a quantifiable range of certainty. We execute 84 experiments using loss-of-control flight maneuver data from a NASA T-2 aircraft, demonstrating that this empirical process allows us to construct cheap and simple models with specific attributes amenable to belief state inference in aerospace applications. While theoretically, we could create a single CVAE with an input space the size of all measurable flight variables and environmental dynamics, it becomes intractable to use such a neural network in an in-situ intelligent multi-agent system. Using the recommendations from our case study, we introduce a technical approach for feasibly describing the belief space by (1) identifying significant statistical relationships among flight variables using rule induction, (2) using a set of rules that cover all features to define the input space of multiple CVAEs, and (3) forming a belief space based on the joint probability density of their collective latent spaces. This results in a series of relatively small matrix multiplications that can be performed in real time, as opposed to large matrix computations in a single CVAE. We demonstrate the application of this approach on the T-2 flight loss-of control experiments, using the architecture and hyperparameter recommendations from the case study. We compare the utilities of an individual CVAE trained on all flight variables and multiple CVAEs defined on subsets of flight variables for detecting qualitative changes in flight. We demonstrate that the use of multiple CVAEs with smaller input spaces permits the CVAE to capture more granular relationships in the latent space, permitting better state space characterization and loss-of-control detection.

Design of experiments↗

A microprocessor based high speed packet switch for satellite communications, executive summary

The feasibility of using microprocessors to control satellite-borne packet switching was investigated by designing a packet switch architecture suitable for microprocessor control, using 2900 series components to design the processor(s), and evaluating the packet switch in terms of system throughput, delay, and queue sizes without the packet switch. System architecture for one, three, and multiple processors was designed and evaluated. The production cost of the single processor packet switch is estimated at $500,000, excluding cost of development. The three processor version which can support a maximum throughput of 500,000 packets/sec is estimated to have a production cost of under $100,000. For the multiple processor system, cost is believed to be proportional to throughput, with $1,000,000 for 500,000 packets/sec being the proportionality factor.

Arozullah, M.↗

Use of Soft Computing Technologies For Rocket Engine Control

The problem to be addressed in this paper is to explore how the use of Soft Computing Technologies (SCT) could be employed to further improve overall engine system reliability and performance. Specifically, this will be presented by enhancing rocket engine control and engine health management (EHM) using SCT coupled with conventional control technologies, and sound software engineering practices used in Marshall s Flight Software Group. The principle goals are to improve software management, software development time and maintenance, processor execution, fault tolerance and mitigation, and nonlinear control in power level transitions. The intent is not to discuss any shortcomings of existing engine control and EHM methodologies, but to provide alternative design choices for control, EHM, implementation, performance, and sustaining engineering. The approaches outlined in this paper will require knowledge in the fields of rocket engine propulsion, software engineering for embedded systems, and soft computing technologies (i.e., neural networks, fuzzy logic, and Bayesian belief networks), much of which is presented in this paper. The first targeted demonstration rocket engine platform is the MC-1 (formerly FASTRAC Engine) which is simulated with hardware and software in the Marshall Avionics & Software Testbed laboratory that

Trevino, Luis C.↗

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗

Survey of Command Execution Systems for NASA Spacecraft and Robots

NASA spacecraft and robots operate at long distances from Earth Command sequences generated manually, or by automated planners on Earth, must eventually be executed autonomously onboard the spacecraft or robot. Software systems that execute commands onboard are known variously as execution systems, virtual machines, or sequence engines. Every robotic system requires some sort of execution system, but the level of autonomy and type of control they are designed for varies greatly. This paper presents a survey of execution systems with a focus on systems relevant to NASA missions.

Verma, Vandi↗

Software Testbed for Developing and Evaluating Integrated Autonomous Subsystems

To implement fault tolerant autonomy in future space systems, it will be necessary to integrate planning, adaptive control, and state estimation subsystems. However, integrating these subsystems is difficult, time-consuming, and error-prone. This paper describes Intelliface/ADAPT, a software testbed that helps researchers develop and test alternative strategies for integrating planning, execution, and diagnosis subsystems more quickly and easily. The testbed's architecture, graphical data displays, and implementations of the integrated subsystems support easy plug and play of alternate components to support research and development in fault-tolerant control of autonomous vehicles and operations support systems. Intelliface/ADAPT controls NASA's Advanced Diagnostics and Prognostics Testbed (ADAPT), which comprises batteries, electrical loads (fans, pumps, and lights), relays, circuit breakers, invertors, and sensors. During plan execution, an experimentor can inject faults into the ADAPT testbed by tripping circuit breakers, changing fan speed settings, and closing valves to restrict fluid flow. The diagnostic subsystem, based on NASA's Hybrid Diagnosis Engine (HyDE), detects and isolates these faults to determine the new state of the plant, ADAPT. Intelliface/ADAPT then updates its model of the ADAPT system's resources and determines whether the current plan can be executed using the reduced resources. If not, the planning subsystem generates a new plan that reschedules tasks, reconfigures ADAPT, and reassigns the use of ADAPT resources as needed to work around the fault. The resource model, planning domain model, and planning goals are expressed using NASA's Action Notation Modeling Language (ANML). Parts of the ANML model are generated automatically, and other parts are constructed by hand using the Planning Model Integrated Development Environment, a visual Eclipse-based IDE that accelerates ANML model development. Because native ANML planners are currently under development and not yet sufficiently capable, the ANML model is translated into the New Domain Definition Language (NDDL) and sent to NASA's EUROPA planning system for plan generation. The adaptive controller executes the new plan, using augmented, hierarchical finite state machines to select and sequence actions based on the state of the ADAPT system. Real-time sensor data, commands, and plans are displayed in information-dense arrays of timelines and graphs that zoom and scroll in unison. A dynamic schematic display uses color to show the real-time fault state and utilization of the system components and resources. An execution manager coordinates the activities of the other subsystems. The subsystems are integrated using the Internet Communications Engine (ICE). an object-oriented toolkit for building distributed applications.

Testbed↗

Automated Operations Development for Advanced Exploration Systems

Automated space operations command and control software development and its implementation must be an integral part of the vehicle design effort. The software design must encompass autonomous fault detection, isolation, recovery capabilities and also provide "single button" intelligent functions for the crew. Development, operations and safety approval experience with the Timeliner system onboard the International Space Station (ISS), which provided autonomous monitoring with response and single command functionality of payload systems, can be built upon for future automated operations as the ISS Payload effort was the first and only autonomous command and control system to be in continuous execution (6 years), 24 hours a day, 7 days a week within a crewed spacecraft environment. Utilizing proven capabilities from the ISS Higher Active Logic (HAL) System, along with the execution component design from within the HAL 9000 Space Operating System, this design paper will detail the initial HAL System software architecture and interfaces as applied to NASA's Habitat Demonstration Unit (HDU) in support of the Advanced Exploration Systems, Autonomous Mission Operations project. The development and implementation of integrated simulators within this development effort will also be detailed and is the first step in verifying the HAL 9000 Integrated Test-Bed Component [2] designs effectiveness. This design paper will conclude with a summary of the current development status and future development goals as it pertains to automated command and control for the HDU.

Haddock, Angie T.↗

Automated Operations Development for Advanced Exploration Systems

Automated space operations command and control software development and its implementation must be an integral part of the vehicle design effort. The software design must encompass autonomous fault detection, isolation, recovery capabilities and also provide single button intelligent functions for the crew. Development, operations and safety approval experience with the Timeliner system on-board the International Space Station (ISS), which provided autonomous monitoring with response and single command functionality of payload systems, can be built upon for future automated operations as the ISS Payload effort was the first and only autonomous command and control system to be in continuous execution (6 years), 24 hours a day, 7 days a week within a crewed spacecraft environment. Utilizing proven capabilities from the ISS Higher Active Logic (HAL) System [1] , along with the execution component design from within the HAL 9000 Space Operating System [2] , this design paper will detail the initial HAL System software architecture and interfaces as applied to NASA s Habitat Demonstration Unit (HDU) in support of the Advanced Exploration Systems, Autonomous Mission Operations project. The development and implementation of integrated simulators within this development effort will also be detailed and is the first step in verifying the HAL 9000 Integrated Test-Bed Component [2] designs effectiveness. This design paper will conclude with a summary of the current development status and future development goals as it pertains to automated command and control for the HDU.

Haddock, Angie↗

An Optimization Approach to Support Science Decision Making for Lunar Surface Exploration

Introduction: Scientific exploration is one of the three pillars of NASA’s Moon2Mars architecture, with crew surface extra vehicular activities (EVA) serving a critical enabling function. Development of surface EVA operational planning and execution, specifically integrating science and flight control teams (FCT), is currently being explored through analog scenarios. This integration, exercised, for example, through the Joint EVA and Hu-man Surface Mobility Test Team (JETT), allows for science input on EVA activities in near real-time through a Science Evaluation Room (SER), or Arte-mis science backroom, which integrates with the broader FCT through the Science Officer. The SER works within the FCT to support dynamic EVA planning in response to changes in operational constraints as well as science opportunities and re-prioritization, increasing the mission science return and accelerating the accomplishment of the Moon2Mars science objectives. The SER works within the FCT to provide recommendations to traverse execution in near real-time. One challenge is the requirement to deliver SER inputs to the FCT on operationally relevant timelines. Failure to do so may result in suboptimal execution of science exploration EVAs or even loss of key science objectives. To close this gap, we present a network optimization tool to allow the SER to provide rapid input to the FCT in response to changes in operational constraints or science opportunities. Inputs are predicated on approved science objectives, and clear rationale must be provided to the FCT for any requested change. Accordingly, this tool incorporates the Science Traceability Matrix (STM), SER prioritization scheme, and station characterization and action planning with operational constraints such as duration, traverse speed, and distance to maximize science objectives based on SER priorities, consistent with FCT operational requirements. Method: As a proof of concept, we used an existing linear programing software package used to simulate optimal routes through cellular metabolism. We built a Demonstrative Model with three STM objectives and four stations on a region of the Moon. The objectives were given an arbitrary prioritization and mapped to the stations through four possible crew actions. (Figs. 1 and 2). This station to STM mapping is consistent with the method used by the JETT5 Science Team to develop analog surface EVA science planning. We used a grid system with the landing site at the origin and the four stations placed across the positive x,y quadrant. Actions were assigned to each station and the accomplishment of those actions resulted in a numerical “reward” based on the ability of that action to achieve science objectives. The aggregate reward from each individual STM objective contributes to a global score (Science Yield), weighted by its priority. Operational constraints included a requirement to start and end at the landing site, 5 minutes each for initial station characterization and “clean up,” and variable total EVA time, traverse rate (fixed to 0.5 meters per second in our example), and time to perform each action (10, 5, 7, and 15 min for actions 1, 2, 3, and 4, respectively). Additional constraints and variables will be added in the future (e.g., sample mass, number of stations, traverse route constraints, illumination). Optimization. We converted the connections (arcs) between these stations (nodes) into a mixed integer linear programming optimization problem (arcs = constraints, nodes = variables) with the objective to maximize Science Yield. For any action, the Science Yield is equal to the relevance of that action to an STM objective [3, 2, and 1 point(s) for High, Med., and Low relevance, respectively], multiplied by the STM Objective Priority [3, 2, and 1 point(s) for High, Med., and Low priority, respectively]. This resulted in a model that computes the optimal station and action combination to maximize the Science Yield. These weightings can be adjusted by the SER as desired. Results: We explored three test cases for the Demonstrative Model. First, we set the maximum EVA duration to 120 minutes and computed the optimal route (Fig. 3A). The model suggested per-forming Actions 1 and 2 at Station P01, followed by Actions 1 and 2 at Station P02, and finally Actions 1 and 3 at Station P04 before returning to the Landing Site. Second, we adjusted the STM Objective Priori-ty order and computed the new optimal route (Fig. 3B). Under this situation, the model suggested per-forming all Actions at Station P02 followed by all Actions at Station P03. The previous test cases were relevant to SER planning activities. Next, we explored providing mid-EVA replanning input to the FCT. Scenario: While executing the Route in Fig. 3A the crew finishes at Station P01 and FCT decides that the EVA needs to finish in 45 minutes back at the Landing Site. FCT asks SER to recommend changes to the plan to accommodate this operation-al change. Using the model and incorporating these new constraints (start at Station P01, max. time of 45 min), the model suggested performing Actions 2 and 4 at Station P03 (Fig. 4), requiring 41 minutes to complete and return to the Landing Site. Interestingly, Station 3 was not part of the original route. Using the model, we determined the EVA would need 66 minutes, instead of 45, in order for the original Station P04 to yield a larger Science Yield than Station P03. The parametrization and simulation was per-formed in less than a minute, demonstrating the operational relevance of the approach. Future Efforts: The results from the Demonstrative Model suggest this tool can accelerate SER decision making on operationally relevant timelines. Use in analog activities, such as JETT5 or follow-ons, which have over a dozen stations for a crew to explore and over a dozen actions per station, will provide needed validation of the utility of this tool for planning EVAs, replanning mid-EVA, or planning follow-on EVAs based on previous results. Further integration with FCT execution monitoring tools may provide additional efficiency gains, al-lowing rapid and iterative exploration of operation-al and science decision space by the FCT and SER.

Science Operations↗

Interdisciplinary analysis procedures in the modeling and control of large space-based structures

The paper describes a computer software system called the Integrated Multidisciplinary Analysis Tool, IMAT, that has been developed at NASA Langley Research Center. IMAT provides researchers and analysts with an efficient capability to analyze satellite control systems influenced by structural dynamics. Using a menu-driven interactive executive program, IMAT links a relational database to commercial structural and controls analysis codes. The paper describes the procedures followed to analyze a complex satellite structure and control system. The codes used to accomplish the analysis are described, and an example is provided of an application of IMAT to the analysis of a reference space station subject to a rectangular pulse loading at its docking port.

Cooper, Paul A.↗

Firmware Architecture of the ARMADAS Bolting Robot

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.

In-space assembly↗