DRAFT Autonomy as an Operational Element of

DRAFT

Autonomy as an Operational Element of Planetary Surface Systems A Pre-Design Research Capture Document

Gary J Rodriguez Lee Johnson Justin G Rodriguez

TM

sysRAND Corporation 17011 Lincoln Avenue Unit 130 Parker Colorado 80134 TM

R&D which endeavors to leapfrog the rocket equation by solving the logistics equation

Autonomy as an Operational Element of Planetary Surface Systems

Placards NASA: “SBIR Data Rights Notice (Dec 2010) These SBIR data are furnished with SBIR rights under Contract Nr. NNJ08JA60C. For a period of 4 years after acceptance of all items to be delivered under this contract, the Government agrees to use these data for Government purposes only, and they shall not be disclosed outside the Government (including disclosure for procurement purposes) during such period without permission of the Contractor, except that, subject to the foregoing use and disclosure prohibitions, such data may be disclosed for use by support Contractors. After the aforesaid 4-year period the Government has a royalty-free license to use, and to authorize others to use on its behalf, these data for Government purposes, but is relieved of all disclosure prohibitions and assumes no liability for unauthorized use of these data by third parties. This Notice shall be affixed to any reproductions of these data, in whole or in part.”

sysRAND Corporation: This is a Research Document that reviews the research of one or more previous projects, and was originally intended to structure future research projects, and proposals. It is copyrighted in order to cover situations where research use of an item, such as a incompletely attributed image, is allowed in research yet not allowed for other use without documented permissions. So fair use of this document, and any subordinate content is allowed, but republication is not. You may make a few copies for your Space Merit Badge, or your Science class if you find the material useful. Use of this document is with the understanding that it is incomplete because NASA’s programs were essentially derailed during the second decade of the New Millennium. This work was conducted from 2006 through 2011, when it was abandoned as out-of-step with the new culture at NASA. The text remains substantially unaltered, yet has been corrected, and edited to the extent possible without altering the Styles, which would result in a cascade of work over the course of many days. Some of the facts have changed, yet have been left unaltered so as to preserve the original contexts. It is our intent that this document may prove a useful starting point for a new generation of space enthusiasts, and practitioners. It represents an in-house method for the preparation of proposal material, project definition, and project planning (WBS, SOW): the Capture Document.

Copyright©2011 sysRAND Corporation and archived Copyright©2018 sysRAND Corporation for pre-print

** Autonomy180225A.doc

sysRAND Corporation

i


Contents 1.0 Automating Planetary Surface Operations....................................................................................... 2 1.1 Low energy trajectory .................................................................................................................. 3 1.2 Intrinsic Autonomy ....................................................................................................................... 4 1.3 Attributes Shape Autonomy ......................................................................................................... 5 1.4 Swarms are the Answer to What Question?................................................................................ 5 1.5 The Mission.................................................................................................................................. 7 1.6 Methodologies ............................................................................................................................. 7 1.7 System Multipliers ........................................................................................................................ 8 1.8 Energy.......................................................................................................................................... 8 1.9 Assumptions ................................................................................................................................ 9 1.10 Scope ........................................................................................................................................... 9 2.0 Excavator Mining/Civil Engineering Applications ........................................................................... 11 2.1 Trenching for Cable and Pipe .................................................................................................... 12 2.2 Structure Emplacement ............................................................................................................. 12 2.3 Postholes ................................................................................................................................... 13 2.4 Structure Burial .......................................................................................................................... 13 2.5 Berm Construction ..................................................................................................................... 14 2.6 Rock Mitigation .......................................................................................................................... 18 2.7 Landing Pad Preparation ........................................................................................................... 18 2.8 Trenching for A.C. Power Cables .............................................................................................. 18 2.9 Surface Survey Data Acquisition ............................................................................................... 19 2.10 Mining ........................................................................................................................................ 20 3.0 Excavator and Support Elements .................................................................................................. 24 3.1 The Excavator Blade: Generation One ...................................................................................... 24 3.2 Blade Pendant Control............................................................................................................... 28 3.3 The Turret .................................................................................................................................. 29 3.4 The Hopper ................................................................................................................................ 30 3.5 The Discharge Chute ................................................................................................................. 30 3.6 Universal Tool Interface ............................................................................................................. 30 3.7 The Tool Rack ........................................................................................................................... 31 3.8 Chainless Excavator Blade: Generation Two ............................................................................ 31 3.9 Suggested Mobility Platforms .................................................................................................... 33 3.10 The TUG .................................................................................................................................... 35 3.11 Hardpoints.................................................................................................................................. 39 3.12 Concept Validation ..................................................................................................................... 40 4.0 Concept of Operations ................................................................................................................... 43 4.1 Concept of Operation Agents .................................................................................................... 43 4.2 Concept of Operations Actions .................................................................................................. 45 4.3 Concept of Operations Metrics .................................................................................................. 46 4.4 Operational Constraints ............................................................................................................. 46 4.4.1 Bandwidth .............................................................................................................................. 46 4.4.2 Risk to the Mission ................................................................................................................ 46 4.4.3 Efficiency ............................................................................................................................... 46 4.4.4 Productivity ............................................................................................................................ 46 4.5 Operational Modes .................................................................................................................... 47 4.5.1 Inert ....................................................................................................................................... 47 4.5.2 Safe Modes ........................................................................................................................... 47 4.5.3 Normal Operations ................................................................................................................ 47 4.5.4 Decommissioning .................................................................................................................. 47 4.6 Worksite Management and Control ........................................................................................... 48 4.6.1 Mobility .................................................................................................................................. 48 4.6.2 Activity ................................................................................................................................... 49 4.6.3 Control Zones ........................................................................................................................ 49

sysRAND Corporation

ii

Autonomy as an Operational Element of Planetary Surface Systems 4.6.4 Excavation Worksite .............................................................................................................. 49 4.7 Typical Excavation Operations .................................................................................................. 51 4.7.1 Command Structures Provide Direction ................................................................................ 51 4.7.1.1 Distributed Control ........................................................................................................ 51 4.7.1.2 Task and Asset Management ....................................................................................... 52 4.7.1.3 Traffic Management ...................................................................................................... 52 4.7.1.4 Site Management.......................................................................................................... 52 4.7.1.5 Tool-centric Control ...................................................................................................... 52 4.7.2 Detailed TUG Operations ...................................................................................................... 53 4.7.2.1 Free Navigation ............................................................................................................ 53 4.7.2.2 Cross-Country Navigation............................................................................................. 53 4.7.2.3 Worksite Navigation ...................................................................................................... 53 4.7.2.4 Basic TUG Service Loops............................................................................................. 54 4.7.2.5 Trains of TUGs ............................................................................................................. 55 4.7.3 Detailed Excavator Blade Operations ................................................................................... 56 4.8 Excavator Work Volumes .......................................................................................................... 57 5.0 Digital Visualization Enhances Design Definition .......................................................................... 59 5.1 Definition of Excavator and TUG for Modeling .......................................................................... 60 5.1.1 Meta-Definition of the TUG .................................................................................................... 60 5.1.2 Meta-Definition of the Turret.................................................................................................. 63 5.1.3 Meta-Definition of the Excavator (Tool) ................................................................................. 64 6.0 Digital Visualization Facilitates Development ................................................................................ 65 7.0 Digital Visualization Supports Operations ...................................................................................... 70 7.1 On-the-Ground Operation .......................................................................................................... 70 7.2 CONOPS Development ............................................................................................................. 72 7.3 Realtime Operations Support .................................................................................................... 72 7.4 Technical Fixes To Visualization ............................................................................................... 72 7.5 Observed TUG Depiction & Simulation Problems ..................................................................... 73 7.6 Observed Turret Depiction & Simulation Problems ................................................................... 75 7.7 Observed Excavator Blade Depiction & Simulation Problems .................................................. 76 7.8 Observed User Interface Problems ........................................................................................... 77 7.9 Terminology for Guys Who Play in Dirt ..................................................................................... 78 7.10 Other Functional Enhancements ............................................................................................... 78 7.11 Towards a User Guide ............................................................................................................... 78 8.0 TUG and Tool Control Models ....................................................................................................... 80 8.1 Evolution of Control ................................................................................................................... 80 8.2 Teleoperation ............................................................................................................................. 81 8.3 Semi-Autonomous ..................................................................................................................... 82 8.4 Constrained Autonomy .............................................................................................................. 82 8.5 Collaborative Autonomy............................................................................................................. 82 8.6 Learning Autonomy.................................................................................................................... 82 9.0 Robotic Models .............................................................................................................................. 85 9.1 Using Language to Remove Ambiguity ..................................................................................... 86 9.2 Functional Partitioning and Synthesis ....................................................................................... 88 9.3 Stage One: Platform Navigation ................................................................................................ 91 9.4 Stage Two: Turret Maneuvering ................................................................................................ 93 9.5 Stage Three: Excavator Maneuvering ....................................................................................... 94 9.6 Traversing Re-entrancy ............................................................................................................. 95 9.7 Firing Rules and Transitions ...................................................................................................... 96 9.8 Surface Data Repository............................................................................................................ 97 9.9 Geographic Information System (GIS) ...................................................................................... 98 9.10 Recursive Process Cell .............................................................................................................. 99 9.10.1 Objective Testing ............................................................................................................ 100 9.10.2 Trajectory Planning ......................................................................................................... 100 9.10.3 Limit Testing .................................................................................................................... 100 9.10.4 Interference Testing ........................................................................................................ 100

sysRAND Corporation

iii

Autonomy as an Operational Element of Planetary Surface Systems 9.10.5 Motion Control ................................................................................................................. 101 9.11 Invert & Translate Function...................................................................................................... 102 9.12 RT System Timebase .............................................................................................................. 103 10.0 Polar Coordinate Frame Defined ................................................................................................. 109 10.1 Selection of a Coordinate Frame of Reference ....................................................................... 110 10.2 Fitting Polar Coordinate Frame to the Vehicle......................................................................... 111 10.3 Convert Cartesian Coordinates to Polar .................................................................................. 114 10.4 Convert Polar Coordinates to Cartesian .................................................................................. 114 10.5 Vector and Plane Notation ....................................................................................................... 114 10.5.1 Position Vector ................................................................................................................ 114 10.5.2 Orientation Vector ........................................................................................................... 114 10.6 Transformations on Vectors and Planes ................................................................................. 114 10.6.1 Translation ...................................................................................................................... 114 10.6.2 Rotation ........................................................................................................................... 115 10.7 Inverse Transformations .......................................................................................................... 115 10.8 Rotation about a Vector ........................................................................................................... 115 10.9 Constructing Equivalent Combined Transforms ...................................................................... 116 10.10 Representative Combined Transforms ............................................................................... 117 10.10.1 Scaling Transforms ......................................................................................................... 118 10.10.2 Perspective Transforms .................................................................................................. 118 10.10.3 Position and Orientation .................................................................................................. 118 10.11 Partitioning the Model to Module Boundaries ..................................................................... 119 10.12 Constructing the End-to-End Model .................................................................................... 123 11.0 Control System Development Methodology................................................................................. 126 11.1 Common Functions .................................................................................................................. 126 11.2 Specialization of Function ........................................................................................................ 127 11.3 Role of States and Metastates................................................................................................. 127 11.4 Device Lifecycle Metastates .................................................................................................... 130 11.4.1 INERT ............................................................................................................................. 130 11.4.2 SAFE MODE ................................................................................................................... 130 11.4.3 POWER_UP.................................................................................................................... 130 11.4.4 NORMAL_OPERATIONS ............................................................................................... 130 11.4.5 POWER_DOWN ............................................................................................................. 131 11.4.6 DECOMMISSION............................................................................................................ 131 11.5 Managing the Scope and Coherency of Data.......................................................................... 132 11.5.1 Stateless Network Fabric ................................................................................................ 132 11.6 Maintaining Platform Integrity .................................................................................................. 132 11.7 Safety as a System Driver ....................................................................................................... 132 11.8 Continuous Fault detection ...................................................................................................... 132 12.0 Technologies enabling Autonomy ................................................................................................ 134 12.1 Stirling Radioisotope Alternator ............................................................................................... 136 12.2 Power System .......................................................................................................................... 137 12.3 Modules Partitioned at Functional Boundaries ........................................................................ 138 12.4 Employing Orbital Systems as a Basis for Surface Systems .................................................. 139 12.5 Smart Tool Controls ................................................................................................................. 141 12.6 Defining the Tool Interface....................................................................................................... 141 12.7 Mechanical Interfaces are Hot-Swappable .............................................................................. 142 12.8 Universal Tool Coupling........................................................................................................... 143 12.9 Modular Tool System Network................................................................................................. 144 12.10 Proximity-detecting Whiskers .............................................................................................. 144 12.11 Kinematics and MEMS Angular Rate Sensors .................................................................... 145 12.12 Wavelet Transform Image Processing ................................................................................ 146 12.13 Stereo Vision Processing .................................................................................................... 147 12.14 Sensor Data Fusion ............................................................................................................. 147 13.0 Methods Intrinsic to Autonomy..................................................................................................... 149 13.1 Non-stop Process Parallelism.................................................................................................. 150

sysRAND Corporation

iv

Autonomy as an Operational Element of Planetary Surface Systems 13.2 State Awareness (Internal) ...................................................................................................... 150 13.3 Situational Awareness (External) ............................................................................................ 150 13.4 Mission Persistence ................................................................................................................. 150 13.5 Aggressive Goal-seeking ......................................................................................................... 151 13.6 Recursive Approximation ......................................................................................................... 152 13.7 Conflict Prediction, Resolution And Tactics ............................................................................. 156 13.8 KoBayashi Maru and the Art of Cheating ................................................................................ 157 13.8.1 Lessons Learned............................................................................................................. 158 13.8.2 Towards Formalizing Cheating as a Strategy for Autonomy .......................................... 158 13.8.3 Methods for Rule Synthesis ............................................................................................ 158 14.0 Rule and Command Processing .................................................................................................. 161 14.1 Fixed Code, Variable Rules ..................................................................................................... 162 14.2 Electronic Work Order ............................................................................................................. 163 14.3 Cyclic and Chained Operations ............................................................................................... 164 15.0 Machine Learning System ........................................................................................................... 167 15.1 Calculi of Control ..................................................................................................................... 168 15.1.1 Propositional Logic .......................................................................................................... 168 15.1.2 First-Order Predicate Calculus ........................................................................................ 168 15.1.3 Temporal Logic ............................................................................................................... 168 15.1.4 Higher-Order Predicate Calculus .................................................................................... 168 15.1.5 Fuzzy Logic ..................................................................................................................... 169 15.1.6 Fusion One ...................................................................................................................... 169 15.1.7 Fusion Two ...................................................................................................................... 169 15.1.8 Using Fuzzy Mechanisms to Emulate Flat Propositional Logic ...................................... 170 15.2 Mechanisms of the MLS .......................................................................................................... 171 15.2.1 Induction .......................................................................................................................... 171 15.2.2 Generalization ................................................................................................................. 171 15.2.2.1 Bands of Application ................................................................................................... 171 15.2.3 Heuristics ........................................................................................................................ 172 15.2.4 Behavior Modification ...................................................................................................... 172 15.2.4.1 Classical Conditioning ................................................................................................ 173 15.2.4.2 Operant Conditioning / Instrumental Learning ............................................................ 173 15.2.5 Tabula Rasa .................................................................................................................... 175 15.2.6 Association ...................................................................................................................... 175 15.2.6.1 Observational Learning............................................................................................... 175 15.2.6.2 Testing to Success ..................................................................................................... 175 15.3 Self-Referential and Self-Aware Systems ............................................................................... 177 15.4 Fuzzy Logic Inference Engines................................................................................................ 178 15.5 Language Processing with Fuzzy Logic .................................................................................. 180 15.6 Servomechanisms Using Fuzzy Logic ..................................................................................... 181 15.7 Reinforcement Training of Fuzzy Logic Controllers ................................................................ 184 15.8 Repository Domains ................................................................................................................ 185 15.8.1 Rules Base for First-Order Servo Controllers ................................................................. 185 15.8.2 Rules Base for First-Order Linguistic Processors ........................................................... 185 15.8.3 Rules Base for Higher-Order Controllers ........................................................................ 185 15.8.4 Knowledge Base for First-Order Servo Controllers ........................................................ 185 15.8.5 Knowledge Base for First-Order Linguistic Processors .................................................. 185 15.8.6 Knowledge Base for Higher-Order Controllers ............................................................... 186 15.9 Bottom-Up: the TUG As a Learning Machine Host ................................................................. 187 15.10 XML as an Interchange Language ...................................................................................... 193 15.11 Using XML to Link Modeling Systems ................................................................................. 193 16.0 Emulation of Swarm Behaviors .................................................................................................... 195 16.1 Symbiotic Relationships ........................................................................................................... 196 16.2 Foundations for Growth ........................................................................................................... 196 16.3 Nature’s Exemplars in Swarm and Emergence ....................................................................... 196 16.3.1 Distributed Leadership .................................................................................................... 197

sysRAND Corporation

v

Autonomy as an Operational Element of Planetary Surface Systems 16.3.2 Behaviors Common Among Swarm Species .................................................................. 197 16.3.3 Behavior Divergence Introduced by Specialization ........................................................ 198 16.3.4 Communications Modalities ............................................................................................ 198 16.4 Limitations of Swarm and Hive Paradigms .............................................................................. 198 16.5 Objectives of Collaboration ...................................................................................................... 200 16.6 Application of Distinctions ........................................................................................................ 200 16.6.1 Proximity and Density of Individuals Effects which Protocol State is Operant ............... 200 16.6.2 Follow Those Who are Changing Direction .................................................................... 200 16.6.3 Simplicity Enhances Reliability ....................................................................................... 201 16.6.4 Reliability Enhances Individual Integrity and Lifespan .................................................... 201 16.6.5 Inherently Redundant by Definition ................................................................................. 201 16.6.6 Autonomy is a Prerequisite ............................................................................................. 201 16.6.7 Coherent Interactions Require Consistent Protocols ...................................................... 201 16.6.8 Distributed Control Systems Require Feedback ............................................................. 201 16.6.9 The Low Energy Trajectory ............................................................................................. 202 16.6.10 Differences Of Context will Effect the Applicable Protocol State .................................... 202 16.6.11 Separation Based upon Proximity and Density .............................................................. 202 16.6.12 Separation Based upon Work Progress.......................................................................... 202 16.6.13 Ground-Level Perception can be Enhanced by other Sensor Views .............................. 202 16.6.14 Self-Interest Serves the Group ....................................................................................... 203 16.6.15 Uniformity in Swarms Suggests that Specialized Systems must Emerge ...................... 203 16.6.16 Specialized System Elements will Notify the Swarm of Their Presence ........................ 203 16.6.17 Communication is Essential to Swarm Integrity .............................................................. 203 16.6.18 Learning in a Swarm ....................................................................................................... 204 16.6.19 Scaling Swarm ................................................................................................................ 205 16.7 Swarm-Based Collaboration .................................................................................................... 205 16.8 Establishing Scale ................................................................................................................... 206 16.9 Shaping Rules for Collaboration .............................................................................................. 207 17.0 Closing Thought ........................................................................................................................... 209 18.0 References ................................................................................................................................... 211 Appendix B: Metacodes Support Mission Assurance .............................................................................. 213 Activities That Generate Event and Exception Reports ....................................................................... 214 Events and Exceptions that Generate Reports .................................................................................... 215 Flow of Data and Metadata................................................................................................................... 215 Activities That Monitor Event and Exception Reports .......................................................................... 216 Passive Console Processes ............................................................................................................. 216 Interactive Console Processes ......................................................................................................... 217 Spacecraft Autonomy ....................................................................................................................... 217 Notional Structured Metacodes ............................................................................................................ 217 Registry ............................................................................................................................................ 218 Encoding Schema ............................................................................................................................ 219 APPENDIX D: Combustion Synthesis Fabric .......................................................................................... 221 APPENDIX E: EXCAVATOR STATUS .................................................................................................... 223 Excavator Blade Upgrades ................................................................................................................... 223 Buckets ................................................................................................................................................. 225 Bucket Thickness ............................................................................................................................. 226 Bucket Effectiveness ........................................................................................................................ 226 Sprocket Redesign/Touch-Up to Minimize Wear.................................................................................. 227 Dust and Rock Mitigation and Exploitation ........................................................................................... 229 GRC Sandbox Test Fixture................................................................................................................... 230 Design of Adjustable Laboratory Excavator Mount .......................................................................... 230 Construction of GRC Mount ............................................................................................................. 231 TUG Jr., The Little Red Mobility Platform ............................................................................................. 232 APPENDIX F: GLOSSARY ...................................................................................................................... 240

sysRAND Corporation

vi


CAUTION: This is a capture document, an emerging corpus of thought that accretes the contents of other documents, sundry notes, illustrations and many other elements – it does require myriad edit iterations to make the document self-consistent and coherent. A very large fraction of the document begins as an idea, concept or factoid embodied as a bullet. There exist a number of missing or incomplete sections that are identified by outline headings, or text fragments. This entire document is a top-down/bottom-up iterative development that will continue until the general system that it describes is instantiated. There are operational or applications topics that are abstract, while other topics speak to the nuts and bolts of hardware, or the details of software. At some point these two domains will bridge, forming a continuum from the micro to the macro, and the reduction and construction methodologies will have performed their intended roles. The resulting non-deterministic mechanism will be seen to interact with a sometimes unpredictable environment in an intuitive way. There are numerous instances of a Work-In-Progress flag throughout this document. These reflect an effort that is equivalent to thinking-out-loud on paper, a process that has been underway for well over a year, and continues . . . This capture document requires a rigorous rewrite cycle to make it easier for the reader, and without the use of a hardhat. This capture approach has been proven to deliver high-quality results that are descriptive and can be easily translated to architecture, hardware, and software documents. The next major step is to begin detailing processes by specifying the programs that instantiate these concepts and their integration. The control software defined herein will be hosted on workstations, driving a UML command stream to the Digital Space TUG Simulation, until hardware is available.

sysRAND Corporation

vii

Autonomy as an Operational Element of Planetary Surface Systems Abstract: The Space Exploration program could substantially benefit from platform autonomy, though the same degree of benefit in the near term is not as obvious when considering swarm and hive architectures in planetary surface operations. This is due to the low density of the platform populations, their size, their energy budgets, and their functional partitioning. Swarm behaviors have merit, when multiple platforms are working on the same project, otherwise, swarm has little to offer. Swarm and Hive Behaviors are ubiquitous in nature and it is likely that there are more instances of swarm species that are still to be discovered than those that are currently recognized. The fundamental mechanism of swarm is that complex behavior emerges from simple rules universally imbedded in the DNA of animals. The lead attribute of swarm and hive is that simple interactions among individuals of the swarm have significance in the context of a larger scale. Another principle is that individuals of the swarm are autonomous and, other than reproduction, are quite capable of living as individuals, albeit at both a higher risk of predation and at a loss of common quarters. Swarm species generally have very few tools with which to interact with their environment; these include mandibles, saliva, teeth, and stingers. Swarm species also have limited ability to communicate with each other; their collaborative behaviors are dependent upon a few atomic symbols and occasional chained-symbols for additional semantic value. Swarm architectures compensate for their gross inefficiencies in work and communications through the use of overwhelming numbers, which self-organize into groups wherein a large number of individuals contribute the many small steps necessary to accomplish a task. The industrial age realized the advantages offered by tool specialization and would thus argue against the use of primitive, one-type-fits-all, swarm or hive architectures at the tool level. However, group protocols are appropriate for traffic management and navigation of mobility platforms that host modular tools. In most cases productivity, communication bandwidth limitations, and round-trip communications lag would demand autonomy to the extent to which it can be employed after touchdown, and such autonomy could be enhanced by swarm in at least navigation and worksite traversal protocols. Civil Engineering, mining, structures, and facilities deployment require a large number of specialized task functions. Large-scale tasks could be accomplished by a large number of small swarm platforms when they are partitioned into discrete, atomic steps. Unfortunately, available energy technologies do not scale in a way that aligns to such platforms. The inefficiencies of numerous small platforms using identical tools would not be practical while launch and mission costs remain prohibitive. Since tools may be interchangeable at the module and platform level, and a mobility platform may deploy two or more tools simultaneously, the perceived advantages of swarm and hive are diminished at the tool level. Creative synthesis of swarm architectural elements with autonomous operations results in a hybrid methodology, which has substantial merit and is likely to be superior to any of the antecedents for this application. The Multi-Purpose Excavator Demonstrator (MPED) is an industrial-class excavator under development by sysRAND for planetary surface exploration and development. This low-power unit is scaled to support civil engineering, In-Situ Resource Utilization (ISRU), and science activities at production rates of up to one metric ton per hour. The device is a bucket ladder with heritage derived from projects originally developed by the Colorado School of Mines. The current device will be used extensively to study the physics of digging in simulated Lunar conditions. A successor design is on the drawing board that will be yet more robust, remotely serviceable and, ultimately, more autonomous. Technical capabilities developed in the Small Satellite community are being translated to other space applications. Concurrent with the excavator project, this company has been developing hardware and software tools for the Air Force Research Laboratory’s (AFRL) Space Plug and Play Avionics (SPA). This capability is also consistent with our participation in international standardization efforts of the Consultative Committee for Space Data Systems' Spacecraft Onboard Interface Services (CCSDS SOIS). The Excavator control system is based upon a COTS industrial controller, to be augmented by AFRL's SPA-E (Ethernet) and SPA-U (USB) Plug 'n Play interface standardization. These controls are further extended for realtime scientific data acquisition of environmental parameters such as plasma flux,

sysRAND Corporation

viii

Autonomy as an Operational Element of Planetary Surface Systems magnetic and electrostatic field strengths, etc. The excavator will employ a universal tool coupling that encourages the interchange of a wide variety of tools, including a number of robotic arms and mobility turrets. This coupling will also connect the SPA-E (Ethernet derivative) from the vehicle to the excavator controller, which is consistent with NASA's extensive use of Ethernet throughout many of its space mission architectures. The SPA-U (USB derivative) interface will be used for sensor interfaces and local IO processing of excavator servo and sensor inputs, along with sensors which measure the ambient environment and the platform's interaction with it. The goal is a fully operational system that employs autonomous and semi-autonomous operation, using a modest energy budget and minimal human supervision and intervention. To achieve autonomous operation of planetary surface platforms we first reduce an application, a representative mobility platform, autonomy and swarm features and mechanisms to their fundamental features. With reduction producing building blocks, we begin the synthesis and integration of an autonomy model that can be simulated in realtime. Applications include civil engineering and in-situ resource utilization in support of long-range logistical objectives. The excavator has been modeled at a production rate in excess of 1,000 kg/hr of Lunar regolith and will be integrated with a universal tool coupling, a robotic turret arm, and a mobility platform.

sysRAND Corporation

ix


“If a solution is esthetically correct, it is very probably mathematically correct.” a sysRAND Design Tenet

sysRAND Corporation

x


Automating Planetary Surface Operations

sysRAND Corporation

1


1.0

AUTOMATING PLANETARY SURFACE OPERATIONS

Long-term exploration efforts on the Moon and Mars will be sustained through logistics that will be hugely augmented by civil engineering and ISRU mining activities on planetary surfaces. Adaptation of human beings to these new homesteads will be largely influenced by the intimate integration of anthropocentric culture and technology with foreign and hostile planetary environments. Tools will be mankind’s interface that subdues the raw planetary environment. Robotic platforms and tools will be the agents for Lunar Exploration and ISRU operations; early implementations will rely heavily on tele-operated control. The evolution of robotics continues with platform autonomy, progressing to collaborative interaction and then task partitioning based upon specialization. Such a technological progression will necessarily occur in both large and small steps. The reason that expensive spacecraft need autonomy: The Mars Rover Spirit, once landed on the Martian surface, could not properly bootstrap its mission computer. The vehicle attempted to reboot dozens of times, and was at risk of being permanently lost since it was being denied the use of its solar panels. Without data, the one of the JPL crew guessed that the computer’s FLASH memory was full, interfering with the boot process. JPL was able to remotely erase enough files on the FLASH memory that a complete bootstrap was finally accomplished, the solar cells deployed, and the batteries recharged – saving the mission. When Opportunity landed a few days later, the FLASH was partially erased before any other step in its deployment commenced. In an autonomy context, the scenario would play out differently: The Mars Rover Spectre, once landed on the Martian surface, bootstrapped its mission computer and then found that its FLASH memory was full. Spectre dispatched MetaCodes that indicated its situation to ground controllers, and while awaiting its next command from mission control, erased datafiles not associated with the mission software configured for the bootstrap phase. Spectre next deployed its solar panels, topped off the charge in its batteries, and finally shut down for the night, since the round-trip reply would be in excess of four hours, which would arrive while Spectre was two hours past twilight. The family of intelligent, modular tools envisioned by the sysRAND team for space exploration and development will be required to operate in a hostile environment that includes: • • • • • • •

hard vacuum, cryogenic temperatures in shade, boiling temperatures in direct sunlight, high-voltage electrostatics, intense, destructive radiation, high wear and abrasion from Lunar dust, and extreme winds, abrasive dust, dust storms, and corrosive Martian soils.

The space environment is considered hostile because the elements are persistent, deep, and can only be ameliorated in small volumes. These environmental factors can only be conquered on a scale that lies beyond our current technologies. To operate in this environment on a sustained basis requires that the tools: • are frugal with energy, • are highly reliable,

sysRAND Corporation

2

Autonomy as an Operational Element of Planetary Surface Systems • are easy to repair or self-repairing, and • require a minimum of supervision. Presuming that modular platform and tool ensembles exist that have these attributes, there are two operational challenges to be solved that are inextricably linked. The current state-of-the-art in control requires near-fulltime link bandwidth for successful mission execution. However, numerous problems impede the quality of communications delivery and by extension, control. These problems are not limited to: • significant propagation delays, some in terms of hours, • link discontinuities, such as schedule discontinuous, or loss-of-signal events, • bandwidth limitations and demands on capacity, • path losses, • subsystems outages or failures that aggravate already scarce resources, and • limited power source capacities. Similar demands made by early ICBM development spurred great advances in high-density integrated circuits for missile guidance by reducing power budgets and increasing computational throughput. We are on a similar threshold where the demands of system control require reduction of the dependency on communications. The clear solution to this problem is to enable the remote platform to make many of the platform/tool decisions autonomously and thereby substantially reduce the requisite fraction of bandwidth applied to command and control. The density of electronics and signaling that defines surface exploration will demand that all elements (or agents) involved in the exploration or exploitation activities operate at frugal energy and bandwidth capacities. Autonomy is consistent with the notion of allowing the spacecraft to manage its own affairs, leaving ground control centers to manage the exceptions. Local decision facilities also have the effect of increasing total system productivity by orders-of-magnitude. This is due to compaction of the total roundtrip latency to local compute time, which is further enhanced by: 1) allowing servomechanisms to operate at a quicker tempo and 2) pipelining and overlapping (phased) computations that anticipate events and actions, a priori. Autonomy further facilitates the reduction in communications bandwidth through the expedient of abstracting Command / Result Descriptor packets and increasing the semantic content or value of command codes, resulting in valuable communications at a substantially reduced verbosity. An Electronic Work Order (EWO) reflects a refinement of this abstraction as it delivers the worksite coordinates, suggested route from the depot yard, equipment module(s) to be extracted from the toolrack, and stores to be drawn from supply; all are accomplished by the mobility platform without the drudgery of micro-level instructions delivered at a sluggish, measured pace. Productivity matters; the command and communications burden can diminish a fine piece of equipment to a reluctant, sluggish marionette. Autonomy at sysRAND is a convergence of several research threads, which include funded and unfunded IRAD projects as drivers. These projects include a number of early-stage efforts that have barely progressed beyond concept or definition. As sometimes happens, the deployment of modular tools such as the Multi-Purpose Excavator Demonstrator (MPED) has catalyzed the need for a control architecture that is somewhat divergent from orbital spacecraft; definition of that architecture is driving projects that are in their germinal stages. 1.1

LOW ENERGY TRAJECTORY

Our view of autonomy was initially cast as a fusion of external situational awareness and internal management of a satellite’s state. This seemed adequate since a satellite’s next instantaneous state is inevitably dictated by the current orbital vector, inexorably continuing until the satellite asserts a proactive state that diverges from its flightpath (or something catastrophic occurs). Considering the control models that might be necessary to sustain the static model of a planetary robot, we later included aggressive goal-seeking as a necessary step towards self-referential, autonomous mechanisms. Unlike a satellite, a surface vehicle must proactively exert energy in some direction, and whether the result has utility is precisely what autonomy must prognosticate. A mobility platform must conserve energy and apply

sysRAND Corporation

3

Autonomy as an Operational Element of Planetary Surface Systems energy towards accomplishing the many tasks assigned to it. Aggressive goal-seeking also seems a necessary adaptation if emergence models were to be relevant to the final working paradigm, if such a thing can be said to exist, short of cognition itself. The subtle competition of a swarm has to be driven by individual objectives or the individual swarm member has no reason to act, except to follow. In swarms, individuals lead, others follow, yet all share common, DNAencoded objectives. Spacecraft will benefit from autonomous operation precisely because autonomy promises to frequently manage unexpected and unknown situations. In a role similar to that performed by autonomy and swarm for organisms, the spacecraft must also benefit by conserving energy and avoiding harm. Early autonomy software must be sufficiently robust that it can manage a large fraction of those situations that it encounters, substantially reducing communications bandwidths, an oft-repeated rationale for autonomy. Autonomy promises to consume substantially more power for computations than would be conserved by a reduction of communications bandwidth, so that fails to provide the solid second justification. A much more compelling justification for the use of autonomy by mining and civil engineering interests should be productivity. The Mars rovers Spirit and Opportunity accomplished a great deal of science data acquisition while traversing the rock-strewn landscape at a rate of inches per hour, such rates are unworkable for ingesting or relocating regoliths at metric-tons-per-hour pace. These requirements must be measured against the capabilities of conventional spacecraft that have few autonomous features, as well as an avionics discipline that does not allow for the unexpected or the unknown. Conventional avionics and control systems are rigidly deterministic and are suited to an infrastructure that is similarly doctrinaire. Conventional systems are deterministic, and approach zero utility when they are thrust beyond the scope of their programming into an environment incompletely understood by their designers. Since computer programs are simply abstracted models of real and abstract domains, the mechanics of autonomy are necessarily non-deterministic, because the domains being modeled span from the barely known to the mostly unknown. If determinism is demanded, then the outcome of autonomous processing must be the metric, where the result of autonomous deliberations is deterministic, and not the internals. Instead of a finite domain of fixed stimuli that reliably map to a domain of fixed responses, the new performance objective is to achieve one or more predicted outcomes by way of non-deterministic software decision pathways. The predicted decisions can be pruned as situational inputs are refined. 1.2

INTRINSIC AUTONOMY

The goal of autonomy disciplines is to develop machines that can operate without humans-in-the-loop to interpret sense data and direct every motion at every scale. The degree to which autonomy is able to free a machine from the limitations of distant control becomes an index to the productivity of the machine. Features that are intrinsically autonomous are also free. The issues of autonomy are numerous, and include the problems of deterministic automata interacting with an unfamiliar, non-deterministic environment. At some level, the unknown becomes familiar, and known. Data that is descriptive of the environment is gained through sensors and recalled, on demand, from high-speed memories, closing the chasm between the unknown and known. Automated machines have the facility to exchange copious amounts of environmental data, realtime, along with processed data and metadata that begin to provide abstractions about the environment – all without suffering the degradation of the data suffered when humans attempt to convey data among individual brains. In effect, given sufficient local communications bandwidth, machines will widely share environmental and navigational data. Although such data is derived second-hand, the fidelity and precision of the data is very high, and the machine is poised to accept such data as being as reliable as that derived from its own sensors. The presence of metadata serves to validate and correlate the new, foreign data against a machine’s local mappings. The availability of such sensor data will also, on occasion, provide images and other sense vectors that become self-referential inputs to a machine – much like images in a mirror,

sysRAND Corporation

4

Autonomy as an Operational Element of Planetary Surface Systems such inputs help to shape a machine’s awareness of itself. Such awareness is not yet cognition. Environment shapes a machine’s autonomy, in a way that recalls that the machine was deliberately designed to perform specific functions within one or more environments. Hardware design represents commitments that are deterministic and confine the machine to interact with any possible environment with whatever design features were imbedded by the designer. It remains the responsibility of the systems and software practitioners then to provide the machine with the flexibility to respond to those aspects of the environment that remain unknown, or if partly known as generalizations, those aspects of an unfamiliar place or feature. 1.3

ATTRIBUTES SHAPE AUTONOMY

Satellites have intrinsic aspects that begin to define the nature of autonomy for the systems designer, and these are intrinsic because they are inseperable from the platform as long as it remains in its operating domain (i.e., in orbit). Among those aspects are the satellite’s velocity vector plus the Earth’s gravity vector, that together form a rigid determinism subject to atmospheric drag, gravitational, and tidal effects of third bodies. As a result, the systems designer in search of autonomous operations, has a strongly deterministic advantage in being able to predict for very long intervals the location of his satellite – an attribute that the ancients would term “destiny.” Discounting for the moment the internal state of the satellite and its ability to perform its mission, the vehicle will reliably continue on its course with no further control inputs from the control center. The satellite’s destiny contrasts strongly with the mobility platform attached to a planetary surface by the unrelenting pull of gravity, a platform’s destiny is that it isn’t going anywhere until it receives a control input to expend energy. Gravity is the principal intrinsic feature that drives the autonomy model for surface platforms. Like the satellite, however, the surface platform will have internal states to be managed and many are nearly identical with the satellite. Another intrinsic feature that biases any autonomy methodology is that the many internal operations of a mobility platform are seeking low-energy minima, and autonomy strategies must consider this reality. 1.4

SWARMS ARE THE ANSWER TO WHAT QUESTION?

Our current view is that adaptation of swarm protocols could enhance spacecraft and planetary surface operations. However, swarm is not a panacea that will solve every problem that has so far eluded us. It is far too easy, and far too often happens, that functions are forced and improperly integrated, often outof-context. For example, many pre-swarm hive architectures were little more than multiplexed teleoperated systems, centrally controlled and coordinated, architectures that added to bandwidth demands rather than diminishing them. Emulation of natural biological mechanisms is dependent upon functional contexts and the energy models that support their implementation. Natural hive systems are distributed systems and lack the central command authority often attributed, incorrectly, to the queen bee. (Her sole duty in life is to mate and lay eggs, and she remain oblivious to any other activity, elsewhere.) In contrast to early hive systems, swarm paradigms stress autonomy as a foundational prerequisite for the realization of swarms, arguing strongly against the use of central command authorities1. Autonomy is more consistent with the expectation that hive operations could substantially reduce the bandwidths needed for tele-operation of multiple robotic platforms. In a practical implementation, the total EarthMars, Earth-Moon, or plausibly Earth-Mars bandwidth is to be reduced by autonomous and swarm implementations. However, it should be realized that this reduction is offset by a much larger bandwidth in local, platform-to-platform and platform-to-facility communications. At the risk of waxing philosophical, we consider that any deterministic model will inevitably suffer as many deficiencies as there are infinite variabilities to be found in natural contexts, and in spite of the fact that thriving ecosystems probably don’t exist on the Moon or Mars, the complexities remain staggering. This reality is poignantly expressed by a prominent outdoorsman in terms of the trails and tracks of life in the 1

Recent and extreme examples of the impracticality of centralized command structures include the Warsaw Pact Central Command Structure, which has twice been discredited in Iraq.

sysRAND Corporation

5

Autonomy as an Operational Element of Planetary Surface Systems wild: “Each trail is one of a kind. The same combination of weather, land, temperature, and creature are probably duplicated no more often than snowflakes. The same interactions between so many variables probably never recur. Even within the easily identified, habitual gait of a person there are nuances made by the changing flux of emotions as he or she moved. The sheer variety of tracks is astounding; the amount that can be learned from them is irresistible.”2

Figure 1 Autonomous Platforms should be Self-Directing by Definition

2

The Tracker, Tom Brown, Jr., as told to William. J. Watkins, Berkley, 1978, p. 6.

sysRAND Corporation

6

Autonomy as an Operational Element of Planetary Surface Systems 1.5

THE MISSION

In order to provide robust logistical support to Lunar and Martian exploration programs, the utilization of Lunar-derived resources seems inevitable. In-Situ Resource Utilization (ISRU) is a multi-disciplinary field of applications that provide civil engineering, resource conversion, and manufacturing of expendables and hardgoods beyond Earth’s deep gravity well. ISRU structured in a Lunar Shipyard architecture can provide advantages that lead to fleets of deepspace craft for missions to Mars. The ‘bucket ladder’ is an excavation tool with a long heritage of industrial use, principally in the removal of overburden for open pit coal mines. The Multi-Purpose Excavation Demonstrator (MPED) is intended to be the technical lead device toward a family of devices that can extract Lunar Soil for an In-Situ Resource Utilization (ISRU) processing plant and perform Lunar civil engineering applications. The MPED represents a flexible mining system that can perform civil engineering operations including digging holes and trenches, constructing berms, smoothing road surfaces, trenching for sub-surface power cables, and moving and layering regolith to cover habitats and other facilities for radiation and thermal protection. The excavator is a low-energy device that can be expected to operate autonomously over a long duration. A production version of MPED would be expected to excavate 100,000 kg of Lunar soil per year, which observes a current “rule of thumb” for this class of device: that it should process 1000x the device mass in regolith per annum. This production metric is also bound by the projected first failure of the device, which will require calibration when performance data is available. The MPED is expected to perform several mining operations on the Lunar Soil, including continuous excavation and trenching of the terrain, breaking up clumped aggregations of soil, rejecting oversize rocks, etc. An excavator will not likely be effective if dust management remains an afterthought, retrofit or ‘tack-on.’ Operation of the excavator buckets and of the transfer elements must be evaluated for opportunities to incorporate Lunar dust as a component of the main flow of ore – not as a nuisance to be mitigated. The Lunar fines are valuable as a resource because they are among the most accessible and highest yielding ore within the lunar regolith size distribution. This is principally due to the high ratio of surface area to volume. Measures that capture the Lunar fines are very similar to those that could exploit volatiles containing several valuable mineral species and water. And like Lunar regolith fines, volatile capture is not an accident, but rather a result of deliberate design that will be enhanced by the second-generation “chainless” excavator blade and companion discharge chutes, etc. 1.6

METHODOLOGIES

In the sysRAND universe systems architecture is practiced by systems analysts as a deliberate design doctrine. Few things rate the label “systems architecture” unless they are truly an abstract systems definition that seeks to reconcile an application with an implementation opportunity. We find that the discipline is partly about recognizing patterns, whether making distinctions (that is, finding subtle differences among things), or deriving generalizations in the course of observing similarities among things. Systems architecture is also about properly partitioning the problem domain; this means that the analyst has to comprehend the client, especially the end-user, in his native context (which ties back to drawing distinctions). The implementation side of systems architecture is concerned with discerning and developing commonality and reusability, aligning functional domains to coincide in a coherent modularity, and assuring that partitioned elements will be sustained by the bandwidth and symbol semantics of the interconnect topology. The analyst/architect observes anomalous and non-linear natural phenomena and translates them into technology, often by revisiting prevailing assumptions. It is essential that the processes are opportunistic and serve to identify new syntheses of divergent technology / methodology or reintroduce of lost and misplaced technologies. While it is possible to misinterpret our methods as unfocused and/or scattershot, we challenge such a myopic view. While applications may be diverse, a similar systems rigor is

sysRAND Corporation

7

Autonomy as an Operational Element of Planetary Surface Systems repeatedly applied to reliably develop innovative technology fusions. A solution does not have to be complex or high-tech to be elegant. Low-tech solutions are the best candidates for implementation in early generations of indigenous ISRU – and they also support repairability and sustainability. Energy and material flows are viewed as regenerative systems. The architect should recognize the power of recursion as evidenced by the natural world at every scale and that although recursion was defined by computer programming, it was already a pervasive, though not yet formalized, universal process. Axiomatic to this is the use of metrics that are congruent with boundaries of natural phenomena at the many scales of mesoscalar domains. 1.7

SYSTEM MULTIPLIERS

The early phase of any systems analysis is usually a thorough examination of the application space. To derive an application model with fidelity to the “real world” it is essential that we drill down into detail that spans the operational context of a platform throughout its entire lifecycle. The excavator project is very much more than the development of digging hardware. For example, implementation of a fieldable architecture will require a reduction of projected large communications bandwidth plus management of the degradation that latencies impose on control precision and response. These constraints are already exhibited by the slow-motion control asserted with Mars rovers, making it especially clear that Lunar ISRU activities will require a minimum level of efficiency and productivity to justify their mass fraction at launch. The Mars rover missions are dominated by the need for safety; primarily the maintenance of platform integrity and minimizing the footprint of the platform on the planetary environment is a secondary concern. Productivity, efficiency, and safety will require a significant injection of platform autonomy if the ISRU mission is to be successful. A large mix of surface assets will populate Lunar Outposts and landing sites so that group behavior, or orchestration of numerous, heterogeneous platforms operating under separate command authorities, will be complex. There is an emerging, and tentative opinion that Swarm Architectures can be a very powerful paradigm for operations in congested Lunar worksites and outposts. When autonomy or swarm can contribute to the productivity of automated tools it eliminates the need for engineering to call out every operation to be made by every platform, second by second. Even something less than a full, rigorous swarm implementation will be adequate to the task. Achieving a credible level of autonomy is an objective of the sysRAND team, particularly since it is a necessary prerequisite for swarm. Swarm is nonfunctional in the absence of autonomy. An understanding of the Lunar Surface Systems operating domain is necessary before autonomous, swarm, or hive architectures can be correctly adapted to Lunar or Mars operations. The use of interchangeable modular tools of many types will prove to be a valuable feature on ISRU mobility platforms; this is in spite of the fact that a rigid, doctrinaire approach to swarm would insist that all platforms be uniformly equipped with a single, identical tool. Autonomy also provides for continuity of operation or graceful shutdown when a Loss of Signal event occurs. This capability enables continuous production to the next milestone or waypoint despite a lack of supervision from a control center, which contributes to productivity. Autonomy can also place the unit in a “safe” mode when it requires a decision outside of its processor’s scope, a fallback which is inevitable with today’s semi-autonomous operations. 1.8

ENERGY

Power sources impose constraints upon the implementation platform. Such constraints will relate to mass, size, range, loitering time, practical accessories, etc. The scale of a platform will also determine the extent of computational power available for the platform’s many subsystems. As autonomy begins to be formalized as a functional architecture, the minimal computer systems requirement to sustain autonomy will likewise crystallize. Since we view autonomy to be a necessary precursor for swarm

sysRAND Corporation

8

Autonomy as an Operational Element of Planetary Surface Systems behavior, follow-on development would implement collaboration protocols and a distributed command structure with considerable local latitude. Energy limitations will probably restrict near-surface agents to the surface, using wheeled, tracked, or articulated limb mechanisms. Using propellants in the quantities necessary for small landers to “hop” around the surface will amount to significant volumes, adding to demands on logistics. Recovery of those vehicles that stray out-of-range and commit other operational errors will also prove difficult. The comparative static operation of a surface platform is expedient insofar as the vehicle can be shut down indefinitely, or until a recovery vehicle can arrive with a battery charge. Additional limitations that argue against UAV analogs flitting about the Lunar surface include the need for onboard RADAR and image acquisition and processing, which continue to impose upon the power supply in a non-linear spiral that is typical of aerospace engineering problems. sysRAND intends to solve the power problem, while supporting round-the-clock operations through use of the Gamma Battery, 12.1.

Figure 2 Formations of TUGS Collaborate 1.9

ASSUMPTIONS

There are many assumptions in play for this device and its operation. Not all assumptions will surface to be visible; some will remain obscured by culture and complexity. Some assumptions already have our attention, however, and the following is only a partial list3: • the excavator is expected to be deployed on robotic precursor missions and manned exploration missions where low-energy, low-mass tools are a practical alternative to large and heavy equipment, • the excavator is expected to be deployed on missions that intend to bury cable, conduit, or pipe beneath the surface in a narrow and shallow, 1 to 3 foot deep cut, • the operating scenarios for this tool are many and flexible, • the regolith will be moderately-compacted with an imbedded scattering of rocks, and • not all soils will be suitable for mining, but most will have civil engineering applications. 1.10

SCOPE

This document provides a top-level functional and operational description of an excavation system, and is limited to operational, and shutdown segments. It also serves to illustrate in detail how the system might be used to meet the needs of the NASA Mars and Lunar Exploration Programs. This document is intended to provide systems architecture and methodology sufficient to draft specifications for software design and development.

3

A previously unpublished assumption that has been in play since day one is that the MPED would begin to incorporate features that would enhance the capture of volatiles from the regolith during the course of mining and civil engineering operations. The anticipated production rate of the MPED justifies this intent, as it is expected to be 1,000 Kg per hour. If recent research is correct, the MPED would flow a quart of water per metric ton of regolith (est.) through its production flow, which must not be lost to space.

sysRAND Corporation

9


Excavator Mining/Civil Engineering Applications

sysRAND Corporation

10


2.0

EXCAVATOR MINING/CIVIL ENGINEERING APPLICATIONS

The applications specific to the excavator meet long-range planetary surface exploration and development objectives. NASA has historically shown little interest in many of these tools; tools such as these imply permanence as well as growing an industrial plant to provide logistical mission support through the use of resources indigenous to the planetary surface. The principal applications for the excavator fall into two principal categories: civil engineering and In-Situ Resource Utilization. Another application is scientific sampling, but there are many devices, such as corers, that better meet this need and are much easier to deploy. A first cut at scaling the material flow for each application class is depicted in Figure 3. The applications available to the blade are dependent upon the agility that is evidenced in its design and implementation. For instance, the excavator blade can be fixed to the mobility platform’s line-of-travel; the 10 cm kerf of the excavator takes advantage of the regolith’s vertical angle of repose/critical angle, supporting trenches for cables, conduits, and footings. The same blade can be swept on two axes for a larger effective cut (depth) and kerf (width), which enables larger volumes to be ingested for bulk processing in short horizontal runs. Civil engineering cable and pipe applications will require narrow kerf trenches, yet other uses for the blade would make use of repetitive sweeping, including ISRU. This sweeping could be horizontal or vertical, or a combination of both motions, nested, as shown in Figure 55.

Figure 3 Scaling Excavator Applications Civil Engineering applications for the excavator blade include berm construction and stabilization, trenching for sub-surface power cables, fluid conduits and footings, digging holes and trenches (for structure emplacement), burial of structures (for radiation, micrometeoroid, and thermal protection), and leveling of surfaces for landing pad preparation. Civil Engineering also provides indirect support of ISRU by building the infrastructural facilities necessary to house processing and manufacturing facilities. In-Situ Resource Utilization applications are centered on surface mining of regolith in bulk quantities sufficient to support oxygen separation, metals extraction, glass production, and the capture of volatiles loosely imbedded in the regolith matrix. Mining regolith and volatiles will vary by soil compaction and related conditions. The excavator is expected to operate in a range of control modes, responding to work orders, traffic advisories, and dispatches received from domain management centers – global, regional, local, and onsite. Excavators perform tasks such as trenching for cable and pipe, structure emplacement, structure burial, berm construction, landing pad and road preparation, etc. Given the recent discoveries of water on the Moon (LCROSS, et al.), operations that mine regolith “ore” will be expected to glean volatiles from the production flow. It may also be practical to sift for volatiles from regolith excavated for civil engineering constructions without interfering with the flow of regolith in a substantial way. This is an attractive option due to the fact that civil engineering applications will disrupt much larger volumes of regolith than will surface mining.

sysRAND Corporation

11


Figure 4 Simulation Rendering of the Excavator Contact Aspect 2.1

TRENCHING FOR CABLE AND PIPE

Trenches for utilities include cable and pipe in support of power, data, environmental sensing, transfer of cryogenic and other fluids, etc. These constructions are among the easiest to perform since they generally require a kerf, or width, equal to that of the excavator blade, 10 cm. The angle of repose and the critical angle of Lunar soil is understood to support a near 90° wall indefinitely, which will simplify cable installation. BLE forces through time 250

Total force on bucket (N)

200

150 Series1 100

50

0 0

500

1000

1500

2000

2500

3000

3500

4000

Sim cycles (100hz)

Figure 5 Rendering Physics Simulation Profile 2.2

STRUCTURE EMPLACEMENT

In anticipation of the arrival of structures for habitats, laboratories, shops, garages, airlocks, corridors, mud-rooms, and the many other functions required to support human habitation, large scale excavations will be required. The succession of nested trenches depicted in Figure 6 illustrates how the excavator can remove a large volume of regolith, most of it compacted. Recursive trenching of the surface creates a rough stepped-trench which is easily smoothed by any number of methods, including metal frames (which could have other uses before being converted to a drag-rake). The scale is based upon 1 with the diameter of the cylinder at 20 units; all other numbers are relative.

sysRAND Corporation

12


Figure 6 Step-trenching to Imbed a Habitat of 20 Units Diameter The volume of regolith removed from the cut can be expected to expand somewhat from its compacted state, although some ‘fly-away’ shrinkage of regolith fines should also be expected. A secondary tool can be used to groom the steps into smoother slopes and a drag-rake is probably the best, cheapest candidate. Such a device can be predesigned into the load-bearing walls of a lander and detached from the vehicle after touchdown.

Figure 7 A Drag-Rake without Prongs 2.3

POSTHOLES

One way to imbed a post into the surface is to ram it with a star-hammer type of tool4 called, predictably, a post-driver. The excavator is also capable of digging narrow vertical shafts to a depth of ~ 110 cm (3.7 ft.) or more and as narrow as a diameter of ~ 30 cm, which can be increased by maneuvering the blade. 2.4

STRUCTURE BURIAL

The schematic in Figure 8 indicates that the volume of regolith excavated for imbedding is nearly sufficient to provide the 6 ft. or more of shielding and micrometeoroid protection, generally accepted as 4

See Figure 37 Tug with Star Hammer Drill in Forward Position.

sysRAND Corporation

13

Autonomy as an Operational Element of Planetary Surface Systems sufficient for the purpose. Again, the units are not specified and are relative. The depth at which a habitat, laboratory, or garage is to be buried depends upon whether the structure may be practically unearthed and relocated. Thus, it is likely that a cylindrical habitat would be lowered into a stepped trench to its equator, i.e., halfway, and then covered over. The most economical approach would have the volume of extracted regolith at least equal to the volume deemed necessary to bury the structure. Therefore, the minimum cylinder required to yield sufficient displaced regolith, in order to achieve coverage of at least 6 ft., has a radius approaching 15 ft. (~5 meters).

Advisory: The excavator Blade with Pintle-Chain is not intended for use in horizontal “scraping,” and such operation is not recommended, since it would result in lateral stresses sufficient to derail the chain. This mode would also excessively load the drive motor with as many as seven buckets simultaneously engaging the surface, which would cause excessive wear-and-tear, in addition to excessive power draw, both of which will degrade the blade’s service life.

Figure 8. The Volume of Excavated Regolith at the Habitat’s Equator is Approximately Equal to the Required Overburden 2.5

BERM CONSTRUCTION

Berms are constructed by dumping excavated regolith in large mounds. Mobility units may damage the uncompacted mound; to obviate such an occurrence, an electrostatic cannon may be used to dispense bulk regolith to form the berm. This may be also an opportunity for the excavator to be enlisted as a conveyor of regolith to the crest of the berm. Sheets of Combustion Synthesis Fabric may be dispensed from rolls to stabilize berms or other expanses of regolith. CSFabric is used as a cover for regolith surfaces and can also be placed between interposing layers of regolith that are deployed by excavators. Once positioned, the CSFabric is “fired,” creating an irregular surface as it binds regolith to the fabric, which then provides large extents of tensile connection across the otherwise unconsolidated regolith. The fiberglass core of the CSFabric is unaffected by the burn. The CS burn occurs around 700° – 800°C, a safe ignition point that should be compatible with flight safety concerns. Since fiberglass doesn’t begin to soften until over 2,000°C, the burn leaves the fiberglas intact. For a description, see APPENDIX D: Combustion Synthesis Fabric.

sysRAND Corporation

14


Figure 9. Berms can be Reinforced with Combustion Synthesis Fabric Surfaces can be contoured with CSFabrics and specialized applications can be serviced by engineering the density of fabric plies and the volume of regolith in the interposing cavities. Landing Pad Surfaces, for example, would use regolith layers of an inch or two between CSFabric plies. Footings can be lined and enclosed with CSFabric.

Figure 10 A CS Fabric Dispenser Works with Other TUGs that Cover the Fabric with Regolith Prior to Firing CSFabric is an early product that can be manufactured by ISRU plant modules, using ISRU-derived feedstocks. This could be accomplished in generation 2 or 3 of ISRU development.

Figure 11 Contoured Berms can Deflect Lander Exhaust Plume and Debris

sysRAND Corporation

15


Figure 12 Deflection Berms Have the Effect of a Large Berm Figure 12 depicts the use of concentric berms to enclose a landing pad in order to avoid the effect of a “hurricane” blowing away the Lunar Outpost and other vital facilities. These deflection berms are small and are intended to induce turbulence in the horizontal exhaust plumes from heavy landers. The thought is that they may have the effect of a much larger emplacement by such an induction.

Figure 13 Early Deflection Berm Simulation Program Output sysRAND is conducting an IRAD project to characterize the behavior of a series of berms, especially for landing pads for the large landers of the Constellation program. We are determining the size, interval and number of berms that would be required to have the same effect as an otherwise large berm. Each of the deflection berms are constructed from regolith encased and layered with Combustion Synthesis Fabric. A second version of the simulation has been completed and a GUI is being developed that allows the user to load model parameters for custom simulations.

sysRAND Corporation

16


Figure 14 A Low-Energy Disposal Method for Rocks

sysRAND Corporation

17


ROCK MITIGATION

The excavator can ingest small rocks, which are easily separated from the ore after volatile capture. Larger rocks can be pulverized or moved by the excavator’s Star Hammer Drills. Still larger rocks that are in the path of a cable run or obstruct the continuous surface of a landing pad can be disposed of with a small expenditure of energy. One method is shown in Figure 14, where an oversized pit is excavated in the proximity of the obstructive rock. The rock is then pushed or towed toward the pit, collapsing the pit wall and burying the rock below the surface. The excavated regolith is then plowed into the pit and the excess regolith, equal to the rock’s displacement, is used elsewhere. Some settling and compaction should be considered before final finish, which could be CSFabric in the case of a Landing Pad Surface. Rocks can also be trimmed with Star Hammer Drills to near-spherical shapes, rolled to the perimeter of a landing pad, and deposited in a shallow depression scalloped by the excavator. These rocks, when positioned, can serve to anchor the deflection berms. Combustion Synthesis Fabric can be fused to the rock directly by means of a CS burn, or an end of the fabric can be pinned beneath a rock. 2.7

LANDING PAD PREPARATION

The excavator can smooth the bumps out of a piece of real estate and erect berms to entrain the waves of high-velocity exhaust plume impingement. Merely sintering the landing pad surface into a crusty lamination may not provide the tensile strengths and surface cohesion sufficient to deflect the blast effects of a new generation of Lunar Landers without suffering extensive damage. When the exhaust streams penetrate the sintered crust, ‘chunks’ of heat-fused soil will resemble glass shards in flight. CSFabric could provide the structural continuity and interleaved treatment of the entrained regolith with Microwave Sintering, thereby adding compressible thickness to the assembly. Pad preparation includes rock mitigation. 2.8

TRENCHING FOR A.C. POWER CABLES

A NASA researcher has determined that D.C. power cables buried beneath the Lunar surface will overheat and melt, ultimately opening the cable in one or more places. Yet A.C. is currently not being considered, a position that re-opens the classic dispute between Thomas Edison (General Electric), whose intellectual properties (IPs) were all Direct Current-driven (DC), and Nicola Tesla (Westinghouse), whose IPs were Alternating Current-driven (AC). This debate should be settled, provided it is based on facts and not subject to rigid agency practices. Since power is precious to space operations, the more efficient AC should be employed by industrial-class operations. These are not flight systems and should be available for the introduction of superior AC technologies. AC has at least three powerful advantages over DC, all of which stem from the fact that AC’s waveforms are dynamic, energetic, and kinetic vs. DC’s static energy, which is strictly derived by potential differences. AC-driven devices are generally smaller and lighter than corresponding DC units, again due to the more energetic nature of the dynamic AC sinewave vs. a static DC potential. To DC current a power cable is a low-resistance resistor that will cheerfully dissipate energy along its entire length, and non-linearly at that. Power dissipation in the DC cable is governed by P = I2 * R. The AC model is significantly different. When an AC cable has a balanced load, the voltage and current waveforms are out-of-phase by ninety degrees, which means that the product of the current and voltage, a balanced load, has equal inductive and capacitive load factors. Inductive loads are typical of AC circuits, e.g., wire, motors, and coils, These can be electronically balanced through the use of switched capacitors to maintain the voltage-to-current phase relationship. The most lightweight and effective insulation is the regolith itself. Gary Olhoeft, of the Colorado School of Mines, et al., has discovered that the Lunar Regolith is a good insulator, both electrical and thermal, until it approaches its melting point. This assures us that a DC cable would most decidedly heat up to its melting point, at which point the molten metal would pool, breaking the circuit.

sysRAND Corporation

18

Autonomy as an Operational Element of Planetary Surface Systems NASA has offered proposal topics in search of lightweight and effective power cable insulators. sysRAND has not yet submitted our solution to these solicitations, although we have had numerous conversations with agency staff regarding A.C. power transmission. Another measure that would reduce power dissipation would be the use of three-phase power, a method that also eliminates the need for a ground wire. An additional measure would be the use of an elevated operating voltage, an approach that trades current for voltage at an equivalent power figure. Since current is the non-linear factor in I2R, a few amps drawn through a few ohms, dissipated across a thousand feet, should not excessively heat the cable. 2.9

SURFACE SURVEY DATA ACQUISITION

The Excavator is closely coupled to a planetary surface like few other devices. It has the opportunity to glean science data that is intrinsic to its excavation functions; through its very presence on the Lunar surface the platform can gather information about its ambient space environment. In the macro sense, topological and subsurface data may be compiled through scientific reconnaissance, while the platform is navigating cross-country and within the worksite. Lunar surface data may be accrued at several scales. The coarsest of these would be Navigation RADAR that can be used intermittently in low-power mode for near-field sensing and in high-power mode for acquisition of distant landmarks and approaching traffic. RADAR will be a rich source of data that can be correlated with similar (landmark) data from other platforms and sorties to continuously enhance the quality of navigational, topographical, and geomorphological compilations. Additionally, RADAR transceivers can be equipped with transponders in order to insert identifiers and positional data in the return echo, a method identical to altitude-encoding aircraft transponders. This feature provides continuous, realtime exchange of information that improves situational awareness, navigation and safety. An intermediate scale would take advantage of the high-accuracy navigation of the TUG to create an image log of the subsurface in strips, which may reveal imbedded rocks (impactors) and submerged crater rims and crevices. Since the TUG will be servicing sites widely distributed across the surface it can acquire data continuously through several sensing modalities. The TUG has the internal volume, power and mounting positions to support: • Ground-penetrating RADAR, • Gamma Cameras, • and Neutron Cameras. When the TUG enters IDLE mode, usually to recharge batteries, mission controllers can take advantage of the available bandwidth to upload large survey datasets from the GPR, Gamma, and Neutron Cameras. Lunar surface data may be also gathered in the micro scale through the sensing of regolith and volatile parameters. The Excavator will collect internal engineering data from which science can be developed. For example, the measure of current required to drive the blade’s motor is an indication of the compaction and cohesion of the regolith. The excavator will have extensions for realtime scientific data acquisition of the local ambient environmental. Some of the candidate sensors are: • Plasma Flux, • Magnetic Fields, • Electrostatic Fields, and • Anomalous Sample Capture.

sysRAND Corporation

19


MINING

Although the surface mining activities of the Excavator are modest from many perspectives, the team has been of the opinion that most surface mining activities should be conducted on the floor of craters, where surface extraction would have a minimal footprint. A recent science fiction film had other, sinister reasons

Figure 15 Bulk Mining of the Maria Could Alter the Lunar Albedo5 5

Image of He3 mining activities from Sony Pictures’ 2009 film, MOON.

sysRAND Corporation

20

Autonomy as an Operational Element of Planetary Surface Systems to mine on the Darkside of the Moon, as shown in Figure 15, but surely a mining operation would have to be sensitive to any scarring of the Lunar surface visible to the human eye. Another alternative to surface mining could be tunnels dug at shallow depths of the regolith, although a dry regolith may not hold a ceiling, and be constantly subject to collapse. Recent discoveries6 of Lunar water and hydroxyl ices provide a second reason for mining excavation in craters. Craters may be the window into the Lunar interior, which could save cutting away at overburden to reach lower strata. While there may be multiple origins of Lunar ices, it could be that subsurface regolith strata contains massive amounts of water, retained from the Moon’s violent formation.

Figure 16 Mini-SAR CPR (RADAR) Imaging of the Moon's Northern Hemisphere

6

Spudis, Paul D., Lunar and Planetary Institute, Space Resources Roundtable, 2010.

sysRAND Corporation

21

Autonomy as an Operational Element of Planetary Surface Systems It is these deeper strata in the crater floor and slopes that is wicking the ice and fluid water towards space, a process ultimately driven by sublimation into hard vacuum coupled with Solar radiation. The absence of frost outside of the perimeters of older craters would confirm this mechanism. There may be sufficient ice for consolidated regolith to maintain structure, particularly given the Moon’s 1/6th Earth-normal Gravity, and this would suggest that lateral mineshaft tunneling originating at the interior slopes of craters could provide water-laden regolith in high concentrations.

Figure 17 A Mineshaft can be Established on the Interior Slope of a Crater

sysRAND Corporation

22


Excavator and Support Elements

sysRAND Corporation

23


EXCAVATOR AND SUPPORT ELEMENTS

The principal feature of the Excavator and notional TUG is modularity. Partitioning designs along functional boundaries permits the reuse of large fractions of common elements, thereby amortizing design, development, integration, certification and operational experience. This means a reduction and elimination of notoriously recurring Non-Recurring Engineering costs (NRE) Functional module partitioning also presents an opportunity to partition software function to correspond to hardware function, again allowing common elements to be used as building blocks. An understated advantage that is derived from modularity is that it encourages innovation by limiting the scope of effort and cost required for evolutionary enhancements to be grafted into existing systems. Functional module partitioning also supports swarm systems by maintaining a high level of commonality, which is characteristic of strict swarm methodologies. Generalized robotic platforms will inevitably deploy specialized interchangeable, modular tools, which will alter how the hosting platforms interact with other agents. These methods are based upon the probability that some of these tools are massive and sharp objects, like excavators and hammer impact drills, or active-energy tools, such as welding torches and microwave horns. A complete excavator system includes a number of hardware components and associated operational elements. The hardware includes: • Robotic mobility platform • Mounting turret • Excavator blade • Discharge chute • Hopper • Volatile capture The Excavator Blade has made the most progress in hardware development. Certain tools, such as manipulator grips and welding heads, will be found in applications on the surface as well as in orbit. Nearly every tool will feature electronics and intelligent software so that they may be used safely, effectively, and indefinitely. Space Plug and Play Avionics is the first generation of systems intended to be prepackaged into functional partitions that can be parametrically controlled using preloaded software modules (or heuristically driven), eliminating conventional and specialized computer programming for each and every instantiation on the bench or in the field. 3.1

THE EXCAVATOR BLADE: GENERATION ONE

sysRAND Corporation has been developing an proof-of-concept, industrial-class excavator blade for planetary surface exploration and development under a NASA contract. This excavator is intended to advance the art and science of digging on the Moon and Mars while enhancing the relevant physics models. The excavator is representative of modular smart tools that will be developed for use on planetary surfaces, and is the key element of a front-to-back excavation system. These devices will be employed to support civil engineering, In-Situ Resource Utilization, search and rescue, spacecraft maintenance and servicing, structure construction and outfitting, manufacturing facilities installation and maintenance, and much more. Many of these tools will resemble the excavator because they will be esoteric, specialpurpose devices which do not generalize like a hammer or a socket wrench. These tools also have to operate for extended duration and be self-repairing in some ways; when they suffer a serious malfunction they may not be repairable for years – or at least until a “shirtsleeves” maintenance depot is erected. This document describes the use of a bucket ladder-based excavator that employs a pintle chain for sysRAND Corporation

24

Autonomy as an Operational Element of Planetary Surface Systems mounting and operating the buckets (scoops). While this device will be used to characterize the physics of digging, it is not intended to be the flying unit. A new generation of chainless excavator is being explored, which offers a number of enhancements, including some self-repair features and a lower mass. Design considerations include the power constraints of all-electric systems, temperature extremes, queuing issues, loose vs. compacted soils, system mass limitations, production rates, etc. Other desirable features are dust mitigation and exploitation, as well as imbedded volatiles capture from an undisturbed regolith "plug." An aggregation of modular assemblies, an imperative device feature, is easier to integrate and operate than a monolithic device. Design considerations that serve to establish the scale and size of the excavator include the sizes of available and appropriate components such as pintle chain, high-torque motor, etc. Parts that could service the intended 500 Kg/hr were about 40% larger than we had intended. The blade had to be long enough that it could reach 24 or more inches beyond the mounts so that the surface edge of the kerf would not be disturbed. To achieve the 24” cut at a notional 45° angle of attack would require that the mount be located at least 34” from the nose. The height of the blade is controlled by the diameter of the sprockets located on each end of the blade. As the chain translates through 180° of direction, its tolerance to the various stresses that tend to derail it from the blade are determined by the sprocket radius and tooth depth. The height is also essential to resisting end-to-end torsion (twisting) by the blade’s structure.

Figure 18 Conceptual Excavator Nose with Sprocket The kerf, or width of the dig, is determined by the size of the buckets (scoops). The need for the excavator to be able to rapidly cut long extents of trench to a depth of 12 to 24 inches, for emplacement of cable and conduit, dictated a kerf of 4” (10cm). The conduit may transport (sometimes cryogenic) fluids, depending upon type. Trenching of voids wider than the 4” kerf is accomplished by sweeping the blade from side-to-side for the desired width. Deeper voids are produced by stepping successively narrower trenches within the maximum width, providing an access ramp on either, or both, ends. Bolting two slabs of ¼“ Aluminum with interposing spacing blocks, to admit the sprocket assemblies and pintle chain, provided the lightest and strongest frame for the blade, given the rough dimensions of 6 feet by 6 inches. The blade can be lightened by cutting an iso-grid pattern into the interior faces of the Aluminum side panels. The digging end of the blade has the mounting and bearings for an idler sprocket upon which the Pintle Chain (ASME D662) is installed, as shown in Figure 19. K-1 platforms are welded sysRAND Corporation

25

Autonomy as an Operational Element of Planetary Surface Systems to the chain at intervals of five links to which the buckets (scoops) are then attached.

Figure 19 Actual Excavator Nose with Sprocket (K-1 Platform visible) The drive motor is a high-torque device with digital controls. It will be replaced later with a high-torque motor with a more compact form factor. The excavator's drive (motor) end should remain above the surface and does not necessarily have to be as narrow as the nose. The 10 cm (4 inch) buckets are slightly wider than the blade assembly.

Figure 20 Modular Motor Mount and Rear Drive Sprocket Several Computer Models have been developed that indicate that the excavator is capable of a production rate far in excess of 1,000 kg/hr, a figure that varies and will shrink depending upon spillage and other loss factors. A relatively low-wattage motor (100 W e) drives the device through a 180::1 ratio gearbox, delivering substantial torque to the drive sprocket. A governor in the control pendant limits the chain rotation rate to 7 rpm, consuming 25 to 50 W atts. The chain is reversible, providing a practical means by which the pintle chain and buckets can extract themselves should they become jammed.

sysRAND Corporation

26


Figure 21 Terms that Apply to the Excavator Blade This document assumes the use of a bucket ladder-based excavator that employs a pintle chain for mounting and operating the buckets (scoops). While this device will be used to characterize the physics of digging, it is not intended to be the flying unit. A new generation of chainless excavator is being developed that offers a number of enhancements, including some self-repair features and a lower mass.

Figure 22 Design of the Chain Motor Mount

sysRAND Corporation

27


BLADE PENDANT CONTROL

Figure 23 The Blade Pendant Controller with Test Fixture The Bodine Motor is intended to be driven by a computer. For convenience during the prototype development, a pendant, depicted in Figure 23, was constructed to provide manual control of the Bodine DC gear motor. Additional indicators requiring logic components and connections, i.e., the tachometer display, direction LED, and fault LED buffers, have been installed. An LM339 Integrated Circuit is a Window Comparator, and, when placed in tandem with a Schottky gate, can drive the Bodine motor's index wheel output to the Control Pendant’s tachometer display. At this point the unit only requires assembly and final, postassembly testing. The switch positions are marked on the pendant surface to indicate the nominal positions.

sysRAND Corporation

28


THE TURRET

Unlike a Robotic Arm, a Turret has substantial mechanical leverage that it can use to advantage. This allows the Turret to operate at lower power budgets and hold positions without continuous application of power. The Turret has shoulder-mounted primary pivots, probably due to subconscious emulation of the Bobcat tractor, that provide the leverage necessary to deliver hundreds of pounds of force. The “joints” of a Robotic Arm are dense, being crammed with a mechanical pivot, a motor, an index wheel, signal and power cables. The Turret can often spread these components across a larger volume, thereby avoiding the anemic mechanical performance characteristic of electric robotic arms. Industrial robots often use pneumatic, hydraulic, or cables to extend power systems to generate the mechanical advantage necessary for their operation. The Turret enjoys a total of ten degrees-of-freedom (10DOF) for maneuvering the excavator and other heavy tools. These DOFs include bidirectional rotation parallel to the platform’s yaw axis, Figure 24, turret arm pitch and excavator blade pitch, turret arm extension and retraction, and turret arm rotation. Worm-driven Jackscrews or geared high-torque axial motors are a compact alternative to linear motors that can maintain a static position indefinitely.

Figure 24 The Mounting of the Turret is Versatile

sysRAND Corporation

29


Figure 25 A Shoulder-mounted Pivot Helps to Provide Leverage 3.4

THE HOPPER

The hopper serves as a temporary storage bin for regolith that is extracted by the excavator blade. The hopper is connected to the excavator through the discharge chute. The hopper is also capable of unloading its contents directly into the receiving bins of the ISRU reduction reactors and glass foundries. The hopper is usually installed in one of the rotary hardpoints of the TUG (or equivalent). The hopper may also be fitted with volatile capture technologies in order to glean gasses as early in the extractive process as possible. 3.5

THE DISCHARGE CHUTE

The discharge chute connects the excavator’s regolith stream to the hopper bin, while capturing volatiles and routing them by a second pathway to the hopper. The discharge chute follows the rear of the Blade throughout its range of motion, and the travel of the Turret Arm, as well. 3.6

UNIVERSAL TOOL INTERFACE

The Universal Tool Interface (UTI) is intended to support the mounting and interchange of modular tools in the field. The UTI allows a mobility platform to stow and extract tools to/from a toolrack aboard a lander or from a depot facility. It is intended that many tools will be compatible with the UTI, as it supports automatic coupling and decoupling of tools to a mobility platform’s tool fixtures. The UTI should be available in various sizes, and Phi Ratio proportions are recommended. The MOOG Company offers several continuous ring couplings and other relevant technologies for incorporation into such a design. A reference design was promised and denied several times by KSC, which was both confusing and frustrating.

sysRAND Corporation

30


Figure 26 Universal Tool Interfaces Scale to Phi Ratio (1.6180/0.6180) 3.7

THE TOOL RACK

The excavator blade has numerous rough and sharp edges and is stowed when not in use to avoid damage and for the safety of nearby personnel and equipment. The tool rack may be found attached to a Lunar Lander, tugs, service yards, depots and outpost structures, or as a stand-alone fixture on the exploration site. The tool rack is analogous to a tool box: it keeps the tools from being lost or misplaced, stepped on or broken, or neglected in a damp corner, rusting. The tools are positioned so that they are accessible by robotic mobility platforms. A tool rack can help to enforce scheduled maintenance of tools and improve their availability. Tool discipline is essential where every logistics piece is shipped at great expense and cannot be easily replaced. 3.8

CHAINLESS EXCAVATOR BLADE: GENERATION TWO

In the interests of reducing the mass of the excavator, other methods for excavation were considered. The current Gen 1 Excavator has an 80-link Pintle Chain with 16 buckets, all of which adds up to a large fraction of the excavator’s mass. Simple queueing theory suggests that only three buckets need be in the loop instantaneously: one on the nose, digging into the workface, a second emptying its contents into the discharge chute, and a third returning empty to the nose position. More than three would seem to add unnecessary complexity to the model, and less is sub-optimal. The chainless excavator can also be self-repairing in some respects. When a bucket is broken, it can be ejected into a recycle bin and replaced with a new one from a magazine, like a cartridge in a pistol.

sysRAND Corporation

31


Figure 27 Concept Drawing of a Chainless Excavator Blade

Figure 28 Deck Hardpoints Support Diverse Modular Tools

sysRAND Corporation

32


SUGGESTED MOBILITY PLATFORMS

A number of robotic mobility platforms have been surveyed in our search for a configuration suitable for excavator operation. One such platform, which has the potential to be a very good fit for surface excavation operations, is Jet Propulsion Laboratory’s All-Terrain Hex-Legged Extra-Terrestrial Explorer (ATHLETE), seen in Figure 29.

Figure 29 ATHLETE in a photogenic pose There are three principal attractions to this particular platform. The relative mass ratio and size of the ATHLETE platform to our Excavator Blade seem subjectively correct. The vehicle’s wide track allows the ATHLETE to straddle a trench, which prevents collapse of near-vertical trench walls from the vehicle load. The fact that individual legs may be partially retracted would further help to clear a trench. Any mobility platform appropriate to the excavator must have a wheelbase and track that is clear of the cutting operation. The next generation of ATHLETE is much larger and might not be as appropriate to the current excavator. Fortunately, the excavator design is scalable.

Figure 30 Front Quarter view of JSC’s Chariot

sysRAND Corporation

33


Figure 31 Starboard view of Chariot Another platform of interest for the deployment of Moonraker is the Chariot from the Johnson Space Center, shown in Figure 30. The Chariot has a wide track which would prevent its toppling under an offside load. A perceived disadvantage of this platform is that it is apparently a solid frame, which could be a problem should a trench collapse. The Chariot could better address ISRU applications were it articulated amidships. Restrictions imposed by the Chariot project made integration its integration with the Excavator impractical. For one, installation of an Excavator/Hopper ensemble would have heavy hardware protruding entirely forward of the platform, causing a center-of-gravity problem. ISRU equipment is going to resemble heavy earth-moving equipment, in spite of our efforts to reduce intrinsic energy and mass needs. The durability, reliability and production requirements will not be properly addressed with diminutive devices, and the Excavator family of devices reflects many compromises, as is.

Figure 32 NORCAT's HOBO Mobility Platform

sysRAND Corporation

34

Autonomy as an Operational Element of Planetary Surface Systems In response to guidance from NASA experts, the excavator team began to explore adaptation of the excavator to NORCAT’s HOBO mobility platform. In spite of the very low profile of the device and its compact form factor, the team was making progress at fitting the excavator and hopper to a tandem HOBO platform. The tandem arrangement was found to be necessary not only for the hardware, but also to provide batteries sufficient to perform excavation. This effort was terminated when the team found that it had entered a minefield on conflicting objectives among several NASA design groups, and the prudent course would be to look elsewhere. One avenue that sysRAND has not pursued is based upon prior experience of another branch of the U.S. Government, the Post Office. In order to realize potentially significant cost benefits, the USPS began to deploy a new three-wheeled delivery truck in the field. This vehicle had a single, steerable front wheel with a conventional two-wheel drive axle in the rear. The program was entirely dismantled when it was found in its first year of operation that the new tri-cycle truck was totally ineffective in snow. Perhaps dual front wheel drive with a single steering rear wheel could have fared better. In any case, we suspect that the physics of winter operation would have very similar effects on the loose, fine-grains of Lunar regolith. 3.10

THE TUG

sysRAND’s expectations to attach the excavator to the NASA JSC Chariot, or a similar mobility platform are not to be realized. In response to continuing uncertainties and to provide for the largest number of mounting options, the turret is being designed for mounting on a vertical 2DOF pivot; through the expedient of translating on a pitch axis by 90°, the pivot can assume a horizontal aspect that is co-linear with the travel axis of the platform (to maintain the Chariot option). Another major component of this system architecture is the TUG, which is a notional robotic mobility platform upon which the excavator is mounted. This device is a “stalking horse,” which allows for the design to proceed, testing assumptions and design features currently on paper. The TUG is an allelectric vehicle to be used as a generic platform for mounting both tools and instrumentation. Any actual TUG implementation is not a part of the current MPED program and is expected to be developed by sysRAND or by another collaborator only if all other options fail to materialize. The TUG features a battery bay and an electronics bay mounted between the drive motors and wheels to ensure a low center of gravity. The largest part of the device is the hopper, which is accessible from the top of the unit, an open bin that can contain up to one metric ton, or one cubic meter, of regolith. The terms ‘hopper’ or ‘car’ are used interchangeably with ‘TUG.’

Figure 33 A Notional TUG with an Excavator Blade Attached to the Forward Mount

sysRAND Corporation

35


Figure 34 A TUG with an Excavator Blade Mounted Fore and a Hopper Mounted Aft The TUG has three mounting points for attaching tools; these points quarter the deck, forward, mid, and aft. The TUG can also mount applications-specific modules, such as sorting stacks for beneficiation of the ore or the capture of volatiles (water, for one). The TUG’s robotic arm selects an assigned tool from a tool rack and preflights it (exercise and diagnostics) before leaving the vicinity of the depot. If the tool is not functional, a replacement is located and mounted. Only conjecture until testing can be conducted, one opinion is that the excavators may perform more effectively when towed, rather than pushed. The configuration of Figure 34 could depict this ordering if the excavator blade chain-bias were reversed, since the TUG is agnostic about which end goes first. sysRAND's Robotic Mobility Platform concept is strictly unmanned, although the TUG's deck may be used as a workbench in the field; units may also be closely parked to form larger, adjoining work surfaces. A universal modular concept is depicted in Figure 35 through Figure 38.

Figure 35 Tug with Excavator, Turret and Hopper

sysRAND Corporation

36


Figure 36 Tug with Crane on Mid-deck Mount

Figure 37 Tug with Star Hammer Drill in Forward Position

Figure 38 Tug with Cherry-Picker on Mid-deck Mount The architecture assumes the flexible use of many mid-sized platforms that can accommodate several tool types. Cooperative, "hive" architectures are intrinsically redundant and their modest size allows for them to be launched frequently. The attachable "smart" tools may be delivered even more often. The mobility platform contains a network of computers that are used to control each joint's degrees-offreedom and tool-specific features. In the case of the excavator, this would be the "buckets" or "scoops," which the excavator blade uses to perform the actual digging.

sysRAND Corporation

37


Figure 39 A Stacked Alternate Hopper Configuration The stacked excavator/hopper ensemble of Figure 39 closely resembles one of the options that had been developed for the NORCAT HOBO. The low profile of the HOBO required that the hopper be articulated for a vertical reach to meet the needs of the reduction reactor, which was a challenge for center-of-gravity when a useable mass of regolith ore was aboard.

TM

Figure 40 An Engaging Logo has been Developed for TUG Marketing David Scott Smith is a freelance cartoonist, illustrator and artist often working under contract with the Walt Disney Company. Dave also authors a number of websites, most notably SpaceBase8.com, a webtoon that is an amusing comedy strip with creative graphics and “sound effects.” sysRAND commissioned Dave to develop a logo appropriate for the excavator and TUG, and he developed the critter in Figure 40 that seems to be a hit with all who see it, and appreciate attitude.

TUG is the humorous, tough-guy art that Dave developed through collaborative interaction with our staff. TUG conveys the impression that he may be just the right guy to get the job done.

sysRAND Corporation

38


HARDPOINTS

The TUG features powered hardpoints to support modular attachments and accessories. Three of these hardpoints are located on the centerline of the TUG’s deck, and one each are located on the ends of the TUG. Hardpoints have rotary Power Take-Offs (PTOs) that can be used to directly drive the Yaw axis of deck-mounted Robotic Arms, Turrets, Cranes, Antennas and other devices. These PTOs can also drive a drill or other rotary-powered device using flexible drive cables. The hardpoints that are mounted on opposite ends of the vehicle can also be used as towpoints, powertake-offs (PTOs), or drive accessory devices. All five hardpoints are available for mounting the TUG to a launch vehicle (wheels up) or for attachment to a lander (wheels out).

Figure 41 A Centaur Delivers four TUGs to the Moon, Selected Frames

sysRAND Corporation

39


CONCEPT VALIDATION

There is no better validation of an idea than to discover that your idea is not a new one. Isaac Asimov was fond of saying that “half of solving a problem is knowing that it’s been done before.” The TUG has a predecessor in the form of the Army Mule. There are substantial differences, particularly that the TUG is unmanned, and has electric drives. The obvious similarities are the near three-foot high deck, and wheels very near the corners. While the expanse of deck was so valued by the Army that half of the driver protruded out in front, in the case of the TUG, we move the driver elsewhere. “The M274 mechanical mule or "Army Mule" was a 4 wheel drive 1/2 ton vehicle that could carry more than 1000 pounds of ammo, cargo, or personnel. They even mounted a 106mm recoilless rifle with missiles on it. These vehicles sometimes come up for sale on Ebay.” – Yahoo.com

Figure 42 A Clean View of the Mule

Figure 43 The Huey, Gun Emplacement, and Mule, circa, VietNam Era7 7

The undergrowth and wear from foot traffic suggests that this example is in an outdoor museum setting.

sysRAND Corporation

40

Autonomy as an Operational Element of Planetary Surface Systems Other, more recent concepts, also employ the six-wheeled platform to apply more traction and torque when four wheels aren’t enough. Six wheels also reduce the area loading across the platform footprint. The author’s first encounter with one of these vehicles was at Robot Defense Systems, a client for whom we designed and built a custom interface for Prowler’s prototype (nodding) LASER Scanner. Prowler had just starred in the (1985) Chuck Norris movie “Code of Silence.” Unfortunately, RDS failed within another year, but not without making a lot of progress with their pioneering work.

Figure 44 The RDS Prowler Starred in a Chuck Norris Movie "Code of Silence"

Figure 45 A Contemporary Robotic Combat Platform Concept

sysRAND Corporation

41


Concept of Operations

sysRAND Corporation

42


CONCEPT OF OPERATIONS

For an architecture to provide a good fit, it should be iterated both top-down and bottom-up; otherwise the architecture misrepresents the application, or worse yet, the implementation technologies force the workspace to conform to a malapropos systems paradigm. A purely bottom-up approach seldom results in a coherent or useable system, unless it is forced to compete and evolve contextually-appropriate complexity. A purely top-down approach often drills down past available implementation vehicles and is recognized as a failure only after expensive overruns and schedule slips. In Lunar mining and civil engineering applications, lethal radiation and other operational hazards argue against deploying human labor in extensive ISRU contexts. ISRU would be rendered impractical if it could not be automated to a level approaching 100%, including support and maintenance activities. As data acquisition platforms, robots have proven to meet – and even exceed -- operational longevity parameters in hazardous contexts where a human cannot comparably subsist: Voyager, Spirit and Opportunity are perfect exemplars. With the variety of tasks that can be performed by mobility platforms on the Moon, it is unlikely that any mobility platform would be so specialized as to have only a single function. A particular vehicle may mount a modular winch, manipulator, or other tool necessary to retrieve or repair a stalled unit, yet this vehicle may not differ substantially from the distressed vehicle, but for its recently-acquired appendages. There will be distinctions among classes and types of mobility platforms; primary among these will be whether a given unit is a manned vehicle or an unmanned, robotic platform. Subordinate will be attributes of size, power supply endurance, mass, control and computational facilities, and fixed tools and mountings for fitting universal tools. Modularity and universal interfaces will be persistent and pervasive in space hardware and software. Re-useability will be a persistent feature, sine qua non. These factors, to some extent, argue against swarm architectures, particularly since power does not scale well and other functions suffer similarly. The methods and procedures anticipated by the design and development team, then later elaborated and focused by the operations staff, are called the Concept of Operation (CONOPS). The design team makes every practical effort to analyze and capture the operational context of a product or service. In the case of the excavator, generalized to a family of modular tools, many of the CONOPS procedures will find their way into program code or expert systems operational rules. This CONOPS is concerned with mobility platforms, tools, worksites and other “agents,” that effect or are affected by other agents or agencies. The universe of possible effects that may be asserted by or impacted on agents are called “actions.” Units of measure and performance objectives to which measures are applied are termed “metrics.” The discrete and multi-dimensional operating envelopes that bound an agent’s range of actions are called “constraints.” 4.1

CONCEPT OF OPERATION AGENTS

The agent that is central to the CONOPS is the Electronic Work Order (EWO). The EWO is a description of the equipment type, the worksite, the task, schedule of access, charge numbers, and other elements necessary to accomplishing a mining, structural, or civil engineering task. The EWO also specifies operating parameters for a TASK, including the levels of autonomy operant at any specific point of a task. Once created, the EWO awaits assignment to a specific agent, a solicitation & bid process may be an effective system for employing assets to maximal advantage. Surface Facilities Engineering designs the civil engineering, structures, and mining projects – and has the authority to issue the requisite EWOs electronically at the appropriate phases of a project. The Worksite is the tract of real estate that is to be modified (improved) by the mobility platform executing the EWO. The worksite is also a control zone with defined site topology and fixed feature layout. Site Control has the authority to manage vehicle traffic, routing and sequencing of tooling paths, cable and fluid conduit insertion, and excavation. Site Control can be instantiated as a system located at

sysRAND Corporation

43

Autonomy as an Operational Element of Planetary Surface Systems a fixed location within, or in proximity to, the worksite. Site Control may also be assigned (like the admiral’s flag) to a mobility platform that has the communications bandwidth and on-board computation capacity to perform site control functions in addition to its other tasks. Ultimately, site control’s principal function is to enforce safety. The Tool Rack is a facility that provides modular mountings (arms and turrets), and tools to mobility platforms. The tool rack may be associated with fixed facilities or affixed to a mobility platform, either on the deck or on a trailer. Consumable supplies are provided elsewhere by a depot function, not to be confused with the tool rack. The Mobility Platform is a robotic device that performs tasks on a worksite or hauls materials among worksites, depots, outposts, etc. JSC’s Chariot, JPL’s Athlete and NORCAT’s Hobo are existing examples of platforms that may emerge as working mobility platforms. sysRAND’s TUG has been conceptualized in order to fill the gap caused by the lack of availability of these to the Excavator project. The mobility platform provides the transportation and deployment platform for modular tool operations in order to accomplish work. The platform can extract tools (Excavator Blade) from a toolrack, collect tools, power, and other provisions, such as marker beacons, spare parts magazines, etc., and confirm the mission package with the control center. The Arm/Turret Control connects modular tools to the mobility platform. It also deploys and positions the tools throughout their work volume. The Modular Tool is the effector, the tip of the spear that includes the mobility platform and the turret. Each performs a specialized function, or two.

Figure 46 An Early, Notional Excavator Platform at Work

sysRAND Corporation

44


CONCEPT OF OPERATIONS ACTIONS

Since the mobility platform (TUG) provides the transportation and deployment platform for the tool’s operation, it must perform many functions that ultimately deliver the tool to the worksite and more specifically, to the workface. The mobility platform executes the tasks specified by the Electronic Work Order (EWO), and these tasks may be typical: • collects a charge or self-charges if it has a Stirling Radioisotope Alternator (SRA), • mounts a robotic arm, a turret, or a gantry, • extracts a tool (Excavator Blade) from a Toolrack, which is compatible with the specified robotic arm, turret or gantry, • collect any additional tools specified by the EWO that are to be delivered to the worksite for use by other platforms, • collects, or is issued, other provisions such as marker beacons, spare parts magazines, gas cartridges, etc. • download/validate the robotic arm/Turret application program for the mobility platform • download/validate the tool’s application program for the mobility platform • confirm the mission package with the control center, • negotiate with Traffic Management for a travel clearance for cross-country navigation, • depart the yard and proceed cross-country to the worksite, • arrive at the worksite, • negotiate with Worksite Management for entry to the worksite, • operates under the supervision of worksite management • proceed to the workface location • position the mobility platform • position the tool’s effector • proceed to extract regolith at the workface • bid for new EWO • accept new EWO • perform new EWO or • negotiate with Traffic Management for a travel clearance for cross-country navigation, • exit the worksite • depart the worksite and proceed cross-country to new location

sysRAND Corporation

45


CONCEPT OF OPERATIONS METRICS

In the course of preparing the excavator for laboratory shakedown and field trials, controls are being refined and the design iterated toward a flight-ready system. In order for the excavator to be useful, the blade should be in constant motion. This is due to the void created in the regolith when it is scooped out – the device cannot get a second bucket of soil from the same space and the blade must be moved forward, sideways, or deeper in order to gain purchase on the next full scoop of regolith. In order to achieve the modeled 500 to 1,000 kilograms of hourly production, the combined motion of the mobility platform, the robotic arm/turret, and the excavator blade must keep the blade’s nose imbedded in the trench, constantly addressing the workface of the regolith cut. 4.4

OPERATIONAL CONSTRAINTS

The excavator has a specific set of useful functions in its operational space. Unlike a hammer, its utility is focused upon cutting through regolith, and moving it, using a minimum of energy. The excavator may be used on undisturbed, consolidated regolith, and it may also be used to move piles of previously loosened regolith. The chain may be operated in reverse, although it isn’t clear that there are many applications for reverse except to clear a rock from the Blade’s path. Other possible operations would be destructive and not likely to be deliberately employed. The excavator would not be used as a hammer, nor would it be scraped across the surface because it would strip the chain from the Blade. Likewise, the excavator would not be used as a baseball bat, a golf club, or a crowbar. Constraints that impact operations include communications bandwidth, mission risk, efficiency, and productivity. 4.4.1 Bandwidth The principal justification for autonomy is the conservation of communications bandwidth, reduced roundtrip signal latency, and the production pace of a local system. Secondary concerns include loss-of-signal and other interferences with remote, teleoperated control. Collaborative swarm operation of multiple units would amplify the productivity (effectiveness) of each unit, again without driving up the aggregate bandwidth of a worksite. Bandwidth constrains all systems from teleoperated to collaborative autonomy. Semi-autonomous and autonomous platforms do have the advantage over teleoperated modes in that they can continue to operate when the data streams are not keeping pace with on-the-ground operations. 4.4.2 Risk to the Mission The system will probably be constrained from any operation that places the mission at risk, whether enforcement occurs at the control center, or on the platform itself. There will be considerable program duty cycle devoted to testing the safety and impact of command streams on the platform, and its modular tools. 4.4.3 Efficiency The author was astonished when a NASA staffer flatly stated at a conference “we don’t worry about efficiency around here.” Efficiency matters, deciding whether a mission, a task, or a tool is feasible. System efficiencies are a measure of energy and motion, determining whether a task is worth doing. 4.4.4 Productivity Productivity is a measure of a tool’s ability to pay its way. Launching anything to Mars or the Moon requires that each item is justified by performing a function. Many scenarios for ground equipment suggest that a device be able to produce a thousand times its launch mass in regolith (or more).

sysRAND Corporation

46


OPERATIONAL MODES

The operational modes of the excavator can be reduced to Inert, Safe, and Normal operations. The inert modes include any that require the excavator to be protected from its environment (and vice versa) while it is in some form of storage or transit. Normal Operational Modes are those wherein the excavator is mounted on a mobility platform or tool rack in order to service digging operations. 4.5.1 Inert The Excavator is inert during integration, storage, and surface shipping. The unit’s batteries or other energy sources are not connected; work surfaces such as the buckets, chain, and sprockets have protective sheathing and covers. The unit cannot be activated without intervention on the service bench. 4.5.2 Safe Modes The Excavator is in safe mode from time to time during its service life cycle. The unit is secured, power is isolated from the mains, and it might have protective sheathing over exposed work surfaces (such as the buckets, chain, and sprockets). It is not only important that the unit be safe from accidental damage, but also that its many sharp and irregular edges not compromise an EVA suit, a transport craft, a cable, or other loose items. The excavator can be transitioned to other states including Launch Phase, Space Segment, Landing Segment, and Maintenance. 4.5.3 Normal Operations When the excavator is stowed in a tool rack or mounted on any sort of mobility platform it is considered to be in normal operation, whether power is applied or not. These operations include tool positioning, chain driving, extending and retracting the excavator, stowing the excavator in the mobility unit’s tool cradle, low power standby and recharging modes, etc. During excavation activities the mobility platform is executing command streams generated by software located on board the excavator blade and downloaded to the mobility platform memory. This program and transfer-of-control is effective for the work site and authorized by the Work Order. Semi-autonomous operation will require onboard computational resources. Many states exist that do not require autonomy, so the computers may be powered-down in order to conserve energy. Computers could remain online if network protocols exist that support the use of excess computer time. 4.5.4 Decommissioning Since the excavator is a module it can be replaced if a spare is available. A blade requiring service can be held in a storage mode until a service facility is available to restore operations. A new excavator concept may postpone such an action, since it may be capable of replacing faulty parts. A decommissioned excavator should be parted out, assuming that bearings, sprockets, and the like have any remaining service life. The current construction of Aluminum may be recycled and melted down once the wiring harnesses, steel and silicon carbide components have been removed. Depending upon the strength of the logistics to the Moon and the level of sparing supported, it is very likely that a few excavators may indeed eventually be deliberately cannibalized for parts. Complete and operational excavators may be the most prudent sparing level until a service depot infrastructure is in place.

sysRAND Corporation

47


WORKSITE MANAGEMENT AND CONTROL

A sysRAND observation: “An accident is an intersection of infrastructural domains outside the authority of an Interface Control Document, e.g.: a freight train collides with a tanker truck at a railroad crossing.” All space not reserved as controlled space is uncontrolled, or free, space and is accorded unrestricted rights essential to navigation. These features and limitations will be defined by convention, treaty, and regulation – all of which are outside the scope of this document. Surface and mineral rights discussions are similarly outside the bounds of this document. Deliberate considerations such as these, or accidents and near-accidents, will demonstrate that there are compelling reasons for governance bodies to isolate the many elements of space exploration and exploitation activities from potential and real conflict. 4.6.1 Mobility Collision Avoidance by vehicles is the principal driver for control zone requirements. Other control zones are intended to keep fuel depots, antennas and other tall structures, moats, open excavations, etc., from conflict with other facilities, by maintaining safe distances.

Figure 47 Conceptual Control Zones including Worksites

sysRAND Corporation

48

Autonomy as an Operational Element of Planetary Surface Systems 4.6.2 Activity There are any number of possible emplacements that will require that vehicular traffic is restricted, or constrained, when operating nearby. These emplacements may include, but are not restricted to: • • • • • • • •

Outposts and Habitats, Depots, Airdocks, Landing Pads, Antennas and Towers (Telescope shrouds), Launchrail, Track, and Tunnel Portals.

One or more of these facilities or intersections of these facilities may provide sufficient justification for registering, constructing, and enforcing a control zone. 4.6.3 Control Zones Control Zones are a ponderous topic that is well outside the scope of this project. However, as soon as permanent or semi-permanent facilities are contemplated, then the shelves of law, zoning, land use, and related experience will be required. It will be essential that Control Zones are designed to accommodate autonomous platforms, and perhaps afford them advantages in navigation and access, in order to facilitate and simplify their application. These practices are similar to powered aircraft yielding right-of-way to unpowered gliders and balloons, or landing aircraft having right-of-way over those taking off. Aviation regulations represent man-millenia of practical, and tested experience developed since the beginning of the last century. 4.6.4 Excavation Worksite The excavator and its mobility platform may travel up to 10 km/hr (6 MPH, notional) when travelling crosscountry in uncontrolled space, terrain permitting. While the excavator platform is traversing the worksite it may be restricted to a rate of 1 km/hr (again, notional). When the excavator is actually excavating, progress may be measured in terms of a centimeter, or two, per second. When the excavator has a blade imbedded in the regolith . . .

Figure 48 Outpost Schematic Depicting Features

sysRAND Corporation

49


Figure 49 Types of Worksite Access The worksite is a control zone that is used to isolate and protect economic activities in support of resource extraction and production. The entire worksite is referenced to datum point (origin), from which vectors identify entry, exit, start, and stop points to automatic and manned equipment. The reference datum point may be a virtual waypoint or an absolute point, identified by a directional beacon or a complex signal transmitter.

Figure 50 A Representative Worksite Layout Installing a Utilities Trench The route planning software overlays the excavation design onto the worksite plan and marks an entry point with a vector of 165°, 2 kilometers from the worksite’s origin point. The approach path to be followed by the mobility platform (TUG) is intended to properly align the platform and excavation tool with the trenchline.

sysRAND Corporation

50


TYPICAL EXCAVATION OPERATIONS

A number of domains will be created in the exploration and development infrastructure. The principal operating modes for planetary surface mobility platforms are cross-country navigation, worksite navigation, and tool operations. These represent three or more scales of operation, sensing, and performance. They also represent differing energy budgets and expenditures. The mobility platform is autonomous when navigating from point-to-point and/or not under supervision of a tool program in tandem with a Work Order. The mobility platform’s initial Finite State Machine (FSM) in a conventional implementation will be, in all probability, replaced by a sophisticated and aggressive goalseeking software mechanism that will support semi-autonomous and autonomous operation. This has the effect of assuring that checklists are followed and milestones accomplished in proper order when sequence matters. The goals of an idle mobility platform are to maintain battery charge and temperature, bid for Work Orders, and stay out of traffic lanes. Once the unit negotiates and secures a Work Order, the mobility platform will mount a tool, navigate to another location, haul material, power the operations of another TUG, etc. The distributed control system for Lunar surface equipment continuously reports the status of the robotic mobility platform’s several subsystems. This “chatter” structure anticipates conditions that threaten the health of the platform or its environs by encouraging each vehicle to explicitly provide information regarding its trajectory to other vehicles. This heterarchical structure also typifies the well-connected, but non-hierarchical, group of agents operating on the Lunar surface. ‘Smart’ tools coordinate their activities with task, traffic, and site management centers. The partitioning of control responsibility should place the bulk of communications bandwidth at local sites and less at regional and global centers. When this “chatter” is local, that is, unit-to-unit and area broadcast, less Moon-to-Earth and Earth-to-Moon bandwidth is consumed. Autonomy facilitates a reduction of communications to control centers while replacing such bandwidth with local unit-to-unit radio traffic at substantially lower power levels. 4.7.1 Command Structures Provide Direction Commands are used to frame (i.e., establish the boundaries for) semi-autonomous and autonomous operation. In these advanced modes of operation, command primitives and man-in-the-loop operation are permitted but are usually bypassed in favor of automatic and low-latency, local decision-making. The command and control elements of the development and exploration centers resemble Terrestrial air traffic control operations, wherein centers and towers provide clearances, advisories, and navigational directives – although the pilot-in-command has the final authority at the controls – a purely practical matter because an air system cannot consist entirely of remotely-piloted vehicles. A notional cluster of command authorities recognizes operational distinctions among point-to-point navigation, surface engineering and work assignment, maintenance and downtime activities, worksites for mining, worksites for civil engineering constructions, and the occasional presence of EVA personnel. 4.7.1.1 Distributed Control The hierarchy of a central command structure should be replaced by a heterarchically distributed and recursive model. The participation of a central command authority should be limited to issuing Electronic Work Orders (EWOs) and management of exceptions (e.g., accidents8). A distributed model is used to span the range of command authorities that direct the excavator’s activity. The autonomy granted to the decision software at each layer is a global parameter (mission directive) in the model. Initially, a low-level interface (operator-in-the-loop) would exist to accommodate remote operations from ground stations on the Earth. It is likely that no autonomy will be permitted early on.

8

The sysRAND definition of an accident is an event where infrastructural elements meet outside the scope of an Interface Control Document (ICD).

sysRAND Corporation

51

Autonomy as an Operational Element of Planetary Surface Systems Other scenarios would select a strong autonomy, except for operator training. The converse may also be selected, where only one layer enjoys the confidence of high autonomy. Each layer may assert more than a single layer intrinsic to its operation, which reflects the recursive mechanical and control structure manifested from “wheels to scoop.”

Figure 51 A Layered Control Structure

4.7.1.2 Task and Asset Management This center issues and closes Electronic Work Orders (EWOs), communicates to the individual robotic tool platforms, and is the system with global control. Early on, Asset Management owns the mobility platform and tools. Later, this will not be the case, as the cost of exploration is shouldered by other countries and corporations. 4.7.1.3 Traffic Management Like the FAA en-route centers, Traffic Management schedules departures and arrivals of equipment in order to avoid en-route conflicts among vehicles and between vehicles and fixed facilities, asserting regional control. Traffic management also attempts to avoid a congestion of platforms at a single location. When conflicts are imminent or accidents occur, Traffic Management will resolve the situation to avoid an expensive accident, with possible loss of life and/or equipment. 4.7.1.4 Site Management Site Management exists in numerous locations, analogous to airports, and should be considered to be a recursive extension of platform emergent behavior. Site management asserts local control over outposts and construction/mining sites, with the ability to assume control over any vehicle that approaches or penetrates into the jobsite. Access to these “control zones” is restricted to slow-moving-vehicles that are conducting civil engineering and mining activities directed by the Site Management. Any unit operating in the site must be executing an Electronic Work Order specific to that site at a particular time. On the other hand, the platform is expected to operate autonomously and collaboratively with other platforms, subject to the constraints of density. Site control need not be yet another fixed facility. It is likely that site control may be a function that is assigned to a platform that is otherwise employed at the site, which suggests that site control hosting can be quite transitory in nature. 4.7.1.5 Tool-centric Control Tool racks will be available on landers and TUGS, as well as in service yards, depots, and outpost structures. When a mobility platform successfully installs a tool from the tool rack, the platform assumes the ‘personality’ of the applications program imbedded in the tool. While the TUG will be a known device with a standardized frame and plug and play interfaces, it cannot be expected to have access to the code for all of the tools at its disposal9, including down-rev legacy tools. Before the tool leaves the depot or 9

The first and weakest justification for the tool controlling the mobile robot.

sysRAND Corporation

52

Autonomy as an Operational Element of Planetary Surface Systems begins operation, the tool’s code will be checked for revision by configuration management agents. After a tool-wielding mobility platform arrives at its duty station and receives a clearance to approach, the tool’s software asserts control. The tool/TUG ensemble operates at reduced speeds necessary for safe operation in a congested work area10. An excavator will also require that the robotic mobility platform continuously apply pressure against the workface, while the mounting turret fine-tunes the servo for variations in applied and resistive forces11. The tool also has intrinsic governors, which assure that it is not destroyed by a few seconds of excessive ground torque or accelerations by an overzealous control program12 resident on the mobility platform, or from an “out-of-context” or “delayed” remote tele-operator. Therefore, applications-specific/tool-specific software will be cognizant of safety and operational issues in that tool’s context. When, for example, the excavator is extended below the surface, a governor has to be employed to avoid the inevitable accidents that would result from engaging the motors in anything but a low-speed (i.e., inches per minute) crawl. 4.7.2 Detailed TUG Operations A Mobility Platform (TUG) has two principal roles in its mission life, 1), transport excavators and other tools from one facility to another, and 2), deploy an excavator or other tool in support of the tool’s work function. Modularity allows the bulk of servo motors and sensors to be common to all tools, yet the tools are very simple. For example, the TUG hardpoints propel at least two degrees-of-freedom with a complex motor, which are two fewer that robotic arms or turrets do not have to provide. Similarly, the Turret delivers eight DOFs to the excavator, a feature that considerably simplifies the excavator. Mobility platforms will be the backbone of development and exploration activities on Mars or the Moon. 4.7.2.1 Free Navigation Free navigation occurs outside of any control authority and is similar to cross-country navigation, with the exception that free navigation, by definition, lacks a specific destination. Since manned presence on the Moon is largely in support of exploration, the TUG can serve science as a data acquisition platform even while conducting mining and civil engineering functions. Most exploration will occur beyond the confines of an outpost or a worksite and thus a considerable amount of TUG travel will be free navigation. 4.7.2.2 Cross-Country Navigation Vehicles will travel from control zones to other control zones; these are typically other, decentralized destinations, such as outposts, landing pads, depots, and worksites. Centuries of experience with nautical, aeronautical, and surface traffic has resulted in the development of rules by which autonomous vehicles may co-exist in spaces that may be congested, undeveloped, sparsely used, special use, pristine, etc. Right-hand nautical (rights-of-way) rules can serve as a basis of conflict resolution among platforms, which are able to communicate their current states, commands, and trajectories to other platforms that are in proximity. Mobility platforms are designated by the principal tool that they are deploying at any particular phase of a task, e.g., “Excavator Delta One,” “Hopper Echo Three,” etc. This is less for the benefit of the robotic platforms and more for those EVA crewmen who are working alongside the automation. 4.7.2.3 Worksite Navigation Unlike free or cross-country navigation, worksites can be assumed to be congested and hazardous. An exception would be during the early stages of starting up a worksite, or later, during decommissioning, or maturation of the site to a new operational level. Speed limits applied to worksites are intended to avoid expensive accidents, and routes are intended to avoid driving gear into a construction trench or pit. Accidents can cause severe schedule slippages while 10 11 12

The second justification for the tool controlling the mobile robot. The third justification for the tool controlling the mobile robot. The most compelling reason for the tool controlling the mobility platform in the worksite context.

sysRAND Corporation

53

Autonomy as an Operational Element of Planetary Surface Systems awaiting replacements, or cost a entire project its existence. Worksite navigation also provides orientation patterns (approach plates) to properly position TUG-mounted equipment to begin excavation and other operations. Local beacons provide GPS-like navigation support for precision civil engineering support. 4.7.2.4 Basic TUG Service Loops A series of scenarios has yielded a consistently repeated solution to the logistics of hauling soil from a digging site and returning empty with a fresh battery charge. The Loading Service Loop depicted in Figure 52 is the foundational procedure for most excavating operations and variations on this theme. Figure 53 depicts the other principal service loop where the TUG disgorges its contents at a designated site. One TUG has engaged an excavator blade and is conducting the digging operation. Other TUGs bring power to the excavator TUG to directly power the blade and the auxiliary systems for the duration of their connection to the lead TUG. When the second TUG’s on-site power budget is expended it returns to the depot with its regolith load and depleted batteries, while another TUG queues up to take its place. The primary objective of this method is to keep the excavator on-station by bringing power to the dig site using the empty TUGs. This has the effect of empty TUGs trading a battery charge for a load of regolith, a reasonable trade in a microscale economy. It is hugely inefficient to discharge one battery in order to charge another -- inevitably wasting power -although this is in fact a practical approach if used to keep the excavator’s host charge “topped-off.” To avoid constant charge and discharge of the host batteries, when an empty TUG arrives at an excavation ‘dig’ site with a fresh charge, the newly arrived TUG powers the excavation directly, while the TUG hosting the excavator blade holds its own power in reserve to the extent that it can.

Figure 52 Basic TUG Loading Service Loop The TUGs should be viewed as having a range of operations, much like an aircraft. A certain amount of power is required to travel from the power plant to the excavation site and even more power is needed to return with a ton of regolith. A practical reserve includes the power to maneuver and dock with the excavator TUG; the loiter time at the excavation site is limited by the return distance from the excavation site to the power plant. Loiter times must always be budgeted, as delays are inevitable and batteries will expend power just to keep warm. Battery budgets also must assume allowances for battery aging and performance derating.

sysRAND Corporation

54


Figure 53 Basic TUG Unloading Service Loop The Unloading Service Loop is distinctive enough to be separately identified. First, it will occur with a frequency often approaching that of the Loading Service Loop when the processes are symmetric. Second, the hopper will be tilted or opened to empty the contents. The regolith may be ‘dumped’ all at once, spread across a berm, or have a shaped-and-metered delivery to fill a trench. 4.7.2.5

Trains of TUGs

Figure 54 TUGs can form a Train to Save Power When a number of TUGs are heading to the same worksite they can save power by having only one unit operating its navigational and control computers. The lead TUG steers and provides master control to all of the motors in the train and all other TUGs slave their drive motors to it. This method is very similar to that employed by diesel locomotives.

sysRAND Corporation

55


4.7.3 Detailed Excavator Blade Operations The MPED is a prototype bucket ladder excavation tool on a pivot arm or turret, with a target production rate in excess of 1,000 kg/hr. It consists of two sprockets supporting a pintle chain to which small ‘buckets’ or ‘scoops’ are attached. The chain is driven by a motor and gear assembly attached to the shaft of the aft sprocket, while the forward sprocket is free-wheeling. A mounting mechanism is integrated into the ‘pivot’ of the blade to allow the unit to be handled as a modular tool among a rack of available tools. This also allows faulty blades to be detached and repaired at will.

Figure 55 Representative Excavator Sweep Patterns When an excavator is used to trench for cable burial its yaw axis remains fixed unless the cut is required to make a slow curve. Wider trenches or soil excavation operations will require that the excavator blade sweep side-to-side and up-and-down in order to extract a large volume of regolith. Such operations are essentially nested loops of control and are offered as control states, using parameters to limit the size of the digging envelope. The ‘prewired’ procedures Figure 55 have advantages and disadvantages when extracting Lunar soil from the geologists’ point of view. A variety of digging patterns allows for convenient evaluation of various methods. System considerations may also be evaluated, such as balancing the clockwise and counter-clockwise torque induced on the buckets during a dig. Patterns A through D tend to balance any bias, while E and F will be cutting into soil in a manner that will tend to twist the bucket almost exclusively right or left, inducing wear. Patterns G, H, and J will tend to contact the soil in line with the direction of thrust presented by the pintle chain, inducing a minimum of torsion during the dig. The horizontal sweep of the blade does not have to be bilaterally symmetric, especially on curves, where a 5 or 10-degree bias off-center may be helpful through the turns. When this offset is applied during a sweeping cut, a curved trench may be feasible. (This remains to be tested.)

sysRAND Corporation

56


EXCAVATOR WORK VOLUMES

One of the factors that scales the computational load and sensor bandwidths is the robotic effector’s work volume. This is the space that the working tip of the tool can reach while exercising its servos in all of their intrinsic degrees-of-freedom (DOF). The illustration in Figure 56 is a notional slice of the irregular spheroid that describes the excavator’s work volume. This planar shape is swept on the turret’s yaw pivot until the blade or turret arm interferes with the TUG or other hardpoint attachments, such as the example hopper. The extreme vertical angle is representative of excavation of caves or tunnels in icy, compacted soils. from 9 o’clock to 12 o’clock position. Angles ranging from 8 to 9 o’clock would be employed to reduce small rises, crater interior edges, slag piles and existing regolith structures. Those angles ranging from 5 to 8 o’clock are typical of original excavation of pristine surface.

Figure 56 A Representative Plane of the Excavator's Work Volume

sysRAND Corporation

57


Digital Visualization Enhances Design Definition

sysRAND Corporation

58


DIGITAL VISUALIZATION ENHANCES DESIGN DEFINITION

Imagination is valuable to the designer / developer, yet an idea needs to be clearly expressed before others can embrace it. A computer-based visual simulation communicates better than any other. A CAD system allows for design elements to be shaped, scaled and detailed as the front-end to articulating and animating graphics elements for visualization. sysRAND is ecstatic with the Digital Space results. Digital Space has been developing an applications-specific module that plugs into their standard rendering and simulation package, which includes physics modeling using open source software. The illustration in Figure 57 is an example of their excellent product and has been exercised by the sysRAND MPED team for fidelity and function. The package includes Python and XML13 scripting facilities that feed directly to the rendering/simulation’s command bus, in parallel to a PC’s keyboard and mouse. XML is also widely used by modeling software systems and the excavator systems definition will ultimately employ DoDAF, implemented on the Atego Studio software platform. The Digital Space (DS) visualization and simulation package is as engaging as a high-quality video game and much more educational. The sysRAND Planetary Surface Excavator (MPED) team has been able to extract more engineering and performance data from the simulation runs than had been anticipated. The package also has the opportunity to become an outreach program, accessible over the web and available to enthusiasts and classrooms worldwide. At sysRAND, visualization helps to structure the abstracted definition for programming and data structures from the start, and a solid example is depicted in Figure 58, an early design graphic that was used

Figure 57 Example of the Digital Space Visualization / Simulation

13

eXtensible Markup Language, intended to define markup-based data representation languages. sysRAND Corporation

59


Figure 58 DOFs with Labels and Principal Attributes to repeatedly establish the coordinate reference frame, axes, terms, labels and other coarse attributes of hardware modules with clarity. 5.1

DEFINITION OF EXCAVATOR AND TUG FOR MODELING

Each of the physical elements of the excavator, turret and TUG has, or will have, a series of CAD drawings to model parts for fabrication and manufacturing. For control, simulation, autonomy and CONOPS testing, many of the top units will also have abstract definitions, definitions that often include descriptions of component parts of the top unit. For purposes of control modeling, the various modules and their control Degrees-Of-Freedom (DOFs) are defined in XML, a meta-language that is in common use among modeling software packages. Since these tools are likely to be modular and feature universal mounting fixtures, the model will accommodate integration of other tools in the future. The excavator, turret, and TUG elements are described here by characteristics and functions that are relevant to control models. 5.1.1 Meta-Definition of the TUG The first level of definition is the TUG, and includes the drive wheels (TWLS), towpoints (TWPT), and deck hardpoints (TYAW). The towpoints and hardpoints are also grouped into a function set of couplers (CPLR), due to common features such as Power Takeoffs (PTOs), Yaw positioning, Latch couplings, etc. Two tiers of the control model (4 DOFs) are intrinsic to this level (module), and are partitioned into the wheel drives and the couplings. The notional six wheels, their steering (if active), brakes and clutches are lumped into a single definition for the moment, particularly since the project is focussed on the excavator and turret. The following meta-definition is a notional placeholder that is intended to begin defining some attributes that are necessary for the excavator, turret and TUG. Observe, for example, the ALIAS term.

sysRAND Corporation

60

Autonomy as an Operational Element of Planetary Surface Systems Z Rotary state = “Malfunction” state = “Jammed” state = “power”, OFF .. ON state = “direction”, CW .. CCW units = “RPM” range = “0..400” Z Complex Coupler state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” PTO Rotary state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” state = “power”, OFF .. ON state = “direction”, CW .. CCW units = “RPM” range = “0..400” TWPT0, CPLR0 X Complex Coupler state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” PTO Rotary state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” state = “power”, OFF .. ON state = “direction”, CW .. CCW units = "degrees" units = “RPM”

sysRAND Corporation

61

Autonomy as an Operational Element of Planetary Surface Systems range = 0..60 TYAW1, CPLR1 X Complex Coupler state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” PTO Rotary state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” state = “power”, OFF .. ON state = “direction”, CW .. CCW units = "degrees" units = “RPM” range = 0..60 TYAW2, CPLR2 X Complex Coupler state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” PTO Rotary state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” state = “power”, OFF .. ON state = “direction”, CW .. CCW units = "degrees" units = “RPM” range = 0..60 TYAW3, CPLR3

sysRAND Corporation

62


Z Complex Coupler state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” PTO Rotary state = “Open” state = “Closed” state = “Malfunction” state = “Jammed” state = “power”, OFF .. ON state = “direction”, CW .. CCW units = “RPM” range = “0..400” TWPT4, CPLR4 5.1.2 Meta-Definition of the Turret The second level of definition is the TUG, and includes the Turret Pitch (TPCH), Turret Arm Rotation (TROT) and Turret Arm Extension (TEXT). Three tiers of the control model (6 DOFs) are intrinsic to this level (module), and are not further partitioned. This device is similar to a Robotic Arm, yet employs enhanced leverage with shoulder-mounted pivots and motors geared for high torque, capable of much higher loads. Y units ="degrees" range = -15..110 Z Rotary units = "degrees" units = “RPM” range = “RPM”, 0..60 Z state = “lock”, OFF..ON units = "centimeters" range = 0..100

sysRAND Corporation

63

Autonomy as an Operational Element of Planetary Surface Systems 5.1.3 Meta-Definition of the Excavator (Tool) In the case of the excavator, and likely many other tools, the third level of definition is the final level and includes the operant tool and accessories and extensions. The Blade Pitch (BPCH) represents the final tier of the spatial control model (2 DOFs). Additional controls include the Blade’s Chain (BCHN) and future accessories would include Star Hammer Drills. Y state = “lock”, OFF..ON units = "degrees" range = -135..-70 Y state = “power”, OFF .. ON state = “direction”, CW .. CCW units = “RPM” range = “RPM”, 0..20

sysRAND Corporation

64


6.0

DIGITAL VISUALIZATION FACILITATES DEVELOPMENT

The Digital Space simulation program has only recently been available to the sysRAND development team, enabling analysis of the model’s functions and fidelity of the the results to original engineering inputs. Images from actual simulation runs are depicted throughout this document. At this time, the team hasn’t had the opportunity to analyze the excavator simulation to develop a digging physics plan. A second version of the simulation program was provided by DS that implemented a number of changes suggested by the team. This version is currently being studied, and additional changes are described in this document. Continuing exercising of the simulation will further refine engineering and science requirements. Identified engineering interests include: • define the turret arm to extend the reach of the blade, • define hoppers, • define the work volume of a discharge chute, • integrate excavator blade, discharge chute and hopper, and • multi-platform (scripted command) simulation support development of CONOPS for continuous and high-rate production.

Figure 59 A Closeup View of the Blade Depicts an Instrumented Bucket

sysRAND Corporation

65


Figure 60 The Nose of the Blade Contacts the Surface The visualization and simulation program will proceed through at least three principal paths that will probably include: • enhancing model physics and operational realism, • defining and refining engineering elements that include turrets, TUG, excavator, hopper, etc., and • developing code-generating tools that support scripting, logs, metacodes and other automation features. Observe that the Pintle Chain has not been implemented, and that the bicycle chain persists in these depictions. The Pintle Chain remains on our To-Do List for the next phase of Digital Space development.

sysRAND Corporation

66


Figure 61 A Head-on View of the Blade with respect to the TUG

Figure 62 A Starboard Aspect of a Blade Digging

sysRAND Corporation

67


Figure 63 A Typical Angle-of-Attack for the Blade

Figure 64 The Turret Connects the Blade and Discharge Chute to the Hopper

sysRAND Corporation

68


Figure 65 Operations Require Extension of the Turret Arm’s Range of Motion

Figure 66 The Turret Viewed from the Hopper's Position

sysRAND Corporation

69


7.0

DIGITAL VISUALIZATION SUPPORTS OPERATIONS

The support that digital visualization provides to the robotic mobility platform in general, and more specifically to the excavator, extends beyond the validation and development of design features. The operation and interaction of excavators and multiple TUGs (or equivalent) with terrain and facilities, can be formalized into working protocols and extensively tested using digital visualization in a simulation role. Operational testing can be extended to include swarm collaborative functions along with heterogeneous mixing of specialized systems. Digital visualization and simulation currently provides high-fidelity testing of teleoperations, and will soon do so for autonomy software, and ISRU operational rulesets. Thanks to changes in national space policy and funding the country is being told that the United States is no longer planning to return to the Moon. Logistics will say otherwise, so sysRAND will continue to develop the Excavator, Turret and TUG to operate in both the Martian and Lunar environments. It isn’t clear at this time that the Excavator can be effectively deployed on NEOs, or are practical tools for such missions. sysRAND wants to assure NASA that a flyable version of the Excavator would be Marscapable. In addition to prior documentations so stating, the inclusion of Stainless Steel in the original design and its more recent upgrades will ensure water tolerance on Mars and other hostile alien environments, such as Houston, Texas. In the interests of consistency, therefore, the "Moonraker" name is being retired and is being replaced in all current instances to a more generic and inclusive "Blade" moniker. 7.1

ON-THE-GROUND OPERATION

We applaud many features of the DS simulation software. Several sysRAND staffers have examined the simulator from different perspectives that range from comfort and familiarity to engineering accuracy and physics intuitions. There are opportunities to test many operational possibilities, obtaining results that could suggest field trials for testing, a priori. One observation that has been made is that are not necessarily problems, although they engender curiousity. For instance, when starting forward, the TUG’s front wheels slip at a faster rotation than the remaining four wheels. Intuition suggests that all six would start off identically, however, sometimes intuitions are wrong. If all wheel drives start with wide-open-throttle (WOT) from a dead stop, the torque

Figure 67 Hardware is “Shadowed” by the DS Simulator Enhancing Design Fidelity

sysRAND Corporation

70

Autonomy as an Operational Element of Planetary Surface Systems from the rear four wheels reduces normal force (traction) on the front two wheels, causing the observed spin due to their diminished contact pressure. Front-wheel-drive automobiles are notorious for this for other, but similar reasons. We’re not suggesting that this scenario is correct for this sim because the actual TUG may be heavy with a complete complement of motors, electronics, batteries, twin Stirling Radioisotope Alternators, and external hardware. Nonetheless, this does speak to the fidelity which is often found in the DS physics model. In practice, TUG designers could offset this traction differential by sequencing motor startup front-to-back, ramping up the front wheels on a shallower current slope, or Pulse-Width-Modulation (PWM) of all motors, in unison. Such notions may be tested in the fully-elaborated simulation when scripts control the platform, further proving the value of realistic, in-situ simulation. We also observed that when the simulated Earth gravity is selected, the TUG barely has sufficient traction to move. It is necessary to ascertain whether this is a power issue or a surface traction problem. Other operational observations served to shape our thinking and influence changes in the design. For example, the initial TUG concept would have employed skid-steering, which, in the manner of a treaded vehicle (e.g.: tank or caterpillar) uses the differential (including reverse direction) of two tracks to steer the vehicle. It is clear from running the Digital Space simulation that normal wheeled operation would cause considerable wheel slipppage, creating dust clouds. The many Lunar dust transport vectors would soon have our intrepid robot coated in the stuff. Slip-Steering would deliberately induce slippage to a larger extent than that generated by pivoted steering, which is not consistent with a low dust-generating regime.

Figure 68 Operator Inputs are Translated into Command Scripts

sysRAND Corporation

71


CONOPS DEVELOPMENT

The loop of command console, autonomy, visulaization/simulation, and metacode software systems will enable very sophisticated planning and testing of concepts of operations (CONOPS). When mission planners have a high-fidelity visualization and simulation tool available that corresponds to anticipated hardware and autonomy software, it is possible to develop a corpus of operational assets and experience, in advance of actual hardware deployment. These training and development platforms will strongly influence autonomy, hardware and software development. 7.3

REALTIME OPERATIONS SUPPORT

Experience and tools enhanced by experience will make possible realtime prognostication that parallels concurrent operation of actual hardware, on-site, in realtime. A software “twin” of the hardware emulates the hardware and shadows it step-by-step. As facilities are available, such as those depicted in Figure 67, it will be possible to manually conduct a session, then edit the logfile to generate a command file to reproduce the training episode at will. Utilities will be able to smooth the operator’s inputs, filter recurring command clusters for conversion to macros, insert (virtual) waypoints, and many other facilities that enhance development of operations and autonomy software protocols. In the operational equivalent of design shadowing, and as design and operations experience is accumulated, the DS Simulation can “ghost” the actual hardware. This affords the operator some situational awareness, even when remote views or communications are imperfect or eclipsed. This ghosting can be derived by providing sparse data from repositories to a twin autonomy emulation at a control location on Earth. The ghosting simulation is executing the identical Electronic Work Order, and following the actions of the Lunar-based TUG, so that when the commlink is broken the ghosting program has a reasonable chance of remaining in sync with the TUG. 7.4

TECHNICAL FIXES TO VISUALIZATION

Changes are herein suggested to enhance the fidelity of the simulation plug-in and result from two sources, the operation of the simulation and the depiction elements. The DS model currently implements arc steering where the center wheels are fixed and the corner wheels coordinate a turn. One complaint that we dispute, yet include here, because it will surface again: “When going downhill, the speed of the TUG is the same as when it is going uphill or on level ground. It should realistically accelerate.” Our opinion is that properly servoed wheel drives will also regeneratively brake any time that there is a downhill, or negative gradient, so that the observed behavior is the correct one. Kudos to DS!

Figure 69 Arc Steering

sysRAND Corporation

72


7.5

OBSERVED TUG DEPICTION & SIMULATION PROBLEMS

Operational problems are those where the TUG’s behaviors are counterintuitive or incorrect in the physics of the motion and applied forces. When directed to drive the TUG in reverse (the "S" button), TUG wheels cycle independently on the steering DOFs and applied wheel torque oscillates between forward and reverse. Realistic operation whould maintain steering settings and reverse torque, as it would when the "W" button is depressed for forward motion. This behavior represents at least one programming bug, although it is likely that more than one is in play. We have tagged this behavior with the moniker of “the shopping cart effect,” and suggest that the DS team observe it carefully -- This behavior has been shown to have application to the realworld and for that reason we want to investigate the physics of this serendipitous finding, and be able to invoke it deliberately, on demand. This feature has successfully allowed the TUG to crab sideways and clear itself from being trapped on rocks, although it may be an artifact of software rules and not reflect actual physics14. An attempted rationalization of this potentially useful effect can be seen in Figure 70, below, Sometimes one or more wheels will be suspended above the surface while not generating traction. This suggests a need for a looser suspension on the TUG physics to maintain surface contact to the extent of the limits of the model’s wheel mechanisms, Sometimes robotic platforms may be simplified by use of fixed wheels that, like tanks, use differential drive to steer a vehicle by skidding. This is accomplished by driving the wheels on one side in forward and the opposite side in reverse. The actual power levels applied to the six wheels may be different. We expect that NASA will choose this option, fulltime, but its hard to tell. A skid steering option could be invoked with a key as a toggle, identically to the Pivot Steering option (turned on with "F" and turned off with "R"), When all six wheels are steerable, it is possible to implement a Skew steering option, where all wheels assume an identical angle. This allows the TUG’s deck to maintain an orientation even while the platform is moving off in another direction. We don’t currently have an application for this possible feature, The simulation could make good use of a “parking brake,” a way to idle the system and hold it stationary, and not have it creep around as it currently does, sometimes rolling back down a hill. A top level on/off function will be employed by other simulation software, so the TUG should freeze in place when so directed, because servos seem to creep in a positive direction when idle. These functions could be a single-key toggle.

14

We described this ‘feature,’ or ‘bug’ to NASA, and they intended to research it separately.

sysRAND Corporation

73


Figure 70 Apparent Crab Effect Made Coherent

sysRAND Corporation

74


Figure 71 Skew Steering

Figure 72 Pivot Steering 7.6

OBSERVED TURRET DEPICTION & SIMULATION PROBLEMS • Flashing beacons near TUG's turret should flash on and off. Intervals of 1 second offer a notional starting point, although a flash rate of 100 strobes/minute is common. • The flashing beacons are not eclipsed by excavator or turret. The TUG seems to block them correctly, • In the latest fixes, the flashing beacons do not flash, • The Turret is currently limited to a yaw of about 45° to port and starboard from the vehicle centerline. The Turret should rotate a continuous and repeatable 360° with no stops or limits on the azimuth plane, and the current arm can only turn about 70* left or 70* right from a position of facing straight ahead (a total of 140* or so) • The vertical limit (pitch axis Y) for the turret arm needs to be increased to 90°,

sysRAND Corporation

75

Autonomy as an Operational Element of Planetary Surface Systems • The graticule shown on the Turret Arm Extension could be graduated in 10 cm (4”) intervals for reference, see Figure 73, • Linear Actuator for turret pitch is broken. However, the actuator is more likely to be a high-torque geared rotary motor, so the Linear Actuator can be entirely removed, • The scale of the Turret should be increased by an estimated 40% in each dimension, • The turret does not react to contact with the ground or small rocks, and • the excavator arm reacts to collision with the largest rocks in the simulation space. It bends and moves in response to the impact, however, this reaction does not exist with the ground or other rocks.

Figure 73 A More Accurate Turret Arm Extension Features a Tubular Shaft with a Fork 7.7

OBSERVED EXCAVATOR BLADE DEPICTION & SIMULATION PROBLEMS

Since the Excavator is the star of this show, it is appreciated that most of the excavator’s features are correct, as presented. We were particularly surprised that DS had included the single instrumented bucket on the underside of the chain. • Chain motion, and therefore, chain motion control is missing. These aspects include chain forward, chain reverse and chain stop command. We suspect that motion may be simulated by depicting the advance or retreat of buckets in three or four discrete steps, rather than as a continuum, • The simulator’s excavator blade is using the motorcycle chains, for accuracy it should be changed to use a pintle chain, per Figure 74. The K-1 platform is positioned over a link and welded in place. The buckets are bolted to the K-1s and occur at intervals of five links for a total of 16 platforms (buckets) along a total of 80 links, • The excavator arm is slow to react to a collision with the largest rocks in the simulation space. This is in contrast to the wheels, which seem to have the proper physics when it comes to collision,

sysRAND Corporation

76

Autonomy as an Operational Element of Planetary Surface Systems • The excavator blade does not react to contact with the ground or small rocks, and • The excavator blade is depicted using the motorcycle chains, it should be changed to a pintle chain.

Figure 74 Pintle Chain Links ASME D-662 7.8

OBSERVED USER INTERFACE PROBLEMS

Early on use of the simulator will be entirely man-in-the-loop. Later, sysRAND will drive the simulation from command scripts that derive from a number of sources which have been identified. Further, the package is expected to be accessible, and possibly distributed, to NASA technical staffers and the public as outreach collateral. So we’re paying some attention to the User Interface aspects of the system. • There is interest in using a gamepad controller, joystick or other ergonomic manual controller, • It has been suggested that a Heads-Up Display analog be developed that indicates the many Degrees Of Freedom (DOFs) of the platform, turret, and tool articulations. An indicator/HUD component for what angles the arm and excavator blade are at, settings of actuators, etc., are typical, • The user can drive the camera through the ground, often causing confusion for the user. This is actually a useful feature, so it would be useful for the camera to pause for user input or tickle an annunciator when it contacts the surface. Alternatively, a key that would return the camera to a default position above the surface may be a solution, • A particularly handy user option feature of the simulation would be to have the Camera perspective lock on to the TUG (relative movement) so the user can focus on driving the TUG instead of both driving the TUG while controlling the camera. Even better would be the facility of prepositioning a small number of cameras, and then selecting among these vantage points, at will, in the course of a simulation, • A Frame Grabber feature could be particularly useful and would conduct screen captures at selected frames per second rates (decimated), perhaps on the occurrence of certain events, eg., timestamp, • A Checkpoint feature captures the system state at arbitrary times, whether by selected interval or user intervention. Checkpoints include navigational/positional data, platform, turret and tool orientation, etc. Checkpoints have a unique label based on a timestamp and can be selected to start a new session using a known starting point, sometimes after rebooting the system. These can be useful for re-enacting a scenario in a new direction, or re-starting a session that was interrupted in mid-course, • An indicator/HUD component for what angles the arm and excavator blade are at, settings of actuators, etc., • When the "S" button is pressed to reverse, the TUG's wheels oscillate on their own accord, be realistically should remain unturned similar to when the "W" button is pressed for forward motion, • The camera view should lock on to the TUG so the user can focus on driving the TUG instead of

sysRAND Corporation

77

Autonomy as an Operational Element of Planetary Surface Systems both driving and controlling the camera, • A larger work site (diameters scaled to kilometers), and • the surface beyond the work site should be more, uncontrolled terrain. 7.9

TERMINOLOGY FOR GUYS WHO PLAY IN DIRT

We are in the habit of understanding the application context of the end-user, someone who is not often the customer for a project. The users of the Excavator/TUG will be rocket scientists who know little or nothing about dust and dirt, students, along with mining, civil engineering and pilot-types. We are trying to employ the best descriptive jargon of the many disciplines and trades that influence or are represented in this domain. In the vocabulary for changing the extension of the arm, when the tool is pulled back towards the turret, it should be called "Retract" instead of "Extend In". Similarly, "Extend Out" should be changed to "Extend", and others. 7.10

OTHER FUNCTIONAL ENHANCEMENTS

Perhaps other projects may surface that can fund additional enhancements to the simulation’s functionality and utility. • Detailed operation of the fore and aft couplers/PTOs would be helpful, allowing operational testing of “TUG trains” and other modular tool aspects, • A user-defined work site perimeter could be very useful, i.e., select a diameter in fractions and multiples of kilometers, • TUGs will traverse uncontrolled surface (cross-country) between multiple controlled zones that include worksites, depots, landing pads, outposts, “drydocks,” garages, etc., • A nice-to-have effect is to have clouds of dust and dirt disturbed by passage of the TUG or digging by the excavator, including tracks, • At some point there will be a need to maintain a map of digging operations and other disruptions of the surface, including trenches, pits, berms, piles, etc., and show them on the surface, • Later, when these things move into mission-level simulation and planning, it will be advantageous to employ terrain surface maps of Mars and the Moon, and • While they do not currently offer utility at this point in time, it will likely be helpful when the accessory, navigation and work lamps are available and under program control. Control on TUG hardware will be mildly interesting because of multiplexing, color modulation, intensity, etc., although this does not have to be strictly modelled in a simulator. 7.11

TOWARDS A USER GUIDE

A good user guide can contribute to the success of a product and can also be incorporated into the Help pulldown window. Experience of alpha and beta users can determine the content of a user guide. So can common sense. We are accruing information that may lead to a user guide, some day. A few items with which we can begin to populate a user’s guide after it has a top-level design (outline) might resemble: • The windows key at the bottom left of the keyboard can be used to minimize the program. • The up and down arrow keys and page up and page down keys operate in rectilinear space. • The left and right arrow keys operate in polar space.

sysRAND Corporation

78


TUG and Tool Control Models

sysRAND Corporation

79


TUG AND TOOL CONTROL MODELS

Implementation guidance is provided toward automating excavator control models. Integration of the excavator with robotic mobility platforms is defined at the top level. Foundational methodologies include an inversion of the usual control ”centrism,” whereby the tool function software now directs the operation of the robotic mobility platform, instead of the conventional orientation where the platform operates the tool as an afterthought or “tack-on.” A work order is issued that provides control authority for the tool to execute a narrowly defined task according to specified parameters that facilitate the resolution of conflicts with terrain and other surface agents. This approach will allow for a centralized dispatch while encouraging development of distributed intelligence -- which operates within the defined operational envelope -- workspace volume, and traffic management. The MPED excavators and the distributed, semi-autonomous mobility platforms (TUGs) are low-power, low-mass devices that could quickly have a presence at numerous Lunar sites. Their communications and control needs are probably best supported with a combination of satellites, local radio towers, and unit-to-unit relay links to over-the-crater-rim network nodes. The distributed wireless network represents the lowest cost, most pervasively applicable approach to connecting things on the Moon. In the here-and-now, in the course of preparing the excavator for laboratory shakedown and field trials, controls being refined and the design iterated toward a flight-ready system. In order for the excavator to be productive, the blade should be in constant motion. This is due to the void created in the regolith when it is scooped out – the device cannot get a second bucket of soil from the same space and the blade must be moved forward, sideways, or deeper in order to gain purchase on the next full scoop of regolith. In order to achieve the modeled 500 to 1,000 kilograms of hourly production, the combined motion of the mobility platform, the robotic arm/turret, and the excavator blade must keep the blade’s nose imbedded in the trench, constantly addressing the workface of the regolith cut. While man-in-the-loop (teleoperated) command and control is the current paradigm, semi-autonomous, autonomous, and swarm control modes will reduce the bandwidths required to control construction and ISRU devices. Over time, this shift will shorten the control path as precursor missions give way to intermittent control from crewed missions. Autonomous features that exchange data among mobility platforms may moderate communications bandwidth to Earth, while local and regional traffic will grow dramatically. 8.1

EVOLUTION OF CONTROL

The specific level of control autonomy varies from none to exception intervention, a span that maps from one hundred percent teleoperated to teleoperated only when all else fails. The operating extent of autonomy for any given platform at any given time is asserted by one or more global variables (mission directives) that are operator-selected, although system watchdogs may reset when inactivity or failure to perform conditions occur. These evolutionary steps can be a result of deliberate design, a de facto result of implementation convergence, or through chance. A continuum of discrete control models spans the evolution of control architecture from teleoperation to swarm operations. The architecture appears to be extensible and evolvable as technical progress is realized. Autonomy features are realized at three distinct levels of structure: • passive autonomy that is entirely reactive, • active autonomy that is proactive, and asserts deliberate control function, • active autonomy that is predictive, asserting control decisions in advance, and • group autonomy that is a gestalt, synergistic result of collaborative protocols among multiple platforms that are actively autonomous. Rules that govern static or equilibrium states should favor activity that causes the system to learn by exploration. For example, while a platform could remain idle when it has no command or function in play that keeps it “busy,” a roaming function would encourage the platform to explore and learn serendipitously about its environment while it awaits new orders.

sysRAND Corporation

80

Autonomy as an Operational Element of Planetary Surface Systems Contemporary notions of spacecraft autonomy would likely be framed by the following expectations: the spacecraft continues to operate during Loss-Of-Signal (LOS) from mission control and/or tracking, the spacecraft continues to acquire sensor data, using the spacecraft’s elastic memories associated with its C&DH / Store-and-Forward functions, if so directed, the spacecraft makes high-level decisions based upon internal states, external situational awareness, and/or stored rules derived from mission directives, the spacecraft’s command system has primitive commands, the spacecraft’s command system also features high-level (abstract) commands, Productive autonomous agents should be quick to identify and perform (volunteer) for the many small tasks that need doing when the have the appropriate tools mounted. Agents should communicate these small tasks to others when the finder is unable to service the need. At all levels it is essential to share things, especially learned behaviors, with peers.

Figure 75 Autonomy Capability Increases with Experience Direct ground control (supervision) decreases although ground authority is maintained through Electronic Work Orders (EWOs) and other mechanisms, such as Control Zones. 8.2

TELEOPERATION

Early models of the excavator and mobility platform ensemble are expected to employ teleoperated control systems. Depicted in Figure 91 is a system block diagram of teleoperation essentials. Integration of a local controller for the excavator will enable operations of the mobility platform, the turret, and the blade from a remote workstation. A succession of control methods will permit the user to control the

sysRAND Corporation

81

Autonomy as an Operational Element of Planetary Surface Systems excavator through the use of manual operator controls (keyboards and haptic joysticks), and later through a direct program control that invokes pre-canned macros from time to time. Under teleoperated control, the operator will provide a delayed response to all remote stimuli in an openloop, reactive mode. 8.3

SEMI-AUTONOMOUS

The next step is to allow the remote platform to respond in a locally-derived, reactive mode that allows for an immediate, real-time response that may be sub-optimal, yet better than any late response, no matter how optimal. For example: a tool is dislodged from it’s robotic arm mounting, and the system responds by halting the yaw and pitch movements currently underway, while removing power from the appropriate branch of the distribution cable. In time, this is followed by a pro-active operating mode, where for example, a platform can apply power to the wheels in anticipation of human input, based upon the operating context, and current on-the-ground situation. A downstream learning program will analyze operator logs, filter novel and repetitive command sequences, develop macros, and operate the bucket ladder and robotic mobility platform directly. Traffic and tool rules begin to emerge from the experience base. 8.4

CONSTRAINED AUTONOMY

The next step in emerging autonomous operation is a predictive mode, in which a platform’s sensor fusion is sufficiently acute, and processing capabilities realtime, such that the platform can anticipate events in advance of their occurrence, no matter the intervening time interval. Examples could include the application of brakes to avoid an impact, or shutting down certain peripheral worksite operations in anticipation of the onset of the Lunar night, (although we still anticipate 24/7 operations). Autonomy on this platform is a continuous operating mode, except for those occasions when an exception or problem occurs. While most systems employ a hierarchy of command decoding, this system decodes commands by closing the gap between the current system state and that specified by the current command. This is a result of the fact that autonomy is operating continuously as the basic mechanism of decoding instructions. The autonomy system will “phone home” only when it is unable to resolve a situation. 8.5

COLLABORATIVE AUTONOMY

When autonomy is sufficiently mature, incorporation of rules in support of swarm behavior is applied to tactical processing in order to evolve collaborative behavior. While this mode may prove to be opportunistic, it will not be imaginative. Rules imbedded in the autonomy’s machine learning system are sufficient to the implementation of swarm or hive collaboration rules. Some functions will be stitching together collaborative behaviors through the endeavor to implement autonomy; these often will be found to be situational awareness, radio chatter, traffic, and trajectory processing. 8.6

LEARNING AUTONOMY

This version of autonomy is projected and may be superceded by cognitive approaches. It is entirely non-deterministic insofar as it is free to alter or replace its operating rules. Genetic Programming or other emergent, self-modifying methods will operate in a context that encourages competition and performance evaluation feedback to the modifying processes. These methodologies employ considerable trial-anderror and require supervision and training. Such activities are likely to require bandwidths that cancel the benefits of autonomy and may be derived at considerable cost in broken machinery and other collateral damages. Genetic programming synthesizes new processes through application of random mutations to program structures on a trial-and-error basis. The resulting constructs are then tested for appropriateness-of-fit

sysRAND Corporation

82

Autonomy as an Operational Element of Planetary Surface Systems and compete with other structures to survive. The trial-and-error component of genetic programming makes the methodology unsuitable for the early stages of most space exploration programs. It would be a rare mission upon which one could “bet the ranch” on the turn of a single code symbol during the next few decades of extremely lean logistics. For learning systems to be productive, there must be time available for trial-and-error iterations of rules development/emergent behavior series. Test platforms may have to operate in a sandbox to develop new rules that can be transmitted to agent machines in the field. Adaptation is a primary, bottom-up mechanism for self-organization to progress from modest complexity to high complexity. It is the method employed by Nature, it is tedious, slow, and not very forgiving.

sysRAND Corporation

83


Robotic Models

sysRAND Corporation

84


ROBOTIC MODELS

The civil engineering and ISRU mining activities of Lunar exploration and settlement require a number of tools in order to shape the surface environment. These activities also require an expenditure of energy, as well as a platform to support the tool’s deployment. sysRAND has devised a notional TUG that is intended to support a wide range of mining and surface engineering tools, as well as an energy plant that frees up the ensemble to conduct operations for extended intervals, around-the-clock. A detailed control structure is under development that uses recursive partitioning and uniform methods for the robotic mobility platform, the robotic arm, or turret, and modular tools. The TUG is a notional unmanned robotic mobility platform that is a generalization of a number of prospective platforms that may be available in the near future. The TUG has three hardpoints for mounting (modular) robotic arms, turrets, and specialized tool mounts. The hardpoints are positioned at quartering intervals along the foreto-aft centerline of the deck. The deck is 8 feet in length and 5 feet in beam, so that the mounting hardpoints are centered at the 2, 4, and 6 foot intervals, and 2.5 feet from each of the sides. The structures and actuators of conventional robotic arms are too weak to handle the tools of surface engineering and mining. Robust robots are hydraulic or pneumatic and use linear actuators, typically a cylinder-and-piston configuration. Such an approach is quite impractical for space applications; as a result, electric actuators are employed. Robotic arms pack a mechanical joint with a precision motor, an index wheel, and power and signal cables, all of which serve to weaken the joint. The lack of leverage for the motor causes significant power draw, whether to change or to maintain position.

Figure 76 Degrees of Freedom for the Excavator Blade The excavator will employ a turret in lieu of a robotic arm that will have the positive attributes of a robotic arm and few of the negatives. A turret uses more powerful but less sophisticated motors while adding considerable leverage, which amplifies the effect of the motor. The turret packaging provides a spacious housing in which a motor can feature gearing to provide much more torque than the bare motor. The

sysRAND Corporation

85

Autonomy as an Operational Element of Planetary Surface Systems gearboxes can also lock the mechanism without further expenditure of power in order to hold position. The turret provides space to support auxiliary functions such as a Power-TakeOff (PTO). The turret is primarily intended to support the unique features and dimensions of the Excavator blade, yet, through the expedient of a universal tool mounting, other tools can also be implemented. The excavator requires that a steady force be applied to the blade so that its weaker positioning motors are not required to deliver all of the necessary forces. In addition to positioning the excavator blade, the TUG and Turret motors each deliver the necessary force to be applied by the blade’s buckets to the excavation workface. 9.1

USING LANGUAGE TO REMOVE AMBIGUITY

The language of robotic controls very strongly resembles that of platform navigation, reflecting the scalability of the spatial location and orientation. Terms defined by Hunt that echo navigation are: Spatial resolution describes the smallest increment of motion at the tool tip that the robot can control. Accuracy relates the robot’s spatial-resolution-defined positional ability (including mechanical inaccuracies) to an arbitrary fixed-target position. Repeatability describes the positional error of the tool tip when it is automatically returned to a position previously taught. Repeatability will generally always be better than accuracy, exclusive of drift.

Figure 77 Concise Definition of Robotics Terms In establishing our development jargon, we can certainly adhere to the formalities of engineering and computer science. We could also be stiff and humorless. However, we much rather prefer to have a

sysRAND Corporation

86

Autonomy as an Operational Element of Planetary Surface Systems sense of humor and relate to our users, who are serving thanklessly in the field. We are in the habit of understanding the application context of the end-user, someone who is not often the contracted customer for a development project. Users of the Excavator/TUG will be rocket scientists who know little about dust and dirt, students who are learning, plus miners and civil engineers who are experts in the(ir) field. However, we prefer the terminology of Guys Who Play in Dirt . . . sail boats . . . and fly airplanes. In an effort to remove ambiguity for all concerned, nautical terminology will often be employed so that platform or tool orientation is not allowed to fall prey to confusion over “left” and “your other left.” In other research pursuits, the jargon characteristic of certain vocations has evolved through experience for practical reasons. Some of these reasons include site and navigation safety, avoiding waste and rework, and generally to maintain crew humor at all times, and so to minimize their frustration with one another. The use of the terms “right” and “left” is ambiguous because they are relative to the observer. Nautical terms are less confusing because they are always referenced to the ship. There also exist ambiguities in the current nomenclature, e.g., when the excavator blade is “down” and canted towards the TUG, say at – 110°Z. The operator has to remember that the correct input to bring the blade back around to “front” from this position is “UP,” which is linguistically counterintuitive. Irrespective of the terminology that we use, there will be a “cross-control” problem where the control inputs are contrary to how one talks about them. Therefore, the TUG, Turret, or Tool may often be referred to as having an attribute of “port” and “starboard,” or “fore” and “aft,” terms which unambiguously specify an aspect of the device. There continue to be other practical applications, where the Excavator’s mounting, power, and signal ports are consistently located on the “port” side of the Blade. The language of Aviation, in terms of navigation, aircraft attitude, and procedures in controlled airspace is also extensively employed here. There is no practical value to reinventing these elements when literally billions of hours of practical nautical and aeronautical experience can be applied. Exempli Gratia: Rotating the Turret on its Yaw axis is a “Turn to Starboard,” or a “Turn to Port.” Rotation of the Turret Arm is relative to the top of the device (think helm): “Turn to Starboard” or “Turn to Port.” In the vocabulary for changing the extension of the Turret arm, when the tool is pulled back toward the turret, it is "Retract(ed).” Similarly, when the Turret arm pushes the tool away, it is "Extend(ed)".

sysRAND Corporation

87


FUNCTIONAL PARTITIONING AND SYNTHESIS

The mobility platform (TUG) is about motion and applying the energy necessary to move simultaneously at several scales to deliver work to a point in space with precision. The Excavator and TUG are an industrial agent operating in the open, out in the field, on the surface of Mars or the Moon, and capable of building very valuable things. The end-to-end model uses servos in three principal stages, per Figure 78: Stage One is navigation of the mobility platform about a planetary surface in a coarse resolution that deals in kilometers and meters. Stage Two reflects the operation of the half-dozen powered hardpoints that are integrated into the TUG, plus any robotic arm/turret/attachment, and is mid-scale, operating in terms of meters and centimeters, while applying the largest fraction of degrees-of-freedom of the entire ensemble. Stage Three is the intelligent, modular tool that performs the actual work function, and is expected to be high resolution (fine), operating in terms of centimeters, occasionally stretching into meter ranges.

Figure 78 Each Modular Device Represents Recursions into Finer Precision Each stage represents a range of degrees-of-freedom (DOF) that approximately follow mechanical module boundaries. In Figure 79, controls are partitioned by the DOFs that are applied successively, and in diminishing scale, a concept that is expressed crisply in Figure 80. It is interesting to observe that at least one rotary function of the next module is subsumed by the previous larger module, e.g.: the TUG powered deck hardpoints drive the yaw axis of the robotic arm or turret. There is a corresponding shift in the task scope for each stage, as well. In the Stage One context, the TUG must be cognizant of navigation, while in the Stage Three context, the TUG must provide the steering path corrections and pulses of wheel-torque necessary to inch the platform forward. (This provides the basis for the excavator to provide pressure against the workface with a minimum of excavator blade motor input). At the same time, Stage Three (Excavator) is oblivious to the location of the worksite and yet is well informed of the location of the subsurface workface by its many sensors.

Figure 79 The Tug, Turret, and Tool Modules are Recursively Defined As we proceed from left to right in Figure 80, it is evident that the scale of each stage is diminished from the previous. The coordinate frame remains fixed, yet the scale of operations for the TUG ranges from

sysRAND Corporation

88

Autonomy as an Operational Element of Planetary Surface Systems kilometers down to decimeters, and the turret and tool from meters to centimeters. accessories will usually operate from decimeters to millimeters.

Finally, the

The variation in scale across the stages is consistent with the implementation of a coherent Reference Coordinate System across the TUG, Turret, and Tool. Since the TUG has three deck mounting points and is agnostic about which direction along the roll (x) axis15 is “front,” the center Mount Hardpoint is the “Origin,” so that operational symmetry can be easily achieved when things are “turned about.” This reduces computational complexity to a matter of adding a displacement to the roll axis to account for a turret mount on the fore or aft quarter hardpoint.

Figure 80 Range of Motion and Energy Spans Stepwise from Coarse to Fine The control model cycles at a forty Hertz rate to provide apparently simultaneous motion in multiple axes, or Degrees Of Freedom (DOF). This scan rate allows the system to operate in apparent concurrency, yet has the resolution to operate all servos in near-realtime. Since the recursive traversal is a circular process, changes in state induced by the current context will become visible upstream on the next iteration. Like the Russian matryoshka doll, posting the mechanical DOF axes suggests a control model that starts at the coarsest level of motion and advances to finer levels of motion, such as that shown in Figure 80. The point of this diagram, and the reinforcing image of Figure 81, is that the same handful of programs operate all of the servos at each layer or level, recursively, at forty times per second. Also note that the coarsest level of motion corresponds to the largest consumers of energy while the finer levels of motion correspond to the smallest.

15

Also called the “keel” axis.

sysRAND Corporation

89


Figure 81 A Vivid Image of Nested Matryoshka Dolls While using the same routines top-to-bottom, or left-to-right, each recursive context uses a corresponding data block in global memory, in a reentrant fashion. Each of the populated hardpoints follows the identical recursive execution path, using the very same program code. While the control program is a reentrant process that can be used in multiple contexts, each of which has a unique dataframe that is referenced upon entry into the re-entrant process. The control program is also tail-recursive, which calls an instance of the procedure upon exiting the current procedure instance. This structure also (optionally) eliminates the need for a procedure stack, since the procedure instance can forward the data derived from the current instance to the next without complexity, either by reference or by value. There is nothing to be gained by a hierarchical structuring of the many control layers. The recursive mechanisms described here are heterarchical, and adjust and fine-tune operations on all levels. There are a number of control problems that are eliminated by this structure.

Figure 82 Limits and Interferences are Tested Before Motion Commences

sysRAND Corporation

90


STAGE ONE: PLATFORM NAVIGATION

The primary servo subsystems are the power and steering of the mobility platform wheels. These are used to drive and steer the platform across the landscape, where wheel rotation motivates the platform along the Z-axis, plus and minus, and the wheel steering applies yaw to the direction vector. The wheels can drive the platform’s Z-axis velocity vector in the range of zero to 10 Km (6 MPH) at the macro scale for moving about in the worksite or cruising cross-country. The wheels also drive at fractions of inches (centimeters) per second, at the microscale to support excavation and mining activities. Stage One navigation is equivalent to an integration of a spacecraft’s guidance and navigation, attitude determination and control system, and propulsion functions. Stage One monitors current and projected slopes, velocity, accelerations, wheel slippage, anti-lock brakes, and course inputs on an apparently continuous basis. At a rep rate of forty times per second, the state of the platform’s attitude, course, speed, etc., are evaluated and corrective feedbacks are applied. During travel, the platform is agnostic about front and rear, and may reverse course by switching wheel motor direction. During excavation or other tool-dependent operations, the platform does observe front vs. rear platform aspects, due entirely to robotic arm/turret/tool deployment on specific hardpoints. The initial TUG concept would have employed skid-steering, which, in the manner of a treaded vehicle (e.g.: tank or caterpillar) uses the differential (including reverse direction) of two tracks to steer the vehicle. It is clear from running the Digital Space simulation that normal wheeled operation would cause considerable wheel slippage, creating dust clouds. The many Lunar dust transport vectors would soon have our intrepid robot coated in the stuff. Slip-Steering would deliberately induce slippage to a larger extent than that generated by pivoted steering, which is not consistent with a low dust-generating regime.

Figure 83 The TUG's Attitude and Navigational Axes

sysRAND Corporation

91


Figure 84 Mirrored Ackerman Steering of the TUG for the Tightest Turn Radius

sysRAND Corporation

92


STAGE TWO: TURRET MANEUVERING

The turret is intended to deploy a wide range of tools and devices, and for this reason the work volume to be supported by the turret will be characterized separately from tool work volume. The work volume of the excavator blade may be an extreme example of a significant extension of a tool sweep, which may lead to an expansive work volume. This example may prove to be typical as other civil engineering and mining tools are added to the turret and tool rack capabilities. Turret maneuvering begins with the TUG’s deck powered hardpoint that contains an integral rotary motor, delivering the torque necessary to drive the turret’s yaw motions, and maintain fixed positions. This motor can rotate continuously in either direction. The next servo is the turret arm pitch that can move through a range of roughly 90°, from Z-30° through Z+60°, raising and lowering the excavator with respect to the TUG. The third servo is the turret arm extension that extends and retracts along the z-axis plane, effectively lengthening the reach of the excavator from the TUG. The fourth servo is the turret arm rotation around the z-axis. THis optional servo is a “wrist” that adds the facility of making planar cuts outside of vertical or horizontal. A fifth servo drives two DOFs of the Excavator’s pitch in addition to the Turret Arm Pitch (nr. 2 servo).

Figure 85 Combined DOFs for Turret Articulation

sysRAND Corporation

93


STAGE THREE: EXCAVATOR MANEUVERING

Moving the excavator is principally accomplished by the many servoes of the Turret Arm. This includes the second two Degrees-of-Freedom (DOFs) of the excavator’s pitch. The remaining servoes are the chain drive and any potential accessories, e.g.: Star Hammer. The digging functions of the excavator include fixed and oscillatory motions. Simple motions correspond to operation of a single servo, where: Trenching is considered to be those cuts that are accomplished with a single, fixed kerf-width digging motion (planar), Sweeping occurs when the Blade is “swept” laterally between two yaw angles, Nodding is where the Blade cuts up and down, on the pitch axis, Rocking happens whenever the Blade twists on a Z-axis (roll), and Combinations of the above motions are interleaved, or sequential chainings, of the above.

sysRAND Corporation

94


TRAVERSING RE-ENTRANCY

The Recursive Process Cell, see section 9.10, is a cluster of inter-related fuzzy logic inference engines that accomplish motion trajectory prediction and execution. Included in the tight group are limits and interference testing. The Recursive Process Cell (RPC) is invoked for every level of servo control from the TUG drives and steering through the Excavator Chain and accessories. In addition there exists two types of reentrant data structures that have a unique instance for every layer of recursion, 1) an InterProcess Communications Data Frame to convey state information among adjacent recursive invocations, and 2) a Context Data Frame that has global data that is specified layerby-layer, and is descriptive of the context in which the current invocation is operating.

Figure 86 Execution Contexts for Process and Data

sysRAND Corporation

95


FIRING RULES AND TRANSITIONS

Firing Rules are an element of Petri Net State Diagrams. Petri Nets are a bi-partite diagram composed of “places,” or state, and transitions. One of the features of a bi-partite diagram is that each of the two component types can only connect to the opposite type. In Petri Nets, places can only connect to transitions, and transitions can only connect to places. Transitions and places each have input edges and output edges. Transitions are further extended by assignment of firing rules, which are evaluated in realtime to determine whether a routine (state) is ready for execution (instantiation) whenever it is invoked. In the Petri Net instance, firing rules are Boolean expressions that evaluate to True or False, and when a transition’s firing rule results in a true condition, it’s output edge activates a place. Similar application of firing rules to program execution fundamentally changes the nature, and behavior of a system. Through the simple device of not executing a routine if it isn’t ready, the realtime application can save valuable time, computations and energy. For the autonomy application, a firing rule is used to activate a process in the case of a true condition, or block it, in the case of evaluating to a false condition. The utility of a firing rule is enhanced by adding the availability of necessary input data to the list of arguments needed to begin processing. This is a structure that is a fundamental dataflow enabler, that also permits concurrent inclusion of state and control information. The argument list in the firing rule can have a type of float, integer, text, pointer, etc., and when data arrives that targets the a specific argument in the list, and is of the correct type, another Boolean term is satisfied. The terms of the firing rule (FR) expression (FRX) are data, and the state or value of the data (semaphore), or the mere presence of the data (as a message) may be used as the term’s participation in the FR evaluation. Once the data has been consumed and the routine executed, the argument buffer is nulled. The syntax of a Firing Rule is: Process_ID [ | ]; An expression is one or more terms connected with logic operators, “+” (or), “*” (and), or “#” (exclusiveor). Terms may also be prefaced with a negation unary operator, “!“. Named firing rules are static so that some determinism may be retained in the system. Dynamic firing rules are intriguing but not necessarily traceable in code diagnostics.

sysRAND Corporation

96


SURFACE DATA REPOSITORY

Data will be accumulated by most activities found onboard the TUG and its extensions. The presence of a Data Repository will facilitate the retention and data mining necessary for enhanced data acquisition and platform autonomy functions. In platform navigation, for example, navigation data may be accumulated and binned by various parameters that might include currency, distance from current location, precision, etc. A data repository provides a persistence that supports a platform’s autonomy and can remain available to a future mission, which may be able to take solid advantage of a given platform’s “experience.” Landmarks and other objects of interest to navigation can be numerous and widely variable in type including, for example, routes of current and previous activity and flags for those that have resulted in dead-ends. Dead reckoning algorithms (e.g., Kalman filters, for one) may be able to mine a sparse data base of diverse information to guide a platform in the absence of more direct assistance. Data repositories also provide an elastic store in support of Command & Data Handling functions, such as Store-and-Forwarding, and can serve to avoid overwhelming systems with excessive dataflows during peak events. Information may be compressed, aged, and decimated yet still retain essential features without retaining each and every minutia of raw data. Persistence of data allows for the synthesis of information and when aligned with context can also yield knowledge. Data repositories also enhance concurrent processing and facilitate operations by removing management of dataflows and subscriptions over brittle networks. The repository also supports the activities of the spatial mapping and the navigation systems, and thereby, the reentrant processes of the recursive cells. These calls for data are used up and down the scale of recursive processes by the C&DH, GNAV, ADCS, Sensors, Objective Testing, Trajectory Prediction, Limit Testing, Interference Testing, plus the Invert & Translate fuzzy logic inference engines. At the coarser scales of control, spatial mapping maintains a navigational map including known interferences, both permanent and temporary, of landmarks, surface features, etc. At finer scales, spatial mapping maintains an internal map of the location of all articulated elements of the TUG/Turret/Excavator ensemble. These are representations of the many servo elements that are described in Section 10.0, Polar Coordinate Frame Defined.

sysRAND Corporation

97


GEOGRAPHIC INFORMATION SYSTEM (GIS)

The system maintains an internal model of its operating, ambient environment. This model is essentially a mobile Geographic Information System (GIS) that is a synthesis of cartographic information acquired by Lunar orbiters, surface surveys, and platform history. The latter provides the finely-granular data with the highest resolution available, since the platform is in the local environment. The mobility platform acquires data that includes topology, mineralogy, subsurface features, traction, texture, and more. The GIS maintains the topological and cartological data sets, and references the rest from the previously cited surface data repository.

sysRAND Corporation

98


RECURSIVE PROCESS CELL

Since the system uses the same coordinate frame system from coarse to fine resolution, and the very same software for all levels of operation, there is rational commonality in operation at all scales. The recursive structure conserves power by sequencing demand, reducing current peaks (ergo, I2R losses), simplifies control by ordering motion, permitting stepwise bounds and limit checking, tests all available sensors at the prevailing clock rate, while non-existent elements are skipped. The maneuvering of the robotic mobility platform (TUG) on the ground or the robotic tool in its work volume requires discrete steps to achieve its directed objectives. As suggested in Figure 87, these process steps include Objective Testing, Trajectory Planning, Limit Testing, Interference Testing, and Motion Control. Each of these processes is a Fuzzy Logic process that is recursively repeated at many levels of scale.

Figure 87 A Recursive Process Cell supports Maneuvering Each recursion tests as to whether the servo is already in the specified setpoint position (entry), or whether it has reached the setpoint position with the current move (exit). This front-and-back test is instantiated once in the code and is used, therefore, as the entry and exit point for the current servo context. This structure offers several interesting, and likely useful, behaviors.  On entry, if a servo is already at the setpoint position, then the current context is skipped.  On entry, when a servo setpoint is greater than its reach from its current position, the layer is inhibited until coarser levels close the gap. This causes the current recursive traversal to collapse to the coarsest position, and start a new traversal, a maneuver that should close the gap at the appropriate level.  The Fuzzy Logic Servo will close the gap from the current position to the setpoint at various rates of acceleration, deceleration, and cruise.  The current Motion Control servo context will test the state of its device.  With motion-in-progress, the Objective Test routine enables exit of the current servo context and invocation of the next finer level, enabling concurrency. Any given servo context can connect to the next level by ceding control to it with the appropriate arguments in the Reentrancy Tables. The recursion instance can also communicate to the next higher level on its next iteration, through the Reentrancy Tables. Each level of control, from Coarse servo contexts to Fine servo contexts, serves to deliver the endpoint tool effector to the workface. Therefore, the system is heterarchical, because there is nothing to be gained in the system by stressing one layer over another, as in a hierarchy. Recursive mechanisms send semaphores that enable and disable operations on adjacent levels. The structure of the Recursive Process Cell simplifies control by ordering motion, permitting stepwise bounds and limit checking. The RPC also conserves power by sequencing demand, reducing current

sysRAND Corporation

99

Autonomy as an Operational Element of Planetary Surface Systems peaks (ergo, I2R losses). Non-existent elements are tested for the sudden addition of new hardware, and are otherwise skipped. Situations requiring autonomously-derived decisions may be accomplished with a bit of trial-and-error, as well as recursive approximation. 9.10.1 Objective Testing After the platform or a robotic limb has been moved it is good practice to test whether the device has arrived at the commanded position, suggesting that such a test process be the last of the motion thread. However, before moving anything, or even computing such a move, it would seem prudent to test the current position of the platform or the robotic limb, to determine how much motion is required, if any. Therefore, pre-testing of the objective should occur before any motion commences, and the objective testing is the first and last process in each recursion of the loop through the device limbs, although posttesting would seem to be redundant, since the next iteration is only 25msec away. 9.10.2 Trajectory Planning Trajectories are planned by various methods. When the precise location of the objective is known, an optimized path to the objective is computed, that minimizes the number of servos to be driven, and attempts to keep any given articulation at a reasonable distance from physical limits of the current servo (to provide freedom of action for the next manueuver). When the objective’s location is imprecisely known, the available location is used as setpoints, and the whiskers, or other inputs are used to direct the servo to the objective. Post-processing of Trajectory Planning will later be upgraded to optimize the trajectory process, e.g., using Aggressive Goal Seeking Methodology to avoid work volume singularities, which arise from DOF loss, which are constraints imposed by self-conflicts from various combinations. Another objective of Trajectory Planning is to select the path that represents a minimal expenditure of energy, and this includes damping out “servo hunting.” 9.10.3 Limit Testing Limit testing ascertains whether the loads, accelerations, and motions are within the operating envelope of the limb or the platform. Two mutually-exclusive choices are provided as global variables (mission directives) to the mission planner in the event that such a maneuver is found to be excessive. The default is that the trajectory planner is directed to recompute a solution and “try again.” The option is that the Limit Tester “clamps” or “limits” the directives to Motion Control by scaling back the rate of acceleration or the scope of the motion. Limit Testing also determines whether the directed motion is within the reach of the tool or platform element currently in the computing context. When the objective is out-of-reach, the loop is closed and the recursion collapsed so that coarser levels of articulation can close the gap to a more advantageous position. 9.10.4 Interference Testing It remains quite plausible and possible that a valid motion, such as an excavator’s blade, could result in an undesirable result. Interference Testing anticipates collision of moving robotic limbs with the TUG’s deck, hardpoint fixtures, terrain, or other moving objects. As in Limit Testing, above, the Interference Testing process has a default method and at least one optional enhanced approach to resolution of the interference.

sysRAND Corporation

100

Autonomy as an Operational Element of Planetary Surface Systems 9.10.5 Motion Control Consistent with the platform’s autonomous control system, Motion Control is a fuzzy logic servo. Unlike the other elements of fuzzy logic control, individual hardware controllers are imbedded controls that employ fuzzy logic software that is rule base and knowledge base compatible with the rest of the system. This does not imply that the servo controllers have compatible fuzzy logic software. This layer, in particular, should monitor the power bus to assure proper servo operations, consistent with Section 9.12, RT System Timebase.

sysRAND Corporation

101


INVERT & TRANSLATE FUNCTION

On those occasions when the Limit or Interference routines identify an obstruction, the Invert and Translate Function attempts to clear the obstacle by inverting or complementing angles. Figure 88 shows a starting point, while Figure 89 and Figure 90 each offer an exchange of slopes and angles between sections of the robotic arm, resulting in an indentical endpoint solution. This is only one strategy of many.

Figure 88 Initial Position

Figure 89 Transform, Complementing Pitch Angles

sysRAND Corporation

102


Figure 90 Transform, Exchanging Yaw Angles while Splitting Pitch Angles 9.12

RT SYSTEM TIMEBASE

The RealTime Operating System (RTOS) is intended to provide a guaranteed delivery of computing services, with a low-latency response time and a minimum of RTOS overhead. The basic service cycle occurs at a rate of forty times per second, or 25 msec intervals, and the autonomy system conducts the recursive cell process traversal at this inner rate. A 200msec outer loop contains eight 25msec inner loops, resulting in a five times per second repetition rate of the outer loop. On each occurrence of the inner loop the recursive process cells are conditionally executed. Not all process contexts will be executed on any given iteration. To be certain that module interfaces are tested for presence or absence of hardware, it is essential that process cells are executed at least a couple times per second to test sensors and signal continuity. It isn’t necessary to test hardware beyond the modules that aren’t in place, so that execution traversals are quickly truncated by their absence. This schema results in an average of five checks of a system’s extent and extremities per second, which should be sufficient to detect, in realtime, the insertion and ejection of hardware. This should also be adequate for awareness of any sudden, perhaps accidental, disconnect of a hardware “string” from the mobility platform, turret, robotic arm, or other base system. The realtime system timebase is the rate at which the cell process traversal occurs, a heartbeat rate of forty times per second, or 25msec intervals. The system service cycle of 40Hz determines that a 400Hz, 3-phase power bus will have a control and sampling resolution of 10 power cycles between each service cycle invocation. It may be rational to test for the presence of power, and perhaps a count of any cycle dropouts since the last service cycle invocation, since the servo motors depend upon power, and any sensed deficiency in the servo controls should not be over-correcting the servo because of power losses.

sysRAND Corporation

103


Figure 91 System Block Diagram

sysRAND Corporation

104


Figure 92 Function Module Partitioning and Corresponding DOFs

sysRAND Corporation

105


Figure 93 A Maximal, but not Practical, Scanning Flow Featuring Three Excavators

sysRAND Corporation

106


Figure 94 A Practical Ensemble of a TUG, Excavator, Hopper and Tandem TUG

sysRAND Corporation

107


Polar Coordinate Frame Defined

sysRAND Corporation

108


POLAR COORDINATE FRAME DEFINED

The measuring system used to construct artifacts of any type very much influences the character of the artifact itself. The excavator is a modular tool within a projected class of modular tools that will be deployed on both remotely tele-operated platforms and autonomous platforms. In our rudimentary survey of tool types that lend themselves to modular deployment, it was determined that a spherical (polar) work volume generally suited most devices heretofore conceived. The architectures devised by sysRAND have a strong tendency to be scalable and recursive. Since the navigation and maneuvering of the platform (TUG) will likely employ bearings and distances it is expected that both on-site crew16 and remote operators17 will be more familiar and comfortable with polar coordinates than the cubic Cartesian system.

Figure 95 Polar Coordinates with Corresponding Cartesian Coordinates Vehicles make use of Roll, Pitch, and Yaw (RPY) as a coordinate frame that has practical application and centuries of heritage. For example, the Yaw-Axis is the Bearing pivot for navigational purposes. The diagram in Figure 97 depicts the RPY axes and the angular symbology that corresponds to each axis. Figure 97 was derived from the Polar Coordinate Frame shown in Figure 95, above.

16 17

Who tend to be test pilots. Who will probably tend to be experienced UAV pilots.

sysRAND Corporation

109


SELECTION OF A COORDINATE FRAME OF REFERENCE

The volumes depicted in Figure 96 show the two principal classes of Coordinate Reference Frames, the rectangular (Cartesian) and spherical (Polar) systems. Other hybrid systems derive from these two canonical types, and cylindrical can be seen to use Polar in the horizontal plane and Cartesian in the vertical axis. Aviators are familiar with some elements of a cylindrical coordinate system used by Distance Measuring Equipment (DME); for example, an application characterized by Altitude, Bearing, and Slant Range. Polar coordinates are also widely known as Spherical coordinates and have, on occasion, been used by industrial robotic systems18. Industrial systems have not made wide use of Polar coordinates; this is most likely attributable to industrial shops’ already extensive use of Cartesian space for Computerized Numerical Control (CNC) and other machining systems.

Figure 96 Work Volume Described by Various Coordinate Reference Systems Each volume will require at least three effectors to maintain six degrees of freedom. One intent of our modular tool approach is to offer multiple and sometimes redundant DOF, where the TUG, the turret, and the modular tool each provide at least two or more degrees of freedom. Since the integrated TUG/Turret/Tool control is already complex, and the TUG will be navigating in a spherical or modified cylindrical space, it seems rational to extend the same model to the tool. The motions of the TUG in the navigation space and the motions of the turret and excavator are precisely described by the spherical coordinate reference system. This approach eliminates constant conversion and only has to recalibrate for scale. A modified cylindrical reference frame would seem to be the second choice, but it is not as congruent as the spherical. Unlike a CNC robot, the excavator does not require precision and tight repeatability of 0.0001” since 1” is probably serviceable with the precision and accuracy of MEMS-based Angular Rate Sensors (solid-state accelerometers). The reference system can influence the computing load of positional computation, and computational complexity is often a function of the fidelity of the abstract programming model to the physical actuality. The Spherical Coordinate System has three axes, x, y, and z, and translate a ray from the origin to a combination of angles among these axes, plus a linear range (reach). The Polar or Spherical Coordinate System has the following parameters: Bearing (Yaw) θ Range (Reach) ρ Slant (Pitch) β Roll φ

18

For example, the venerable Unimate 2000B.

sysRAND Corporation

110

Autonomy as an Operational Element of Planetary Surface Systems One of these terms can be considered to be redundant. All four terms are concurrently computed and the built-in redundancy is used as one test of validity and accuracy. Each of the platform’s servoes has a corresponding scale of application that each have an operating envelope, or work volume: Planetary Surface Mounting Hardpoint Turret Tool Mounting 10.2

Stage One: kilometers -- decimeters Stages Two: decimeters -- centimeters Stages Three: decimeters – centimeters

FITTING POLAR COORDINATE FRAME TO THE VEHICLE

When viewing the modular excavator as a device operating concurrently at three scales, it is consistent to fuse the spherical tendencies of the platform with the spherical proclivities of the tool’s workspace and declare the entire ensemble to operate within a uniform coordinate system. The scales differ only by the span of their measurement units and the distance to “landmarks” and “features” with which they interface. The vocabulary (jargon) of the platform navigation can be made consistent with that of the mining and civil engineering community. Roll-Pitch-Yaw (RPW) is thus consistent whether applied to bearing, range, distance, slant range, etc., or to the cut (depth), kerf (width), track, etc., of a dig. Our research into the topic has further found that the datum points and datum lines used to define a vehicle design vary by institution; the only consistency is that implementations are wildly inconsistent. For the surface platform that we are devising it is entirely consistent to employ a coordinate basis that manifests in some aviation and most nautical platforms. An overarching view is that X and Y tend to be finite while Z is expected to be subject to constant change, since in aircraft, ships, and wheeled vehicles it delineates the path of travel. Ergo, the axes of the polar system adapted to our use are: Yaw: X-Axis, angle φ Pitch: Y-Axis, angle β Roll: Z-Axis, angle θ Figure 97 shows the adaptation of the spherical coordinate system to the TUG/Turret/Tool platform, which is the modular excavator.

sysRAND Corporation

111


Figure 97 The TUG Principal Coordinate Frame (Origin O )

sysRAND Corporation

112

Autonomy as an Operational Element of Planetary Surface Systems Each coordinate frame is described by a 4-tuple, or quartet, (ρ, φ, β , θ )19, in a system first presented in Figure 95, above. Although these parameters roughly correspond to those of the Cartesian system, they are not the same, or interchangeable in any sense. The notations used for polar coordinates differ among authors only a little less than do those of datum lines, so that Figure 95 is a synthesis of several references that sysRAND intends in order to repeat the common usages and resolve the anomalous usages. Each of the coordinate frames is characterized as follows: • The robotic platform will have a coordinate system, describing its Universe (U) in terms of distance, ρ, and angles φ, β, and θ. Distances are measured in kilometers down to decimeters. The origin is the deck center hardpoint. • The Turret/Robot Arm will likewise use the same coordinate system and measure distances in terms of meters down to millimeters. The origin is the hardpoint into which the device is engaged, fore, center, or aft. • The Excavator or Tool will employ the identical coordinate system, measuring distances from meters down to millimeters. The origin is the tip of the Turret or Robotic Arm “wrist.” • The quartet is recognized as having a redundant term. Our intention is to use this redundant term to cross-check the other terms. This has the effect of a validity check plus an indicator of which term may be incorrect.

Figure 98 Three Powered Hardpoints are Located at Quartered Intervals on the Deck 19

Rho, phi, beta, and theta.

sysRAND Corporation

113


This exercise is another example of top-down/bottom-up methodology put to practical use. Once the choice from among the many possible coordinate systems is made, it remains to acquire and create the components necessary to implement the system (bottom-up). As the synthesis of an implementation illuminates the universe of possibilities, the application domain begins to crystallize (top-down) as the needs of the application grope toward the implementation vehicle (i.e., learning of capabilities and constraints). The math modeling components are detailed. The tracking of the current device state of location and orientation is a necessary next step. The projection of trajectories, checking of limits, conflicts, and clearances is a next essential turn. The progression of scale from the platform deck to the excavator tip reveals in turn the progression of model development. It also highlights the modular nature of the physical devices, the coordinate frame, and the system model. The mapping of the model to each physical module is an example of the progression of model from the coarse to the fine spatial reference. As each module is inserted into the “chain,” a corresponding software definition is plugged into the computational module, completing the end-to-end definition. 10.3

CONVERT CARTESIAN COORDINATES TO POLAR

To convert from Cartesian coordinates, (x, y, z), to Polar, ( performed: __________ ρ = √ x2 + y2 + z2 __________ β = cos-1 (z / √ x2 + y2 + z2 )

ρ, β, θ ), the following equations are

θ = tan-1 (y / x) 10.4

CONVERT POLAR COORDINATES TO CARTESIAN

To convert from Polar, ( are performed:

ρ, β, θ ), to Cartesian coordinates, (x, y, z), the following trigonometric functions

x = ρ sin β cos θ y = ρ sin β sin θ z = ρ cos β 10.5

VECTOR AND PLANE NOTATION

10.5.1

Position Vector

10.5.2

Orientation Vector

10.6

10.6.1

TRANSFORMATIONS ON VECTORS AND PLANES

Translation

sysRAND Corporation

114


Equation 1 Translation Matrix for Z-Axis

10.6.2

Rotation

Equation 2 The Yaw or X-Axis Rotation is Described by the φ Angle

Equation 3 The Pitch or Y-Axis Rotation is Described by the β Angle

Equation 4 The Roll, or Z-Axis Rotation, is Described by the θ Angle

10.7

INVERSE TRANSFORMATIONS

10.8

ROTATION ABOUT A VECTOR

sysRAND Corporation

115


CONSTRUCTING EQUIVALENT COMBINED TRANSFORMS

A vector that describes a current or computed position of a robotic link is described as two arcs of rotation and a translation along the Z-axis20. Pol(ρ, θ, β) = Rot(Z,

θ) Rot(Y, β) Trans(0, 0, ρ)

Equation 5 A Translation Nested within an Angular Displacement

Equation 6 A Translation Nested within Two Angular Displacements

20

Adapted through notational changes from Robot Manipulators: Mathematics, Programming and Control, Richard P. Paul, MIT Press, 1981.

sysRAND Corporation

116


REPRESENTATIVE COMBINED TRANSFORMS

Some of the useful transforms in characterizing coordinate frames for each section of the platform and tool robotics have been found or derived and are provided here as design documentation. These examples are variations of a single construction that begins with a linear translation followed by two angular displacements, corresponding to an extension along an axis along with a trajectory that combines motion in two axes.

Equation 7 Six Combinations of a Translation Followed by a Two-Axis Trajectory

sysRAND Corporation

117


10.10.1

Scaling Transforms

Equation 8 Scaling Matrix for all Axes

10.10.2

Perspective Transforms

10.10.3

Position and Orientation

sysRAND Corporation

118


PARTITIONING THE MODEL TO MODULE BOUNDARIES

The excavator consists of three principal elements: the Excavator, a Turret (Robotic Arm with leverage), and a notional robotic platform (due to the continuing uncertainties of available platforms). Each of these elements arrives with its unique extensions to the coordinate frame. The model supports both single and compound operations across the many degrees-of-freedom (DOFs). When mounted on the forward powered hardpoint21, the Turret rotates about a vertical X-axis, which is displaced by two feet from the platform Origin or Datum Point. The hardpoint features a high-torque motor -- so that a turret or robotic arm need not do so -- while also providing a universal coupler, electronic signals, and power connections. All three deck-mounted hardpoints are identical and interchangeable but for position. The hardpoint defines the origin for a new Coordinate Frame for each position.

Figure 99 Turret (Hardpoint) Rotational Axis The image in Figure 99 shows the typical mounting point for a turret that is designed to deploy an excavator blade. Since the forward hardpoint is halfway between the center hardpoint and the vehicle front, the difference between the platform datum point (principal Coordinate Frame) and the reference Xaxis is at Z plus 2 feet. Recalling that the platform is agnostic about which end is fore or aft, sometimes this reference could be assigned to be Z minus 2 feet. The three hardpoints are depicted in Figure 98.

21

A hardpoint is any part of an airframe designed to carry an external load. sysRAND Corporation

119

Autonomy as an Operational Element of Planetary Surface Systems Trajectory Planning for the Excavator begins with the Turret, while Trajectory Planning for the Turret begins at the hardpoint on the deck. Yaw is synonymous with rotation around the X-axis; since there is no extension or “reach” along this axis this motion component is simply described by the XROT matrix in the following (reiterated) equation:

Equation 9 Yaw Rotation of Turret Driven by TUG As depicted in Figure 100, the displacement of the shoulder-mounted pivot from the Yaw (X) rotational axis is fixed and is used to enhance the leverage available to the tool and to conserve power. The arm extends from the X-axis deck pivot to the shoulder-mounted pitch pivot at the upper rear of the turret. This segment is described by Equation 12. The values are β , which is fixed at a notional 45° and ρ, which is fixed at a notional 2 feet.

Figure 100 Fixed Pivot Displacement from the rotary Hardpoint

sysRAND Corporation

120


Equation 10 The Fixed Arm of the Turret Assembly The description of the Turret at this point is the multiplicative concatenation of YROT(YTRANS) x XROT. This portion of the model locates the shoulder mount as the basis of the Turret Arm Pitch axis.

Equation 11 Lower Turret Fixed and Yaw Rotation Model

sysRAND Corporation

121


Figure 101 Turret Pitch Pivot and Arm Reach The next stage of the Turret model describes the extendable arm, which is intended to allow the excavator to reach further into a pit or trench or to clear the vehicle. In Figure 101 the Turret’s Pitch Pivot can be seen to have a constrained angular space, operating within a vertical plane that extends through the X-axis and is swept by the Y-axis. The matrix that describes the arm is found as Equation 13. To avoid an overload of symbols, the fixed components reflected in the description of Equation 11 are replaced with constants and are restated in Equation 12. This frees up the notation for use as variables in the remainder of the Turret definition.

Equation 12 The Lower Turret Restated with Constants

sysRAND Corporation

122


Equation 13 The Matrix Description of the Upper Turret (Arm)

10.12

CONSTRUCTING THE END-TO-END MODEL

The Turret description to this point is the concatenation of Equation 12 and Equation 13, which yields the matrix detailed in Equation 14. At this point the Turret Description is complete, although the addition of an optional, rotating wrist would add an additional z-axis (θ ) descriptor to the model. This model also does not include a representative tool, such as the excavator. The excavator has an additional pitch servo that can sometimes be considered redundant, and other times not.

Equation 14 Combined Description of the Upper and Lower Turret The length of the Turret Arm is variable within the notional limits indicated in Figure 101 and will require inclusion of additional fixed segments, which would quickly add to the complexity of this device. An alternative method is pictured in Figure 102, suggesting that the hypotenuse anchored at the pivot might be sufficiently accurate and repeatable for our purposes.

sysRAND Corporation

123


Figure 102 The Variable Length of the Arm May be Simplified as the Hypotenuse The farthest extent of the Turret’s Y-axis reach defines the work volume for the basic turret and TUG ensemble. This endpoint is also called the “tip” of the Turret, or Robotic Effector. The next device is the excavator blade, a boundary that also introduces the next Coordinate Frame, which generalizes as the tool frame.

Figure 103 Pitch Pivot on Excavator Port with both Fore (ρf) and Aft (ρa) Extent

sysRAND Corporation

124


Control System Development Methodology

sysRAND Corporation

125


11.0

CONTROL SYSTEM DEVELOPMENT METHODOLOGY

The autonomous TUG navigates from any arbitrary location to any other location within range through a succession of recursive steps. Each of these steps closes the distance between its current location and its destination, one service loop at a time. The amount of ground covered during any particular service loop is dependent upon the velocity and acceleration of the immediately preceding service loop and those prior. The current service loop can increase, decrease or maintain the instantaneous rate of acceleration and thereby begin to alter the TUG velocity, or simply maintain it. In platform navigation there will likely be several “gears,” or overlapping ranges of torque. The range of functions span from a crawl at a scale of a centimeter or two per second to maintain pressure on the workface, to a galloping 10 Kilometers per hour (6 MPH). When the autonomous TUG is deploying tools, it once again does so through a succession of recursive service cycles. Each of these cycles may span several elements in scale (from large to tiny) of the TUGTurret-Tool-Accessory chain, in any given iteration of the recursive loop. Each servo device moves to a point that is approximately the center of the next smaller scale servo’s range of motion, so that the next level of precision does not find itself out of reach of its objective position. The autonomous TUG is persistently seeking to close the distance between its location and that point in space where the modular tool is to perform work. For example, when an excavator is mounted on TUG’s Turret and the TUG has been issued an Electronic Work Order, then the resulting integrated system becomes a specialized unit, focused on travelling to the worksite and applying the excavator to the workface. Most of this work, and a large fraction of autonomous operation, is accomplished by the recursive process cell. The platform’s sensing, planning, or exception handling is woven into the recursive process cell. Often regarded as obsolete and inappropriate in the contemporary computing universe, the top-down / bottom-up approach actually has many positive attributes that speak in its favor. Our system development experience has afforded us the opportunity to test drive many tools and methodologies since the early 1970s. The top-down / bottom-up (TD/BU) approach differentiates, or bifurcates, development by constructing complexity towards the macro from the micro, simultaneously from the macro to the micro. A developer, analyst, or architect who chooses to implement a purely top-down, or a purely bottom-up method, should realize that each has its own risks. A purely bottom-up development effort hazards missing the application, thus building an implementation vehicle (of any level of quality) that completely misses the customer’s or end-user’s requirements. Nature uses this approach, suffering mutations that alter a species from the bottom-up, one individual at a time. Since nature conducts these evolutionary processes over countless eons, there is every opportunity for what appears to be trial-and-error, from our lofty abstraction layer. There have been innumerable examples of systems (or products) that were impeccable technological feats that failed to address market objectives. At the opposite extreme, a purely top-down development effort risks missing existing implementation vehicles, with the result of re-inventing unique and insular implementations. An example would be a capable signal processing system that requires specialized FPGA development in concert with laborious programming tool development, when the same algorithms could have been written in c++ on a PowerPC platform, all COTS-provisioned tools. This autonomy project has benefited from the use of top-down / bottom-up as a methodology. There are numerous examples of developing application-specific structural components, all while reducing seemingly monolithic applications into myriad processes. One tendril at a time, those processes fuse into the newly-defined components to derive the solution. 11.1

COMMON FUNCTIONS

The elegance of modular, intelligent tools is that a very large fraction of the tool ensemble is common. In this model the single, largest common element is the TUG, followed by a robotic arm or a turret. This fraction is shared with many other tools on a scheduled basis. The TUG also represents the fraction that

sysRAND Corporation

126

Autonomy as an Operational Element of Planetary Surface Systems is the easiest and first to become autonomous and, ultimately, collaborative – where cross-country and worksite navigation are examples. Common functions also include shared functions, and these would include lighting, instrumentation, etc., in addition to the mobility, physical mounting, power, and intelligence afforded by the TUG and Turret. 11.2

SPECIALIZATION OF FUNCTION

The key to the industrial revolution was the leap in efficiency that resulted from workforce specialization, a breakthrough that was enabled by a succession of common componentry that later became interchangeable componentry. Today, many of the menial specialized tasks have been assumed by automatic equipment, including robotics. The factory has progressed from a swarm of humans performing specialized tasks to a swarm of humans with specialized training, servicing the machines that perform specialized tasks. Swarm or hive architectures preclude specialization, by definition. If all operators have no specialization, then a swarm, operating with inefficient tools or tools of a single, generalized type, will be inefficient (e.g., insect mandibles). There will be task functions that cannot be performed by a single tool type. Here we recall an old platitude: “to a man with a hammer, everything looks like a nail.” A heterogeneous mix of platforms may be similar, or not, and may have specialized tools of one of more types, and is capable of a number of support operations simultaneously executing in a coordinated fashion. The modularity of the TUG, Turret and Excavator delivers a hybrid system that can be considered swarm from the wheels, and up to a point where modules diverge among members of a group of TUGs. This semantic quibble does not detract from the fact that modular platforms can continue to be very collaborative, even after differences occur. This point is probably the raison d’être for this entire capture document. In the modular model, commonality constitutes a large fraction of the platform and specialized modules can exhibit very divergent behavior from most other modules. Over time, we may realize that specialized ensembles are each divergent from the rest and that there is no normative behavior beyond mobility. For example, an excavator cuts a trench, a grappling manipulator removes rocks, star hammers pulverize larger rocks for removal by grapplers, other platforms unroll and place cable, and plow the tailings back into the trench. 11.3

ROLE OF STATES AND METASTATES

Finite State Machines (FSMs) are powerful tools for the construction of control code that is very deterministic, and can embody a robust fault-tolerance in said systems. However, FSMs are rigid, and quite inflexible, which creates problems for FSM-modelled software that is confronted with an environment or internal state that remains unmapped, that is, outside of its universe of discourse. A FSM, as an abstraction device, attempts to map a continuous domain into a discrete domain, for execution on a computer that is, itself, a discrete critter. For that reason, states are not used for servo loops here because the arcs of turret arms, and excavators are treated as continuous, and not scalar discretes in our model. Sometimes, the structure of states block access to event data, creating a situation where an FSM can be indefinitely locked-in to a state. There are at least three reasons for this, 1) a state’s exit condition does not occur, 2) the event that is driving the FSM is not tested in the current state, or 3) the event is tested in a state that is not likely to be in context anytime soon. Since FSMs are discrete, there is a tendency to define state elements as “events,” which are a way to discretize time in its relationship to state. This is usually an appropriate step, but again, only if the domain is strictly deterministic, and bounded. Sometimes, a device may ease into a state unobserved, and find itself in an even stranger place, because the conditions for the proper state transition were too fuzzy, or

sysRAND Corporation

127

Autonomy as an Operational Element of Planetary Surface Systems incompletely qualified, for the FSM to track to the situational reality in which the platform finds itself. Excepting the general case of the digital computer, most FSMs do not support interrupts, a role that we would fill with the notifier construct. FSMs have value to construction of a complex control system, and in the case of this autonomy project will be implemented as a “soft,” or “fuzzified” methodology. Instead of a deterministic Finite State Machine where states are modes, the FSM concept will be modify modes to become “moods” that maintain focus on a task and its subelements, providing global enablers and inhibitors to subsidiary processes. States are mapped to operational contexts, to avoid situations where excavators randomly dig up the outpost, like a dog burying his bones. There are a number of features, extensions and constraints to FSMs that will be tested for applicability to the autonomy project. One of these features will be realized by allowing an FSM to have multiple states active concurrently, a concept that may have resonance with the way complex systems actually work. Multiply active states may allow the resolution of the total system state (gestalt) in a way that yields inputs to learning processes. Coupled FSMs exist, and may be precursors to concurrent FSM structures. Another feature would introduce “metastates,” which are superstates that describe in a global manner the top-level objective or class of behaviors that should prevail for a time. Metastates may succinctly describe that a unit is in a powered-down “safe” mode, or that it is awaiting repair and cannot move, or that it should be acquiring tons of regolith for processing. Yet another change in FSM methodology would be the development of “notifiers,” where events and conditions are packaged in a way that can successfully drive FSMs so that events and nearby states have visibility, and aren’t ignored. Command interpreters and mission planners are sometimes FSM-based, deliberately by design22, or ad hoc. Other changes in FSM methodology are the awareness that rules bases can emerge to resemble state machines, and that FSMs may be brought into the pervue of Fuzzy Logic Inference machines, knowledge and rules bases. Perhaps for consistency, if for no other reason, although this would allow FSMs to be learning, as well. In this autonomy implementation FSMs are consulted by the many constituent Fuzzy Logic Controllers (FLCs) and Fuzzy Logic Inference Engines (FLIEs), but state machines do not rigidly drive the system.

22

e.g.: Plexil and the Universal Executive.

sysRAND Corporation

128


Figure 104 Excavator Operations will Traverse the Statespace

sysRAND Corporation

129


DEVICE LIFECYCLE METASTATES

Metastates provide a constraining envelope which is context-driven. They represent global, long-term autonomous platform states. Provision should be made for a structure upon which a new tier of states, or metastates, can be constructed by learning systems as new rules emerge.

Figure 105 Platform Operations Lifecycle FSM Metastates address the larger picture of a platform’s operations, and represent a layer of abstraction above the routine activities of navigating, mining and civil engineering. Metastates further represent primary qualifiers that enable, inhibit, or ignore the routine states within the FSM itself. This is distinctive from routine states that enable, inhibit or ignore signals, actions, or state transitions. 11.4.1 INERT Device rendered harmless for storage or cartage Mechanical Locks and Shipping Restraints In-place No gas or liquids under pressure Pilot Power System OFF Main Power System OFF 11.4.2 SAFE MODE Device Inactive and Ready for Flight or Deployment Mechanical Locks and Shipping Restraints Removed Gas or liquids under pressure Pilot Power System Enabled for Separation Switch ON Main Power System OFF 11.4.3 POWER_UP Device Activation Authorized Pilot Power System ON Main Power System ON Internal System Bootstrap Internal Network Negotiations Internal Systems Checkout System on Stand-by 11.4.4 NORMAL_OPERATIONS Device Operation Authorized Pilot Power System ON Main Power System ON Systems Operational Device Free to Bid for Tasks Device Free to Perform Tasks

sysRAND Corporation

130

Autonomy as an Operational Element of Planetary Surface Systems 11.4.5 POWER_DOWN Device Deactivation Authorized Internal Systems Checkout Mission Logs Closed Main Power System OFF Pilot Power System ON 11.4.6 DECOMMISSION Device Rendered Inert Main Power System OFF Pilot Power System OFF Control is relinquished RELEASED thru SALE ABANDONED in-situ SALVAGED or cannibalized

sysRAND Corporation

131


MANAGING THE SCOPE AND COHERENCY OF DATA

The intelligence of the platform control system is distributed across many levels of context, a feature that could cause issues of data coherency across the platform. This is generally managed by parking global variables in the repository, where data frequently accessed migrates to a repository’s cache memory. 11.5.1 Stateless Network Fabric Maintaining instantaneous coherency of data over a distributed network remains difficult to deliver or enforce, while delivering relatively static data as a global variable is costly and continues to suffer from issues of propagation delays, setup and hold times, and metastability risks. For example, a single pulseper-second signal distributed to all computational nodes of a network adds 2 pins to each of 2 conductors to n nodes, or a 4n increment to cable and circuit complexity. 11.6

MAINTAINING PLATFORM INTEGRITY

Maintaining platform integrity is accomplished, in the main, in a distributed manner at various points in the system. Maintaining integrity largely depends upon interpretation of data provided by (external) situational awareness and (internal) state awareness. While this function is not a discrete program it is expressed in the Recursive Process Cell’s Trajectory, Limit Testing and Interference Testing routines. The rapid rate at which the Recursive Process Cell visits these routines at all scales, is intended to test as many boundaries and states as possible, on a near-continuous basis. Another function of platform integrity is to check incoming command stream or an EWO for validity and safety, prior to execution. 11.7

SAFETY AS A SYSTEM DRIVER

Safety is realized through proactive, deliberate design that is often realized by software methodologies. Limit Testing and Interference Testing processes are two examples, of many, that are running continuously (or nearly so, at forty times per second) to check that the system remains within a safe operational envelope by all servomechanisms. Another example is a proposed feature of servo electronics, where each servo controller would include a WatchDog Timer (WDT) that expects to be “touched” within a pre-determined number of system heartbeats. Failing to receive a predetermined number of these consecutively, the servo would shutdown. 11.8

CONTINUOUS FAULT DETECTION

The MetaCode capture and reporting system provides a “backbone” methodology for standardized identification and assertion of faults, errors, states, events, milestones, etc. A strong benefit of this subsystem is that it, 1) encourages rigor in software development, and 2) it provides a framework of standard codes and methods for implementing provisional codes pending registration. The platform is the final agency responsible for detecting faults or faulty codes. Meta-assemblers were devised for supporting a wide variety of code-target platforms, especially arcane and very large instruction word (VLIW) machines, e.g., nanocode and microinstruction implementations. A powerful feature that was often unavailable in meta-assemblers was user-defined error-checking. This was often arrived at by testing variable states and data validity, such as strings containing data restricted to the ranges “0”..“9,” “A”..“F,” and ”:” such as are found in Intel Hex Record Format (IHRF). Software that is fault-tolerant and reliable is prerequisite to implementing systems that are persistent and are not going to roll over and die at the slightest fault, e.g., a parity error, or propagate its fault condition elsewhere.

sysRAND Corporation

132


Technologies Enabling Autonomy

sysRAND Corporation

133


TECHNOLOGIES ENABLING AUTONOMY

Autonomy is one of those concepts that has nuanced meaning representing different things to different people. Rather than splitting meanings, and analyzing the corpus of autonomy just now, we instead cast our view that provides the bench upon which we can construct our models. We are pursuing a plan-of-attack that has three principal elements. Recall that the compelling justification for developing autonomy in the first place is to reduce the bandwidths required between Earth and the Moon or Mars, along with the latencies induced in the transit time for signals traversing space bidirectionally. With these objectives firmly in mind, we enumerate autonomy as features where: 1. the platform performs a large fraction of the intended functions without intervention, 2. as exceptions occur, the platform manages them, allowing it to return to mode 1, and 3. some exceptions are not managed by the platform, requiring external intervention. To accomplish tenet number one, the amount of a platform’s intrinsic autonomy is determined by design function. Satellites have substantial intrinsic autonomy by virtue of the fact that they are in an orbit that tends to be quite deterministic, where the next second of orbital flight is strongly influenced by the satellite’s current orbital state (vector). To obtain the next large fraction of the intended function, it is essential that the satellite is able to maintain power generation, attitude, course, radio links, and payload functions on its own for long durations. The eighty-twenty design rule-of-thumb would suggest that at least eighty per cent of the spacecraft operation only requires twenty per cent of the control system’s attention, while twenty per cent of the taskload requires eighty per cent of the available computational attention. The remaining two tenets will, therefore, split the eighty per cent of the remaining control system attention, so that 16 per cent of level 2 exceptions will consume 16 per cent of the control system’s attention, and the remaining 4 per cent that are level 3 exceptions are expected to consume 64 per cent of the attention budget. Another variant on this rule-of-thumb is the ninety-ten rule, where only the numbers are changed. The numbers are skewed, and both the 80/20, and the 90/10 rules seemed to be distorted, at least intuitively. We are convinced that a higher fidelity distribution among the three tenet classes would be partitioned as follows, intrinsic autonomy would account for 1/phi of the total taskload, at the cost of 1/phi2 (or 1-1/phi). When these ratios are applied recursively we obtain the fractions for tenet 2, and again for tenet 3, except that tenet 3 attention is allowed to consume all of the remaining computing bandwidth.

Figure 106 Our Notional Load Model is Phi-Ratio-based Surface platforms diverge from the orbiting satellite model because their default state is static, fixed in place until energy is directed to move the platform. This implies that an efficient control model will have to be aggressive, if the platform is to be productive.

sysRAND Corporation

134

Autonomy as an Operational Element of Planetary Surface Systems Since the intrinsic autonomy of Tenet One is the largest fraction by any of the rules-of-thumb, it is implicit that the baseline power, control, and payload subsystems are reliable, and have a high availability (uptime). There are a number of technologies now available that enable or enhance autonomy in robotic platforms. For example, the more robust the platform’s power supply, the less time spent recharging, repairing or scheduling around high-power events. Solar panels are impractical as a power source for an ISRU TUG because they fail to support operations round-the-clock, dust is a persistent problem, the large extent of panels required would expose them to operational hazards endemic to earth-moving equipment, and time spent charging batteries would hugely interfere with performing excavation. For these reasons, a concurrent development at sysRAND is an RTG that does not emit neutrons and translates the Gamma Ray into useful thermal energy, probably for the first time ever in modern times. Idle time and excess power can recharge batteries that assist during peak demand events. A necessary precursor to autonomous controls is a reliable avionics platform that, like power, has a high reliability, and a high availability. When the control system is properly operating, then it contributes to the ability of the platform to operate reliably, and not be a source of new problems. This section describes technologies and methodologies that enhance the operation of the TUG, and its accessories in the field.

sysRAND Corporation

135


STIRLING RADIOISOTOPE ALTERNATOR

sysRAND is introducing a technology fusion that is called variously a Stirling Radioisotope Alternator (SRA), or a Gamma Battery, that can be favorably compared to conventional RTGs, in most contexts. The proposed device has a non-fissile nuclear core, surrounded entirely by an X-Ray Fluorescent Cascade Shielding (XFCS) that converts Gamma and X-Ray photons into visible and InfraRed photons, heating a working fluid, (e.g., Nitrogen or NaK), and driving a dynamic electric generator. A lowtemperature, high-efficiency Stirling Engine in conjunction with an alternator work together to provide double-digit efficiencies at a low operating temperature. Instead of operating an RTG in the neighborhood of 700° C to endure a less than nine percent thermoelectric conversion efficiency, a Stirling Engine turning a polyphase alternator can provide a robust efficiency of 25 to 39%, at a modest operating temperature in the neighborhood of 300°C. The XFCS is the revolutionary technology inside the Gamma Battery (SRA) that translates Gamma and X-Ray radiation into practical visible and InfraRed heat. Heretofore, Gamma has only been shielded against, and has not been an effective contributor to the working output of an RTG or a nuclear reactor.

Figure 107 Stirling Radioisotope Alternator Block Diagram The Stirling Engine is a well-understood thermo-mechanical technology which is quite similar to other Carnot Cycle engines: Diesel and Gasoline-powered reciprocating engines. The Stirling uses heat to expand a working gas in a small chamber, driving a piston downstroke where the gas is cooled. A FreePiston Stirling Engine (FPSE) is a potential derivative that removes the crankshaft and piston connecting rod and allows the piston to oscillate freely between the cylinder ends. In the FPSE model, electrical energy is developed by imbedding high-Guass, rare-earth permanent magnets in the piston body and coil cores within the cylinder walls. The Gamma Battery SRA has no fissionable components and is expected to employ Cobalt-60, Cesium137, or Strontium-90 as the radioisotope core. The device produces no neutrons. Many of the available Gamma-only radioisotopes are routinely recovered from reprocessing spent fuel rods. The technology has a useful range of scalability, which is to say that a unit of arbitrary size can be expanded or shrunken to other sizes, linearly. The limit is when the fuel core achieves a size that causes it to melt from self-heating. One way to circumvent this problem is to use a metal oxide to gain a higher melting point. As batteries, the SRA modules are also incremental, i.e., more than one unit may be added-on in series or parallel to achieve the desired current or voltage, a feature that is quite congruent with modular practices. With the objective of providing power in a form factor devoid of the constraints inherent with current

sysRAND Corporation

136

Autonomy as an Operational Element of Planetary Surface Systems nuclear devices, chemical batteries and solar cells, the GB is a fusion of several technologies that are expected to yield a family of scalable, lightweight devices, with an assured long endurance and a designed-in high power output, all at a relatively low cost. The features of this device offer the possibility that it could revolutionize remote and autonomous sensor platforms, including sonobuoys, satellites, UAVs, mobile robots, and many more. In spite of the fact that the Gamma Battery can be thought of as a Radioisotope Thermal Generator-class unit, there is nothing exotic about it. There are, however, not-soobvious subtleties. 12.2

POWER SYSTEM

Since the TUG/Excavator ensemble is not a flight system, it should be qualified for operation in space yet not space qualified. It also does not require the gilding of man-rating. It is long overdue for NASA to begin implementing the more efficient, more energetic, and less wasteful Alternating Current (AC) regime to replace Direct Current (DC) in non-flight applications. There exists eons of flight, maintenance, and manufacturing experience with 400Hz power in the avionics and powerplant sectors of aviation, and these are rigorous applications that are tightly regulated. Alternating Current (AC) is very energetic when compared to Direct Current (DC). DC is static, and based solely upon potential differences for energy translation, and is almost entirely dissipative, or resistive, in implementation. AC has the advantage of intrinsic dynamism (constant change), particularly on its edges, and has inductive and capacitive components that usually dominate the resistive element. In fact, in most well-designed systems where it matters, resistance is an index of a device’s efficiency, and is minimized. The power loss from resistance alone has now caused NASA to rule out sub-surface power cables, buried in trenches, because the regolith is such a good electrical and thermal insulator that they anticipate that the conductors would melt. This is probably true, although the first thinning in a length of cable will further increase the resistance, and the subsequent, increasing voltage drop would quickly drive the localized power dissipation to a point that would open the cable, in the fashion of a fuse. sysRAND has identified the need for AC in this application in papers that have not been published, and is prepared to release one or more of them again, after a bit of freshening. AC dissipates significantly less power, three phase distribution spreads the effective power losses across yet another conductor (3 vs. 2), while also replacing an absolute ground with a virtual ground (reinforced by the lack of a coherent ground in the Lunar regolith). Use of 3 phase, 400 Hertz power allows for efficient direct drive of motors, and servoes use drive transistors that operate less dissipatively, like Triacs, on a cycle-by-cycle basis.

sysRAND Corporation

137


MODULES PARTITIONED AT FUNCTIONAL BOUNDARIES

A module containing and bounding a discrete heterogeneous spacecraft bus or payload function is one of the basic design tenets of sIDEreal systems architecture. A number of practitioners have been “fractioning” monolithic satellite control programs into distributed models; others are developing “clean sheet” distributed models along the very same heterogeneous module partitioning. A heterogeneous module partitioning method is common to industrial software applications. sysRAND refers to them as Application-Specific Modules (ASMs).

Figure 108 Recursive Construction of Mission Structure The minimum functions known to be required for a spacecraft bus and a spacecraft payload are general knowledge in the industry. (We cite the authoritative Space Mission Analysis and Design (SMAD III) as an appropriate reference.) Whether they are tightly-intertwined in a monolithic implementation or distributed across any number of nodes, the minimum set of functions that are necessary for a spacecraft or satellite bus to service a payload mission are: Attitude Determination and Control System ADCS Guidance and Navigation GNAV Command and Data Handling C&DH Communications (with encryption/decryption) COMM Power Management and Distribution PMAD Thermal Management THERM Propulsion PROP For these, sysRAND has applications in design that also employ Automatic Integration and Test (AI&T

sysRAND Corporation

138

Autonomy as an Operational Element of Planetary Surface Systems Proxy), Payload Manager (PAYLD), Space Weather (SpaceWX), Modular Tools, and Repositories. A distributed system can “stripe” bus function processes across a number of processor nodes. This approach is sensitive to at least three problems: 1) the latency introduced by going off-processor and through a network to reach another processor, causing round-trip delays that can make otherwise solid software brittle, 2) non-determinism, again caused by the variability of parallel busses23 or serial networks, and 3) piling up an excess of small bandwidth linkages, which drive the size and bandwidth capacity of the total network and with it its redundancies24, etc. Our experience with parallel and control systems has lead us to the design doctrine that when the coupling between processes or IO is “tight”25, then the processes or IO should be both logically and physically proximate. A lifetime of partitioning functional modules out of the total system with a persistent divide-and-conquer assault has resulted in the recognition that when the software can be bounded in a way that is congruent with the hardware IO upon which it is dependent, the resulting module (ASM) has higher utility and marketability because its function is complete and easily comprehended. An example of a recursive heterogeneous process structure is depicted in Figure 108. The utility of this approach is bolstered by the many benefits of the overall, comprehensive design that results. These include low interrupt service latencies, lower system clock rates, larger duty cycles for the applications26, and permitting a processor to doze when it is idle, conserving precious power. Such benefits are difficult to realize with a monolithic system, even without considering the massive cost of duplicable redundancy. For example, our functional spacecraft partitioning often places Attitude Determination and Control (ADCS) and Guidance and Navigation (GNAV) functions on the same module, sharing gyros and accelerometers; such hybrids could commit a large portion of the module to the heterogeneous function code and hardware resources. Command and Data Handling (C&DH) might represent a function that is relatively generic and agnostic about hardware (except, perhaps, memory capacities), so that a “vanilla” processor board to host C&DH could represent a small fraction of the total module. By means of this spacecraft bus partitioning, each functional partition only requires O(1/n), yielding a combined O(n). In spacecraft systems architecture, redundancy is usually achieved by multiplying functional nodes by an integer multiple of two, three, or five. The conventional use of the term “redundancy” indicates that identical capabilities exist either minimally as “hot” or “cold” spares (2- or 3way), or, more robustly, as a concurrent population of systems that determine the answer by majority vote (3- or 5-way). Functional Partitioning permits a fractional redundancy factor, which reflects that once those nodes that have specialty IO are doubled or tripled, the remaining general nodes (hosts) may employ a reduced redundancy, which reflects a shared risk. 12.4

EMPLOYING ORBITAL SYSTEMS AS A BASIS FOR SURFACE SYSTEMS

Most coherent distributed network architectures can employ Plug and Play features to great advantage. The SPA family currently includes SpaceWire and USB networking. Other popular networks are currently being implemented by sysRAND’s sIDEreal system and include CANbus, Ethernet, and encapsulated JTAG. A typical small satellite network of Application Processors (AP) is depicted in Figure 109. The APs perform the top-level tasks such as Command & Data Handling, Attitude Determination & Control System, Power, etc. The applications are partitioned by these boundaries which offers many benefits to the system, including development simplicity, fault tolerance, fault recovery, redundancy mapping, and substantially more robust network operations – particularly when compared to “striping” single 23

Such as 32 and 64 bit VME or PCI busses, mostly due to indeterminate bus arbitration. “Death by a thousand cuts.” 25 The bandwidth is high or the latency must be vanishingly small. 26 A lot more time executing and reciprocally less time spent in stasis on the program stack. 24

sysRAND Corporation

139

Autonomy as an Operational Element of Planetary Surface Systems applications across multiple nodes, which yields a brittle network with excessive bandwidths and a multitude points of failure. Partitioning Space Plug and Play Avionics by function also supports the implementation of hardware and software integration into function modules, again C&DH, ADCS, GNAV, etc., that can be completely tested, shrink-wrapped (with a pigtail for on-the-shelf testing), and are only minutes away from spacecraft integration and test.

Figure 109 sIDEreal’s Spacecraft Network Model A cursory examination of the two abstracted system models of Figure 109 and Figure 110 reveals that they are nearly identical. The principal difference is that the Satellite Model is static after assembly and integration, while the Modular Tool Model has a portal for modular tools, where a robotic arm, or arm-andtool can be removed or added, at will. Some of the technical capabilities under development in the Small Satellite community are being translated to other space applications. sysRAND is active in these and related developments. Two of the very promising interface developments are Space Plug and Play Avionics (SPA) and sysRAND’s sIDEreal Network Operating System, a federated network of applications programs that will ultimately permit integration of satellite bus and payloads with a minimum of application program development and design. SPA and sIDEreal will enable spacecraft busses to be rapidly assembled, integrated, and tested. Since the Air Force Research Laboratory and NASA have an interest in incorporating the SPA and SDM in future mission spacecraft, it is logical that these two agencies participate in this development. The multi-disciplinary sysRAND design and development team is in the position to: 1) assure that the sysRAND electronics and computer systems design does not preclude insertion into the SPA/SDM domain, 2) define the field operations that maintain device productivity and safety, and 3) imbed the excavator controller within the SPA technology should the opportunity present itself. This capability is also congruent with the Consultative Committee for Space Data Systems' Spacecraft Onboard Interface Services (CCSDS SOIS) efforts for international standardization. sysRAND's SDM and SOIS based implementations are supported with a foundation of existing and pervasive standards such as TCP, Ethernet, CANbus, JTAG IEEE 1149, VHDL, and RS485 Physical Layer – to cite just a few of the more common examples. Modular Smart Tools are alternate components of a common docking and locking port on a robotic arm or turret installed on a robotic mobility platform. The Excavator Application is a specific example of a generalized and layered control architecture, with components resident on the mobility platform, arm/turret, and modular tool. A Concept of Operations (CONOPS) is being designed specifically to support civil engineering and ISRU activities. Control centers communicate with the Excavator Applications Program (or other modular tool) through the Mobility Platform’s RF links.

sysRAND Corporation

140


Figure 110 The TUG has Functions Identical or Similar to Orbiting Spacecraft A Universal Tool Coupling connects the robotic arm/turret to the modular tool, which conveys power and network signals between them. A COTS industrial controller that features Ethernet and USB ports will be used to directly control the excavator. The ARM processor will support AFRL's Plug 'n Play interfaces, SPA-E (Ethernet), and SPA-U (USB). These controls are to be further extended for realtime scientific data acquisition of the planetary environment. 12.5

SMART TOOL CONTROLS

A family of Commercial-Off-The-Shelf (COTS) satellite network processors developed by sysRAND will be the core of the excavator's system. The system uses ARM7 and ARM9 processor nodes27 for the primary system bus services (applications), which will be the planetary surface equivalents of Attitude Determination and Control Sub-system, Command and Data Handling, Guidance and Navigation, Power Management and Distribution, etc28. Using COTS for the early development stages usually enhances the development process by maintaining an applications focus. A secondary network of 8051 and ARM Cortex processor nodes is used for input/output processing and interfaces the sensors, effectors, and transducers to the network of Apps processors. All secondgeneration components of the excavator control network will be flight-ready and code-compatible with the previous versions. These devices will be Rad-Hard and rigorously tested as space avionics. The control system architecture has, as its basis, the Space Plug and Play Avionics (SPA) developed by AFRL. sysRAND has been a prime contractor (SBIR) on elements of SPA and has developed substantial architectures applicable to modular spacecraft. These methods have been found to be portable to intelligent, modular planetary surface tools. 12.6

DEFINING THE TOOL INTERFACE

The excavator will be fitted with a Universal Tool Coupling (UTC) and a robotic turret arm for integration onto a robotic mobility platform. This coupling will also connect the SPA-E (Ethernet Derivative) from the vehicle to the excavator controller. All of the USB devices on the Excavator have local connection to the processor on-board the excavator and do not cross the UTC interface. Applications request data through request-response transactions conducted to repositories. At least one instance of an Applications Processor is the Modular Tool Portal with a SPA subnetwork. The Modular Tool Portal resides on the mobility platform or other spacecraft and connects the platform’s mobility 27

A port to the IBM / Motorola PowerPC Processor Family is in planning. Space Mission Analysis and Design III, by Wertz and Larson, is a valuable and comprehensive introduction to spacecraft systems.

28

sysRAND Corporation

141

Autonomy as an Operational Element of Planetary Surface Systems functions to the virtual command bus. The Modular Tool Portal is a typical Applications Processor, which is extended to the Robotic Arm/Turret/Modular Tool ensemble through a local SPA-E serial bus. The Modular Tool Processor functions are not defined as SPA functions and are a Generic Tool Application. 12.7

MECHANICAL INTERFACES ARE HOT-SWAPPABLE

TUG-compatible modules are electro-mechanical elements that can be inserted and removed as needed. Therefore, the modules have mechanical and electrical couplings. Modules are intended to be installed and removed “hot,” that is, with “live” power and electrical interfaces. There are many features of hot-swappable devices that are required for proper operation, and these include holding a module inactive until positive control can be asserted by the hosting system, and quickly becoming inert when the module is removed from the host. The modules also maintain an eXtended Transduce Electronic DataSheet (xTEDS), which is a self-descriptive XML file that describes the device to the rest of the system. The module may optionally maintain a copy of the latest program image that corresponds to its function. Actual controller hardware would be subject to the shock and vibration of excavation activities, although probably not as severe as that endured by helicopter avionics.

Figure 111 The Modular Tool Subsystem with Redundant SPA-E Links

sysRAND Corporation

142


UNIVERSAL TOOL COUPLING

The excavator team is developing or adopting a Universal Tool Coupling that can be generalized to a large family of Modular Tools, hence the ‘universal’ designation. A Tool Coupling has two major components, one on the end of the Arm/Turret and the complementary part attached to the excavator. In all likelihood the excavator will have a pair of couplings, where one supports the mechanical loads and routes signals and power, while the second is used as leverage to position the excavator blade. A UTC is expected to have several features to support platform reconfiguration, self-repair functions, and stowage. UTCs can partially or completely eject a module, so that module can be loosened and reseated, loosened for handoff to a toolrack handler, or disconnected entirely. An example of the latter case could be a situation where the tool becomes entangled in something, and the Turret or Tool must be sacrificed (if even temporarily), in order to save the mobility platform.

Figure 112 The Tool Positioning Subsystems Support Sensors and Actuators

sysRAND Corporation

143

Autonomy as an Operational Element of Planetary Surface Systems The Universal Tool Coupling incorporating the SDM Plug 'n Play model will likely find its way to orbital applications, where a variety of tools, effectors, and sensor platforms may be attached to satellites. The connections between the Modular Tool (Excavator), the Mounting System (Turret), and the Mobility Platform are SPA-E. The PHY layer imbedded in the rotating couplers may be composed of optical loops to avoid the use of electrical contacts or shielded copper cable loops within the Universal Tool Coupling. The SPA-E and the ETBP Networks are bridged across the mechanical break between the blade and the turret. The UTC may be adaptable for use in orbital installations for the most general application of tools, although an excavator in orbit may prove the exception, since such an installation has no utility. 12.9

MODULAR TOOL SYSTEM NETWORK

The Tool Control Subsystem is imbedded in the Modular Tool (Excavator) and communicates with both the Modular Tool Portal Processor and the Tool Positioning Processor, exchanging power and signals across rotating couplers. The Tool Control Processor has a subordinate SPA-U bus that includes actuators, sensors, and servos, that provide at least 4 DOF. The Modular Tool System employs components of the Mobility Platform, the Robotic Arm/Turret and a Modular Tool. The SPA Plug ‘n Play provides integration, versatility, and operational flexibility. Most command flows are from the Modular Tool to the Platform while the unit is under the authority of the worksite. Outside of the worksite’s control authority, the mobility platform directs the stowage and dismount of modular tools, thereby supporting system states such as depot or in-transit (cross-country) CONOPS. 12.10

PROXIMITY-DETECTING WHISKERS

Proximity Detecting Whiskers are proximity detectors, fabricated of flexible metal that can provide downhole visibility through Lunar dust clouds. The field contour processing provides guidance when reinserting the blade into a trench or continuously during operation to avoid damaging collisions with rocks or disruption of the walls of a trench.

Figure 113 Electrodynamic Proximity-sensing Whiskers sketched onto the Blade A set of ‘Rabbit Ears’ is mounted on the upper rear of the excavator blade to establish the field strength in ambient space as a reference. Whiskers are multi-mode and multiplexed, which allows other testing to

sysRAND Corporation

144

Autonomy as an Operational Element of Planetary Surface Systems include ‘shorts’ between adjacent whiskers, whiskers and the blade, etc. Whiskers are used to maintain a safe clearance between the blade and various parts of the platform; if a collision with rocks is imminent, then the bucket chain and platform propulsion are stopped.

Figure 114 Additional Whiskers sense the Ambient ES Field 12.11

KINEMATICS AND MEMS ANGULAR RATE SENSORS

Solid state Angular Rate Sensors replace bulky and brittle index wheels and gyroscopes in traditional robotic systems that use rotary encoders placed at the arm joints to determine position, and through intensive processing through multiple units, project required trajectories to various path waypoints. Although the multiprocessor technique provides high precision and repeatability, its high power and multiple unit requirement is not necessary for excavation-type tasks. Positional inputs can be provided by 3-axis angular rate sensors (accelerometers), tilt detectors, and electrostatic proximity detectors. These types of sensors provide the necessary positional precision for excavation-type tasks, but without the extremely high precision data that traditional encoders provide (for high precision, high repeatability CNC machines), requiring high-performance and power budgets of multiple control processors. The TUG and Turret are substantial units that employ index wheels as integral parts of their positioning motors, and rross-coupling anglular rate sensor data can be used to cancel motor and chain noise (including backlash), and verify the position indicated by the index wheels.

Figure 115 Example 3-Axis Accelerometer Utilizing MEMS Technology sysRAND’s simplified control schema for the excavator turret/arm is being designed to use positional information obtained from various 3-axis accelerometers (angular rate sensors) placed throughout the system, usually near the extreme ends of rotating linear limbs. Correction for positional error creep over time from component tolerances and computational rounding errors is accomplished using baseline

sysRAND Corporation

145

Autonomy as an Operational Element of Planetary Surface Systems measurements, taken periodically during operation. This process will perform zeroing/baseline measurements at a minimum and a maximum position, akin to plotters, by peaking the amplitude of a focused LED/laser impinging on a photodiode array. Light-Emitting Diodes (LEDs) are used to calibrate position of the turret or excavator by transmitting an encoded signal back to a CMOS photo sensor positioned on the turret. Specific modulated beams are activated when the turret or excavator LEDs are expected to be within view of one of several digital cameras mounted about the turret and TUG. LEDs would typically be used in pairs where the distance between them is known and relative position can be triangulated, confirming positions of the many modular elements of the TUG ensemble. For high contrast views, the shadowed emitters and sensors are suggested.

Figure 116 Modulated LEDs Confirm Servo Positioning through Video Processing 12.12

WAVELET TRANSFORM IMAGE PROCESSING

The edges of objects within digital images contain the bulk of high-frequency components. Wavelets can extract these high-frequency object boundaries at a computational cost of O(n), compared to O(n log n)

sysRAND Corporation

146

Autonomy as an Operational Element of Planetary Surface Systems for an equivalent FFT. Expeditious extraction of objects from the visual field can enhance object recognition for dependent downstream processes. Edge detection is frequently used in AI and robotics, and wavelets offer an economical use of computational resources, vs. a comparable FFT implementation. 12.13

STEREO VISION PROCESSING

A second-tier of image processing would use Phi Ratio Geometry’s Vesica Pisces as the geometric device29 that would use vanishing-point intersection of images to range an object from the cameras. There are numerous tools that can facilitate extraction of information from digital images, particularly using Wavelet Transforms for edge-detection.

Figure 117 Stereo Image Integration and Ranging

12.14

SENSOR DATA FUSION

A prime example of the fusion of sensor data is tracking across multiple cameras, where navigational and tool-in-use video scenes are compared to identify cameras that share fields-of-view, irrespective of scale. This is a dynamic data acquisition mode30, although some cameras may already be known to each other since they share the same mobility platform and tool ensemble. Ranging and scaling may be performed on an ad hoc basis, again using a derivative of the Vesica Pisces method used for stereo vision processing. Wavelet processing can enhance edge detection and object extraction as a precursor to matching of objects by multiple platforms with distinct views, where tracking across multiple cameras supports the sharing of raw images in conjunction with decimated and reduced data frames of extracted data. Further enhancement of scene feature extraction and data fusion would be the realtime overlay of LASER Rangefinder or LASER Imaging data onto the processed scenes. These operations not only add dimension to the data for use by platform autonomy programs, but also add inestimable value to the data for cartographers, mineralogists, and others.

29 30

Phi Ratio Geometry Foundations and Tools, G.J. Rodriguez, work-in-progress. C.J. Taylor Self-Localizing Smart Cameras.

sysRAND Corporation

147


Methods Intrinsic to Autonomy

sysRAND Corporation

148


METHODS INTRINSIC TO AUTONOMY

Launching any sort of hardware to the Moon, Mars, or elsewhere in space requires very large amounts of energy, and therefore, funding. Efficiency can shape a mission; a solid example is provided by solar cells, whose usually low efficiency further degrades mission capabilities as the panels are steadily eroded by radiation. Efficiency does matter, and the more efficiently that ISRU equipment performs, the more frequently such hardware will be on the mission manifest. In addition to reducing communications bandwidth and control latency, autonomy is necessary to impose more effective use of tool resources. In industry and commerce this is known as productivity. For instance, the Excavator model suggests that the device can ingest a metric ton of regolith per hour of operation at low power settings. This implies that, 1) higher power settings may generate even higher yields if the energy is available, 2) the duty cycle for the platform for the mining task can be reduced when the device is available at higher settings, 3) sensitivity to downstream processes such as discharge chute, the hopper, attending units (if available), trips by the platform to the dumpsite (if attending units are not available), or a combination of these factors, could substantially reduce the production yield. The excavator must be addressing the workface for it to pay for itself, and any activity that interferes with excavating is reducing productivity, and therefore, production. Autonomy enables group operations and group operations offer the promise of enhanced productivity by keeping specialized units like the excavator fully employed. Mission Persistence is the compulsion for a system to complete its mission, and implementation of persistence can be substantially augmented through the application of Aggressive Goal-Seeking and the maintenance of platform integrity. Mission persistence also assures continuity, so that the platform is productive across a long lifespan, amortizing the launch costs across a maximized production.

Figure 118 Elements Leading to Autonomy and Group Operations A principal tenet of this model is that autonomy is a necessary prerequisite to, and is foundational to, developing collaborative swarm behavior, and not the converse. "Decision-making in insect societies is decentralized. Group-level decisions are the result of individual insects acting mainly on local information obtained from interactions with their peers and their immediate environment.31" In decentralized decision-making, the upper levels of command must be comfortable with the training and agility of the field operatives (or their programming) and not micro-manage processes that are better conducted on-site. If the control centers lack confidence in on-the-ground autonomy, such skepticism will be evidenced by elevated communication bandwidths. Autonomy is intended to substantially reduce communications with a control center, while displacing such bandwidth to local platform-to-platform radio traffic, which benefits from substantially lower power levels.

31

“Biological Foundations of Swarm Intelligence,” Beekman, Sword and Simpson, in Swarm Intelligence, Introduction and App.lications, Blum and Merkle, editors, Springer-Verlag, 2008, p. 9, ¶ 1.

sysRAND Corporation

149

Autonomy as an Operational Element of Planetary Surface Systems Like the control centers, platforms must similarly have the confidence that their peers are executing a predictable decision process. It must be reiterated here that the design objective is that autonomy software is generally deterministic in terms of outcome, although it may not be so predictable in execution path or trajectory. It may be necessary that a yardstick is developed for Autonomy that is an equivalent of the Turing test for automata. These metrics will be required to characterize the effectiveness, productivity, and determinism of autonomous software. 13.1

NON-STOP PROCESS PARALLELISM

sysRAND has adapted, and tested a software technology that provides non-stop, parallel processing and network operation. sIDEreal netOS provides a reliable foundation of operating system and networking, to nine-nines sigma. The network operating system supports process parallelism on processor nodes and across a network using message-passing in a state-free process interconnect. 13.2

STATE AWARENESS (INTERNAL)

Sensors monitor conditions internal and external to the platform, power, thermal, UV flux, etc., and report same through data and metadata streams. The Metacode Capture and Reporting system captures those data sources that are essential to realtime diagnostics, AI&T, etc. A large fraction of internal state awareness is the capture and evaluation of sensor data that occurs at the system heartbeat rate of 40 times per second, by the traversal of the space of Recursive Process Cells. In addition to the servo sensors so represented, the platform’s core of power supplies, thermal sensors and other common sense points contribute to the platform’s awareness of itself. Some internal state data may be shared with other agents through chatter over communications links. 13.3

SITUATIONAL AWARENESS (EXTERNAL)

Recursion drives the situational awareness of the platform’s internal state, and is interleaved with the evaluation of the external environment. Platform sensors are not only active and sampled at 25msec intervals, these sensors are operating at many scales. In a worksite swarm of platforms and other agents, internal state and environmental data is exchanged as radio chatter. At higher levels of abstraction, the platform’s awareness of itself with respect to the environment, as well as other agents begins with information derived from sensor fusions, trajectory prediction and conflict resolution of the vehicle and its modular tools, which are derived by the intrinsic structure of the Recursive Process Cell traversal. This feature doesn’t imply that the information was arrived at for free, but it is available at no additional expenditure of computational resources. 13.4

MISSION PERSISTENCE

Three strategies are closely-coupled and must be distinguised so that they can each be properly implemented: mission persistence, aggressive goal-seeking, and recursive approximation. Persistence in its simplest form could be as simple as a WHILE–DO or REPEAT–UNTIL clause that contains an elemental process that has value when enhanced by repetition. E.g., one strategy that has been employed in the wild is the simple device of putting one foot (or paw, or hoof) in front of the other, tenaciously advancing across the parched grasslands until a stream or watering hole is encountered. This strategy may actually work more often than not. The exceptions where blind repetition does not work could conclude a mission through repetition of an ineffectual process, thereby dooming the platform to a futile extinction. An example of this latter case would be applying a left-hand rule so often that one circumnavigates a large obstacle, returning to the starting point again and again. One can only conclude that for persistence to bring value to autonomy, the persistent process must express intelligence, or at least variety, in its actions. Intelligent behavior, in this case, may be simply expressed as evaluating performance criteria.

sysRAND Corporation

150

Autonomy as an Operational Element of Planetary Surface Systems In humans, persistence expressing variety would be confused with determination. Mission Persistence is aggressive goal-seeking, and video game software exhibits this feature. Mission persistence is the repetition of an action in pursuit of an objective. It is improbable that the identical trajectory can be repeated due to differences in the environment and internal state, now vs. then. At a minimum, simple repetition may actually cause progress and a change in location (therefore, the environment), and likely a change in the internal state, if only through a diminished battery charge. If a certain action, whether or not repetitive, consumes more than a bounded amount of energy, or fails to produce the progress typical of a certain energy expenditure couped to a certain task, then the current subtask (trajectory) should be re-evaluated. Persistence will not be all that helpful if it fails to include metrics that determine whether progress is being made with the current processes. Therefore, a key element is to test whether the intended change in position or orientation occurs during the current iteration. This same test can also be applied cumulatively across a series of repetitive commands. This suggests that progress should be measured across multiple scales if the macro-command would so indicate. Actual, measured progress can be applied to a recalibration of the systems performance and operational metrics. 13.5

AGGRESSIVE GOAL-SEEKING

It is likely that effective autonomous systems behavior can be implemented through programming behaviors that can only be described as aggressive goal-seeking. This is not to imply that a platform is a bully, it intends to convey the idea that the platform hustles. It is clear that an autonomous surface system should incorporate an innate ability to close the gap between its current state and its objective state. Not all of the steps can be programmatically defined, a priori, since a data set describing the working environment will frequently be sparse or incomplete. The mechanism that will attempt to accomplish a specific mission without custom programming is expected to be a goal-seeking program that aggressively closes the distance between an existing state and the intended state. The intended state is specified by a triple of time, space, and task, which indicates a gap between “what is” and “what is to be.” An aggressive goal-seeking program is relentless in its efforts to close the distance between the starting state (τj, σj, ωj) and the terminal state (τk, σk, ωk). The goal-seeking program structure is thought to be highly recursive as waypoints and milestones are identified and implemented as intermediate times, places, and events (τj + δ, σj + δ, ωj + δ), which lead toward the terminal state through intermediate milestones (τj + Δ, σj + Δ, ωj + Δ). There may be gaps of another kind, those in navigation data that can only be bridged by surface exploration, and this may be accomplished by dead-reckoning, where the platform continues toward its navigation objective, all the while extending the mapped terrain. One of the author’s favorite navigational quips goes something like: “I may not know exactly where I’m going, but I’m certain of where I am.” So another aggressive goal-seeking function is to map and survey, constantly in exploration mode, even while performing other directed tasks. While other strategies, including use of the Recursive Process Cell, will serve to drive goal-seeking, yet additional strategies are necessary to take a meta-view, to avoid a situation where the platform is “stuck,” or oscillates between two stagnant states. These many navigational strategies also scale down into the operation of turret and tool modules. An aggressive goal-seeking program avoids having the software being trapped in low-energy minima through the continuous re-evaluation of milestones and waypoints, and continuous evaluation of a limited retreat to a previous milestone or waypoint. One key element of AGS that already exists is the setpoint. A commonplace example of the setpoint having goal-seeking attributes or behaviors is the cruise control servomechanism of the contemporary automobile. Without a human-in-the-loop, a car on cruise control is going to exhibit an aggressive behavior by persistently travelling at the setpoint, irrespective of obstacles, curves, intersections, or surface conditions.

sysRAND Corporation

151

Autonomy as an Operational Element of Planetary Surface Systems Another feature of aggressive goal-seeking is backtracking, where the task series progresses in reverse from an objective towards the starting point. For navigation purposes, another approach could be based on flanking, where the path is oblique to a direct line to the objective, proceeding for an indefinite distance, and frequently testing for a complete path. Testing should take place periodically, continuously, or whenever breaks in terrain occur. When AGS is evaluating alternate activities it does in the vicinity of the servo scale where it may be stalled. The routine should operate at, or near, the current recursion level because usually it doesn’t gain much to spin the excavator chain, or rotate the turret, when attempting to traverse a rugged landscape. 13.6

RECURSIVE APPROXIMATION

Recursive Approximation was generalized from Behavioral Psychology’s successive approximation methodology, and adapted to the Recursive Cell structure of this model. The method is an iterative construct that approaches an objective stepwise at the appropriate scale, until the objective is met. The recursive cell structure intrinsically supports recursive approximation due to its feature of continuously evaluating the distance between its current position (location) and its current setpoints, and closing that distance with the servomechanism appropriate to the scale of the gap. Development of these methodologies has advanced due to the implementation of solutions in Fuzzy Logic and Learning Control. Key features of Recursive Approximation would include: completion of intermediate goals or Waypoints that lead toward completion of the mission, innate flexibility to bypass a subgoal if it means moving away from the goal or next subgoal, the facility to develop subgoals as intermediate steps toward the next subgoal, the recognition that this process is heavily recursive on multiple scales or levels, the code is structured accordingly, testing of the rate of continuous subgoal and goal closure on multiple scales, simultaneously, and resolution of conflicts between resource or threat and attaining goals, fight or flight. Successive Approximation is an autonomy strategy enabled by the explicitly recursive structure of the control system. Inclusion of persistence and aggressive goal-seeking should result in an aggressive, and tenacious goal-seeking platform. See Farrell and Polycarpou for relevant examples of Learning Approximation using Fuzzy Logic and Neural Networks for control.

sysRAND Corporation

152


Figure 119 Principal Elements of Goal-seeking Path

Figure 120 Midpoints and Waypoints are Recursively Invoked

Figure 121 Second Tier Midpoint Fails to Complete

Figure 122 A Second-tier Midpoint Identifies a Conclusion

sysRAND Corporation

153


Figure 123 Additional Paths are Found by Expansion

sysRAND Corporation

154


sysRAND Corporation

155


CONFLICT PREDICTION, RESOLUTION AND TACTICS

Aggressive goal-seeking methods will seek to complete tasks, and will be weighted to bias against any risk to the platform from collision, or other costly delay. Implementation of any exploration model will inevitably lead to conflicts among any number of fixed and mobile assets, whether any of them are driven by goal-seeking heuristics or not. Conflict resolution has a few mechanisms in play: • providing rights-of-way, prioritization or seniority rules, which are used to deconstruct (reduce) a conflict and thereby eliminate it when it occurs, • assuring development of collaborative rules which tend to proactively minimize overt conflict among assets before they occur, • reinforce energy-conservation algorithms by favoring right-of-way for the vehicle in motion, while requiring that the vehicle in motion avoid collisions and unnecessary proximity to stationary or slow-moving vehicles. Threats are situations that can be projected to compromise the platform integrity, or mission success (or both). When they occur these are usually called accidents, incidents, or liabilities. Conflict among platforms, missions, and tasks will occur whether aggressive goal-seeking is implemented or not. AGS can be structured to keep conflicts to a minimum, including conflict among fixed objects, landscape features, moveable objects, and moving objects. Trajectory mapping provides the opportunity to forecast and avoid conflicts, where objects are tracked for: • • • • • •

threat assessment, collision avoidance, closure rates, traffic protocols, navigational inputs, and independent motion.

These measures cross over to enhance collaboration. Multiagent systems

sysRAND Corporation

156


KOBAYASHI MARU AND THE ART OF CHEATING

"This is the Kobayashi Maru, nineteen periods out of Altair VI. We have struck a gravitic mine and have lost all power..." Jktine May 16, 2009 in Urbandictionary.com “A no-win situation caused by a set of rules that can only be won by changing the rules, in effect, cheating. This term comes from the name of a small ship in distress in a scenario shown in a Star Trek movie [the 1982 motion picture Star Trek II: The Wrath Of Khan.] According to the film, the scenario is featured in a training simulator for students attempting to become ship's captains. They receive a distress signal from the Kobayashi Maru and can either attempt to rescue it and be destroyed by enemy forces or leave it and let it be destroyed. James T. Kirk, according to the film, is the only person to have won the scenario--by reprogramming the simulator. Kobayashi Maru, loosely translated, means "Little wooden ship." Someone experiencing a Kobayashi Maru can be said to be “between a rock and a hard place.”” Kidduffah Tubes Jul 4, 2004 in Urbandictionary.com

Long before Captain James T. Kirk dramatized his “cheat” at Starfleet Academy, in defiance of the nowin scenario with which he was confronted, I had my own Kobyashi Maru moment. In 1977 another of the systems engineers thought to amuse me by loading a new task to the Burroughs B4700 Master Control Program program “mix.” Pointing to one of the many TWDI (Tweedy) hard-wired CRT character terminals, he invited me to take a seat and follow the directions. In the few seconds that it took for me to take my place at the terminal, the computer took the first move and awaited my input. A cursory check of the 8 x 8 grid of “quadrants” revealed a scattering of Klingon and Romulan warships plus a solitary Starbase, so I could only conclude that I was now playing a Star Trek version of Dungeons and Dragons, and further, that I was in deep vacuum. While the computer dispassionately awaited my turn, I found that I had time to examine the situation and didn’t have to make a sudden, rash move. It was, however, one of those moments when you could toss your hands up in a gesture of futility and surrender: warp drive was disabled, shields were down, phasers inoperative, and photon torpedoes offline. The unfolding scenario revealed that the Klingons had struck first, since the computer must possess the White Queen. At this point, any rabid “Trekkie” of the age would realize that the only latent lethalities that my nearderelict, cybernetic Enterprise retained were Impulse Drive and deep energy reserves. Impulse Drive could hardly allow one to escape and a starship is way too big to hide in an asteroid belt, and the game didn’t offer any asteroids, anyway. Enterprise was a sitting duck, with all of that expensive Starfleet equipment busted, the game offered no way to translate all that energy into a fight or flight scenario to live to fight another day. Perhaps the tractor beam could pull the nearby Klingon close enough that he couldn’t fire on me, yet the game had no mechanism for boarding another ship, friendly or hostile, and that would be the necessary next step. So playing kissy-kissy wouldn’t work, but that thought led to the winning move: set the tractor beams to repel, dump most of the available energy banks to the tractor beams, and execute! The ensuing massive, virtual, gravity pulse proceeded to sweep all sixty-four quadrants clear of anything smaller than a planet! The Enterprise lived to fight another day, once Scotty fixed everything. (Unfortunately, the maneuver left no starbase for my intrepid starship to return to; perhaps that receding

sysRAND Corporation

157

Autonomy as an Operational Element of Planetary Surface Systems starbase provided the inspiration for the later Star Trek Voyager series.) 13.8.1 Lessons Learned The Lessons Learned from my obscure encounter with the Kobayashi Maru scenario have application to our efforts, and a few are worth stating: It isn't always necessary to alter the simulation programming to win. If a computer offers an opportunity to cheat the system, by all means oblige it! Employ the available assets in an unconventional way, i.e., outside of the usual contexts. The latter of these is one that is familiar to most devotes of spy thrillers and action movies. The other two, however, we introduce because they are low-energy approaches to creating new rules that don’t require reprogramming to implement. 13.8.2 Towards Formalizing Cheating as a Strategy for Autonomy Cheating intends to achieve a goal through a trajectory outside existing, pre-defined plans. When the pejorative usually applied to cheating is lifted for the sake of our deliberations, cheating can be viewed as a fundamental mechanism for generating new strategies. Cheating can be seen as a matter of rewriting rules to cover situations not otherwise covered by predetermined or appropriate rules. We posit that cheating may take one of the following forms, and may not be limited to: • • • • •

acting contrary to existing rules, disregarding existing rules, devising new rules in the absence of applicable rules, devising new rules contrary to old rules, and redefining rules by reinterpreting or obfuscating them.

Recognizing distinctions is essential in this enumeration, where the negative of a rule is not the same as dismissing a rule. In the storylines of most books and movies, there is frequently the deus ex machina, the non sequitor, the “alligator over the transom” that allows the hero to win (and survive the author’s perverse imagination). To short-circuit process is to disregard existing rules, or to appear to observe them, pro forma, yet only superficially comply with them. 13.8.3 Methods for Rule Synthesis Gaming the system is a method familiar to legislatures everywhere. It is a method of cheating where the agent manipulates a system’s operating rules, and procedures to achieve objectives beyond those of the system designers. This problem-solving approach requires working familiarity, and awareness of system rules, or a facility for extracting or infering the (perhaps hidden, or unstated) operating rules of a system so that they may be cheated. The result is itself a methodology that performs rules extraction (a trial-anderror method to infer, and test for rule existence and/or enforcement), and develops meta-rules that implement meta-strategies. Speaking of the external view, rule formation (and cheating) also demands that there are meta-definitions of resources for the software to use to connect the dots in conventional and unconventional ways. Anticipate system behavior based upon special knowledge Borrow technique from elsewhere (generalizing) Use system features and resources to advantage

sysRAND Corporation

158

Autonomy as an Operational Element of Planetary Surface Systems Use system features in a context apart from pre-defined contexts Successful strategies often devise new rules by employing the converse, inverse or contrapositive of a function. Examples of this are to exit a “trap” by leaving the same way that served as the entrance, e.g., “go the other way,” or “leave to find a way.” A defined process for executing this strategy is the Invert & Translate function in the Recursive Process Cell of 9.11. Cheating is creative solution-finding, unbounded by most constraints on an acceptable solution. Not all constraints may be discarded, because many, very real constraints are enforced by Newton’s Laws of Motion, gravity, and other immutable, persistent effects. The take-away from this topic is that a successful autonomy program has to be creative, by definition. This creativity can be bounded, and it is important that constraint enforcement is not excessively zealous. Notionally, rules may have a number of classes or types: • • • • •

synthesizing, for building things, reducing, for deconstructing things, operating within the domain, manipulating the domain, and constraining any of the above, to provide limits for safety or endurance.

sysRAND Corporation

159


Rule and Command Processing

sysRAND Corporation

160


RULE AND COMMAND PROCESSING

The Command Interpreter processes micro and macro commands, and is able to reach into every nookand-cranny of the control system. The Command Interpreter is capable of traversing the statespace independently of the machine learning system. It is expected that prototypes and early generations of the system will rely on tele-operated control as a confidence and an experience builder. Haptic controls already generate command streams in the Digital Space TUG simulation, and this model will be used to generate command streams that can drive the TUG and tool hardware, while being stored in logfiles. Logfiles will be editted and processed to extract control sequences that can be packaged as macros, and unique commands. Pattern recognition software can observe system operation in order to identify new rules that facilitate the command set. For example, while the platform will have the macro procedures for cutting a trench in the surface to specified dimensions and orientation, the site control may choose to send a series of such commands at discrete points, or instead, as a package of chained commands (so that a stepped trench may be constructed). Milestones can be used to pause a sequence so that a cut may be stepwise inspected, and evaluated before investing schedule, and energy on a construction that is flawed or may present a hazard to the platform. The actions of autonomous platforms are directed by a number of “imperatives” that operate at various scales and contexts. Few imperatives are capable of constructively adding to device’s capabilities, except indirectly by constraining another agent. All imperatives operate by imposing constraints and limits on the operation of robotic agents (e.g., TUGs), and these include: • • • •

policies, directives, rules, and commands.

Policies are boundaries and constraints that endure for extended intervals, perhaps for the service life of a facility. One policy example could be that “(electronically) published rights-of-way rules will be observed by all platforms within a region of exploration and development,” a requirement that may be satisfied by a download of a navigation plug-in. Another might be that “although the zone between Clavius Base and Tycho Crater is not a controlled area, navigation is restricted to roads and electronically delineated corridors.” In other words, don’t step off the path. Directives serve to establish an operating context for a specified duration. An example of these selfcancelling imperatives could be that “the landing pad will be completed by 2300 hrs, when ‘unsupervised access by construction equipment into the landing zone is cancelled, and all intrusions prohibited, except for maintenance activities under a special clearance.’“ Rules are maintained internally, as entries in the fuzzy logic Rule Bases, and are specific to each servo, or language processor. These rules are processed in conjunction with servo, environmental and global inputs by the fuzzy logic interference engine. They usually take the form: IF < condition > THEN < statement1 > ELSE < statement2 >. Conditions and statements generally reference set membership functions using logic operators. Commands are external, direct control inputs that specifically command a function or operation. Commands may be micro, standard, or macro, and each directs an element of the control system to perform a function. Scripting devices, such as the Electronic Work Order (EWO), can provide detailed information that is imbedded with the command stream. EWOs can also indirectly refer to specific

sysRAND Corporation

161

Autonomy as an Operational Element of Planetary Surface Systems information that is available from servers over the communications networks. There are a number of situations that influence the development of rules and protocols, and these include: • Persistent, deeply imbedded rules that are often deliberate, and are intrinsic to the very structure of hardware and software, such as the recursive scanning built into the servo multitasking service, • Other structural rules that are arbitrary, such as language semantics that are imbedded by way of programming “style” in the course of turning out code, • Transitory rules that are derived by learning software and are later forgotten through disuse, and • Transitory rules derived from experience that generalize and are reinforced, becoming persistent, and perhaps shared. Rules, like programs, are debugged over time, where experience sharpens the model, and optimizations inevitably result. This capture document is an example of iterative trial-and-error perfecting the final product. 14.1

FIXED CODE, VARIABLE RULES

sIDEreal identifies the pieces that need to put in place for the end-to-end interface, which is essentially interactive from the ground perspective (Enterprise). sysMON is a leading example of where all of this is going – we’re interacting in realtime with processes on the spacecraft. So we have to build up some boilerplates for sIDEreal to deliver all of these services. Fortunately, most of them can be hammered out fairly quickly and simply, at least on the enterprise end, using tools and existing prototypes that we have used and demonstrated. The spacecraft end will be a little more complex because we have to keep things lean and simple, to avoid exploding the computational load on that end. Very little, if any, of the spacecraft facilities require the local use of a compiler. In the interests of keeping our expensive space assets from turning into junk, we need to continue to develop and test program code on the ground, long before it is uploaded and executed on the spacecraft. In that sense, program code is immutable and invariant. This continues to be consistent with the sIDEreal model of pushing the GUI and other (human) user interfaces to the workstation context, while developing lean applications code for use on the spacecraft. A corollary to this concept is the idea that spacecraft programs talk to ground programs, and ground programs talk to humans. Spacecraft programs do not talk to people directly, ever. In the interests of developing systems that are intrinsically adaptable, and adaptive, and not easily made obsolete, we take a long view of our taskspace. For instance, implementing a spacecraft Command and Data Handling (C&DH) modular function with Fuzzy Logic constructs delivers an implementation platform that can be cleanly augmented over time. The Fuzzy Logic implementation can appear to be very conventional during early development by operating only in the bi-state (binary) regime. Only later, when autonomous features are sought, do the variables and operators of fuzzi-dom begin to be evidenced.

sysRAND Corporation

162


ELECTRONIC WORK ORDER

An Electronic Work Order presents the tasks (goals) and performance objectives for the automata to perform. Performance objectives provide the criteria that specifies the level of quality to which an autonomous unit can measure, determining when the task is complete. In an example case of a ramp, the unit would receive parameters of slope, the beginning and endpoints, the width, the extent of the sidewall, and the precision to which the work must comply. An EWO is issued through at least two mechanisms, 1) the result of open bidding for a solicitation, or 2) being selected because of a platform’s route, location or availability makes it the most suitable agency at the moment of issue. The EWO maintains control authority of ground control and engineering organizations by instituting and enforcing constraints and boundaries on autonomy, EWOs are man-readable and are accompanied by an XML script of the man-readable parameters for machine procedures. As an EWO is constructed, optimizations are applied for modular platforms that attempt to minimize tool changes within a given task or group of tasks. Control Center will not always be assumed to be correct – perhaps a message is garbled, or the data is stale and now contains errors – so that the received EWO should be tested by the platform to determine whether operational parameters are at least nominal for the task domain, and do not place the TUG and tools at risk. A ramp should not be constructed, for instance, if another group of TUGs has already constructed the ramp to the necessary specifications.

sysRAND Corporation

163


CYCLIC AND CHAINED OPERATIONS

In cutting a simple trench the blade “nods” up and down, pushing forward at the bottom of the cut, then cutting the workface in an upward arc, breaking the surface, before reversing the arc back to the bottom through the newly-cut void. These patterns are most likely rectilinear because the buckets are nearly so, and a circular or elliptical excavation tool would exhibit different patterns, thanks to scaling effects. More complex operations nest side-to-side “sweeps” with nodding, with nesting occurring either above or below. More specifically, the blade control can be sweeping in the outer loop, and nodding in the inner loop, or vice versa. The sequence specified in its entirety by the current command.

Figure 124 Excavator Sweep Patterns (Port to Starboard Addressing Workface) In Figure 124, patterns A through F have the disadvantage of using side-cutting by the Excavator Buckets, a method that is considered to be less than effective and likely induces excessive wear on the Blade mechanisms. The remaining patterns, G through J, employ a strictly up and down cutting pattern that moves laterally either at the bottom or the top of the cut, a method that should distribute the wear evenly.

sysRAND Corporation

164

Autonomy as an Operational Element of Planetary Surface Systems A psuedo-code description of (J) in Figure 124, above, may approximate the following: NODDING CUT Do Do Drive the TUG forward Until a Bucket Thickness is Sensed; Do Push Blade Down in an Arc on the Blade Pitch DOF Until Bottom of Cut is Sensed; Do Push Blade Up in an Arc Until Breaking through the Surface; Until Milestone (Waypoint) Achieved; These iterated operations are quite congruent with the Recursive Process Cell, and will easily map onto the hardware and software structure. Macros can be used to construct complex nested loops and also to chain complex task sequencing, unless the device is trained to chain task sequence by the machine learning system. Given an operational Machine Learning System, the platform would be trained to derive this process as a chained iteration of steps. Compare to an operant conditioning training schedule

sysRAND Corporation

165


Machine Learning System

sysRAND Corporation

166


MACHINE LEARNING SYSTEM

In the culture of the aerospace community, conventional avionics are rigidly deterministic. While this assures a predictable execution of program code in a pre-determined environment, it will generally fail to exhibit behavior appropriate to any of a universe of possible (plausible) environmental states that were not included in the software development model. So in a complex, and unpredictable environment, the deterministic approach is often inappropriate when it should be delivering a solution. Emergent, adaptive, or learned behavior is indeterminant in execution, by definition. Learned behavior, while not so predictable in execution path or trajectory, is generally deterministic in terms of outcome. If it is sufficient for a platform to autonomously arrive at a designated location, and it does so, then it is a quibbling matter that the platform is two meters short and pointed thirty-seven degrees to the West of the reference orientation (assumed to be the man-in-the-loop result). A principal tenet is that autonomy is a necessary prerequisite to coordinated swarm behavior, and foundational to developing robust exploration programs for Mars, the Moon, and NEOs. Axiomatic is that effective use of platforms, tool resources, and energy requires a substantial amount of platform operational autonomy, especially since we are trying to replace the need to support humans on-site, 24/7. It should be understood that implementing swarm behaviors using non-autonomous platforms does not convey autonomy to the platforms, although the swarm may benefit from emergent behaviors that result from rule interaction. In order for autonomy to be allowed to direct these expensive machines, which arrive at Mars and Earth’s Moon after an expensive flight, intermediate development objectives will have to be met. These objectives will be crafted so as to increase the fraction of control that is autonomous, all the while shrinking that fraction that is characterized by human control, or intervention. These competing, and inversely related, control doctrines will together define a metric that we will term Degree of Autonomy, for now. Whatever system parameters, or device behaviors that shape our yardstick, the metric is the robotic equivalent of the classic Turing test for human-consciousness-imitating automata. Fortunately, we do not require a sentient system to construct an autonomous modular tool platform, and it is only necessary that the platform can interpret work orders, navigate a planetary surface, and operate tools – easy if you say it fast, yet autonomy remains an ambitious objective. As for implementation, we recognize the progress in Genetic programming, a methodology that synthesizes new processes through application of random mutations to program structures on a trial-anderror basis. The resulting constructs are then tested for appropriateness-of-fit and compete with other structures to survive. At this point, we don’t choose to take that path. It is our objective, after all, for these machines to execute commands, and work orders in order to be the constructive endpoint of our intelligent networks, and we do not intend for them to be so autonomous that they ignore the work that we build them, and fly them at great cost to remote places to perform. We describe an autonomous system that overlays B.F. Skinner’s Operant Conditioning methodologies onto Fuzzy Logic Inference Engines, and these methods have been seen to be mechanistic by some practitioners, including ourselves, opinions that encourage efforts to bring learned behavior to machines. Through various other insights that have been articulated in the autonomy capture document, generalization and other effects are plausible enhancements to the Machine Learning System. We expect to implement Machine Learning by application of these Behavioral Psychology technologies, and heuristics to modify the knowledge and rules bases of the many levels of servomechanisms, for implementation by their respective Fuzzy Logic Inference engines.

sysRAND Corporation

167


CALCULI OF CONTROL

Formal Languages and Their Ontological and Epistemological Commitments Language

Ontological Commitment Existential Propositional Logic facts First-Order Logic facts, objects, relations Temporal Logic facts, objects, relations, times Probability Theory facts Fuzzy Logic facts w/degree of truth

Epistemological Commitment Confidence in Facts true/false/unknown true/false/unknown true/false/unknown degree of belief Є [0,1] known interval value Є [0,1]

Figure 125 Formal Languages and Their Ontological and Epistemological Commitments32

15.1.1 Propositional Logic Propositional Logic is flat, dimension-less, and binary. 15.1.2

First-Order Predicate Calculus

First-Order Predicate Calculus

15.1.3

S. Russell, Artificial Intelligence: A Modern Approach, pg 240

Temporal Logic

We are implementing the additional ontology of time, and timing relationships in these systems, and therefore, we are implementing Temporal Logic. However, in the interests of clarity in mapping out our system, we choose to call this modification First-Order Logic, for our own convenience. 15.1.4 Higher-Order Predicate Calculus Higher-order logic is a self-referential, meta-process, in that it views functions and relationships between objects as objects, unlike first-order logic expressions that only reference objects. The value of this facility is that new relations can be defined later in a system’s life, relations that do not exist, a priori. To be more explicit, it allows that not all mechanisms have to be hard-coded, and that many, if not most, may be defined by the higher-order predicate calculus. “like most special-purpose logics, higher-order logic is strictly more expressive than first-order logic, in the sense that some sentences of higher-order logic cannot be expressed by any finite number of first-order logic sentences.” – Russell and Norvig By definition, a higher-order logic system should have access to metadata descriptions of events, relationships, and objects.

32

Adapted from Artificial Intelligence: A Modern Approach, Stuart Russell and Peter Norvig, Prentice-Hall, N.J., 2003, pg. 244.

sysRAND Corporation

168

Autonomy as an Operational Element of Planetary Surface Systems 15.1.5 Fuzzy Logic This logic is multi-valued, and allows for nuance and subtlety not accessible to most other formal languages. Through mapping and classification of inputs, outputs, and variables, Fuzzy Logic is capable of capturing many conditions of in-between-ness that the absolute extremes of propositional and n-order predicate calculi exclude. Fuzzy does this by classification of objects into degrees of membership in sets, and multiple sets, thereby imbuing an object with many attributes not available in a binary mapping. Set membership attributes imply relationships, and available operations. 15.1.6 Fusion One To add considerable fidelity to “reasoning” processes, Temporal Logic will be mapped onto the multivalue domains of Fuzzy Logic. This integration will add considerable texture and contextual relationships not normally available in a vanilla Temporal/First-Order Logic System. 15.1.7 Fusion Two To add considerable fidelity to “reasoning” processes, Higher-Order Logic will be mapped onto the multivalue domains of Fuzzy Logic. This integration will suggest new relationships and mechanisms well beyond those available to the original designer.

sysRAND Corporation

169

Autonomy as an Operational Element of Planetary Surface Systems 15.1.8 Using Fuzzy Mechanisms to Emulate Flat Propositional Logic In fuzzy logic notation, partial membership of a variable in a fuzzy set is indicated by the set’s endpoints, 0 and 1. The partial membership is expressed as a decimal fraction to the precision necessary for the application, and this is usually satisfied by two or three decimal places.

μA : x → [ 0, 1 ] The endpoints, or extremes of the set can be used in a manner that excludes the fractional, multivalue middle of the set. This would not normally be the case, although it is useful in at least two contexts. The first of these is to verify the operation of a particular case, much as one might do to test a complex spreadsheet. Another case of merit would be to establish a skeletal solution structure to prove proper operation before populating it with regular fuzzy values. Numbers are not likely to remain crisp zeroes and ones for long in the fuzzy domain, if operators specific to fuzzy are invoked. If these values are to remain crisp, then the operators must be constrained to the familiar Boolean domain. The first of the Boolean operators would be the negation, or complement of a value, and the fuzzy complement operator fills this role, and is an invertable function:

μĀ : 1 – μA ( x ) Bi-state, or Boolean logic requires an “OR” function, and the fuzzy union operator predictably fills this role, and is consistent for our constrained set:

μA∪B : max { μA, μB } The bi-state operator corresponding to the “AND” function is the fuzzy intersection:

μA∩B : min { μA, μB } Further review of available fuzzy operators may reveal other functions that may maintain crisp values for our purposes. This should not be a surprise, given that fuzzy logic grew from Boolean roots.

sysRAND Corporation

170


15.2.1

MECHANISMS OF THE MLS

Induction

15.2.2 Generalization Generalization is a process of inductive logic, and is performed in this system when a recently learned rule is conveyed to all of the first-order functional units (usually servoes). This is approximately the second half of induction, where the first half has been shown to be the process of identifying a feature common to multiple objects or processes, and translating that feature into a rule. The MLS copies a new rule into the repository, posting it to each of the servo controllers that copy the rule to its local operating rules cache. These new rules are then reinforced or extinguished through time, and this is accomplished by adjusting their value to the specific servo controller, a situation where the extinguished rules, those approaching zero, are flushed from the cache. Rules extinguished by any, or all, servo controllers remain ensconced in the primary repository, where they are available in the future, or are later extinguished by “forget” maintenance routines, in order to avoid clogging the repository with garbage rules. Garbage only slows down the search mechanisms, interfering with the generation of new, more appropriate rules. In the recursive process cell model, a rule that is derived at any particular recursive level should be “suggested” for application to all other layers of the recursive stack. Over time, each of the layers will either reinforce or extinguish the rule, thereby generalizing the learned behavior to the extent that it is found to work in other contexts. The reinforcing/forgetting aspect of generalization may be global, or could be found to be localized to a band of levels, outside of which the new rule is found to fade. Forget procedures are themselves subject to experiential modification, and may become a bit complex in the aggregate. For example, a forget process may consult with other, nearby servo layers to ascertain the usage of a particular rule. Subsidiary rules that constitute the forget procedures may determine that a servo, δ, seeing that no other nearby servo has used the rule since its inception at timescale λ, elects to decrement the utility counter by one. Later, when another servo, ε, employs the rule, it increments its local utility counter by one, and resets its local timescale. The Machine Learning System (MLS) assigns an index number for each occasion that it develops a rule. This index number follows the rule as it is distributed to each ply of the recursive control system. The index number assists in following the generalization, invocation, reinforcement and retirement of rules. 15.2.2.1 Bands of Application Any given phenomenon may be found to occur at some mesoscale, and persist for one or more additional levels of scale. These groups of scales can be said to form bands, and will be found to cease in effect at some higher, and some lower scale relative to the current scale, at a level that we identify as a “void.” Some phenomena can reccur in bands that alternate with voids, recursive bursts occurring within recursions that occur on multiple scales. This effect was observed in other diagnostic/cognitive work that is based on the recursion found in Phi-ratio-based structures33.

33

See Phi Ratio and the Self-Organizing Universe, G.J. Rodriguez, [work in progress, 2010—] .

sysRAND Corporation

171

Autonomy as an Operational Element of Planetary Surface Systems 15.2.3 Heuristics Heuristics are the abstracted rules of the Machine Learning System’s Higher-Order Logic that shape the operating rules of the First-Order functions. The mechanisms of behavioral psychology are consistent with those of heuristic practices that have been employed ad hoc by mathematicians and engineers for a very long time. A fusion of the two methodologies is likely as a mechanistic application of behavioral methods is developed and formalized. Backtracking from an objective towards the starting point Taking an example from top-down/bottom-up development methodology, combine goal-seeking with backtracking Learning systems generalize rules from experience, an inductive process It is not clear that induction is possible using a deductive mechanism, although abstract model processing may show the way Fuzzy logic-based linguistic processing of meta-defined structures may be used to implement The mechanisms of operant conditioning, and related, are also implemented through the higher-order predicate calculus. 15.2.4

Behavior Modification “Connectionist learning approaches can be used in learning control. Here, we can distinguish three classes: supervised learning, reinforcement learning, and unsupervised learning. In supervised learning, a teacher provides the desired control objective at each time step to the learning system. In reinforcement learning, the teacher’s response is not as direct, immediate, and informative as in supervised learning and serves more to evaluate the state of the system. The presence of a teacher or a supervisor to provide the correct control response is not assumed in unsupervised learning.” Berenji and Khedar

Supervised and reinforcement learning generate command excursions that are noisy, containing considerable self-correction, and feedback inputs that should be considered to be an interference with learning inputs. Smoothing of command streams are probably best performed through the introduction of control latency that make the objective of each control input obvious to the filtering processes. While unsupervised learning includes undirected, and accidentally-reinforced training opportunities, this mode can be found to generate a large fraction of superstitious behavior that has to be excised over time, either by deliberate discrimination by a trainer or supervisor34, or through automated filtering processes. The latter may be passive, where a certain SR-tuple weighting is minimized to extinction. Unsupervised learning may also include a mode that can best be described as exploratory, where task objectives provide the incentive for development of behavior reinforcement opportunities, in tandem with (performance) objective testing processes. Exploratory learning is further reduced to at least two levels of learning, situational awareness, and more abstract rule development, ie., induction.

34

We make another distinction here. A trainer serves offline, in a test setting, to develop control history. A supervisor manages online behavior modification while tasks are being performed, in approximate realtime.

sysRAND Corporation

172

Autonomy as an Operational Element of Planetary Surface Systems Situational awareness can be seen to contain landmarks that tend to endure, and features that are transient, subject to change. Sometimes, features held to be enduring, and may later be discovered to have been altered. An example of the latter case could be when a small gully, associated with navigational data and adjacent landmarks, has been filled and covered over, forcing changes to navigational data sets. The fact of this change should not be forgotten, because the ground will settle and may be unstable for years, or perhaps, because an investigation may be facilitated at a later date, when a large piece of government-furnished equipment turns up missing. Instrumental Conditioning35 Successive Approximation Classical Conditioning36 Pavlovian Neutral Stimulus Observational Learning37 Imitation In our case, imitation may be facilitated through the free distribution of learned behavior parametrics over radio

15.2.4.1

Classical Conditioning

15.2.4.2 Operant Conditioning / Instrumental Learning B.F. Skinner’s Behavioral Psychology employs a mechanistic approach to psychology and cognitive research that this systems architect has long considered to have application to artificial intelligence applications. Unfortunately, when the cognitive revolution replaced behavioral psychology as the research methodology, as revolutions do, the new community failed to incorporate behavioral psychology as one of the pillars of diagnostic insight into brain operation. The point of application in TUG autonomy are component processes of the Recursive Process Cell. The Machine Learning System is a meta-function that tests for successful completions in the Objective Testing process, and modifies the operations of the Route Planning/Trajectory, Limit Testing, Interference Testing, and Motion Control fuzzy logic inference engines. This method structurally supports rule-based development in the course of Human-in-the-Loop simulations (training sessions), while later supporting the self-actualized (internal, automatic) reinforcement of systems behavior.

Some rules may be determined, a priori, to be immutable. Because they are so classified, they could be pre-loaded into hard-wired (read-only) storage. However, all rules should be loaded into the inference system’s rule base for consistency, and the immutables set to a maximum weight. Otherwise, duplicate, and perhaps, competitive subsystems are attempting to apply rule sets, merging them at the point of application. Simplify. Consider, for a moment, that immutable rules could be modified, or displaced by novel developments. There are those rules that have been found to be universally applicable throughout the ages and therefore, endure. If a rule is so good that it should be cast in stone, so to speak, then its advocates should have the confidence that it would withstand change. The Golden Rule is an exemplar of this type, yet perhaps in our future a wiser humanity may devise the Platinum Rule, and a clever system should allow for evolutionary change. Otherwise, it isn’t the rule that gets superceded, but the system that 35

Naturally Intelligent Systems, Maureen Caudill and Charles Butler,MIT Press, 1990, pg.113. Op. Cit., pg. 115. 37 Ibid. 36

sysRAND Corporation

173

Autonomy as an Operational Element of Planetary Surface Systems exhibited more adaptive flexibility. WIP>> A fundamental mechanism of behavioral methodology is association, which is the mechanism that connects two somethings together, whether real or abstract, or one each (such as the name of a dog and the dog). With computers, we should be able to associate things at a high rate. Axiomatic to association is discrimination which is where distinctions come in Creating a set of two items, an item and an existing set, a relationship between a cause and an effect, or a stimulus and a response. Association cuts across scale, mentally connecting the dots between the butterfly and the hurricane, for example. A behavioral approach is evolutionary, especially since acquired knowledge can be simply sync’d between platforms and reference repositories. Reinforcement is a feedback mechanism that, in typical machine fashion, has positive and negative domains. While this application is quite abstract the search continues for a behavioral method that can be instantiated more concretely in a circuit, a low-level (less abstracted) exemplar of the concept. tree of S-R development strategies attention span Maximum delays exist between stimuli and responses to assist in the discrimination of a random behavior from an elicited behavior. Sometimes this can be particularly long, and the researcher must impose a policy of reinforcing random behaviors even when they are not stimulated. STIMULUS

TAU-1

RESPONSE

TAU-2

REINFORCEMENT

A Stimulus is a Triggering event A Response is an action Reinforcement may take the form of adjustments of priority, ranking, weight, phase, delays. Meta-functions cannot rule out alteration of the reinforcement rules, such as tweaking Tau-1 or Tau-2. The MLS, when properly and successfully characterized as logic process, is a precursor to redefining it in circuit terms as logic functions. There is an affinity between the antecedent-consequent of a Fuzzy Logic system, and the stimulus-response of behavioral operant conditioning. State transitions can be a stimulus An action may also be invocation of another state.

sysRAND Corporation

174

Autonomy as an Operational Element of Planetary Surface Systems 15.2.5 Tabula Rasa The prototype system will begin with a “blank slate,”

15.2.6 Association A fundamental tenet of Behavioral Psychology, association describes the cognitive process of connecting a cause to an effect by an organism. Association has been found to be applicable to some of the simplest of neural networks, such as flatworms and other invertebrates that have been trained, cut up, regrown, and continue to exhibit the operant conditioning. We extend this process to linkage of an antecedent to a consequent in fuzzy logic, and that association is both operational as well as structural. Observe Associations Make Hypotheses Modify Hypotheses

Inductive Step Inductive Step

{ is to make a variant of a hypothesis }

Association is an inductive process, where a rule is formed that describes (in a meta-sense) a response for an identified stimulus Chaining is the situation where a response is the stimulus that elicits another response Test Hypotheses Refute Hypotheses Discard Hypotheses Confirm Hypotheses

15.2.6.1

Deductive Step

Observational Learning

15.2.6.2 Testing to Success Testing to Success has a negative reception in some communities, where it is seen as a clumsy approach, devoid of rigor, and failing to pursue all possible points of failure. While there is merit to these criticisms, there is value to the method because in our experience we have found that no matter how rigorous the investigations, there are problems that will not be found a priori, without exercising the system, or the subsystem in its totality. We view Testing to Success from a perspective that mirrors that of Tom Brown, the Tracker: “When Stalking Wolf gave us a test, it was not a test in the sense that it could be graded. It was a way of knowing what to work on next. The importance of the test was not the results but what we did with them.”38 Test regimes can be established to develop a foundation of operating rules, initially through simulation software, and later through exercising hardware. Testing regimes should not only identify specific problems, but also indicate weaknesses in the system that should be addressed, giving us the opportunity to apply a fix that is thoroughly consistent with the system’s architecture, and not a “band-aid” that will 38

Op Cit, Brown, pg. 115.

sysRAND Corporation

175

Autonomy as an Operational Element of Planetary Surface Systems only cause additional, future problems. The inventory of control rules and experiential data will be developed, while the machine learning process will be refined. In the Machine Learning System, testing is synonymous with S-R training A number of command and data handling (C&DH) processes exist that can accommodate conventional encoded command streams. Spacecraft autonomy will require more abstract operations, including the processing of abstract, poorly-defined commands and chained-commands. While these objectives and others will be explored in the future, they can be managed by fuzzy logic inference engines and heuristic problem-solving. A C&DH may be constructed as a fuzzy logic-based language processor. The autonomy application can be deferred while the modeling system and other elements are completed. Most fuzzy logic multi-value data attributes can be suppressed by the expedient of setting all variables to the extremes of range of valid fuzzy variables, e.g., 0.00, 1.00, disregarding the entire fractional span in the middle, e.g., 0 .. 0.99. It is then a matter of excluding certain fuzzy operators that cannot avoid generating fuzzy data. This approach reverts to treating rule processing as a discrete, two-state (conventional) decision model. The Automated Integration and Test (AI&T) application has a number of functions in common with C&DH.

Figure 126 Testing Regimes can Create Learning Opportunities (new rules) in Simulation

sysRAND Corporation

176


SELF-REFERENTIAL AND SELF-AWARE SYSTEMS

A lead prototype project of many towards achieving machine cognition is underway that identifies natural structures, and effects that are subtle, but very effective Phi ratio-based discoveries. These findings become analogs for application to microcircuit technologies, and ultimately to machine cognition and awareness. Such developments can augment, and sometimes replace, autonomous systems described in this document. The project is detailed in a capture document: AEON: Development of Cognitive Architecture Through Application of Phi-Conformal Structures.

sysRAND Corporation

177


FUZZY LOGIC INFERENCE ENGINES

When Lofti Zahdeh invented Fuzzy Logic, he brought clarity and structure to decades of work that sought to make practical the use of multivalue logic and continuous (non-discrete) domains. Fuzzy Logic uses set membership, logic inference, predefined rules, and mappings of variables to physical or realworld phenomena, to provide logical control of systems. Fuzzy Logic can also be used for modelling, and often resembles neural network implementations. Fuzzy Logic frequently provides an alternative control methodology to Proportional Integral (PI) or Proportional Integral Derivative (PID) models. Non-adaptive Fuzzy Control Systems are characterized by fixed parameters that are predefined and invariant. When a Fuzzy Control System supports changes in one or more of the five core processes, it is considered to be an either an adaptive or a learning Fuzzy Logic Control System. A Fuzzy Logic Controller has a number of functions that are mappings from the crisp domain to the fuzzy domain, or the converse. The quality of an FLC is only as good as the fidelity of the FLC’s many definitions to the “real world” allow it to be. Learning features permit the FLC to improve this fidelity, or adapt to a changing environment. A Fuzzy Logic Processor is a software package that will support autonomous operation in several roles, including route, task and trajectory planning, language processing of Electronic Work Orders and other command structures, limits and interference testing, performance and objective criteria testing, and motion control. Each and every contextual instance of each and every point of control or analysis is termed to be a Fuzzy Inference Engine, because each instance is a re-entrant use of the primary Fuzzy Logic System. The Fuzzifier function performs a conversion of “crisp” input and feedback variables into fuzzy representations. The fuzzifier conversion implements the strategy of the Inference Engine. The Knowledge Base maintains descriptions of the plant that include mappings between the physical and fuzzy domains, fuzzy set representations of input/output variables, and membership functions. These elements are used by the Fuzzifier for converting crisp values to fuzzy.

Figure 127 Fuzzy Logic Controller Block Diagram39

39

Based upon Cirstea, et al., pg. 119.

sysRAND Corporation

178

Autonomy as an Operational Element of Planetary Surface Systems The Rule Base asserts the (sub)system’s control strategy. Expert Knowledge and/or Heuristics are captured as propositional statements, and expressed as IF-THEN rules. Linguistic variables are associated with an expression’s antecedents and consequents, in the form:

Antecedents can be seen as “that which comes before,” while consequents are the “inevitable result” of the antecedent’s existence or occurrence. Applying propositions from the rule base as a logic filter, the Inference Engine evaluates the state of the fuzzy variables, and reducing the implicit knowledge to the equivalent of a system state vector, which then specifies the action(s) to be asserted by the FLC. The inference engine will be either individualfiring-rule or composition based. The latter is a min-max compositional evaluation, or similar. The Defuzzifier is essentially the inverse function of the fuzzifier, in that the defuzzifier converts fuzzy values or representations into “crisp,” non-fuzzy values. The Fuzzifier and Defuzzifier functions are not always symmetric, or perfectly invertable. The Plant is the system under control of the Fuzzy Logic Controller (FLC) core. Sensors capture the state of physical devices within the plant, providing feedback essential to the control of any servomechanism. Scaling and Normalization processes convert crisp values to a fuzzy number, which is a member of a fuzzy set that is convex, normalized, mostly continous (at least segmented), and has a mapping for a functional value μA(x) = 1 at precisely one element (unique). The crisp input is represents an everywhere non-negative function that must be multiplied by a normalizing constant so the area under its graph is 1.

The Knowledge and Rule Bases may be described using XML markup language for system consistency. Reference the CCSDS (Green Book) Report XML Telemetric and Command Exchange (XTCE), CCSDS 660.0-G-1, July 2006.

sysRAND Corporation

179


LANGUAGE PROCESSING WITH FUZZY LOGIC

The Inference Engine employed by language processors, such as the Electronic Work Order or a command processor, will be composition-based. A language will be derived for surface operations, which is a subset of technical English, that is essentially a cross-referenced semantic dictionary of words that are defined in terms of the Semantic Differential. SD is used by marketeers, sociologists and other practitioners of language to grade meaning of elements (words) among a domain of language elements. The very definition of SD congruently maps to Fuzzy Logic operations and functions. The founder of Fuzzy (multivalue) Logic, Lofti Zahdeh, extensively applied the new art to the processing of language and meaning. So by blending fuzzy logic with the semantic differential we are not reinventing the pencil, we are only sharpening it. “Semantic differential Osgood's semantic differential was designed to measure the connotative meaning of concepts. The respondent is asked to choose where his or her position lies, on a scale between two bipolar adjectives (for example: "Adequate-Inadequate", "Good-Evil" or "Valuable-Worthless"). Semantic differentials can be used to describe not only persons, but also the connotative meaning of abstract concepts—a capacity used extensively in affect control theory. “Theoretical background Nominalists and realists Theoretical underpinnings of Charles E. Osgood's semantic differential have roots in the medieval controversy between the nominalists and realists. Nominalists asserted that only real things are entities and that abstractions from these entities, called universals, are mere words. The realists held that universals have an independent objective existence either in a realm of their own or in the mind of God. Osgood’s theoretical work also bears affinity to linguistics and general semantics and relates to Korzybski's structural differential.” -- from Wikipedia (locate source) The bipolar adjectives of SD employ a scale that is congruent with the 0 .. 255 range of a fractional number (byte) that can describe set membership in the Fuzzy Logic realm, as a fixed-point binary mantissa, or fractional component of a real number.

Figure 128 Modern Japanese version of the Semantic Differential40 40 Again from Wikipedia: The Kanji characters in background stand for "God" and "Wind" respectively, with the compound reading "Kamikaze". (Adapted from Dimensions of Meaning. Visual Statistics Illustrated at VisualStatistics.net.)

sysRAND Corporation

180


SERVOMECHANISMS USING FUZZY LOGIC

The fundamental goal-seeking model is essentially a servomechanism. A servo has a setpoint that indicates the desired performance level (command input) of the servo. The servo employs positive or negative feedback in order to adjust its level of work to bring it into agreement with the setpoint. The majority of servomechanisms implemented in the TUG/Excavator ensemble are used for Motion Control.

Figure 129 Abstraction of a PID Controller41 Contemporary control loops generally make use of Proportional Integral (PI), Proportional Integral Derivative (PID), or Fuzzy Logic. There are a few practical neural network servo implementations about. A PI or PID system strictly adheres to differential equations that describe the objective model, and a simplified example is depicted in Figure 129. The PID controller is imbedded once per servo in a dedicated controller card, such as that depicted in Figure 130.

Figure 130 A Conventional Robot Servo Control42

41 42

Adapted from Bekey, pg. 79. Op Cit, pg. 78.

sysRAND Corporation

181


Figure 131 An Integrated Fuzzy Motion Controller One method used in this autonomy implementation is to simplify, simplify, and simplify. In the interest of simplification, therefore, a system that could be used top-to-bottom would be very helpful. It was decided that the large number of servomechanisms may best be met by a series of Fuzzy Logic Inference Engines that are based upon firing rules, which contrasts to the composition-based language processors, that again, simplify the system. The block diagram in Figure 131 is an abstract example of a fuzzy logic controller that is tailored to motion control, and the implementation would likely be a three-phase motor controller. If the power supply is a three-phase alternating current system that is an avionics-compatible 400 Hertz, then the motor drives are considerably simplified to gating shaped three-phase 400Hz pulses. The diagram of Figure 132 reflects another implementation detail that intends to support the effort to keep the system simple. This device partitions the core fuzzy logic engines that operate in Propulsion and Tools module software on the TUG’s core system from the controller’s high-current drivers and other application-specific hardware components. The hardware layers are integrated into the various motors

Figure 132 Partitioning of Motion FLC to Extract Redundant Hardware

sysRAND Corporation

182

Autonomy as an Operational Element of Planetary Surface Systems used for motion control. This minimizes the hardware that operates at the extremities of the system, reduces the performance required of dedicated processors, and places the core fuzzy logic controls hardware and software in the TUG’s best shielded location. This also allows the FLC’s rule and knowledge bases to be more conveniently accessible to the Machine Learning System without inflicting heavy network bandwidth on the overall system.

sysRAND Corporation

183


REINFORCEMENT TRAINING OF FUZZY LOGIC CONTROLLERS

Learning and Tuning Fuzzy Logic Controllers Through Reinforcements Hamid R. Berenji, Pratap Khedkar Connectionist learning approaches can be used in learning control. Here, we can distinguish three classes: supervised learning, reinforcement learning, and unsupervised learning. In supervised learning, a teacher provides the desired control objective at each time step to the learning system. In reinforcement learning, the teacher’s response is not as direct, immediate, and informative as in supervised learning and serves more to evaluate the state of the system. The presence of a teacher or a supervisor to provide the correct control response is not assumed in unsupervised learning. Distinctions Supervised and reinforcement learning generate command excursions that are noisy, containing considerable self-correction, and feedback inputs that should be considered to be an interference with learning inputs. Smoothing of command streams are probably best performed through the introduction of control latency that make the objective of each control input obvious to the filtering processes. While unsupervised learning includes undirected, and accidentally-reinforced training opportunities, this mode can be found to generate a large fraction of superstitious behavior that has to be excised over time, either by deliberate discrimination by a trainer or supervisor43, or through automated filtering processes. The latter may be passive, where a certain SR-tuple weighting is minimized to extinction. Unsupervised learning may also include a mode that can best be described as exploratory, where task objectives provide the incentive for development of behavior reinforcement opportunities, in tandem with (performance) objective testing processes. Exploratory learning is further reduced to at least two levels of learning, situational awareness, and more abstract rule development, ie., induction. Situational awareness can be seen to contain landmarks that tend to endure, and features that are transient, subject to change. Sometimes, features held to be enduring, and may later be discovered to have been altered. An example of the latter case could be when a small gully, associated with navigational data and adjacent landmarks, has been filled and covered over, forcing changes to navigational data sets. The fact of this change should not be forgotten, because the ground will settle and may be unstable for years, or perhaps, because an investigation may be facilitated at a later date, when a large piece of government-furnished equipment turns up missing.

43

We make another distinction here. A trainer serves offline, in a test setting, to develop control history. A supervisor manages online behavior modification while tasks are being performed, in approximate realtime.

sysRAND Corporation

184


REPOSITORY DOMAINS

15.8.1 Rules Base for First-Order Servo Controllers First-Order Logic is implemented on the servo controllers, from platform navigation through modular mining accessories. The established rules (facts) of the first-order logic are descriptive of the problem or operating space and the initial baseline rules are derived by subject matter experts (SME) through deliberate design, simulations and scenario-building. In the current case of surface mobility platforms and modular tools, these SMEs are civil, mining, and equipment engineers. The first order logic to be implemented here extends the domain of facts, objects, and relationships through the inclusion of time and timing relationships normally considered to be the pervue of temporal logic. Through the implementation vehicle, ie., fuzzy logic inference engine, facts, objects, relationships, and time have a degree of truth in the interval spanned by [0, 1]. Those rules that consistently drive towards zero truth are eventually flushed from the rules base cache memory, after a delay which is intended to suppress oscillation. Servo Controllers are event and firing-rule driven. 15.8.2 Rules Base for First-Order Linguistic Processors Rules bases for Linguistic Processors are composition-based 15.8.3 Rules Base for Higher-Order Controllers Higher-Order Logic is implemented on the Machine Learning System controller. The established rules (facts) of the MLS first-order logic describe the abstract relationships among firstorder logic elements. The MLS problem or operating space and the initial baseline rules are derived by subject matter experts (SME) through deliberate design, simulations and scenario-building. These rules are called Heuristics, and are basic problem-solving methodologies familiar to mathematicians, computer scientists, artificial intelligence practitioners, and tacticians. Typical of these heuristics would be tests for transitivity, strategies for back-tracking, recursive approximation, etc. Through the implementation vehicle, ie., fuzzy logic inference engine, the meta-information that describe relationships among the abstract elements that constitute first-order rules is evaluated, again discerning a degree of truth in the interval spanned by [0, 1]. Those relationship rules that consistently drive towards zero truth are eventually flushed from the Heuristics rules base cache memory, after a delay which is intended to suppress oscillation. Rules bases for Linguistic Processors are composition-based 15.8.4

Knowledge Base for First-Order Servo Controllers

15.8.5

Knowledge Base for First-Order Linguistic Processors

sysRAND Corporation

185

Autonomy as an Operational Element of Planetary Surface Systems 15.8.6

Knowledge Base for Higher-Order Controllers

sysRAND Corporation

186


BOTTOM-UP: THE TUG AS A LEARNING MACHINE HOST

A number of command and data handling (C&DH) processes exist that can accommodate conventional encoded command streams. Spacecraft autonomy will require more abstract operations, including the processing of abstract, poorly-defined commands and chained-commands. While these objectives and others will be explored in the future, they can be managed by fuzzy logic inference engines and heuristic problem-solving. A C&DH may be constructed as a fuzzy logic-based language processor. The autonomy application can be deferred while the modeling system and other elements are completed. Most fuzzy logic multi-value data attributes can be suppressed, per 15.1.8, Using Fuzzy Mechanisms to Emulate Flat Propositional Logic, by the expedient of setting all variables to the extremes of range of valid fuzzy variables, e.g., [0.00, 1.00], disregarding the entire fractional span in the middle, e.g., 0 .. 0.99. It is then a matter of excluding certain fuzzy operators that cannot avoid generating fuzzy data. This approach reverts to treating rule processing as a discrete, two-state (conventional) propositional decision model.

Figure 133 Basic Spacecraft Modular Functions Augmented to Support Fuzzy Logic Methodologies

sysRAND Corporation

187

Autonomy as an Operational Element of Planetary Surface Systems Major enhancements to the basic C&DH function box are a command parser and a command sequencer. The command parser ingests packaged commands that are written in XML, so that macros are intrinsic, and not an add-on function. XML also provides powerful compatibility with modeling tools, such as Atego Studio, a feature that allows DoDAF models to drive simulation and diagnostics scripts. The command sequencer posts the parsed and decoded command elements, executing each in sequence, observing the pauses, forks, joins, firing rules, etc., necessary of such a function. The Automated Integration and Test (AI&T) application is derived from this augmented C&DH version, and therefore, has a number of functions in common with C&DH. The AI&T node, if equipped with a repository, could serve as a hot-spare for the C&DH, providing valuable redundancy without the cost of a committed, duplicate node. The C&DH and AI&T nodes are nearly identical hardware implementations, yet they diverge from the remaining ensemble in that they have a substantial foundation of functionality that is hard-coded in nonvolatile memory.

Figure 134 A Scripted Command Parser / Sequencer is Imbedded in the C&DH

sysRAND Corporation

188

Autonomy as an Operational Element of Planetary Surface Systems The command parser and sequencer can also access the many recursive/re-entrant layers of the rule base. The rules are reduced to a compact form that is significantly less verbose than XML, so as to substantially conserve computing cycles. The ability to control sequence also provides the opportunity to insert or inhibit certain rules, supporting sophisticated diagnostics, and intricate operations that leave no residual rules in the rules base after their conclusion. This facility is not provided to the knowledge base. While we may deceive the spacecraft by changing the rules, the knowledge base must always offer the integrity of honest data.

Figure 135 The Command Stream has Access to the Rule Base

sysRAND Corporation

189

Autonomy as an Operational Element of Planetary Surface Systems In a Phase Three effort, fusion of sensor data will be streamed through the repository, where certain data persists. Repository data is available to the FL inference engines of various modular functions as raw data, processed information, or contextual knowledge. Most spacecraft computational functions will not make direct use of the more abstract knowledge available, at this point.

Figure 136 Data Fusion Presents Information to the Spacecraft

sysRAND Corporation

190

Autonomy as an Operational Element of Planetary Surface Systems Since the MLS can generalize, conduct operant conditioning, etc., the inclusion of a Machine Learning System significantly enhances autonomy. The MLS can transcend artificial system boundaries to access knowledge, information, raw data or metadata. MLS completes the system, except for training. The various knowledge and rules bases may be downloaded or uploaded, supporting the wide sharing of experience among platforms.

Figure 137 Machine Learning Completes the Autonomous System

sysRAND Corporation

191


Figure 138 Each Servo Controller is a Recursive Process Cell

sysRAND Corporation

192


XML AS AN INTERCHANGE LANGUAGE

XTCE XML to code First-Order Rules Bases

15.11

USING XML TO LINK MODELING SYSTEMS

While XML does have utility, we have to be careful that we don’t try to use it inappropriately, thereby unnecessarily displacing another method that offers more functionality be being appropriate. We would like to investigate the possibility, and consequences of using XML for conveying the rules base to/from the spacecraft, particularly since XML is self-descriptive44. One problem may be the complexity of parsing XML at runtime on the spacecraft, a step that could substantially impact the overhead of processing rules. As it is, the compact, human-readable text used by inference engines is already a computational burden. A truly autonomous spacecraft will require that the fuzzy logic inference engines and their requisite Rules and Knowledge bases reside on the platform and not solely on the ground. To implement the latter cancels out most of the advantages of autonomy. However, a problem with a similar translation of the knowledge base to/from XML is manifold, 1) in spite of our advocacy of the concept, we don’t yet know the practicality of conveying a rules base via XML, specifically from the perspective of the fuzzy logic inference engine, 2) the knowledge base has a large mass of linkages among atomic and structured data items, links that often don’t function outside of the original spacecraft, or coherently among two or more spacecraft (at this time), and 3) many data structures are large images derived from raw video frames or processed video frames, neither of which lend themselves to XML. To be useful, the knowledge base needs to be viewed with a tool that can depict video frames, three dimensional and perspective views, annotations and metadata. None of these, and other elements have any congruence with the content of a DataSheet. On the other hand, there are a number of metadata elements that would significantly enhance a DataSheet’s presentation.

44

CCSDS (Green Book) Report XML Telemetric and Command Exchange (XTCE), CCSDS 660.0-G-1, July 2006.

sysRAND Corporation

193


Emulation of Swarm Behaviors

sysRAND Corporation

194


EMULATION OF SWARM BEHAVIORS

Swarm architectures assume (insist) that the individual agents have the latitude to resolve their local conflicts locally, which is to say that swarm agents are autonomous. Swarm models are replete with attributes that conflict with industrial models, e.g.: nature’s swarm intelligences are not centrally-driven, yet it is clear that swarm, hive, and emergent complexity have much to offer to robotics operating in remote environments. Some multiplexed, tele-operated systems simulate hives, giving the impression of hive behavior, while they are centrally-coordinated and driven. Many existing group systems are little more than multiplexed command and centralized control distribution systems, which have demonstrated that swarm behavior can be crudely emulated but fails to accomplish the primary objectives of a swarm implementation: substantial reduction of bandwidth and latency of round-trip control and sensing datastreams. Such models would drive the bandwidth requirements even higher, while the ground-based computers probably add a few seconds to latency while they attempt to compute complementary protocols for each and every surface agent. This is precisely the “fork-in-the-road” where swarms and hives may depart from the needs of satellite and surface systems’ operational requirements. Our suspicion is that there is a substantial sweet-spot that will deliver the promise of swarm while excluding the inefficiencies. Like so many aspects of life, it is essential that we approach a topic with moderation and pries out the practical from the whimsical. Rigid adherence to natural behaviors by automata is an invitation to the many hazards of inappropriate or misapplied context. In addition, swarm practitioners should recall that many of the features of a microcosm are not factors applicable to a barren, inorganic Moon immersed in hard vacuum. Swarms and hives are inherently low-energy and are generally low-efficiency mechanisms. Millions of years of evolution have shaped an organism’s genes to construct the many devices and behaviors necessary to survive within ecological niches, always at energy minima. Advantages from swarm collaboration are achieved at an energy level that is significantly less than other adaptations would require, including the long-term evolutionary processes of feature development. Fundamental to swarm, hive, and emergent behaviors is the fact that each swarming species occupies an ecological niche, residing in the identical niche that the individual member of each species (as a loner) would occupy. The difference is that the collaborative behavior of the group leads to competitive and survival advantages. In addition to the similarity attribute, swarm populations tend to be large, and so does their rate of attrition. While swarms of tuna or pollack can suffer only slight losses to an individual predator, a pack of intelligent predators, such as killer whales or porpoises, can consume an entire school of fish, leaving no survivors. Other examples of swarm do suggest that sheer numbers are necessary to keep pace with the natural mechanisms of attrition. It is also evident that the many tasks required of a complex hive or colony take their toll on the individual member; this is the price exacted for survival of the society and its members. Just as DNA evolves structural changes to a species so also does evolution incorporate derivatives and novel behaviors for the swarm. Departures from conformity may be exhibited by an individual mutation that, if successful, is gradually or abruptly blended into the general population. When dealing with fish swarms, for example, the influence of an individual’s batch of eggs on a swarm’s large numbers of hatchlings is strictly a function of survival, and this depends upon adaptations resulting from mutations, whether physical or behavioral. Yet departures from conformity are necessary to have derived a swarm species from a non-swarm species in the first place; the benefit can begin to produce tangible results beginning with the very first tendency to group. Taking this process even further, within a species it is difficult to exhibit a novel specialization beyond a small set of parameters (excluding gender). Nature tends to introduce new features as entirely new species because functional differences do not differentially reproduce within a species (and still breed true), for reasons related to growth, DNA-programmed differentiation, and maturation of the zygote. The closest accommodation of a differentiable feature is when that feature is a recessive or dominant trait.

sysRAND Corporation

195

Autonomy as an Operational Element of Planetary Surface Systems The need for efficiency to manage energy expenditures translates to a need for specialization and the simplest way to attain a diverse mix of specialties in the face of a species’ uniformly identical individuals is multi-species collaboration. 16.1

SYMBIOTIC RELATIONSHIPS

Symbiosis is another natural model that can augment swarm to benefit mixed species to gain the advantages that individuals with specialized functions can bring to the group. A premier example of a species enlisting another species is Homo Sapiens and Canis (initially the wolf, followed by domesticated derivatives). Collaboration among species arises elsewhere in the natural realm; these examples include reef fish and cleaning shrimp, sharks and remoras, grazing ungulates, zebras and sharp-eyed birds – the list is extensive and we should not overlook the humble bacteria and Candida fungi found in most gastrointestinal tracts. Like swarm behaviors, symbiotic behaviors provide advantages in an ecological niche of which a single species cannot avail itself. 16.2

FOUNDATIONS FOR GROWTH

The primary principle to be learned from natural process is that self-organization is recursive – persistently and pervasively so45. Most elements of nature are scalable within a narrow range of existence, and share attributes consistent with self-similarity, where the Laws of Physics are found to operate at distinct clusters of Phi Ratio-based scaling and corresponding energy states. These recursive levels of scale are a mechanism that was not well understood until the Computer Age, although recursion was strongly hinted at for centuries. Lunar surface operations will initially be accomplished through implementation of a collection of ad hoc tele-robotic hardware and protocols. Given the interest that NASA has demonstrated in surface operations and control methodologies, it would seem propitious that a deliberate design is pursued. sysRAND is integrating a number of methods that result in a flexible and somewhat informal federation of modular hardware and software. The approach first constructs a “standard” unmanned robotic mobility platform, top-down/bottom-up, to include non-stop network systems. This platform supports modular tool extensions that use interchangeable universal tool mountings and complement the “hot-swappable” electronics content. This chassis is then populated with “smart” software that assures a high degree of platform and tool autonomy. Once demonstrable autonomy is in place, the extensions necessary to support swarm and hive behavior are inserted. After extensive field experience is obtained in-situ, adaptive software elements are imbedded into the modular software federation to enable emergent behavior to be expressed and learned. 16.3

NATURE’S EXEMPLARS IN SWARM AND EMERGENCE

Swarm Intelligence and Hive Architectures provide useful examples for mission CONOPs when operating examples are extracted from nature and generalized into behavioral primitives for robotic platforms. There are numerous communities of organisms in nature that operate collectively as though they were a single organism. Swarm species have ecological niches similar to those which would be occupied by the species-as-individuals. However, if a swarm were to be compared to a microcosm of single individuals, their collaborative behavior in their niche would be found to sustain larger populations of healthier individuals. There is consistent benefit to forming and operating large collaborative groups; this awareness leads to the perceived need to capture the operative behaviors from naturally-occurring swarm species and apply such to automata. Our initial research objectives in swarm are quite abstract yet have immediate applicability to the TUG and Excavator project. The threads currently include determining those characteristics which enable: distributed leadership or leaderless formations, extraction of behaviors common among various swarming species, identification of behavior divergence among common units vs. specialized units, departure from conformity, and evaluation of communications modalities, and particularly radio.

45

See Phi Ratio Geometry and the Self-organizing Universe, G.J. Rodriguez, work-in-progress.

sysRAND Corporation

196

Autonomy as an Operational Element of Planetary Surface Systems These threads address the issues of swarm, autonomy, and specialized function. Other features of swarm that apply to predation, migration, or reproduction, for example, are not considered to be applicable to either the Martian or the Lunar surface contexts. 16.3.1 Distributed Leadership The models that describe swarm behavior of fish, birds, ants, and bees are compelling examples for robotics specialists to emulate in order to achieve a leaderless formation of robotic platforms. There are many examples of groups that have distributed leadership or are apparently leaderless. Distributed leadership can also be taken to an extreme, such as enabling the individual to be self-lead, which is synonymous with a leaderless swarm. “Although queen is a term that reminds us of human political systems, the queen is not an authority figure. She lays eggs and is fed and cared for by the workers. She does not decide which worker does what. In a harvester ant colony, many feet of intricate tunnels and chambers and thousands of ants separate the queen, surrounded by interior workers, from the ants working outside the nest and using only the chambers near the surface. It would be physically impossible for the queen to direct every worker’s decision about which task to perform and when.”46 The Queen bee mates and lays eggs. She does not issue coordinating commands to the masses of worker bees. A key to swarm behaviors in nature is that the individual agents are each in pursuit of both that which is in the interests of the individual and that which is in the collective interests of the swarm or hive. There is no intrinsic mechanism at work that is explicitly directing traffic, scouting, foraging, gleaning, or nesting activities. Yet for mechanisms to be useful to the mission that funded and put them in place, there is the need to issue commands from time to time. When these commands are the driving agency for autonomous systems, a swarm then begins to converge as a useful element. Leaderless formations actually do have informal leadership, which is often expressed by an individual who breaks ranks or moves ahead of the swarm, moves which typically result in providing transient direction for the swarm. To put a finer point on it, there doesn’t appear to be any ranking of one member of a swarm over another; no chevrons, no “bird guano” on the visor, no executive washroom, no hierarchy of any kind. Except for human governance models, there is no effort on the part of natural processes to direct a species from a central command authority.47 “There is no need for a central director to oversee the (swarm) process.”48 Fisher is one of many to make such an assertion and the idea begs for functional studies running the gamut of governance models and the energy required to orchestrate large-scale economies and projects. We seek to introduce swarm behaviors among unmanned equipment, yet we must provide direction to the robotic platforms in order to structure a successful outcome that aligns with our exploration and development objectives. Our model insists that each individual is autonomous and is driven by its internal programming to seek tasks through a competitive bid process, which selects the unit that is best positioned to service the work order or may be sub-optimal in order to solve some other system-wide needs, e.g., pre-positioning assets for other tasks. If there are any priorities or hierarchies to be implemented they will have to be enforced by the authority that issues the EWOs. 16.3.2 Behaviors Common Among Swarm Species In order for swarms and hives to be useful exemplars, swarm behaviors must be discernable. These are 46

Debra Gordon quoted in Emergence, Steven Johnson, Scribner, 2001, p. 31. This suggests that efforts to govern humans may be horribly misplaced and that freedom is the natural state of mankind. 48 The Perfect Swarm: The Science of Complexity in Everyday Life, Len Fisher, Ph.D., Basic Books, 2009, p. 2. 47

sysRAND Corporation

197

Autonomy as an Operational Element of Planetary Surface Systems those behaviors that are observed in all of a species’ individuals as stimulus-response pairs, where one individual’s behavior or a pheromone trail evokes a predictable response from the swarm members in the immediate vicinity. Those behaviors and interactions that are found to be common among various swarming species have been particularly valuable in developing the general operating rules of swarm. Early on, Craig Reynolds reduced the observed behaviors to rules of avoidance, alignment, and attraction.49 These stimulus-response pairs are reducible to operating “rules” that can be translated to machine automation. 16.3.3 Behavior Divergence Introduced by Specialization Specialized function implies specialized operation and most collaborative rules for the general swarm agent regarding the specialized agents will be of two types: 1) grant a wide berth, or 2) help when asked. It is essential that, once a specialized unit is identified, a baseline unit can usually generalize divergence or exceptions as extensions of existing rules. The exceptions, deviations or novel rules may also be provided in the radio chatter which would accompany the specialty unit. Exceptions can be elaborated with the few modifiers necessary for the ‘vanilla’ robot to interact with the specialized robot, rules which are the cybernetic equivalent50 of “avoid the business end of an excavator, there’s lots of pointy sharp things there,” “approach from the hopper end,” and “excavators are grouchy and don’t like to be interrupted” (re: TUG logo). 16.3.4 Communications Modalities Some swarms consume considerable energy to sustain communication among individual members. In others, communication is limited to maintaining one’s position in the formation, an effort that is barely more difficult than flying or swimming solo but provides the advantage of many more eyes alert to predators and obstacles. In the absence of predators, initial constraint of the application of swarm methodologies to the interaction of individuals immediately opens up the opportunity for swarm or hive members to be heterogeneous participants in the very same protocols, irrespective of their differentiators. Implementation of swarm may achieve early successes as navigation and traffic protocols. In addition to the trajectories of “other” platforms observed and computed from video by an autonomous platform, radio chatter can disclose intentions (and thereby, trajectories) to those in close proximity. Radio would be employed to implant a command in the top control program of a tool platform. The form of this command will range from the micro to the macro to the abstract as the sophistication of the control system steps toward autonomy. Properly designed, autonomy’s aggressive goal-seeking program will pursue a command to completion as its internalized objective, dispassionately and relentlessly. 16.4

LIMITATIONS OF SWARM AND HIVE PARADIGMS

While we are enthusiastic about studying and employing the disciplines of complexity, emergence, and swarm, we are cautious about the hazards of implementation that can occur when the systems analyst/architect fails to keep the application context central to his thinking. A swarm enthusiast or purist is generally of the opinion that: “. . . the robotic system being studied should be rather homogeneous. That is, the individuals that makes up the swarm should be rather identical, at least at the level of interactions.”51 This statement confirms that there may be a tendency for swarm experts to view the natural order of things to be the only method available for consideration. If the swarm practitioner is also a purist he will insist that all swarm individuals must be identical and be identically equipped, an insistence based upon an excessive generalization.

49

Craig Reynolds quoted by Len Fisher, op. cit., p. 26. A phrase coined by John Brunner in the last chapter of the novel Stand on Zanzibar. 51 “Swarm Robotics,” Sahin, Girgin, Bayindir, and Turgut, in Swarm Intelligence: Introduction and App.lications, Blum & Merkle, eds, Springer, 2008. 50

sysRAND Corporation

198

Autonomy as an Operational Element of Planetary Surface Systems Given the scale of the robotic platforms that we envision for Lunar deployment we should be careful that we do not impose severe constraints upon our thinking, lest we lose our opportunities to deploy productive and efficient systems, thus dealing a bruising setback to the often-orphaned ISRU community. The need for productive specialization should not be allowed to be compromised by the swarm purist, and insistence on a homogeneous system at the scale of earth-moving equipment could be a strong rationale for disqualifying swarm as having any merit as a practical family of paradigms. While bio-organisms can provide compelling examples, care must be taken that a purist approach does not unnecessarily force results that are sub-optimal for machines. Similarly, machines should not be preordained to closely mimic behavior exhibited by insects or fish. The danger is that while swarm architectures can be valuable models, they can also become a creative straightjacket, unnecessarily constraining the development of better models. In their enthusiasm for the methodology, developers ignore the deficiencies of swarm and attempt to force-fit an implementation. It pays in any methodology to occasionally step back and re-assess a project as objectively as possible. Our concern about this point is real because the swarm practitioners have made statements in a number of papers, which more than suggest that there remains a proclivity for swarm practitioners to approach swarm with a doctrinaire zeal that will cloud application of the methodologies with assertions such as: “Such a system would define the most elemental form of complex behavior: a system with multiple agents dynamically interacting in multiple ways, following local rules and oblivious to any higher-level instructions.”52 Insistence that swarms do not recognize command streams from outside the swarm may certainly be true of the natural exemplars, but have little utility to site and mission planners. The Lunar Surface equipment developer will likely be an engineer with little interest in parsing nuanced phraseology in order to meet his design goals. So it is incumbent on us to ask questions on his behalf such as, “Does ’oblivious to any higher-level instructions‘ require that a tool platform can’t be instructed to perform a task?” So we must pose the question, “What use is a swarm exhibiting emergent behavior if the swarm isn’t performing a vital function for the Lunar Complex?” Ultimately, if learning methodologies to ever take hold in autonomous architectures, then departures from conformity would have to be encouraged within the implementation. The costs of spaceflight are currently steep and programs cannot afford inefficiencies – numerous though they may be. The costs of placing hardware on the Lunar surface, for one, require that each mass of discrete hardware earn its keep, so few luxuries will make it to the Moon. Swarm behavior is not reflexive. While the group behavior may be synergistically greater than the sum of individual behaviors, it remains a group phenomenon and does not impart any new attributes to its constituent members. Axiomatic to this view are: • if the members of a swarm are not intrinsically autonomous, their accretion does not impart autonomy to the individual, and • if the members of a swarm are not sentient, their combined behavior does not result in individual intelligence or awareness, and • if the members of a swarm are not sentient, their combined behavior is not sentient. Swarm behavior among robots does NOT create sentient robots. While a swarm may benefit from emergent behaviors that result from rule interaction, a swarm does not convey intelligence, or autonomy to swarm members. Swarm can result in more complex communications and behaviors that can be demonstrated to degrade as individuals are sequestered once again from the group, or groups are further subdivided into smaller, isolated groups. It is likely that species with swarm in their DNA suffer stress when their population falls below a certain threshold. Generally, these observations do not detract from the benefits to the individual of group collaborative behaviors. Consequently, while we seek to learn from 52

Emergence, Steven Johnson, Scribner, 2001, p. 19.

sysRAND Corporation

199

Autonomy as an Operational Element of Planetary Surface Systems nature’s ad hoc, bottom-up approach to self-organization, it is imperative that we employ our native intelligence and devise opportunities to optimize the development and operations of surface systems. Terrestrial ISRU and Civil Engineering activities already employ hive architectures with humans-in-theloop, which have numerous small platforms; each platform performs small tasks of various durations and each piece of equipment has an autonomous human operator. Observe that these devices are specialized for a function and that some have interchangeable accessory modules. Investigation of swarm and hive organisms, wherein many individuals are treated as a single organism, will surface a certain amount of “noise” which must be qualified. Those elements that are not likely to be useful outside of the ecological niche should be flagged, but not immediately discarded. In contrast to the determinism of avionics, there is a built-in variability in natural systems that perturbs systems sufficiently so that non-determinacy can drive continuous evolutionary processes. Space or planetary surface systems should be allowed to weigh the value of a given natural swarm attribute or feature, and whether such has a corresponding analog in the space context, before such a feature is dismissed as irrelevant. 16.5

OBJECTIVES OF COLLABORATION

Rules of behavior extracted from observed swarm behavior can be analyzed and generalized for application to clusters of machines that would be tasked to perform (relatively) large-scale operations. Collaborative behaviors, when instantiated in each platform, can be used to enhance productivity, maintain unit integrity, and resolve conflict, often preemptively by deliberate and a priori design. 16.6

APPLICATION OF DISTINCTIONS

A principal distinction, among others, is that our interest is not merely in adapting to an environment – we are more interested in altering or leveraging specific components of a hostile environment towards compatibility with human habitation. It is abundantly clear that humanity cannot afford to field the number of humans on the Lunar surface that will be required to manually construct, and establish outposts. The necessary workloads are impractical for the size of crews that an exploration and settlement effort can afford to mount. Work on the Lunar Surface is hazardous to humans on many fronts, whether the hazard is radiation, micrometeoroids, large equipment in motion, etc. In these efforts, swarm intelligence and hive architectures provide useful examples for mission Concept-Of-Operations (CONOPs) when operating examples are extracted from nature and generalized into behavioral primitives and macros for mostly-unattended robotic platforms. 16.6.1 Proximity and Density of Individuals Effects which Protocol State is Operant For spontaneous group behaviors to be exhibited, the individual elements must be compelled somehow to form a group. Craig Reynolds53 studied swarm behaviors and characterized three foundational rules that seem to be common to swarm species: attraction, avoidance, and alignment. The strongest of these must be attraction, or cohesion, that is the strong tendency of an individual to move towards the average position of those of the same species closest to her. The next rule is avoidance – simply avoid bumping into other individuals of the swarm. The last of these foundational rules is alignment, where individuals move in the average direction that nearest neighbors are moving. 16.6.2 Follow Those Who are Changing Direction In those situations where the swarm takes a sudden change of direction, another rule must be in play, otherwise the inertia of attraction and alignment would dominate, and the swarm would continue to travel in a direction dictated by the center-of-gravity of the swarm. There is also a need to respond suddenly to predators and other exigencies that could be dampened by inertia. Therefore, there must be a rule that says, in effect, when fellows on either side move suddenly away, follow them. Then again, Reynold’s three rules may work because a fish’s neural paths may be incredibly short and stunningly fast.

53

The Perfect Swarm: The Science of Complexity in Everyday Life, Len Fisher, Basic Books, p. 26.

sysRAND Corporation

200

Autonomy as an Operational Element of Planetary Surface Systems 16.6.3 Simplicity Enhances Reliability Complexity informs us that a set of simple rules can derive very complex behavior. These rules can be augmented with extensions and modifiers that address the management of exceptions. As a specific exception becomes commonplace, a swarm that evolves an adaptation that expresses a new rule remains successful. In the machine domain, we manage change by exception, and a change that becomes a recurring event is managed by software changes. If the 80/20 Power Law were to apply to this application, system operators will be very busy solving one problem for every four automatic moves, which, at machine rates, would be several fulltime jobs. A simple system may tend to be a reliable system. 16.6.4 Reliability Enhances Individual Integrity and Lifespan Swarms that enjoy large populations can be tolerant of similarly large attrition rates when replacement rates are at maintenance levels, so that reliability of the individual is not urgent. Reliability of the individual can enhance the endurance of the swarm, in a positive feedback loop, increasing the value of the individual to the swarm. Reliability assures a sustained presence through conservation of resources and energy, thereby supporting smaller populations. Axiomatically, reliability allows a smaller population to do the work of a spendthrifty larger, less reliable population. 16.6.5 Inherently Redundant by Definition In swarm, larger populations are correspondingly redundant and because they are also undifferentiable, they are completely interchangeable. 16.6.6 Autonomy is a Prerequisite Swarm is a superset of the functionality of an individual. There is no function that a swarm can perform that is more than the accretion of small efforts by a large number of swarm members. The apparent dynamism is discernable, yet it results from individual capabilities. Without autonomy, there is no swarm. 16.6.7 Coherent Interactions Require Consistent Protocols In order to achieve coherent behavior by a useful fraction of a swarm, clear and consistent communications protocols must be in force. Poor communications not only result in divergent actions, but cause additional confusion that serves to disrupt coordinated behavior. Ambiguities of command create problems. 16.6.8 Distributed Control Systems Require Feedback Robotic platforms work together as a distributed control system and each robotic platform embodies a distributed control system. Since these are distributed systems, there is, by definition, no central control system to direct the network’s agents. Control systems that project themselves over a network should expect feedback to arrive over the same network. Numerous examples from Nature provide pervasive evidence that: “all decentralized systems rely extensively on feedback, for both growth and selfregulation.”54 A spacecraft’s mechanisms must be aware of how much energy to apply, its direction (vector), and when to apply or remove it. Feedback allows a servo control system to operate independently, once a setpoint has been applied, and is an indispensable element of autonomy. Steven Johnson suggests that feedback is also an indispensable component of swarm, as well. Norbert Weiner taught us that any control system worth the name has feedback, whether direct or 54

Op. Cit., Johnson, p. 133.

sysRAND Corporation

201

Autonomy as an Operational Element of Planetary Surface Systems indirect. Sensors provide direct feedback to servos, and this is often local to a governing microprocessor. Other servos, such as power or thermal management (PMAD, Therm), operate over a network, exercising switches and reading voltage levels and temperature sensors. Indirect feedback is often contextually-derived, or may use an intermediary to convey the sense data that is necessary for subsystem feedback. For example, the current draw of a microprocessor may be used to approximately determine its instruction execution rate. Steven Johnson55 cites evidence that some creatures also detect gradients, which reflect densities and numbers of swarm members. 16.6.9 The Low Energy Trajectory Whether at the molecular level, or in the pursuits of individual organisms, nature can be seen to favor the low-energy trajectory. When this non-linear effect conserves energy, it can survive, and perhaps thrive, on less energy input. Swarms are similar in that they will find a low energy way to perform a task, appropriate to their physiology. Competition among work teams will allow the more efficient team to complete the task sooner, all while confiscating work from less-efficient fellows. 16.6.10 Differences Of Context will Effect the Applicable Protocol State Distinct conditions may be observed in swarms, whether across the entire swarm, or localized to part of the population. Discernable states are observable whether the swarm is feeding, fleeing, stampeding, migrating, or in other common behavior. Observation of swarms has identified that members are retaskable, even when individuals are otherwise occupied, and that a few can lead others in to a new, divergent swarm behavior. A widely dispersed swarm may have several, concurrent swarm tasks underway in zones or threads. Communications drive each of these task contexts. 16.6.11 Separation Based upon Proximity and Density The speed with which schools of fish change direction, for example, suggests that their retinas, lateral lines (neurons) and brains may be prewired to detect changes at the sensor’s smallest resolution, and respond to the apparent changes rapidly, thereby holding their position in the formation. Such mechanisms would make conformance to attraction, avoidance, and alignment rules reflexive. 16.6.12 Separation Based upon Work Progress As work is being accomplished, individuals may have to depart from the group in order to find more work, as the density of work is thinned out. 16.6.13 Ground-Level Perception can be Enhanced by other Sensor Views As Steven Johnson points out, there are constraints on cognition at the street level of perception56. Electronics offers many advantages and new fusions of capability that considerably advance the capabilities of a swarm of platforms. One of these is the facility of having a platform transmit current images to its peers operating in the same worksite, which allows the platforms to further refine their situational awareness to a whole new level. This can be particularly acute when the platform also conveys any metadata which it has derived from its internal processing of the images. This facility expands upon a platform’s situational awareness through self-referential views from other platforms. Shared data may include hazards, landmarks, topological features, markers, buildings and other vehicles. Such a sharing of contextual data can later provide self-referential inputs to robotic platforms that will be of huge value when machine awareness is available.

55 56

Op. Cit., Johnson, pp. 76-77. Loc. cit., Johnson, pp.. 74-75.

sysRAND Corporation

202

Autonomy as an Operational Element of Planetary Surface Systems 16.6.14 Self-Interest Serves the Group Maintaining platform integrity is not only beneficial to the platform’s endurance, but its availability serves the group, the project, and the mission. Certain aspects of an agent’s operation involve expendables, and precious resources that should be used as needed, but otherwise conserved. Programmed or rulesbased behaviors have little to gain from egalitarian biases, where conceding control, rights or resources will generally not be advantageous to the platform. This view does not insist that a platform’s behavior must be selfish, but it does suggest that the platform consider its near-term needs before releasing irreplaceable assets to another. In the micro-economy that is represented by an agent and its accessories a successful strategy may be to hoard resources. Energy is one example of a resource that would be managed for the success of tasks and the overall mission. Excess energy can be accumulated when the agent has a robust power supply and energy is conserved. More specifically, excess energy may be available on TUGs equipped with Stirling Radioisotope Alternators (SRAs, see Appendix E), and transferred to other equipment that has batteries for account credit. A subtle way to conserve energy while being mindful of platform integrity is vehicular traffic. In order to optimize traffic flow, while observing the rules, agents should attempt to maintain the right-of-way, which will conserve energy and time, and will facilitate traffic flow for almost everyone. 16.6.15 Uniformity in Swarms Suggests that Specialized Systems must Emerge As stated earlier, nature arrives at the low energy solution, for an individual has a limited energy budget and food is always problemmatic. At some point an evolved specialization will emerge that is more effective, requiring less energy. These specialization is either a mutation to the current species, or when sufficiently divergent, spawns a new species. The industrial revolution has provided a robust economy through the assignment or assumption of specialized function by individuals who participate in that economy. Excessive specialization implies a need for changes in protocol among individuals. To be effective, swarms should allow for specialization of some of its members, whether as modified individuals, or entirely distinct types of participants. 16.6.16 Specialized System Elements will Notify the Swarm of Their Presence Swarms consist of hordes of identical individuals with very little specialization outside of reproduction, for most species. When critters with specialized features are collaborating, it is a symbiotic mix of two or more species rather than a swarm. In our context, TUG is designed to attach to modular turrets, arms and tools. Combining specialized modular tools to a TUG converts the TUG to a mobile specialized modular tool. This suggests that the TUG will continue to exhibit swarm behaviors at the navigation level, yet be dissimilar to other TUGs from the deck on up. In these different configurations distinct operational rules may apply, and a practical protocol may have the specialized TUG transmit rules for interface to other units in the radio chatter. It is important that specialized agents announce their presence to avoid collision with specialized tools that can cause damage. Terrestrial examples are the backup beeper of construction equipment, or delivery vans or garbage trucks. Other vehicles mix with traffic, yet are quick to announce their presence when their specialized function is required, e.g., an ambulance siren. 16.6.17 Communication is Essential to Swarm Integrity While an observable fraction of the honeybee’s hive behavior is invested in communications among individuals. While certain inputs may be derived by computing the trajectories of fellow robots, the radio link provides an instantaneous communications advantage which has been denied the bugs. This provides an advantage to the platform by reducing the computational load and temporal latency of pattern recognition and trajectory prediction. Nature’s oblique or indirect methods for communication, e.g.: pheromone trails, pollen dance, etc., can be

sysRAND Corporation

203

Autonomy as an Operational Element of Planetary Surface Systems replaced by the immediacy of explicit data made available from radio links. Instead of physiological and behavioral cues to sustain swarm operations, we intend to use radio communications chatter to provide continuous, realtime exchange of information. This shared information is processed and so has an elevated semantic content, requiring less link bandwidth than streaming raw data. Both raw data and processed information will have a number of metadata tags imbedded in the streams, as well. Information of interest would include: • navigation, • task descriptions, • EWOs, • sense vectors, • internal state awareness, • situational awareness, • safety, and • planned and observed trajectories. More abstract classes of data could emerge in the conversations, such as: • experiences, • derived rules, and • metadata. Local radio is probably spread spectrum technology that encourages opportunistic, and emergent coordinated behavior among autonomous units. “Chatter” is originated by a unit conveying its situational awareness, while “gossip” relays chatter from another unit along with the platform’s local situational data. Platforms can also make use of RADAR to anticipate traffic and locate landmarks. The platforms would find RADAR Transponder capability to be very valuable, providing identifier codes and positional data. 16.6.18 Learning in a Swarm Implicit in the work of the swarm researcher is the tacit objective of developing machine consciousness. While the objective is noble, the swarm research community would seek to achieve machine awareness through the same path as the often – and justifiably -- maligned Connectionist school. Those theories posit that if a sufficiently large number of nodes were to be interconnected, a spontaneous, self-aware system would emerge from this “rat’s nest” of interconnectivity. Were this plausible or possible, the Internet might have exhibited signs of consciousness such that the Turing test would be satisfied daily. That the Internet remains a large, albeit useful, network of non-sentient hardware is de facto evidence that other refutations of the concept remain vindicated. Similarly, the swarm is thought to attain intelligence. More probably, the large number of individuals presents many more opportunities for an unintentional stimulus-response-reinforcement sequence57 to occur and a transient learning experience results. The word “transient” is loaded, for it is one matter for a swarm individual to learn a “lesson,” yet it is a tall barrier for the individual to convey the lesson or to know that the lesson must be conveyed to others. Examples may be sufficient to spread a behavior through a swarm, should the learner survive being eaten long enough to show the lesson to others. The next barrier is to convey the lesson in an enduring way to subsequent generations, and some mechanism must exist that imprints upon the hive or colony’s permanent rule set, a.k.a., codes reproduction DNA.

57

From the Behaviorist School of B.F. Skinner.

sysRAND Corporation

204

Autonomy as an Operational Element of Planetary Surface Systems 16.6.19

Scaling Swarm There are many examples of swarms that have populations of hundreds and thousands of individuals. There are other organisms that have informal swarm protocols, that can form and disband ubruptly. Canines and felines are good examples of swarm that require negotiation before an individual is accepted into the group. Six to Eight spiders of a species shown in Figure 139 share the fabrication and repair of expansive webs in the Costa Rican rain forest. Mathematical induction assumes that if a predicate is true for 1, and 2, and 3, then it is true for all integer values. Since swarm is demonstrable for thousands, hundreds, and tens, then it must be true for a few. Invoking an inverted mathematical induction process, we must conclude that the minimum number required to sustain swarm is two individuals. Two is certainly the minimum necessary to form a collaboration, and again is the number necessary to reproduce in most species.

Figure 139 Sparse Networks of Swarm Exist 16.7

SWARM-BASED COLLABORATION

Collaborative operation of surface platforms extends well beyond travelling in tight formations. Swarm behavior will require that dissimilar specialized units work in extremely close proximity, often making physical contact with each other in order to complete tasks. Other, less complex, collaboration will exchange power for regolith, in the case of a TUG designated as a hauler.

Figure 140 Swarm is a Dynamic and Transitory Synthesis of Autonomy and Collaboration

sysRAND Corporation

205


ESTABLISHING SCALE

Scalability of swarm has a number of attributes and an obvious one is that larger populations offer intrinsically greater redundancy. Swarm applications are dependent upon power sourcing technologies that determine the smallest size that individual units of a swarm may assume. A closely related scalability constraint is computation, that, like power sources, has practical size and power consumption limitations. “The members of the swarm system should be relatively incapable or inefficient on their own with respect to the task at hand. That is, either (i) the task should be hard or impossible to be carried out by a single robot, and the cooperation of a group of robots should be essential, or (ii) the deployment of a group of robots should improve the performance and robustness of the handling of the task.”58 Since we approach mechanistic swarm from the perspective of deliberate design, we are short-circuiting evolutionary, trial-and-error processes of nature. Having the advantage of a couple centuries of the industrial and information revolutions in our toolbox, we will disagree with the above citation of a swarm purist, and several tracts not cited. We concede that if simplicity were our primary objective, then Sahin, et al., are correct on all counts. We seek to use nature for guidance and not as a straightjacket. We redundantly express that it seems absurd to constrain capabilities because of a definition, or an interpretation of a definition. It makes little sense to “dumb down” a capability just to allow it into the swarm tent, when a complete capability solves the problem. Were we starting from a clean sheet and were provided with an incredibly compact power supply, then our approach might resemble ants in implementation. Specialization also influences scale, and over-simplification can lead to over-specialization, where the only tool available to an ant is her mandibles. An over-simplified individual may be smaller, but at a cost. Again, referring to the above citation (i), an impossible task may be as simple as a case of extreme expectations, or a mis-match of capability to the task requirement. The flip-side of specialization is that machines that are designed to a specific task are often very efficient and productive in the performance of that task, a feature that is very much related to low-energy solutions earlier discussed in 16.6.9. In order to benefit from performance and robustness, specialization should be accommodated. Nature has many examples of symbiotic relationships between divergent species, and examples from industry would mix specialized machine types to perform coordinated functions, even when agents are not equally yoked. The TUG, for example, accommodates many specialized modules, and pays a size penalty for doing so. Modularity continues to have value when scaled up and down, yet there are practical limits imposed on the designer and mission planner, especially by the launch vehicle.

58

Ibid, p. 89, ¶ 3.

sysRAND Corporation

206


SHAPING RULES FOR COLLABORATION

PRE-WIRED VS. LEARNED One strategy is to allow units to compete by observing rights-of-way, where pre-wired rules dominate, and adaptation has a limited role. TUGs which form convoys and later couple to form trains would be a good example of learning, emergent behavior which could occur spontaneously from machines which are exploiting adaptive programming. Rights of Way essentially a 2-D surface optimizing behaviors to maintain right-of-way in traffic Tactics as an element of collaboration self-interest energy conservation completing tasks Resolving Conflict So, if these attributes are not congruent, then what? robotic platforms can import common rules Some (rules) operators can be enhanced or inhibited Unique operators (rules) Nature’s models Extract or extricate the communications behaviors from the tasks Rules shape rules Rules often scale Generalization Induction Induction generates rules Deduction observes (follows) rules Other agents provide feedback, reacting, or not, to a platform’s behavior with their own behavior augmented by radio chatter an observation of cause-effect poses a hypothesis (rule) --- a hypothesis is a proposed rule supplied by induction a hypothesis is tested deductively, by execution a superstition is a faulty hypothesis, based upon an erroneous connection of an effect with a cause therefore, induction is not random, or connectionist Cause-effect rule or proposition is Aristotelian: IF condition THEN statement (transitive)chaining is an example of “rules shape rules”

sysRAND Corporation

207

Autonomy as an Operational Element of Planetary Surface Systems IF [A] THEN [B] IF [B] THEN [C] IF [A] THEN [C] Everything one ever needed to know about group behavior can be learned from Sun Tsu's Art of War.

The Higher-Order Logic System, integrated with the Fuzzy Logic Inference Engine, should provide capable rules for collaboration, and continuously adjust them for new and emerging situations on the worksite, and in cross-country navigation.

sysRAND Corporation

208


CLOSING THOUGHT

This largely volunteer development was conducted in a deliberate, intense, and sober manner. Perhaps it is appropriate that it is concluded with a bit of whimsy, and since a bottle of carbonated wine is nowhere nearby, and respectfully acknowledging the inspiration of those who created Mike, HAL, Shalmaneser, Harley, and others we borrow from a closing page of John Brunner: THE COOL AND DETACHED VIEW “Bathed in his currents of liquid helium, self-contained, immobile, vastly well-informed by every mechanical sense: Shalmaneser. Every now and again there passes through his circuits a pulse which carries the cybernetic equivalent of the phrase, ‘Christ, what an imagination I’ve got.”59

These machines may not be cognitive, yet they will certainly be altering their program flows.

Figure 141 The Dispassionate TUG isn’t enough of a Poet to Appreciate the Home Planet

59

STAND ON ZANZIBAR, John Brunner, 1963.

sysRAND Corporation

209


References and Appendices

sysRAND Corporation

210


REFERENCES

Bekey, George A., Autonomous Robots: From Biological Inspiration to Implementation and Control, MIT Press, 2005. Berenji, Hamid R., and Khedkar, Pratap, Learning and Tuning Fuzzy Logic Controllers Through Reinforcements, IEEE Transactions on Neural Networks, Vol. 3, No. 5, September 1992. Blum, Christian, and Merkle, Daniel, eds., Swarm Intelligence, Introduction and Applications, SpringerVerlag, 2008. Brown, Tom Jr., The Tracker, as told to William. J. Watkins, Berkley, 1978. Brunner, John, Stand On Zanzibar, Ballantine Books division of Random House, N.Y., 1968. CCSDS, XML Telemetric and Command Exchange (XTCE), Informational Report, CCSDS 660.0-G-1, July 2006. Chariot at Moses Lake images are courtesy of K. Pratt, http://flickr.com/photos/kpratt/2585479219/ Consalvo, Mia, Cheating: Gaining Advantage in Videogames, MIT Press, 2007. Cirstea, M.N., Dinu, A., Khor, J.G., McCormick, M., Neural and Fuzzy Logic Control of Drives and Power Systems, Newnes (Elsevier), 2003. Daubechies, Ingrid, Ten Lectures on Wavelets, Society for Industrial and Applied Mathematics, 1992. Emergence: The connected lives of ants, brains, cities, and software, Steven Johnson, Scribner, 2001. Excavator development under NASA Contract Nr. NNJ07JB25C and NNJ08JA60C. Farrell, Jay A., Polycarpou, Marios M., Adaptive Approximation Based Control: Unifying Neural, Fuzzy and Traditional Adaptive Approximation Approaches, Wiley-Interscience, 2006. Fisher, Len, Ph.D., The Perfect Swarm: The Science of Complexity in Everyday Life, Basic Books, 2009. Hubbard, Barbara B., The World According to Wavelets: The Story of a Mathematical Technique in the Making, A.K. Peters, Ltd, 1998. Johnson, Steven, Emergence, New York, Scribner, 2001. Kaiser, Gerald, A Friendly Guide to Wavelets, Birkhäuser, 1994. Lunar Surface Renderings generated, courtesy of Digital Space software, 2010. Paul, Richard P., Robot Manipulators: Mathematics, Programming and Control, Cambridge, MIT Press, 1981. Peterson, James L., Petri Net Theory and the Modeling of Systems, Prentice-Hall, 1981. Rodriguez, Gary J., Phi Ratio Geometry and the Self-organizing Universe, work-in-progress. Rodriguez, Gary J., Phi Ratio Geometry Foundations and Tools, work-in-progress. SPA-U development through Air Force Contracts Nr. FA9453-06-M-0163 and FA9453-07-C-0074.

sysRAND Corporation

211

Autonomy as an Operational Element of Planetary Surface Systems Schmucker, Kurt J., Fuzzy Sets, Natural Language Computations, and Risk Analysis, Computer Science Press, 1984. Stilman, Boris, Linguistic Geometry: From Search to Construction, Kluwer Academic Publishers, 2000. Terano, Toshiro, Asai, Kiyoji, and Sugeno, Michio, Fuzzy Systems Theory and Its Applications, Academic Press, 1987. Wertz, James R., and Larsen, Wiley J., Space Mission Analysis and Design III, Hawthorne, California, Microcosm Press, 2008. Wickerhauser, Mladen V., Adapted Wavelet Analysis from Theory to Software, A.K. Peters Press, 1994. Yager, Ronald R., Filev, Dimitar P., Essentials of Fuzzy Modeling and Control, Wiley-Interscience, 1994.

sysRAND Corporation

212

Autonomy as an Operational Element of Planetary Surface Systems APPENDIX B: METACODES SUPPORT MISSION ASSURANCE A satellite is a high-density, remote data acquisition device. Much of the traffic is streamed data, which is essentially a realtime compilation of data through several layers of multiplex, bringing together assorted data frames and formats for transmission downlink to the ground. Against this background there also exists the flow of commands, status, and event notifications. There is an opportunity to enhance the durability and robustness of systems and applications through the implementation of a subsystem that captures and reports the many types of system events. The systems that can benefit from implementation of an event subsystem are operating systems, network operating systems, and applications of every sort, particularly realtime applications. Remote platforms conduct data acquisition, control, or monitoring functions, and Metacodes are imbedded in the streaming data that flows from these remote platforms to their hosting enterprise networks. These remote platforms are usually mobile and span numerous application domains: spacecraft, UAVs, UUVs, aircraft, ships, submersibles, buoys, glaciers, icecaps, etc. Metacodes provide a unified, structured, and standardized approach to fault, event, and state capture on spacecraft and reporting on the ground, in contrast to the usual random, ad hoc, or non-existent implementations of error reporting. Such notifications are unsolicited, one-way traffic from the remote satellite node to the ground station tool console, in distinct contrast to the normal transaction protocol of command-response with addressed endpoints. Metacodes resolve a spectrum of reporting issues, especially when a single event avalanches into a storm of data. They also provide a convenient way to enforce error-handling discipline in the programming community. A unified, structured, and standardized approach is compelling since we have the opportunity to define a consistent method to avoid conflicts among the inevitably divergent, ad hoc implementations of the future. Several ground-based support programs require notification of faults, failures, successes, and assorted hardware and software events and milestones. Most of these are reported through the basic science traffic and so are imbedded deep within the data, and not immediately accessible to the potential community of consumers of exception notifications. Events could be more accessible were they characterized as metadata descriptions of a system’s operational state. There are a number of processes which would subscribe to exception data, were it available, and a repository is a logical distribution structure. Treating exceptions as meta-events and their descriptions as metadata is a practical method for flagging exceptions for priority handling. Metadata can be advanced to the head-of-the-line and transmitted before regular data with a prior timestamp. In a recent research project with the Air Force, feedback of this kind was determined to be a common need of debug, diagnostic, simulation, health monitoring, performance monitoring, Automated Integration & Test, and Independent Verification & Validation. Downstream a few years, Metacode feedback will sustain self-reconfiguring and self-repairing systems. The thinking on fulltime, background system services that lead to the Metacode concept was principally shaped by design work on Flight Data Recorders60 (FDRs), hardware and diagnostic software development on mainframes, workstations, and imbedded realtime controllers, both troubleshooting and design. The Metacode system can be regarded as a flight data recorder function “on steroids.” Like an FDR, some codes are generated cyclically by a reporting function, or appear to be cyclical due to the repetition of key routines. In this definition, the majority of metacodes are event-driven, and are reported as they occur. Metacodes are a feedback mechanism that reliably reports the system state of a remote device. 60

The author developed a data acquisition module hosted on the Rockwell Collins BSIU and installed on the VH3 and VH60s of the President’s Helicopter Fleet, where they remain in service today.

sysRAND Corporation

213

Autonomy as an Operational Element of Planetary Surface Systems Diagnostics, for example, are designed to isolate faults in hardware. Many system faults lie outside of this targeting, and while induced by the diagnostic, many faults remain unreported by it. In other applications, there are numerous tests that could be performed, if only a reporting and intervention structure existed. An important component of the metacode concept is that Metacodes may enhance the rigor that can be applied by programmers. Metacodes also provide a reference for normal and abnormal operations by documenting the events, as well as the sequences of events that follow a particular fault, sometimes propagating throughout the platform in a cascade of collateral faults. A “storm” of metacodes is possible, especially in the case of multiple system failures, perhaps induced by an impact from orbital debris. The Metacode system has at least four principal feedback functions: Metacode Capture, Reporting, Processing, and Definition. The rest of the Metacode operation is the front-end application that issues the Metacodes. ACTIVITIES THAT GENERATE EVENT AND EXCEPTION REPORTS Nearly every program running on a satellite or other platform is performing activities that can generate reports of events and exceptions. These clearly include the entire array of user and application programs which comprise the satellite bus and payload elements. They also include a number of services which are to be provided by the Extended Test Bypass (XTBP) subsystem61. These include, and are not limited to: • Debug • Diagnostics • Built-In Self-Test • Hardware-In-the-Loop Simulation I (node-oriented) • Hardware-In-the-Loop Simulation II (network-oriented) • Hardware-In-the-Loop Simulation III (comm-oriented) Test Like You Fly • Health Monitoring • Performance Monitoring • Automated Integration & Test • Independent Verification & Validation The metacodes generated by these programs are not the normal responses to test stimuli and the like. The metacodes report other events that occur as a result of the operation of the various diagnostics and simulations that are underway. For example, a diagnostic that is conducting a memory address line test will return indications of success or failure in probing the uniqueness and repeatability of address line states vs. preset memory pattern content. Metacodes are provoked tangentially to these hypothetical memory diagnostic activities and could include faults such as Unresponsive Program, Parity Error, Stack Overflow, Stack Underflow, or Runaway Recursion. Errors that are immediate candidates for incorporation as metacodes are readily found in c programs and include Return from Subroutine codes, Case Record Defaults, or Divide by Zero events. A typical c programmer almost never provides a useful code on return from subroutine, and an aggressive programmer may return a flag indicating success or failure of a subroutine – and then act on the problem indentified by the return flag, such as repeating the operation. These exceptions can be routed to monitoring processes by way of the distributed metacode reporting mechanisms.

61

Several enhancements were developed and others defined to extend the functionality of the Test Bypass (serial) Bus in Air Force contract Nr. FA9453-07-C-0074. Metacodes were one suggestion of several.

sysRAND Corporation

214

Autonomy as an Operational Element of Planetary Surface Systems EVENTS AND EXCEPTIONS THAT GENERATE REPORTS There are a number of sources of events and exceptions, which would be assigned metacodes and formats; they include, but are not limited to, the following: User Application Events Return from Subroutine codes, Case Record Defaults, Divide by Zero, Runaway Recursion, Unresponsive Program, Insufficient Memory for Allocation, etc. Debug Activity Program Breakpoints, Data Watchpoints, Single-Step, Halt & Resume Detectable, Conventional Errors Parity Errors, Overflows, Underflows, Divide by Zero, Stack Overflow / Underflow Communications Faults Framing Errors, Checksum Errors, Character Parity Errors, Failure to ACK, NAKs, Timeouts, Baud Rate change, other parameter change, Mark, Space, Idle or Hi-Z line condition, Protocol Faults, etc. Processor State Doze, Wake, Reset, WDT, etc. In the course of program operation, there are numerous sources of runtime errors, faults and exceptions. Some of these are classic errors that are routinely managed by conventional methods, e.g., divide-byzero, parity error, or an out-of-memory condition. These faults account for a small fraction of the total domain of possible events, and these are often not well managed when they do occur. Another example is the switch-case function of c/c++, where a default option is employed to handle all of the undefined paths possible in a multi-way (vectored) branch. Nearly all programmers follow the “default“ keyword with a terminating “break,” that exits the switch-case and falls-through to the next line of code. An otherwise good program could contain this poorly-defined decision point, and a corrupted or undefined switch-case variable causes program behavior that is undefined, probably untested, and certainly undetected. Another example of fault detection and reporting opportunities that do not conventionally have a notification method is the return argument that terminates operation of a subroutine or function procedure call. These are more frequently used by programmers to (properly) report back to a calling program, although the argument usually consists of a simple integer or boolean indicating a good or bad result. This binary state is often conveyed on return at the expense of more descriptive state information from the routine, which is simply discarded. Unfortunately, a conscientious programmer could dutifully report precise details, yet the calling system or program likely wouldn’t have a method in place to exploit such information in any way. Consequently, without a Metacode system the stacked return argument would typically be ignored. FLOW OF DATA AND METADATA A Metacode system provides a method for capturing event codes when they are emitted by applications programs, then transporting them downlink to the enterprise network of applications. Metacode notifications are unsolicited, one-way traffic from the remote satellite node to the ground station tool console, in distinct contrast to the normal transaction protocol of command-response between addressed endpoints. Metacodes represent unsolicited messages for unspecified consumers, and, therefore, are problematic to a network. The spacecraft repository will accept all such unsolicited messages and acknowledge receipt thereof. Metacode capture programs provide portals for operating system, network operating system, and applications programs to send event codes to enterprise repositories. The capture programs buffer the Metacodes and “triage” them into a few priority classes, which attempt to optimize available downlink bandwidth. Low-value codes are sent after similarly time-stamped streaming data, while Metacodes that report system breakdown are pushed to the front of the downlink queue – an approach reflecting the

sysRAND Corporation

215

Autonomy as an Operational Element of Planetary Surface Systems Metacode’s FDR function. Metacodes are then imbedded in the data stream moving through a spacecraft’s repository, which is imbedded in a Command & Data Handling’s (C&DH) Store-and-Forward function, while a subset of prioritized Metacodes is simultaneously transmitted through the sIDEbus service network. Both C&DH data- metadata-metacode and the AI&T X–Proxy metacode traffic are routed to the COMM node’s radio link. Metacodes are subsequently routed through ground stations to mission repositories where they are mined and filtered by specialized applications. Receipt of certain Metacodes may invoke a StimulusResponse Chain of activities in order to address the reported issue. A succinct and standardized encoding of events and exceptions suggests that structured metacodes could convey a rapid cascade of failure with high fidelity, if each event were succinct and precise. ACTIVITIES THAT MONITOR EVENT AND EXCEPTION REPORTS A number of processes would exploit the services of metacode reporting. Some processes would be very responsive to events occurring outside the norm while others would log such and not respond to them. The response time, or hysteresis, of the interactive processes varies and is dependent upon the operant close-loop system. A number of these interactive processes and their common reporting requirements has lead the development team to devise metacodes as a common solution. One consumer group could be termed a passive class, i.e., long term continuous process improvement processes, more logistic than operational in nature. For example, performance metrics and functional behaviors will be captured from Metacodes and 8051 Emulation and then used to populate SysML models. Other data could be esoteric items such as xTEDS definitions, software and hardware revision levels, and other self-descriptive metadata. In another application, metacodes are broadcast from an ASIM or APNode toward the radio link (or intervening Console Proxy) to report events, exceptions, and faults. At the Tool Console, receipt of Metacodes may invoke a diagnostic Stimulus-Response chain of transactions by specialized rule processors in order to address the reported problem. This class of metacode consumer is interactive and is closely-coupled to the control system. Timestamps and other metadata link Metacodes to corresponding streamed data residing in the repository. Network portals provide access for numerous applications, including Wikis, to “mine” mission repositories and thereby provide essential feedback to debuggers, diagnostic programs, simulations of all types, health and performance monitoring, AI&T, IV&V. Passive Console Processes Many processes may passively filter through metacodes at a rate significantly slower than realtime and make no response to the indicated events. These passive processes may optionally log the stream of exceptions for post-processing and state reconstruction. Passive processes do not directly interact with the spacecraft, in spite of the fact that the passive process may invoke a fault. Passive processes may also serve as watchdogs in order to observe whether a specific active process responded as expected within the operating parameters of the mission. Passive processes, which may filter incident metacodes to establish the state of a device, would include: • Health Monitoring, • Performance Monitoring, • Independent Verification & Validation62, and • Automated Integration and Test.

62

From a certain perspective, IV&V can be viewed as a subset of AI&T functionality.

sysRAND Corporation

216

Autonomy as an Operational Element of Planetary Surface Systems Interactive Console Processes A number of programs would be more effective if the user were aware of any extraordinary activity that was being generated by his application or service, or whether the exceptions were occurring concurrently with his program, but were not intuitively coupled to it. Those programs which could respond to the satellite's node when metacodes are generated could include: • Debug • Diagnostics • Built-In Self-Test • Hardware-In-the-Loop Simulation I (node-oriented) • Hardware-In-the-Loop Simulation II (network-oriented) • Hardware-In-the-Loop Simulation III (comm-oriented) Test Like You Fly • Automated Integration & Test Some of these service programs may actually deliberately invoke an event and capture the response as a component of the signature of a given process. Examples of this activity would include Automated Integration & Test (AI&T) and Independent Verification & Validation (IV&V). Spacecraft Autonomy Another consumer of metacode information would be autonomous and semi-autonomous systems operating aboard the spacecraft. The key metacodes would be those that contribute to situational awareness, whether internal to the spacecraft or sensed to have occurred externally. Metacode cascades can be evaluated to make determinations of damage and assess possible work-arounds, recovery, and annealling processes. NOTIONAL STRUCTURED METACODES If a structured Metacode reporting system is to support a variety of vendors, and modular interoperability, standards are essential to success. Metacodes resolve a number of reporting issues in a consistent and structured manner that can be standardized.

Figure 142 Metacode Support for the Mission

sysRAND Corporation

217

Autonomy as an Operational Element of Planetary Surface Systems Registry Metacodes presume to maintain a registry of standardized codes that are available for reporting events that are application-specific, vendor-specific, or common to both. The Metacode system requires a standardized registry in order to provide a large reference space of unique and unambiguous (nonredundant) codes for programmers and Metacode-compliant Integrated Development Environments (IDEs). This feature assures that a stack-overflow Metacode, for example, occurs only a few times in the codespace, offering only a small number of descriptive code derivatives. Every effort should be made to maintain code uniqueness and non-ambiguity by avoiding multiple synonym codes. To minimize the fraction of network bandwidth consumed by Metacodes, they will have to be succinct and impose a minimum of packet overhead when encapsulated for transport. Other methods should be devised to throttle, filter, and triage metadata to avoid loading the networks during a cascading failure. Class codes are used to bifurcate the codespace into user (application) space and system space. The user space is further split into payload and drivers/utilities while the system space is differentiated into node (PE) and network categories. The four principal categories are summarized in Figure 144 as: • User / Application – payload • User / Application – drivers / utilities • System – Processor Element / Node • System – Network This classification provides for distinctions between application programs and system supervisory programs and recognizes that fault codes are non-maskable, which means that fault codes are not generally allowed to be extinguished before delivery, while others may be tossed into the bit bucket although they may be counted or otherwise lumped into data with coarser granularity. Each of these categories is further broken down into four bins which classify metacodes to agree with the AIAA / ANSI Reliability Standards. The three reliability bins are joined by Fault Codes in the System classes to provide four bin types: • Reliability – Critical • Safety – Critical • Quality • Fault Codes CCSDS has a simple list of metadata codes buried in one of their preliminary standards papers that we have been unable to locate a second time. The list was unstructured and incomplete, and we immediately recognized its intended function as vaguely similar to MetaCodes.

Figure 143 FDRs Sense Things in Realtime

sysRAND Corporation

218


Figure 144 Metacodes are Classified by Urgency and Criticality Encoding Schema A compact 16bit (2 byte) number is used to identify the fault, and Table 1 shows that extensions to the basic code can provide additional data for those codes that can be enhanced by additional descriptive fields. Expected behaviors of metacodes, taken as a subsystem, would include a number of basics: • Network and processor hardware develops faults, class codes B & F, which are observable by software, • High-priority metacodes, Class Codes 8 .. F, may be sent singly, or grouped if a packet is available, to include a timestamp, • Low-priority metacodes, Class Codes 0..7 are sent in packets that share the same epoch (second) timestamp, • Supervisory programs may set overrides, setting a more restrictive mask authority, • Reliability equates to function – before safety and quality can be assured, the function must exist and perform deterministically, • Safety must assure platform integrity before quality can be assured, • Reporting Priorities are preset to match the available bandwidth dedicated to expected metacode traffic, and • A cascade of metacode traffic could conceivably overwhelm a network during a major event, causing a packet storm, hence the priority thresholds.

sysRAND Corporation

219


Table 1 Proposed Compact Codespace for Metacodes

sysRAND Corporation

220

Autonomy as an Operational Element of Planetary Surface Systems APPENDIX D: COMBUSTION SYNTHESIS FABRIC Combustion Synthesis Fabric (CS Fabric) is intended to stabilize or enclose large masses of regolith. CS Fabric's advantage over sintering bulk regolith is the tensional continuity that its fiberglass matrix offers across a large surface, and around a voluminous bulk. CS Fabric was invented at a time when hydroxyl ice on the Moon was a hope, but not yet a fact, and is a “dry” solution that remains relevant as an ISRU tool. CSF operations on Mars and the Moon would be conducted from wheeled robotic mobility platforms; on NEOs or Phobos they would employ free-flying robotic platforms as CSF dispensers, where a looselyaggregated asteroid could be wrapped in bands of CSF to maintain integrity prior to maneuvering it, or conducting excavation activities. Lunar industrial infrastructures (ISRU) require the structuring of unconsolidated regolith through: • the construction of landing pads, roads, and deflection berms, • the stabilization of pit and trench walls prior to large-scale structure emplacements, • prefabrication of “baskets” and “bags,” prior to filling them with regolith to complete sandbags, “shims,” shoring, and project-specific bulk forms (structural foundations), • patching leaks, and ruptures of pressure vessels, and • strapping bulk items in a fashion similar to duct-tape. CS Fabric (CSF) use is application-specific: landing pads and roads would have thinner interposing layers of bulk regolith than a deflection berm, where CS Fabric sandwiches consist of alternating CSF and regolith layers. The CSF would be rolled out over a regolith construction, covered with additional regolith to a depth appropriate to the application, fired, and iteratively, CS Fabric would again be rolled over the construction and the process repeated. This method permits the construction of large-scale civil engineering projects by stabilizing the loose regolith with various plies and biases of CS Fabric strips, either densely or loosely. A brief summary of Combustion Synthesis Fabric features demonstrates that CSF: • • • • • • •

provides structure to unconsolidated regoliths, provides a continuous metallic matrix, can have a high ratio of fabric to enclosed regolith, is flexible until fired, when it becomes solidified, can assume arbitrary shapes, extents and volumes, can be fabricated from common, indigenous minerals, and has a safe, very high ignition point.

During early Lunar missions, mobility platforms trailing meter-wide rolls would dispense CS Fabric of Terrestrial manufacture. Dispensers would be modular, consistent with "swarm” operations63 of versatile service platforms, and used briefly to install the reinforcing fabric before the mobility platforms would be reassigned to other tasks. Facilities constructed of regolith / CS Fabric stackups would be durable, longterm capital investments. Combustion Synthesis Fabric (CS Fabric) structures unconsolidated Lunar Regolith (and others) against plume and wheel erosion. CSF is a flexible fabric containing its own fuel and oxidizer components, impregnated into the weave or fibers, employing combustion synthesis to fuse the soil to a fabric matrix. The result of a CS “burn” is an irregular, three-dimensional “mat” that should engage the regolith with tendrils and lumps of combustion alloy growth, obtaining a firm grip on the regolith, especially when sandwiched between regolith layers. We expect that the Iron patina found on many Lunar regoliths will become involved in the CS process, and serve as a secondary bonding (alloying) agent. The porosity of the plated fabric is intended to allow the wide range of granule sizes (scale) to provide continuity in the resulting mat of material on either face, and throughout the fabric. 63

Autonomy as an Operational Element of Lunar Surface Systems, G.J. Rodriguez, 2010

sysRAND Corporation

221

Autonomy as an Operational Element of Planetary Surface Systems Once deployed, the fabric would be in contact with regolith on at least one side and most likely both, to a depth of at least one centimeter. After the plies of soil-fabric-soil are set in place, the fabric is ignited with an electric squib, whereupon the process goes exothermic, propagating combustion across the span of the fabric. The result would be a material with an irregular molten-glass appearance and a crust of partially-consumed soil particles, offering a stiff contour interposed between two layers of a regolith “sandwich.” The substrate fabric is not consumed during the combustion process because of the combustion’s short duration, as well as, relatively low temperature (700 – 800°C) when compared to the fabric’s higher deformation temperature (~2,100°C). CS Fabric is manufactured from materials commonly available on the Moon so that later generations of ISRU plant can fabricate the material. CS Fabric should stabilize and contain hundreds to thousands of times its own mass in sculpted regolith comprising the structures. This specific technology is intended to stabilize a contoured Lunar surface area in order to prepare facilities at a Lunar Outpost. The CS Fabric is deployable from a surface Tug trailing a simple dispenser roll. The tug is probably the same type of unit that excavates the trenches and stacks up the berms, and is equipped with a modular dispenser. (A simple reality check is the observation that non-pyrotechnic fabrics are used to reinforce asphalt roadways, while fiberglass is used to reinforce all sorts of structures with and without epoxy.) sysRAND (IRAD) has completed a second-generation computer model in an effort to characterize the effectiveness of a series of small berms in the disruption of horizontal, somewhat laminar, flows. We will determine the size, interval, and number of berms that would be required to have the same effect as an otherwise large berm. Each of the Deflection Berms are to be constructed from regolith encased and internally reinforced with Combustion Synthesis Fabric. A GUI is being developed to support the second, higher fidelity, version of the simulation, which allows the user to alter model parameters for custom simulations. This will support optimization and development of a practical Deflection Berm.

Figure 145 Raw Fiberglass and Simulated Unfired (Green) CS Fabric

sysRAND Corporation

222

Autonomy as an Operational Element of Planetary Surface Systems APPENDIX E: EXCAVATOR STATUS EXCAVATOR BLADE UPGRADES A number of upgrades have been applied to the Excavator Blade, to implement design iterations, and to correct problems with the original design that surfaced in testing over the last many months. Examples of the former include the addition of Buckets to the Pintle Chain, and replacement of the Aluminum Sprocket Test Articles with Stainless Steel, the latter incorporating adjustments to the wear patterns in evidence in the high-contrast of Aluminum and Dark anodize plating. The Blade was intended to fit Commercial-Off-The-Shelf (COTS) chains, except that no two chains are the same length, and yet all are faithful to the ASME Pintle Chain Specification D662. The chain was found to have inadequate support provided by the original tensioning system. COTS tensioning hardware (idler sprocket) was installed on each of the lengths of the chain, sprocket to sprocket, in order to absorb transients independently. One of the operating assumptions was that for the chain to be properly tensioned there should be a tensioner on each length of chain because transients would probably not be symmetric. This intuitive step was found to be completely flawed in that the installation was rigid and locked up the chain. The next intuitive step was to employ only the upper idler sprocket, and this too, proved to be the wrong solution. Research into the literature explained that an idler could only be applied to the “slack” side of the chain, and not in the side being drawn by the drive sprocket. The team was beginning to regret the departure of the former lead engineer, who proved so capable during the Phase One effort.

Figure 146 Most Recent Blade Modifications

sysRAND Corporation

223


Figure 147

Excavator Blade on Static Display, Starboard View

The optimal chain tensioning solution is to redesign the nose sprocket to be a floating assembly, built around shock absorbers that maintain tension, while adjusting to variations in chain lengths. This solid solution is of sufficiently large scope at to require a new project, see Figure 160.

Figure 148 Excavator Blade on Static Display, Port View

sysRAND Corporation

224


Figure 149

Next Shock Strut Mounting Concept

BUCKETS The bucket design has converged, the design completed, reviewed, fabricated, and delivered. The design team is impressed with the quality of the buckets, particularly the quality of workmanship, the metal finish and interior welds. The current bucket design concept is folded sheet metal, which is easier and cheaper to manufacture than either hogging out a block of metal or bolting together multiple parts.

Figure 150 Basic, Curved, and Serrated Buckets, CAD Images The bucket design uses a 1” tall x 4” wide mouth. The low height of the bucket opening reduces soilcutting-induced torque on the chain during excavation, while the 4” wide kerf provides adaptable trenching capability. Using a 3.5” bucket length so that the bottom of the bucket does not scrape the work face, the bucket ladder operating at a nominal 14 RPM (sprocket rotation) produces an estimated production rate (less spillage and other shrinkage) in excess of 600 kg/hr. The actual production rate will vary from this nominal figure, dependent upon ground conditions, including soil swell, decompaction due to disruption, and system limitations, such as available motor torque. The production rate was expected to be between 1,000 and 1,200 kg/hr. However, the bucket form factor was shrunken on two axes, reducing the volume to less than half of the original target. When the motor is upgraded, the projected estimates of regolith production should again exceed a metric ton per hour. The existing low-profile flanged button headed mounting bolts were too long by a convenient ¼” and were replaced by ½” long bolts. The current bolt length of ¾” causes interference between the bolt ends and the side structure plates of the excavator on the upper/taut side of the chain. These were originally designed to clear the sides, when the upper tensioning assembly was utilized in the system.

sysRAND Corporation

225


Figure 151 Curved, Serrated, and Basic Buckets, Realized The buckets are fabricated from industrial steel and have an unpainted, brushed steel finish that should not be painted. Operation of the excavator will quickly abrade the buckets of any superficial surface coating, such as paint or powder coat. In humid or water-rich environments (like Houston), buckets should be routinely sprayed with oil to prevent rust and corrosion. A bio-compatible oil commonly used in similar applications is fish-oil, WD-40, which also offers the convenience of an aerosol dispenser. Bucket Thickness The metal thickness for the bucket was set at 1/16th of an inch or 0.0625” (15-Gauge), a value determined by an informal study of several shovels and related tools and their applications. This thickness of metal provides substantial stiffness while still allowing for ease of construction, reducing the cost per unit, and is the standard for most commercially available high shock tools such as ice scrapers. The local Lowe’s hardware store in Parker, Colorado was particularly helpful in this effort. Bucket Effectiveness During test bed excavation, a series of buckets with differing cutting edges will be utilized. Besides the traditional flat cutting edge, a curved and a serrated edge will be tested. Notionally, the serrated cutting edge will be advantageous when making cuts into highly consolidated materials, as it allows initial penetration forces to be concentrated at only a few points and then uses crack propagation to complete the cut. The curved edge bucket, by contrast, is thought to be most effective in excavating looser regolith while minimize any pivot moments (e.g., torsion) due to “hang-ups” of the bucket during excavation, reducing both wear and the chance of chain derailment. This is due to the fact that the entire edge of the curve is tangent to the cutting edge, enabling slippage, thereby minimizing hang-ups even while cutting into the workface. A future instrumented version is intended to close off the front of the bucket with a shaped pressure plate and enclose other sensors, which transmit by wireless link to the control system.

sysRAND Corporation

226

Autonomy as an Operational Element of Planetary Surface Systems SPROCKET REDESIGN/TOUCH-UP TO MINIMIZE WEAR The first versions of the excavator’s sprockets were intended to test the durability of Aluminum and the feasibility of a lightweight sprocket. Follow-on work was planned that would carve out metal and so reduce device mass. As a test article the Aluminum sprockets were deliberately plated with a goldcolored anodize finish that was intended to provide a high contrast with the underlying bright Aluminum when scratched or abraded. This feature performed its function well and showed edge abrasion from the start. We anticipate the pending delivery of sprockets of a revised design intended to correct the indicated wear by incorporating a new tooth form, trough edge chamfering, and a mud groove at the base of the trough. The mud groove, used extensively in ATV and dirt bike sprocket applications, provides a clearance between the chain and sprocket for entrapped debris to clear. The new sprockets have been machined from 303 stainless steel alloy, allowing the sprocket hardness to be more closely matched to the pintle chain’s oil-quenched hardened steel, providing better wear characteristics between the two components during operation. The stainless steel 303 alloy also provides solid corrosion resistance while maintaining good machinability. The new sprockets will also resist rust, providing a reference toward deployment on Mars by residing in the humid climes of Houston and Cape Kennedy for a few years. The redesigned tension/idler sprocket design has been delivered to the machine shop; fabrication will follow the drive and forward sprockets.

Figure 152 Revised Tension, Drive and Forward Sprocket Designs (Color-Enhanced Features)

sysRAND Corporation

227


Figure 153 The Small Sprocket for the Chain Tensioner

Figure 154 Revised Forward Sprocket and Drive Designs in 303 Stainless Steel

sysRAND Corporation

228

Autonomy as an Operational Element of Planetary Surface Systems DUST AND ROCK MITIGATION AND EXPLOITATION Various elements of the excavator are intended to minimize the creation of dust, even while the excavator is being optimized for dust and volatile exploitation. Further efforts intend to minimize the penetration of pervasive and extremely abrasive dust into the interior (engineering spaces) of the excavator blade. Dust mitigation proceeds from the coarsest scale to the finest and consists of three principal measures. The first is notionally called “dust excluders,” the second are rings, and the last are seals. Dust Excluders are inserted into the voids that exist between the blade elements, and may be derived through two divergent CAD Tools methods. The first of these is a “volume pour” within a volume confined by the side structural panels and any intruding object within the volume, such as shafts and seals. The second approach is subtractive and establishes the boundaries of the void: Beginning with an inclusive space, points of interference, including axle and chain operation, assembly access, and similar intrusions, are successively removed, yielding the shape of the void. In either case, the remaining void then describes the block(s) of Delrin to be employed, and may be considered to be an extension of the Archimedes Principle of Buoyancy. Since the nose and stern assemblies differ, the Delrin excluders for each will also differ. Each will be split into two machinable pieces down the vertical bilateral line of symmetry of the excavator blade. The nose halves may be sufficiently similar, perhaps also being rotationally symmetric, and a single design may serve both sides. The axles of the blade’s nose and stern are areas identified as the most susceptible to abrasive wear and interference issues from the excavated material (abrasive dust), along with the chain and bucket edges.

Figure 155 The Nose Mount Depicting the Concentric O-Ring The second layer of dust mitigation is evidenced by the circular channels around the hub on either side of the front sprocket assembly, which are provisions for a backer ring and o-ring to seal the hub/bearing assembly. The selected o-ring materials are polyurethane and Polythrafluoroethylene (PTFE), for their excellent wear and tearing resistance. Each of these o-ring materials will be tested in digging operations and their performance reviewed, determining the final material to be used in the prototype. The third protection against dust is the double-sealed bearings which are mounted on the axles of the front, drive, and tensioning sprockets.

sysRAND Corporation

229

Autonomy as an Operational Element of Planetary Surface Systems GRC SANDBOX TEST FIXTURE Design of Adjustable Laboratory Excavator Mount The Adjustable Laboratory Excavator Mount was placed on hold while mounting options were being sorted out by various NASA ISRU managers. Due to the current unavailability of mobility platforms, sysRAND decided to target the Lunar Soil Test Bench at the Glenn Research Center’s Lunar Soils Laboratory as the location for mounting and testing the Excavator Blade. We are pleased that Glenn concurs and is willing to host our excavator at their test facility. The preliminary design of the mounting hardware attaches the Excavator Blade to the Glenn Research Center’s Lunar Soils Test bed. The blade itself will pivot on a main rotational joint located at the system’s center of mass, i.e., 25.2 inches from the rear. This joint is designed to incorporate the future placement of a brushed slip ring assembly that will provide power and data flow to the excavator. A secondary joint, located approximately 9 inches from the rear, will provide the rotary actuation to the excavator. The main pivot joint and secondary actuator arms will be attached to support arms (located on both sides of the excavator) consisting of a structural C-channel beam. This beam will terminate into an adaptor plate that will interface with the Glenn Research Center’s test bed load cell assembly. The adjustable mechanical struts of the adapter have been replaced with two threaded jackscrew actuators for a fraction of the cost of fabricating the “U” shaped tubing. Conveniently, the actuators operate with 12VDC power, making them compatible with most deployment options.

Figure 156

Adjustable Laboratory Excavator Mounting for the GRC Sandbox

The excavator will be attached to the mounting as depicted in Figure 157. The offset of the pitch actuators from the primary mounting port is at a point approximately 60/40 between the nose and stern, and is very close to the center-of-gravity (balance point) of the blade. The C/G is expected to move around from time to time as adjustments and enhancements are made to the basic design.

sysRAND Corporation

230


Figure 157

The Excavator Mounted aboard the GRC Adapter

Construction of GRC Mount Many of the fittings required to mount the Excavator Blade were adapted from existing sprocket hardware, minimizing the lead times and costs of fabricating new parts, especially setup costs.

sysRAND Corporation

231

Autonomy as an Operational Element of Planetary Surface Systems TUG JR., THE LITTLE RED MOBILITY PLATFORM

Figure 158 Factory-Available Single-Axle Trailer Kit The MPED team was determined to deliver a serviceable, and testable excavator system. Since no mobility platform was available the team chose to build a compact mobility platform, initially without automation or propulsion. A towable platform in the form of a trailer seemed to meet our needs, and simple web searches turned up a number of trailer kits. For orientation, conventional front-and-back, right-and-left references are used when regarding the platform as a trailer, to be towed. In it’s role as an excavation platform, references of nose-and-aft, portand-starboard are used to remove ambiguity. There can be confusion here since the towing position is 180° contrary to the excavation position, and the latter is the one that we care about.

Figure 159 The Tandem Trailer Assembled from Two Kits

sysRAND Corporation

232


Figure 160 Another View of the Open Frame, where Springs and Axles are Visible A single axle trailer was an early option, yet evaluating operating modes suggested that problems would surface, many of which were related to extreme displacements of centers-of-gravity. Tandem trailers are only available as axle kits, and all of the remaining hardware has to be user-provided. Our instincts were generally correct, and we were able to shift the axle back and insert another axle from the second kit. This modification predictably meant that many of the pre-drilled bolt holes were no longer correctly positioned, so that a number of additional bolt holes were drilled and other adaptations were necessary. Other advantages of a second kit is that we have some spare parts: wiring harness, lights, reflectors, mounting hardware, etc. We must admit that we do have some sparing that may not ever be used, unless we have to rebuild the frame. We have fewer spare frame parts than we expected because we chose to add two additional cross-members to reinforce the frame supporting the deck plate. These additional beams are visible at the frame’s quarter points, in Figure 159, Figure 160 or Figure 161. It is also clear from these images that the tires are pneumatic, providing additional cushioning to the platform both on and off-road. The pneumatic tires will perform better off-road than a similar-sized solid rubber wheel. Each wheel has a Zert for injecting grease for lubrication of each individual wheel. These Zerts are located on the lower-inside of each wheel on the axle/wheel bearing housing. One of the other reasons for implementing a tandem axle was to reduce the area loading of the tires without having to upgrade to larger wheels and tires, or construct “dualies.” The trailer needs to travel well on the highway, and yet be able to traverse unpaved terrain. The many nuts and bolts of the trailer are possible points of failure that will be serviced with Lok-Tite or other thread-locking fluid. This treatment would be in addition to the production nylon lock nuts. Also observe in Figure 160 that the cabling remains outside of structural parts and does not get routed through drill holes and punchouts. This allows the frame to be partially disassembled without interference from the cabling. The ball socket of the hitch has is a receiver for a 1-7/8” towing ball, providing a nominal 1,500 pound towing capacity. Unfortunately, the most common small ball hitch is a 2” ball, which has a 2,000 pound towing capacity rating. A replacement 2” ball receiver will be ordered and mounted on the trailer for the widest compatibility with towing vehicles.

sysRAND Corporation

233

Autonomy as an Operational Element of Planetary Surface Systems Visible on the tongue is a VIN (Vehicle Identification Number) and trailer load certification plate. We await receipt of paperwork that will allow us to register for the trailer’s license plate and title. The visible wiring harness uses the standard trailer/vehicle electrical connection to provide working brake and parking lights on the trailer. Due to the addition of the forward wheel/axle/fender assembly, the factory amber side marker light mounting location was lost. A replacement amber reflector was placed on the side of the forward fender and a three-dimensional amber light/reflector unit placed on top of the forward fenders to compensate for this complication. The rear red taillights provide both parking and braking/signaling capabilities. The left rear taillight also serves as a holder and illumination unit for the trailers license plate – in a fashion similar to the plate mountings on CJ and Wrangler Jeeps.

Figure 161 The View from Aft Starboard Quarter, Showing the Tongue

Figure 162 View Forward from Below the Nose

sysRAND Corporation

234

Autonomy as an Operational Element of Planetary Surface Systems Not installed or pictured is the excavator system power/control wiring harness which will be electrically separate, including grounds, from the trailer/vehicle lighting harness. This system will include the onboard trailer batteries, a 12VDC-to-24VDC inverter, fuses, “emergency stop” push buttons and excavator/mounting/control pendant system itself. 1/8” thick Aluminum diamond plate was chosen for decking material, akin to the TUG mobility platform concept model, showcased in Figure 163 through Figure 165. The larger, rear plate is secured to the trailer using the existing frame hardware with the addition of rubber washers sandwiching the diamond plate. Longer mounting bolts will allow the plate to ‘float’ and help alleviate any stresses/strains in the trailer from uneven ground contact, bumps, and vibrations. Due to the relative thin-ness of the Aluminum deck plate, which was the thickest we could obtain at the sizes we required, a backer plate of steel will be used underneath the excavator mount for stability and hardware security. The forward, smaller diamond plate section will be hinged, allowing access to a yet-to-be-built compartment below the trailer that will house the excavator batteries, inverter and other miscellaneous gear. The plate door will be hinged at the front, using friction hinges to keep the door open at any angle, and a magnetic latching system to keep the door closed. A spring-loaded snap-down handle will be installed on the plate for ease of entry. One of the benefits of locating the lab at Centennial Airport is that when we needed to “chock” the wheels, we had a choice of two pilot shops on the field. The chocks are charged with keeping the sharp corners of the trailer out of the drywall. The gel cell (lead acid) batteries are sitting on the deck to help keep a reasonable center-of-gravity (C/G). They are 12 Volt batteries, each rated at 26 Amp/Hr.

Figure 163 Fitting the Diamond Plate Deck

sysRAND Corporation

235


Figure 164 The Deck fits, Leaving a Gap for the Battery and Electronics Bays

Figure 165 The Diamond Plate Deck Extends Over the E-Bay with a Hinged Panel

sysRAND Corporation

236


Figure 166 Forward Starboard View of Blade and Adapter

Figure 167 The Fixed Adapter Mounts on Dummy Load Cells Linear Actuators are used to Adjust Blade Pitch

sysRAND Corporation

237


Figure 168 Port View of Blade and Mobility Platform Proxy

sysRAND Corporation

238


Figure 169 Pitch Actuators and Adapter Mounting via Load Cells

Figure 170 Aft View of Excavator Blade and Mount w/o Pitch Actuators

sysRAND Corporation

239

Autonomy as an Operational Element of Planetary Surface Systems APPENDIX F: GLOSSARY 2DOF

Two Degrees of Freedom

6DOF

Six Degrees of Freedom

A/TPS/A

Arm/Turret Positioning Sensors/Actuators

ADCS

Attitude Determination and Control System

AFC

Auxiliary Function Control

AGSP

Aggressive Goal-Seeking Program

AI&T

Automated Integration and Test

AIDE

Applications-Oriented Integrated Development Environment

AOR

Angle of Repose

AP

Application Processor

API

Application Program Interface

ASIM

Appliqué Sensor Interface Module

ASIM

Application-Specific Interface Module

ASME D662 ASME Pintle Chain Specification ATHLETE

All-Terrain Hex-Legged Extra-Terrestrial Explorer

BLE

Bucket Ladder Excavator

C&DH/S&F Command Data and Handling/Store-and-Forward CA

Critical Angle

CANbus

Controller Area Network bus

CCN

Cross-Country Navigation

CCSDS

Consultative Committee for Space Data Systems’ Spacecraft Onboard Interface Services

CEB

Chainless Excavator Blade

CNC

Computerized Numerical Control

COMM

Communications

CONOPS

Concept of Operations

COTS

Commercial, Off-the-Shelf

CS

Combustion Synthesis

sysRAND Corporation

240

Autonomy as an Operational Element of Planetary Surface Systems CS Fabric

Combustion Synthesis Fabric

DME

Distance Measuring Equipment

DOF

Degree of Freedom

DSB

Dedicated Service Bus

EWO

Electronic Work Order

FFT

Fast Fourier Transform

FSM

Finite State Machine

FTBES

Front-to-Back Excavator System

GNAV

Guidance and Navigation System

GTA

Generic Tool Application

HMDS

Hopper Motor Drive System

ICD

Interface Control Document

IO

Input/Output

IRAD

Internal Research and Development

ISRU

In-Situ Resource Utilization

IV&V

Independent Validation and Verification

JTAG

Joint Task Action Group

K-1

Chain link platform per ASME D662 specification

LOS

Loss-of-Signal

MCCR

MetaCode Capture and Recording

MILS

Man-In-the-Loop Simulation

MPED

Multi-Purpose Excavator Demonstrator

MST

Modular Smart Tools

NOM

Nominal value

NRE

Non-Recurring Engineering costs

NSP

Network Service Provider(s)

PAYLD

Payload Manager

PCI

Peripheral Component Interconnect

sysRAND Corporation

241

Autonomy as an Operational Element of Planetary Surface Systems PHY

Device operating at the physical layer of an OSI model

PIC

Pilot in Command

PID

Proportional Integral/Derivative Servo Control Loop

PMAD/TMS Power Management and Distribution/Thermal Management System PROP

Propulsion

PTO

Power-TakeOff

PTP

Point-to-Point

Pt2Pt

Point-to-Point

RCS

Revision Control System

RDM

Remote Debug Monitor

RF

Radio Frequency

RMP

Robotic Mobility Platform

RT

Real Time

RSA

Radioisotope Sterling Alternator

SARS

Synthetic Aperture RADAR System

SDM

AFRL’s Satellite Data Model

sIDEbus

sysRAND’s Diagnostic Services Bus

sIDEreal

sysRAND Integrated Development Environment for REALtime systems

sIDEreal netOS sIDEreal Network Operating System singularity

A tool position that inhibits freedom of motion and should be avoided

SOA

Service-Oriented Architecture

SpaceWX

Space Weather

SPA-E

Space Plug and Play Avionics, Ethernet-Based

SPA-U

Space Plug and Play Avionics, USB-Based

TCAS

Traffic Collision Avoidance System

THERM

Thermal Management

TRL

Technological Readiness Level (NASA-defined)

TUG

Notional multi-purpose mobility platform (e.g., for MPED)

sysRAND Corporation

242

Autonomy as an Operational Element of Planetary Surface Systems TURRET

Modular tool, enhanced robotic arm

UAV

Unmanned Aerial Vehicle (Remotely Piloted Vehicle)

UTC

Universal Tool Coupling

UTMR

Universal Tool Mount and Ring

VHDL

Very High Speed Description Language

VME

Virtual Machine Environment

WDT

WatchDog Timer

xTEDS

XML-Based Transducer Electronic Data Sheet

sysRAND Corporation

243


Illustrations Figure 1 Autonomous Platforms should be Self-Directing by Definition ...................................................... 6 Figure 2 Formations of TUGS Collaborate .................................................................................................. 9 Figure 3 Scaling Excavator Applications .................................................................................................... 11 Figure 4 Simulation Rendering of the Excavator Contact Aspect .............................................................. 12 Figure 5 Rendering Physics Simulation Profile .......................................................................................... 12 Figure 6 Step-trenching to Imbed a Habitat of 20 Units Diameter ............................................................. 13 Figure 7 A Drag-Rake without Prongs ....................................................................................................... 13 Figure 8. The Volume of Excavated Regolith at the Habitat’s Equator ..................................................... 14 Figure 9. Berms can be Reinforced with Combustion Synthesis Fabric .................................................... 15 Figure 10 A CS Fabric Dispenser Works with Other TUGs ....................................................................... 15 Figure 11 Contoured Berms can Deflect Lander Exhaust Plume and Debris ........................................... 15 Figure 12 Deflection Berms Have the Effect of a Large Berm ................................................................... 16 Figure 13 Early Deflection Berm Simulation Program Output ................................................................... 16 Figure 14 A Low-Energy Disposal Method for Rocks ................................................................................ 17 Figure 15 Bulk Mining of the Maria Could Alter the Lunar Albedo ............................................................. 20 Figure 16 Mini-SAR CPR (RADAR) Imaging of the Moon's Northern Hemisphere ................................... 21 Figure 17 A Mineshaft can be Established on the Interior Slope of a Crater............................................. 22 Figure 18 Conceptual Excavator Nose with Sprocket ............................................................................... 25 Figure 19 Actual Excavator Nose with Sprocket (K-1 Platform visible) ..................................................... 26 Figure 20 Modular Motor Mount and Rear Drive Sprocket ........................................................................ 26 Figure 21 Terms that Apply to the Excavator Blade .................................................................................. 27 Figure 22 Design of the Chain Motor Mount .............................................................................................. 27 Figure 23 The Blade Pendant Controller with Test Fixture ........................................................................ 28 Figure 24 The Mounting of the Turret is Versatile ..................................................................................... 29 Figure 25 A Shoulder-mounted Pivot Helps to Provide Leverage ............................................................. 30 Figure 26 Universal Tool Interfaces Scale to Phi Ratio (1.6180/0.6180) ................................................... 31 Figure 27 Concept Drawing of a Chainless Excavator Blade .................................................................... 32 Figure 28 Deck Hardpoints Support Diverse Modular Tools ..................................................................... 32 Figure 29 ATHLETE in a photogenic pose ................................................................................................ 33 Figure 30 Front Quarter view of JSC’s Chariot .......................................................................................... 33 Figure 31 Starboard view of Chariot .......................................................................................................... 34 Figure 32 NORCAT's HOBO Mobility Platform .......................................................................................... 34 Figure 33 A Notional TUG with an Excavator Blade Attached to the Forward Mount ............................... 35 Figure 34 A TUG with an Excavator Blade Mounted Fore and a Hopper Mounted Aft ............................. 36 Figure 35 Tug with Excavator, Turret and Hopper ..................................................................................... 36 Figure 36 Tug with Crane on Mid-deck Mount ........................................................................................... 37 Figure 37 Tug with Star Hammer Drill in Forward Position ........................................................................ 37 Figure 38 Tug with Cherry-Picker on Mid-deck Mount .............................................................................. 37 Figure 39 A Stacked Alternate Hopper Configuration ................................................................................ 38 Figure 40 An Engaging Logo has been Developed for TUG Marketing .................................................... 38 Figure 41 A Centaur Delivers four TUGs to the Moon, Selected Frames ................................................. 39 Figure 42 A Clean View of the Mule .......................................................................................................... 40 Figure 43 The Huey, Gun Emplacement, and Mule, circa, VietNam Era .................................................. 40 Figure 44 The RDS Prowler Starred in a Chuck Norris Movie "Code of Silence" ..................................... 41 Figure 45 A Contemporary Robotic Combat Platform Concept ................................................................. 41 Figure 46 An Early, Notional Excavator Platform at Work ......................................................................... 44 Figure 47 Conceptual Control Zones including Worksites ......................................................................... 48 Figure 48 Outpost Schematic Depicting Features ..................................................................................... 49 Figure 49 Types of Worksite Access ......................................................................................................... 50 Figure 50 A Representative Worksite Layout Installing a Utilities Trench ................................................. 50 Figure 51 A Layered Control Structure ...................................................................................................... 52 Figure 52 Basic TUG Loading Service Loop.............................................................................................. 54 Figure 53 Basic TUG Unloading Service Loop ......................................................................................... 55

sysRAND Corporation

244

Autonomy as an Operational Element of Planetary Surface Systems Figure 54 TUGs can form a Train to Save Power ...................................................................................... 55 Figure 55 Representative Excavator Sweep Patterns ............................................................................... 56 Figure 56 A Representative Plane of the Excavator's Work Volume......................................................... 57 Figure 57 Example of the Digital Space Visualization / Simulation ........................................................... 59 Figure 58 DOFs with Labels and Principal Attributes ................................................................................ 60 Figure 59 A Closeup View of the Blade Depicts an Instrumented Bucket ................................................. 65 Figure 60 The Nose of the Blade Contacts the Surface ............................................................................ 66 Figure 61 A Head-on View of the Blade with respect to the TUG.............................................................. 67 Figure 62 A Starboard Aspect of a Blade Digging ..................................................................................... 67 Figure 63 A Typical Angle-of-Attack for the Blade ..................................................................................... 68 Figure 64 The Turret Connects the Blade and Discharge Chute to the Hopper........................................ 68 Figure 65 Operations Require Extension of the Turret Arm’s Range of Motion ........................................ 69 Figure 66 The Turret Viewed from the Hopper's Position .......................................................................... 69 Figure 67 Hardware is “Shadowed” by the DS Simulator Enhancing Design Fidelity ............................... 70 Figure 68 Operator Inputs are Translated into Command Scripts ............................................................. 71 Figure 69 Arc Steering ............................................................................................................................... 72 Figure 70 Apparent Crab Effect Made Coherent ....................................................................................... 74 Figure 71 Skew Steering ............................................................................................................................ 75 Figure 72 Pivot Steering............................................................................................................................. 75 Figure 73 A More Accurate Turret Arm Extension Features a Tubular Shaft with a Fork .......................... 76 Figure 74 Pintle Chain Links ASME D-662 ............................................................................................... 77 Figure 75 Autonomy Capability Increases with Experience....................................................................... 81 Figure 76 Degrees of Freedom for the Excavator Blade ........................................................................... 85 Figure 77 Concise Definition of Robotics Terms ...................................................................................... 86 Figure 78 Each Modular Device Represents Recursions into Finer Precision ......................................... 88 Figure 79 The Tug, Turret, and Tool Modules are Recursively Defined .................................................... 88 Figure 80 Range of Motion and Energy Spans Stepwise from Coarse to Fine ......................................... 89 Figure 81 A Vivid Image of Nested Matryoshka Dolls ............................................................................... 90 Figure 82 Limits and Interferences are Tested Before Motion Commences ............................................. 90 Figure 83 The TUG's Attitude and Navigational Axes ............................................................................... 91 Figure 84 Mirrored Ackerman Steering of the TUG for the Tightest Turn Radius ..................................... 92 Figure 85 Combined DOFs for Turret Articulation ..................................................................................... 93 Figure 86 Execution Contexts for Process and Data ................................................................................. 95 Figure 87 A Recursive Process Cell supports Maneuvering ..................................................................... 99 Figure 88 Initial Position ........................................................................................................................... 102 Figure 89 Transform, Complementing Pitch Angles ................................................................................ 102 Figure 90 Transform, Exchanging Yaw Angles while Splitting Pitch Angles ........................................... 103 Figure 91 System Block Diagram ............................................................................................................ 104 Figure 92 Function Module Partitioning and Corresponding DOFs ......................................................... 105 Figure 93 A Maximal, but not Practical, Scanning Flow Featuring Three Excavators ............................. 106 Figure 94 A Practical Ensemble of a TUG, Excavator, Hopper and Tandem TUG ................................. 107 Figure 95 Polar Coordinates with Corresponding Cartesian Coordinates ............................................... 109 Figure 96 Work Volume Described by Various Coordinate Reference Systems..................................... 110 Figure 97 The TUG Principal Coordinate Frame (Origin O ) ................................................................... 112 Figure 98 Three Powered Hardpoints are Located at Quartered Intervals on the Deck ......................... 113 Figure 99 Turret (Hardpoint) Rotational Axis .......................................................................................... 119 Figure 100 Fixed Pivot Displacement from the rotary Hardpoint ............................................................ 120 Figure 101 Turret Pitch Pivot and Arm Reach ......................................................................................... 122 Figure 102 The Variable Length of the Arm May be Simplified as the Hypotenuse ................................ 124 Figure 103 Pitch Pivot on Excavator Port with both Fore (ρf) and Aft (ρa) Extent.................................... 124 Figure 104 Excavator Operations will Traverse the Statespace .............................................................. 129 Figure 105 Platform Operations Lifecycle FSM ....................................................................................... 130 Figure 106 Our Notional Load Model is Phi-Ratio-based ........................................................................ 134 Figure 107 Stirling Radioisotope Alternator Block Diagram..................................................................... 136 Figure 108 Recursive Construction of Mission Structure ......................................................................... 138 Figure 109 sIDEreal’s Spacecraft Network Model ................................................................................... 140

sysRAND Corporation

245

Autonomy as an Operational Element of Planetary Surface Systems Figure 110 Figure 111 Figure 112 Figure 113 Figure 114 Figure 115 Figure 116 Figure 117 Figure 118 Figure 119 Figure 120 Figure 121 Figure 122 Figure 123 Figure 124 Figure 125 Figure 126 Figure 127 Figure 128 Figure 129 Figure 130 Figure 131 Figure 132 Figure 133 Figure 134 Figure 135 Figure 136 Figure 137 Figure 138 Figure 139 Figure 140 Figure 141 Figure 142 Figure 143 Figure 144 Figure 145 Figure 146 Figure 147 Figure 148 Figure 149 Figure 150 Figure 151 Figure 152 Figure 153 Figure 154 Figure 155 Figure 156 Figure 157 Figure 158 Figure 159 Figure 160 Figure 161 Figure 162 Figure 163 Figure 164 Figure 165

The TUG has Functions Identical or Similar to Orbiting Spacecraft ..................................... 141 The Modular Tool Subsystem with Redundant SPA-E Links ................................................ 142 The Tool Positioning Subsystems Support Sensors and Actuators ...................................... 143 Electrodynamic Proximity-sensing Whiskers sketched onto the Blade ................................. 144 Additional Whiskers sense the Ambient ES Field.................................................................. 145 Example 3-Axis Accelerometer Utilizing MEMS Technology ............................................... 145 Modulated LEDs Confirm Servo Positioning through Video Processing ............................... 146 Stereo Image Integration and Ranging .................................................................................. 147 Elements Leading to Autonomy and Group Operations ........................................................ 149 Principal Elements of Goal-seeking Path .............................................................................. 153 Midpoints and Waypoints are Recursively Invoked ............................................................... 153 Second Tier Midpoint Fails to Complete ................................................................................ 153 A Second-tier Midpoint Identifies a Conclusion ..................................................................... 153 Additional Paths are Found by Expansion ............................................................................. 154 Excavator Sweep Patterns (Port to Starboard Addressing Workface) .................................. 164 Formal Languages and Their Ontological and Epistemological Commitments ..................... 168 Testing Regimes can Create Learning Opportunities (new rules) in Simulation ................... 176 Fuzzy Logic Controller Block Diagram .................................................................................. 178 Modern Japanese version of the Semantic Differential ......................................................... 180 Abstraction of a PID Controller .............................................................................................. 181 A Conventional Robot Servo Control ..................................................................................... 181 An Integrated Fuzzy Motion Controller .................................................................................. 182 Partitioning of Motion FLC to Extract Redundant Hardware ................................................. 182 Basic Spacecraft Modular Functions Augmented to Support Fuzzy Logic Methodologies ... 187 A Scripted Command Parser / Sequencer is Imbedded in the C&DH................................... 188 The Command Stream has Access to the Rule Base ........................................................... 189 Data Fusion Presents Information to the Spacecraft ............................................................. 190 Machine Learning Completes the Autonomous System ....................................................... 191 Each Servo Controller is a Recursive Process Cell............................................................... 192 Sparse Networks of Swarm Exist .......................................................................................... 205 Swarm is a Dynamic and Transitory Synthesis of Autonomy and Collaboration ................. 205 The Dispassionate TUG isn’t enough of a Poet to Appreciate the Home Planet .................. 209 Metacode Support for the Mission ......................................................................................... 217 FDRs Sense Things in Realtime............................................................................................ 218 Metacodes are Classified by Urgency and Criticality ............................................................ 219 Raw Fiberglass and Simulated Unfired (Green) CS Fabric ................................................... 222 Most Recent Blade Modifications .......................................................................................... 223 Excavator Blade on Static Display, Starboard View ............................................................ 224 Excavator Blade on Static Display, Port View ...................................................................... 224 Next Shock Strut Mounting Concept ................................................................................... 225 Basic, Curved, and Serrated Buckets, CAD Images ............................................................ 225 Curved, Serrated, and Basic Buckets, Realized.................................................................... 226 Revised Tension, Drive and Forward Sprocket Designs (Color-Enhanced Features) ......... 227 The Small Sprocket for the Chain Tensioner......................................................................... 228 Revised Forward Sprocket and Drive Designs in 303 Stainless Steel ................................. 228 The Nose Mount Depicting the Concentric O-Ring .............................................................. 229 Adjustable Laboratory Excavator Mounting for the GRC Sandbox ................................... 230 The Excavator Mounted aboard the GRC Adapter............................................................ 231 Factory-Available Single-Axle Trailer Kit ............................................................................... 232 The Tandem Trailer Assembled from Two Kits ..................................................................... 232 Another View of the Open Frame, where Springs and Axles are Visible .............................. 233 The View from Aft Starboard Quarter, Showing the Tongue ................................................. 234 View Forward from Below the Nose ...................................................................................... 234 Fitting the Diamond Plate Deck ............................................................................................. 235 The Deck fits, Leaving a Gap for the Battery and Electronics Bays ...................................... 236 The Diamond Plate Deck Extends Over the E-Bay with a Hinged Panel .............................. 236

sysRAND Corporation

246

Autonomy as an Operational Element of Planetary Surface Systems Figure 166 Figure 167 Figure 168 Figure 169 Figure 170

Forward Starboard View of Blade and Adapter ..................................................................... 237 The Fixed Adapter Mounts on Dummy Load Cells ................................................................ 237 Port View of Blade and Mobility Platform Proxy .................................................................... 238 Pitch Actuators and Adapter Mounting via Load Cells .......................................................... 239 Aft View of Excavator Blade and Mount w/o Pitch Actuators ................................................ 239

sysRAND Corporation

247


Tables Table 1 Proposed Compact Codespace for Metacodes .......................................................................... 220

sysRAND Corporation

248


sysRAND Corporation

249