CHARACTERIZATION of ON-ORBIT ROBOTIC ASSEMBLY of SMALL SATELLITES by Ezinne Uzo-Okoro B.Sc., Rensselaer Polytechnic Institute

CHARACTERIZATION OF ON-ORBIT ROBOTIC ASSEMBLY OF SMALL SATELLITES

Ezinne Uzo-Okoro

B.Sc., Rensselaer Polytechnic Institute (2004) M.Sc., Johns Hopkins University (2009)

Submitted to the Program in Media Arts and Sciences, School of Architecture and Planning, in partial fulfillment of the requirements for the degree of

Master of Science

at the Massachusetts Institute of Technology May 2020

Author ……………………………………………………………………………………………………… Program in Media Arts and Sciences May 8, 2020

Certified by ……………………………………………………………………………………………………… Joseph Paradiso Alexander W. Dreyfoos (1954) Professor, Media Arts and Sciences

Accepted by ……………………………………………………………………………………………………… Tod Machover Academic Head, Program in Media Arts and Sciences

CHARACTERIZATION OF ON-ORBIT ROBOTIC ASSEMBLY OF SMALL SATELLITES

Ezinne Uzo-Okoro

Submitted to the Program in Media Arts and Sciences, School of Architecture and Planning, on May 8, 2020, in partial fulfillment of the requirements for the degree of

Master of Science

Abstract:

On-orbit assembly missions typically involve humans-in-the-loop and use large custom-built robotic arms designed to service existing modules. The concept of on-orbit robotic assembly of modularized CubeSat components supports use cases such as rapidly placing failed nodes within a constellation of satellites and monitoring damaged assets in Low Earth Orbit. Despite the recent proliferation of small satellites, there is a lack of planned demonstrations of spacecraft manufactured through the on-orbit assembly as well as the servicing of small satellites in space. Key gaps limiting in-space assembly of small satellites are (1) the lack of standardization of electromechanical CubeSat components for compatibility with commercial robotic assembly hardware, and (2) testing and modifying commercial robotic assembly hardware suitable for small satellite assembly for space operation.

Working towards on-orbit robotic assembly, we report on progress addressing both gaps. Toward gap (1), the lack of standardization of CubeSat components for compatibility with commercial robotic assembly hardware, we have developed a ground-based robotic assembly of a 1U CubeSat using modular components and Commercial-Off-The-Shelf (COTS) robot arms without humans-in-the-loop. Two 16 in x 7 in x 7 in dexterous robot arms, weighing 2 kg each, are shown to work together to grasp and assemble CubeSat components into a 1U CubeSat. We assess performance for a subset of five commercial robotic arm sensors and find the force-torque (FT) sensor as the most efficient sensor for use at the end-effector and brushless motors as the best sensor for use at other joints. We report on the feasibility of sensing and grasping CubeSat components robotically, while using Inverse Kinematics to target, position and maneuver the robot arms. Addressing gap (2) in this work, solutions for adapting power-efficient COTS robot arms to assemble highly-capable radiation-tolerant CubeSats are examined. We also analyze the systems engineering process for in-space CubeSat robotic assembly systems. Lessons learned on thermal and power considerations for overheated motors and positioning errors were also encountered and resolved. We find that COTS robot arms with sustained throughput and processing efficiency have the potential to be cost-effective for future space missions. Thesis Advisor: Joseph Paradiso Alexander W. Dreyfoos (1954) Professor, Media Arts and Sciences

CHARACTERIZATION OF ON-ORBIT ROBOTIC ASSEMBLY OF SMALL SATELLITES

Ezinne Uzo-Okoro

This thesis has been reviewed and approved by the following committee members

Joseph Paradiso ……………………………………………………………………………………………………… Alexander W. Dreyfoos (1954) Professor, Media Arts and Sciences Director, Responsive Environments Group

Kerri Cahoy ……………………………………………………………………………………………………… Director, Space Telecommunications Astronomy Radiation Laboratory Associate Professor of Aeronautics and Astronautics

Daniel Hastings ……………………………………………………………………………………………………… Cecil and Ida Green Professor Aeronautics and Astronautics Department Head

Acknowledgments I thank Kerri Cahoy for being a guiding force, for her mentorship, patience, tireless advocacy, generous support, and brilliant insights during the uphill climb from idea to implementation. I complete this work, grateful for the privilege of having worked with her.

Many, many thanks to Joe Paradiso for his grace and flexibility. I thank Dan Hastings, whose guidance and support of this work provided immense validation.

I thank Joe Parrish and Neil Gershenfeld for showing interest in my research and providing helpful direction.

Linda Peterson is the solution-finder who cared and for that I am grateful. Joost Bonsen’s advice led to funding and Tod Machover’s leadership set a particularly helpful tone.

I thank Marc Murbach and Chad Frost, whose insights have elevated this work.

I thank everyone, including The Legatum Center team and fellow STARLab team members: Paul Serra, Christian Haughwout, Paula do Vale Pereira, Mary Dahl, and Emily Kiley, whose support propelled this work forward. I thank classmates Prakash Manandhar and Dan Erkel.

I thank the brain trust, who endure countless calls and emails with kindness, and uplifting positivity.

I thank my parents and siblings for their consistent love.

I thank my dear family: my husband for his encouragement and my nine-month-old son for his patience with all the robot tests, and being incredibly manageable during the last 18 months.

Contents 1 Introduction 7 1.1 Motivation and Background 7 1.2 Organization 9 1.3 Contribution 10

2 Systems Engineering of On-Orbit Assembled Small Satellites 10 2.1 Introduction 10 2.2 Development Approach 10 2.2.1 Spacecraft “Locker” System 10 2.2.2 Modular CubeSat Subsystems 13 2.2.2.1 Interfaces 14 2.2.2.2 Avionics 16 2.2.2.2.1 Modularized Boards 16 2.2.2.2.2 Microcontroller 17 2.2.2.2.5 Fasteners 17 2.2.2.3 Attitude Determination and Control 18 2.2.2.4 Thermal 19 2.2.2.5 Electrical Power System (EPS) 19 2.2.2.6 Propulsion 19 2.2.2.7 Telecommunications 20 2.2.2.8 Ground Station 20 2.2.2.9 Payload 21 2.2.3 Assembly, Integration and Test Processes 21 2.2.4 Launch Accommodations 22 2.3 Observations 24 2.4 Summary 25

3 Feasibility of COTS Robot Arms In Space 26 3.1 Introduction 26 3.2 COTS Robot Arm Flight Heritage 26 3.3 Robot Arms for Assembly 28 3.3.1 Selection and Timing 28 3.3.2 Design Optimization and Modeling 32 3.3.2.1 Optimization Modules 33 3.3.2.2 Genetic Algorithm 35 3.3.2.3 System Variables 35 3.3.2.4 Assembly Time Feasibility 36 3.3.3 Design of Experiments (DOE) 37

3.4 Observation 38 3.5 Summary 40

4 Robotic Assembly of a 1U CubeSat 42 4.1 Introduction 42 4.2 Ground-Based Robotic Assembly 42 4.2.1 Robot Arm Sensor Evaluation 42 4.2.2 Approach 43 4.2.3 Implementation 46 4.2.3.1 Mechanical Workmanship 47 4.2.3.2 Robotic Algorithm 48 4.3 Observations 50 4.4 Summary 52

5 Summary and Future Work 52 5.1 Summary 52 5.1.1 Flight Hardware Selection 53 5.1.2 Implications for In-Space Manufacturing 53 5.1.3 Relevance and Benefits 54 5.2 Future Work 56 5.2.1 Optimization Analyses for Assembled CubeSats 56 5.2.2 Spacecraft Development Process 56 5.2.3 Space Qualification 57

6 References 58

Appendix 65 LewanSoul xArm Robot User Manual and Data Sheet 65

1 Introduction

1.1 Motivation and Background

Today, as space becomes more accessible, there is a lack of affordable on-demand capability to address multiple government [1] and commercial constellation needs for on-orbit servicing and assembly. The industry’s first satellite life extension vehicle, Northrop Grumman’s Mission Extension Vehicle-1 (MEV-1), completed its first docking to a client satellite, Intelsat IS-901 on February 25, 2020. MEV-1 is designed to dock to geostationary satellites whose fuel is nearly depleted and does not make use of robot arms for its on-orbit servicing mission [2]. On-orbit robotic assembly to date is costly, as evidenced by prior and current missions [3]. For example, the Defense Advanced Research Projects Agency (DARPA) Robotic Servicing of Geosynchronous Satellites (RSGS) $400M program aims to demonstrate that a robotic servicing vehicle can perform safe, reliable, useful and efficient operations in or near the Geosynchronous Earth Orbit (GEO) environment. RSGS is using the custom-developed and large radiation-hardened Front-end Robotics Enabling Near-term Demonstration (FREND) robot arm, which is a 1.8 m arm from shoulder pitch to wrist pitch weighing 78 kg, with an additional 10 kg for electronics.

The need for low-cost, low-latency and agile space infrastructure, which can reach strategic orbits such as GEO and Low Earth Orbit (LEO) in addition to polar and International Space Station (ISS) locations, could be realized using a robotic assembly of modularized components into CubeSats. A standardized modular CubeSat and COTS-based robotic assembly could break the reliance on high-risk, high-latency, high-cost legacy space hardware. Satellite cellularization [4][5][6][7] has made incremental advances in the modularization of small satellite subsystems. However, this thesis explores a new approach to CubeSat production based on the robotic assembly of functional spacecraft components.

We envision a new mission in which small COTS robot arms are enclosed in a free-flying small spacecraft “lockers” of approximately 24 inches x 36 inches x 12.5 inches for the assembly of a new standard of small satellites. These mini-fridge-sized spacecraft “lockers” with propulsion capability are intended to be orbit-agnostic in order to deploy on-demand robot-assembled CubeSats where needed. The locker, as described in Section 2, holds robotic arms, modular components including sensor and propulsion modules, and payloads for 1U to 3U-sized CubeSats. The mission is expected to deliver an unprecedented improvement in response time from >30 days to less than 10 hours for a small satellite build and deployment cycle.

This robotic-assembly based mission using propulsive “lockers” could help create a resilient platform capable of rapidly assembling and deploying scalable space systems faster than NASA’s documented minimum launch-on-demand response time (35 days) for the International Space Station (ISS) crew rescue [8], shown in Figure 1.

Figure 1. Concept of operations for a “locker” with robotic arm assembly, showing future rapid response time of ~hours, compared with current and traditional missions response times of several weeks

There are four phases necessary to successfully realize the mission concept. Phase 1 involves the ground-based robotic assembly of a CubeSat prototype using two dexterous arms and electromechanical components in a laboratory environment and assessing different payload and propulsion options to optimize response time and sensing. This work addresses the feasibility of Phase 1 and characterizes the systems engineering efforts required to develop in-space robotic assembly. Phase 2 involves the development and launch of a flight unit locker with robot arms and CubeSat modular components, including propulsion options for the CubeSats themselves and not just the locker. The locker would be hosted at the ISS Japanese Experiment Module Exposed Facility (JEM-EF) [9][10][11] and would demonstrate the on-orbit assembly of five 1U to 3U sized CubeSats. The first prototype CubeSat would be a ground-based assembled structure deployed first in order to test the locker deployment system. The four remaining CubeSats - two with Radio Science Experiments (RSE) and magnetometers, two with visible (VIS) sensors - will be robotically assembled on-orbit. The ISS Phase 2 technology demonstration is expected to prove the on-orbit assembly of modular reconfigurable CubeSats, increase Technology Readiness Level (TRL), and assess response time quantitatively.

A subsequent Phase 3 develops the agile free-flyer spacecraft locker with robotic arms to assemble [12][13] and deploy rapid-response CubeSats. Response time is further reduced and options to mount on existing satellites are considered. Showing response time that improves ground development time by 10x would be a key objective. Finally, Phase 4 involves the development of a strategic constellation of free-flyer locker satellites with robotic arms to autonomously assemble and deploy CubeSats in select orbits. The goal is to demonstrate a response that improves ground time by 100x (from a minimum of 35 days to launch, instead to reach the desired initial orbit in less than four hours).

Figure 2. The concept will progress to free-flying orbit-agnostic facilities that can rapidly deploy agile sensors. The four major steps of the project are shown: 1) Lab Prototype, 2) ISS demonstration, 3) Free-flyer with human supervision, 4) Constellation with autonomous facility. . The goal of the proposed technology demonstration is to incrementally address the gap in the availability of robotic arm systems for CubeSat assembly. First, by demonstrating and testing a small satellite prototype on the ground with no humans-in-the-loop and space-qualifying the successful ground prototype for use in a relevant space environment. The robotic assembly of modularized CubeSat components offers several key benefits as it seeks to provide an unparalleled number of possible CubeSat configurations for scientific and commercial use, such as: 1. Flexibility, by allowing for selection of sensor and propulsion components; 2. Resiliency, by deploying dexterous robot arms without humans-in-the-loop on Earth and on-orbit to assemble custom-configured CubeSats with optimal sensor/agility (see Section 2.2.4) 3. Efficiency, by assembling a CubeSat in 4 hours and saving launch mass for packaging CubeSats by 2x.

1.2 Organization

The systems engineering development lifecycle for the locker and CubeSat modular components are analyzed in Section 2. We assess payload sensors for the new CubeSat assembled with no humans-in-the-loop. A description of the electromechanical boards is presented and completed testing and packaging are discussed. Hand calculations to show relative motion and control of both robot arms and the components using the dynamic equations of motion [14] were completed for the system. Integration and test processes for the system are analyzed and summarized.

Following a state-of-the-art review of current robot arms in space, a feasibility study on the use of dexterous COTS robot arms in space is analyzed in Section 3. System objective functions, design variables, and system parameters are developed to optimize for robot arm assembly time. We observe constraints and bounds, and components of the COTS robot arm are evaluated for in-space use. We summarize the study results toward feasible on-orbit CubeSat robotic assembly.

Section 4 describes the lab prototype demonstration of the robotic assembly of a 1U CubeSat by two dexterous COTS robot arms. The assembly process uses two COTS robot arms to assemble modularized boards fastened with magnets into a small satellite. The assembly steps use open-loop control and a Python software program. We show that the robotic arm assembly of modularized components as a viable option for a new class of CubeSats.

Section 5 provides a summary of the work and introduces the next steps for space qualification of the system.

1.3 Contribution

This thesis contains the following contributions: 1. Analysis of the systems engineering process required for executing robotically assembled small satellite missions without humans-in-the-loop.

2. Analysis of the use of COTS robot arms to assemble CubeSats in space and optimization of robotic arm assembly time. Data on existing robot arms are presented.

3. A new method of small satellite assembly is demonstrated without humans-in-the-loop. The technology demonstration shows two low-cost dexterous robot arms assembling a 1U CubeSat.

2 Systems Engineering of On-Orbit Assembled Small Satellites

2.1 Introduction

We design an on-orbit robot arm system which will rapidly assemble and deploy small satellites in less time than it takes for satellites to be assembled and launched from Earth. The goal is to provide an unparalleled number of possible small satellite configurations for scientific and commercial use in Low Earth Orbit (LEO). We analyze a systems engineering approach to developing and preparing a CubeSat structure and robotically assembled components [12] in a relevant space environment.

2.2 Development Approach

2.2.1 Spacecraft “Locker” System Rather than develop a new custom spacecraft, we use a Simple Payload Quick Return (SPQR) [15] box as a spacecraft to transport the robot arms and CubeSat components to the ISS for the technology demonstration (Phase 2). The basic SPQR, which we call a locker, is a low-cost rectangular solid, with dimensions 24 in x 36 in x 12.5 in as shown in Figure 3. It maximizes the use of the ISS JEM-EF volume and interface and is compatible with a small ISS air-lock (e.g., the JEM airlock). We expect to obtain data for at least three months of continuous operations.

Figure 3. (a) An SPQR illustration with DS2 and TDRV Re-entry Payloads (Precision De-orbit) (b) The SPQR prototype ‘core’ area for manufacturing is shown, where the 1U CubeSat is located. A Cyclops micro-conical adapter interface is shown on top of the box. Source: NASA Ames Research Center.

The SPQR spacecraft has the functionality of a small satellite, which includes basic power, thermal, telemetry, command/control functional elements. Small body-mounted solar arrays provide adequate power. There is a risk that the power requirement, 250 W, only works for half an hour; therefore, we target thirty minutes of assembly time for each CubeSat. The satellite function is housed in an enclosure within the linear tube mechanism [15]. Most of the volume consists of two empty bays, which has housed the Tube Deployed Re-entry System (TDRV) in previous technology demonstrations (see Figure 3a). The deployment system consists of an electrically actuated latch, which permits a spring-loaded piston to eject a particular device. The SPQR has been launched in ‘soft-stowage’ in a Cygnus Northrop Grumman (NG)-12 mission and the SpaceX Commercial Resupply Service (CRS)-16 cargo flight to the ISS [15], and fit within the maximum size of an object passing through the ISS JEM-EF Airlock [16]. The SPQR is similar to the LoneStar and Spinsat launched previously with Cyclops and Kaber Deployment Systems to the ISS.

The spacecraft locker concept, depicted in Figure 4, advances the use of functional and modular components for rapid integration. Research on cellularization has proven that functional components operating independently that can be assembled together to meet user demands [4][5][6][7]. The robotic arms and modular CubeSat components are stowed inside the SPQR, which will require a thermal management system for thermal control [17]. Future phases would include the implementation and proto-flight technology demonstration, including the development of the Simple Payload Quick Return (SPQR) locker and the flight demonstration via a USAF STP launch to the ISS JEM-EF.

Figure 4. Conceptual system design of the interior of the SPQR spacecraft locker.

Figure 5. The spacecraft locker will be placed on an Exposed Facility (EF) of the Japanese Experiment Module (JEM). Source: NASA.

As of May 2020, a 20 kg SPQR is in development, and once functional, a growth path to an even larger system could be contemplated. In the case of a 20 kg SPQR, a larger 2.5 m evolved TDRV would be stored externally on the ISS. The previously described SPQR satellite function would reside inside a compartment on the large TDRV. A larger payload canister would be loaded inside the ISS and mounted through the aft-end of the TDRV and locked in place. For end-of-mission requirements, a low ballistic coefficient ~1 kg/m2 is assumed for rapid de-orbit [15]. The SPQR will deploy an Exo-Brake [18] to slow down, lose altitude, and then disintegrate upon atmospheric re-entry approximately 36 weeks after deployment. If the Exo-Brake fails to deploy, the SQPR spacecraft will re-enter the atmosphere in 247 weeks [4].

We acknowledge that several efforts, such as thermal modeling of the spacecraft locker and payloads, coupled with system-level analysis of the mission environment to yield sufficient margin and contingency on the spacecraft capacity are required for space operations and will be conducted in the next phase of development (see Section 5.1), but are beyond the scope of the lab prototype work in this thesis. All environmental sources, including Earth, Sun and other inputs, will be modeled in future work.

2.2.2 Modular CubeSat Subsystems To aid the rapid proto-flight demonstration of on-orbit robotic assembly, we design modular CubeSat electromechanical components and addictive-manufactured structures embedded with connectors as interfaces. We use the radiation-tolerant Raspberry Pi 4 onboard computer, a Wireless Sensor Module (WSM) ESP32, and the SHR/UHR hazard set (ISS set). The components are assembled by two dexterous robots and deployed into orbit all in a microgravity environment. The goal is to test the first on-orbit robotically assembled CubeSat at the ISS. The mechanical structure of the CubeSat consists of two polyetherimide (PEI) 3D printed base and top covers and two robot arms snap six PCBs (Printed Circuit Board) into the covers with magnets. This approach makes it possible to assemble the satellite in approximately eight minutes (on Earth) without the challenges associated with free-floating small parts (e.g., screws, or nuts, etc). After assembly, the CubeSat is powered via a USB connection. The lab prototype functionality is verified by the illumination of several LEDs. (At the ISS, the functionality is verified after deployment, when the communications system is enabled.) All boards and structures are manufactured on Earth and flat-packed for launch. The CubeSat is intended to be deployed into a sun-synchronous polar orbit for three reasons: the orbit provides consistent lighting of the Earth-scan view, permits good ground resolution, and finally, we anticipate that the CubeSat will conduct an Earth-observing mission first.

The 1-Unit Cubesat platform integrates reliable, off-the-shelf subsystems with successful flight heritage into a compact form factor, providing high performance and reliability at a low cost. The 1U platform delivers the power, structures, antennas, communications, and on-board computer required. All satellite power, control, computing, and radio communication tasks are available to the selected payload, which can pass its data through the microcontroller onto the communication system for downlink (see block diagram in Figure 6).

Figure 6. 1U CubeSat System Block Diagram, which shows the microcontroller board and subsystems including the Electrical Power System, On-Board Computer, Communications, solar arrays, and payload.

Five of its six sides of the CubeSat are covered with solar panels containing two triple-junction GaAs solar cells each, separated by four window slots, through which the polymer test samples, radiation sensor, RBF pin, and diagnostic ports protrude, are directly exposed to the external space environment. The power/radio/battery unit is on the Y- side and the X, Y, and Z- solar cells are connected to provide 3.5 V, 0.4 A, 1.4 W into a boost circuit that charges the two LiPo 7.4 V batteries to a total capacity of 4.4 Ah. The Z+ side has both transmitter and receiver radio patch antennas for Globalstar. The Electrical Power Subsystem (EPS), telecommunications, and the on-board computer are physically co-located, as depicted in Figure 7(d), by prototype boards.

2.2.2.1 Interfaces The payload board uses an ultra-low-power MSP430 microcontroller "LaunchPad" development daughterboard, containing radiation-tolerant, non-volatile FRAM memory. The board is connected to the microcontroller, providing shared control, data processing/buffering, and radio communication to the science boards in a round-robin fashion. The payload and the microcontroller are mounted to the back of the solar array boards (which face the outside of the satellite). The solar array boards contain cutouts (32 mm x 9 mm) that allow sensors (such as a camera) to be exposed directly to space. All boards and components are flat-packed on Earth before being snapped into place in the locker. This approach eliminates the need for tools and uses magnets as fasteners when the satellite is robotically assembled on-orbit. All subsystems boards are routed through connectors which line the structure (see Figure 7a-b) to the microcontroller. These connectors provide a common connection point for all boards to aid functionality. This configuration is important for future iterations of CubeSat builds with multiple payloads. It allows the microcontroller to provide payloads with equal access to the on-board computer, EPS and communication.

Figure 7. (a) Front view of the base and top cover structure. (b) Back (internal) view of the base and top cover structure. (c) Rendition of all boards snapped into the structure. (d) All boards snapped into the 10cm x 10cm x 10cm structure, weighing 1kg.

Table 1. Specifications for a robotically assembled 1U CubeSat Volume 1U Mass 1000 g Attitude Capability Detumbling Data bus I2C/RS-232 Storage 2 x 2 GB Average payload power 400 mW Power bus 3.3 V / 5 V (2 A max) Uplink 9.6 kbps (VHF) Downlink 9.6 kbps (UHF)

Figure 8. Two robot arms performing an initial test assembly with magnetized boards

We use payloads selected in the trade study in Section 2.2.2.9 and specifications as listed in Table 1. The system will use the GlobalStar constellation, which orbits at 1400 km with a 52° inclination to allow for low-cost communications and negligible ground operations. We anticipate these initial CubeSats will only downlink health data and small data files, which require very little onboard memory, with a data rate of 1200 bps.

2.2.2.2 Avionics We use prototype boards to represent solar panels, lithium-polymer batteries, and a passive attitude control system. The Raspberry Pi 4 onboard computer uses an 8-bit PIC microprocessor with flight heritage including the SOAREX-8, GeneSat, and the ATEK/MAPHEUS-8 sounding rocket campaign. The microprocessor runs the flight software, the communication system, the electrical power system, and the passive thermal observation system. The data is routed through the embedded routing connectors within the structure, which provide up to 2.5 W of power at 3 V and 5 V.

2.2.2.2.1 Modularized Boards Since most CubeSat components used for a 1U form factor are modular by nature, standard boards (see Figure 9) were purchased and used for an initial laboratory demonstration of

electromechanical construction. These standard boards were customized. In the center of the target, we include a photodiode for duplex short-range optical communication for carrying high speed signals, and pads were added for an LED. On the backside (red board), pads for connectors to connect the round contacts and optical parts to an external PCB were also added. We also included nine round contacts on the front side of the board (dark blue board) and through-hole pads for pogo pins for carrying power and low speed signals.

Figure 9. Standard prototype electronic boards for initial assembly construction 2.2.2.2.2 Microcontroller All the modular boards are connected through a microcontroller board, shown inside the CubeSat in Figure 8. The microcontroller board provides a single connection point for all satellite boards, which reduces the probability of assembly errors. For the payload board, it relays data from the boards to the ground station and provides computational power, sequencing control, and additional memory. The computational power is provided by an ultra-low power MSP430FR6989 microcontroller with 128 kB of FLASH memory for flight code and 130 kB of non-volatile, FRAM (Ferroelectric Random Access Memory) for computations. The microcontroller board operates in a peer-to-peer relationship with the on-board computer. The microcontroller can request the EPS to cycle power the payload to control their duty cycle. The FLASH and FRAM technologies provide increased resistance to single event errors caused by ionizing radiation. Data is passed from the payload to the microcontroller, which transmits and sends the data to the telecommunications system for transmission to the ground station.

2.2.2.2.5 Fasteners Methods for assembling space components include using welding, mechanical fasteners, adhesives, magnets, or snap-on latches [19][20]. Magnets are selected for ease of assembly and weight. The magnets can be used for passive attitude control [21]. Care must be taken to minimize their effect on electronics and attitude control, particularly after studying the lessons learned from the magnetic conjunction of MCubed and HRBE missions [22]. Measures such as ensuring the dipole strengths are near 0.5 A-m2 for sufficient passive attitude control [23] are taken. We also ensure the translational separation velocity of the following CubeSat in the deployer, if using Poly Picosatellite Orbital Deployers (P-POD) deployment, is greater than 2.1

cm/s [22]. These measures are taken to avoid unnecessary conjunction of multiple components while meeting CubeSat requirements [24]. After evaluating mechanical structures and mating mechanisms for assembling CubeSat subsystems and components into a functioning CubeSat, we find that using magnetic fasteners on the additive manufactured structure (and rails along the Z-axis) results in a CubeSat structure compliant with International Space Station (ISS) CubeSat mechanical specifications. After several iterations where snap points were considered and tested as an alternative, we find the use of magnets proved to be feasible for the lab prototype. Figure 7 (a) and (b) show the snap locations on the structures.

2.2.2.3 Attitude Determination and Control Passive attitude control is provided by a permanent magnet, aligned in the z-axis of the CubeSat, which will slowly align the satellite to the Earth's magnetic field. The satellite's rotation is dampened by three orthogonal µ-metal strips mounted on the microcontroller board. Hand calculations to show relative motion and control of both robot arms and the components using the dynamic equations of motion [14] were completed for the system. To obtain the maximum slew rate of the spacecraft, we use

n L ω = L max,RW (1) max,SC MOISC

where nL , the fraction reaction wheel momentum available is assumed to be 1, Lmax,RW is the maximum reaction wheel angular momentum, and MOISC is the (maximum axis) Moment of Inertia of the spacecraft. This results in a maximum of 19 degrees per second for a one to six U CubeSat using the Blue Canyon Technologies RWP50 system. To calculate the maximum angular acceleration of the spacecraft, we use

τ α = max,RW (2) max,SC MOISC

where τ max,RW is the maximum reaction wheel torque. The time required for a spacecraft slew from stationary to stationary is ω ω2 Δt = Δθ + max,SC if Δθ ≥ max,SC (3) slew ωmax,SC αmax,SC αmax,SC ω2 Δt = √ Δθ if Δθ ≺ max,SC (4) slew αmax,SC αmax,SC where Δθ is the angle of the slew. This results in sixteen seconds for 180-degree slews. The use of reaction wheels to control the orientation of the locker and the elimination of the base linear motion from the equations of motion are key to this method. We anticipate that the effect of the reaction wheels on the dynamics of the system can be divided into two components: the components relating to the generalized momentum of the reaction wheels and the components included in the dynamics by modifying the inertial properties of the base of the system. The resulting form of kinetic energy is used in Lagrange’s equation to obtain the dynamic equations of motion.

2.2.2.4 Thermal The CubeSat will use Kapton heaters and will be designed to be passive until further analysis demonstrates active heating is required. The operational temperature bounds are -20° C to 40° C. Surface optical properties to be designed for ideal thermal balance. Most components will include built-in temperature sensors, which can be monitored with an onboard RTD temperature sensor, such as Honeywell 480-4982-ND RTD. Extra RTDs can be implemented to monitor the temperature of the payload. Should active heating be required, we calculate a steady-state radiator sizing using

4 A(QSolar + QIR + QAlbedo) + QElectronic = Aεσ(T rad) (5)

given that Qsolar is zero and always pointing the radiator away from the sun; the radiator is coated with white paint such that ε = 0.83 and α = 0.20 ; the payload is insulated from the spacecraft (thermal isolators are used to attach the payload to the bus); Z+ face of the spacecraft - with the aperture - is always nadir pointing; there is a large conduction path from the payload to the radiator. The orbit-averaged electronic heat used is calculated from 0.85 (efficiency of electronics) × 0.30 (percentage of orbit where payload operates) × 30W (heat load).

2.2.2.5 Electrical Power System (EPS) The on-board computer receives requests to cycle power to the boards, including the payload, and uses energy from the solar arrays to charge the batteries. (See Block Diagram in Figure 6). The solar arrays are constructed using twenty-eight percent UTJ (Ultra-efficient Triple-Junction) solar cells and provide 433 mA at 2.35 VDC. Each cell covers one-half of a 1U face. Therefore, two cells are connected in series on each solar array board to provide 4.7 VDC at 433 mA (~2 W) from each board, assuming full illumination and operation at maximum power. Each of the five solar array boards is connected in parallel. The EPS uses PPT (Peak Power Tracking) to regulate the current extracted from the solar cell array to ensure the array remains at peak power. The EPS charges four lithium-polymer batteries, configured as two series pairs of batteries in parallel. Together, they provide 4.4 Ah at 7.4 V. The batteries have flight heritage onboard the ISS; additional battery or EPS testing may be required by the ISS prior to flight.

2.2.2.6 Propulsion To provide propulsion capability, should the CubeSat need to adjust orbit, we select the IFM Nano thruster. The thruster has no moving parts and can use the RS-422 or RS-485 protocol (likely different packet structures and data returned). Since this component is modular and will be used as-is, the BIT-3 requires 28 V regulated input power and the thruster can accept 12 V or 28 V. The IFM Nano emitter has been tested for nearly 24,000 hours of firing. It had flown on-orbit for over one year and has shown no degradation signs. The BIT-3 PPU is designed for

deep-space operations with SEE tolerance and “rad-hard fence” around critical electronics, therefore, there are no environmental concerns for use in LEO.

2.2.2.7 Telecommunications We use IEEE 802.11b, which operates in the 2.4-2.4835 GHz range and is regulated by the Federal Communications Commission [25]. The use of the band is limited to a maximum of 1 W power output. As this is an unlicensed band, which is reserved for public use, the National Telecommunications & Information Administration (NTIA) allows for use in academia. WiFi, as demonstrated successfully on SOAREX-8 [26], is used as a LAN with many stations reaching the internet via an access point. We use a point-to-point configuration using ESP32. ESP32 is a low-power microcontroller with integrated WiFi and dual-mode Bluetooth, which includes built-in antenna switches, power amplifier, low-noise receive amplifier, filters, and power management modules. WiFi uses the unlicensed spectrum, incorporates the Barker code or Complementary Code Keying (CCK) for error detection, and Phase-Shift Keying (PSK) modulation. Normally the maximum range of WiFi is about one mile since either all packets must be acknowledged within a set time period or they are retransmitted. Beyond a mile, the transmission time usually exceeds the acknowledgment timeout. We exploit a few settings within the WiFi standard to create a half-duplex link allowing us to send our packets to the ground. The payload transmitter is initialized into “packet injection” mode, which sends packets to the broadcast address and thus does not require an acknowledgment. We also set it to only 1 Mbps although the IEEE 802.11b standard supports up to 11 Mbps, to provide 10.4 dB of processing gain and subsequent link margin. The ground station consists of another WiFi dongle attached to a laptop. The laptop initializes its WiFi in monitor mode.

2.2.2.8 Ground Station Most CubeSats use ground station radio uplinks to send commands to the satellite and radio downlinks to send data from the satellite. We intend to use a ground station-to-CubeSat radio link for both sending commands to the satellite and receiving data from the satellite. The ground station operates in the 435 MHz (UHF) amateur frequency band. To avoid designing a new ground station, we use an EyeStar Simplex radio, provided by NSL, which communicates with the GlobalStar satellite constellation. It provides a 24/7 data downlink to ground receiving gateways located around the globe, tied to a secure NSL data server, from which we view near-real-time (two-minute latency) health and science data on smartphones and laptops anytime, anywhere. The low data rate of 3 bps is adequate for the small data volume expected for the project (see Table 2). The data received by the ground gateways are made available via an Internet portal and transmits two types of packets from the EyeStar radio: a Satellite Health Packet, which is an 18-byte packet that will be transmitted at a regular interval to report the temperature and bus voltage of the satellite, a Payload Packet: a 36-byte packet containing the data from the payload board that will be transmitted at regular intervals. The data rate is expected to be 50-100 kB/day, which is primarily limited by the expected power budget and data rate costs. Using the flight-proven Simplex radio ensures that a beacon will still be received

independent of other CubeSat subsystems. This beacon will indicate satellite functionality in the event of a payload or microcontroller failure.

Table 2. Data Budget

2.2.2.9 Payload A Payload Selection Trade Study was conducted to downselect various feasible CubeSat sensor capabilities [27] for the initial prototype of a functional 1U CubeSat. All sensors and payloads available to CubeSats will be considered after the initial prototype. VIS, IR, and RF diagnostic sensors [28] were considered as shown in Table 3. Three factors were key to the weight assessment values: the least amount of mass and volume required by the payload and the highest maturity level of the payload. The resulting weights showed the selection of a magnetometer and standard RSE as initial CubeSat payload options for robotic assembly.

Table 3. Payload Study Outcome, where WA is the Weight Assessment of each parameter

2.2.3 Assembly, Integration and Test Processes Systems Engineering activities included in the traditional Integration and Test (I&T) cycle such as assembly, integration, verification, and validation of the system, subsystems, and interfaces, assume a spacecraft being assembled on the ground. While the flat-packed system would be

verified and validated on the ground, it would also be the effective flight configuration when taken as a part/payload of a larger spacecraft. Therefore, the flat-pack stack needs to meet the same vibration tests, payload envelope, and TVAC tests as a fully-assembled spacecraft. The interfaces between the stacked elements when in the CubeSat assembled form factor would need to go through the same level of tests. The interfaces between the stacked elements would also need to go through the standard tests. Space programs typically engage a philosophy of “test early, test often” to ensure that the components we select do not present surprises during flight.

Initial environmental testing is to be undertaken at the component level to ensure fitness for purpose. Each of the commercial products is stripped of their plastic shrouds, and placed in a thermal vacuum chamber. The chamber is cooled to −10°C, then heated to determine the maximum safe operating temperature. The Raspberry Pi single-board computer runs the Linux random number generator (rng), which is piped through gzip compression to stress the processor at 100% load during the test. Meanwhile, another thread performs a checksum on the data generated, saving the results to a file stream, and verifying the checksum. During preliminary testing, the thermocouple on the Raspberry Pi shielding indicated 120°C when the processor shut down due to internal thermal management. When the chamber returned to room temperature, the processor did not resume function without a power reset, indicating that a watchdog will be required if the spacecraft is expected to ever exceed that temperature. All other components functioned correctly throughout the test. Prior to delivery, system-level tests will be necessary to verify all functionality of the CubeSat. These included a thermal vacuum test of the assembled payload, an RF interference test, and a vibration test to the General Environmental Verification Standards (GEVS).

2.2.4 Launch Accommodations The analysis uses conservative flat-pack assumptions and can be further improved with optimized modules. Figure 10 shows the launch cost savings per volume that can be achieved with flat-packed components launched for on-orbit robotic assembly. Table 4 shows a comparison of a “smart deployer”, which includes launched pre-integrated SmallSats packaged in a deployer, and a free-flying “locker”, which robotically assembles and deploys CubeSats on-orbit as needed. The grey highlight in the table denotes capabilities with the same benefits. Other capabilities in the table show more flexibility with modular on-orbit robotic assembly. A group of satellites, which are part of a constellation may be referred to as a tranche. Note that while pre-integrated CubeSats may be a simpler way of flying a tranche, it does not simulate on-orbit manufacture and assembly.

Figure 10. Launch costs vs. CubeSat volume savings. Table 4. Comparison of a Smart deployer (no Robotic Assembly) vs. Free-flyer locker. Capability Free-Flyer Locker Smart Deployer (On-Orbit Robotic Assembly) (no Robotic Assembly)

Development Timeline 12-24 months 24-48 months

Launch Timeline Minimum 35-day launch manifest Minimum 35-day launch (One launch) manifest (one launch)

Volume (number of 120 3U CubeSats (shelved/flat 60 3U CubeSats Satellites in 177U packed structures) (pre-assembled with Free-Flyer) structures and rails upright)

Spacecraft Various Limited (determined before Configurations launch)

Propulsion Various Limited (determined before launch)

Payload Options Various Limited (determined before launch)

Deployment to Target Hours (from on-orbit location) Hours (from on-orbit location)

There are also mass constraints on the ISS Japanese Experiment Module (JEM) locker. The mass constraint is approximately 100 lbs for the JEM airlock RMS arm, which serves as an upper bound for the ~177 U of volume. Hand calculations show the advantage of assembly at the ISS is that the Figures Of Merit would be 120 possible CubeSats (1-3U) per unit volume (locker) if components were stacked vertically and assembled robotically versus 72 pre-integrated stored CubeSats, which require a satellite frame and dispenser per CubeSat and

costs approximately 10-20% of volume. Figure 11 below shows the volume savings reached by stacking structural pieces vertically versus the volume required of a pre-integrated CubeSat.

Figure 11. (a) A rendering of a deploy-only box on-orbit packed with 60 3U CubeSats (b) A rendering of a spacecraft locker with spacecraft components to assemble 120 3U CubeSats.

Cost Considerations—The ISS demonstration concept could qualify for a research (free-of-charge) ride from the Air Force or NASA [29]. Otherwise, we intend to work through a payload integrator, which bundles several CubeSats into a single launch. In 2019, one major integration vendor is Spaceflight Industries (formerly Spaceflight Services) and with bundles beginning with 3U CubeSats for $295K (USD) to LEO [30]. Another vendor, NanoRacks, quotes $40K per CubeSat unit (for academia) through $85K per CubeSat unit [31]. However, as the satellite gets larger, the price per U eventually begins to decrease. In addition to differences in vehicle costs, flight cost per unit depends heavily on the destination and the configuration of the payload stack. For example, assuming 40% capacity loss to the adapter and CubeSat dispensers, a dedicated rideshare flight on Virgin Orbit LauncherOne to 500 km SSO could be estimated as $110K per CubeSat Unit, while the same vehicle to 230 km equatorial orbit could be $65K per CubeSat Unit [32]. For the purposes of this thesis, we assume the ISS orbit of between 370 km and 460 km and a 51.6-degree inclination [33]. As the CubeSat volume grows, traditional launch opportunities grow at $80K per CubeSat Unit and eventually level off. However, when assembled on-orbit, the launch costs of flat-packed components begin at $10K per CubeSat Unit.

2.3 Observations

Designing a spacecraft locker to robotically assemble and deploy CubeSats on-orbit has raised as many questions as it answered. The important answer is the feasibility of the concept of operations. However, assembling a lab prototype has revealed the level of effort required to make this project succeed as a flight mission to the ISS. Modular components could be a more efficient CubeSat approach and do not currently exist in a form that can be readily integrated and assembled on-orbit. For instance, designs for modular propulsion systems need to be

explored with potential propulsion manufacturers such as Busek and Enpulsion. In the area of fuel use for maneuvering, given that we are unclear about the volume needed for specific use cases, we intend to lean on additional research optimization tools for fuel needs.

The ability to tailor battery life for mission scenarios requires further study and simulations to optimize the power ranges for each CubeSat configuration. Solar Array sizing will also be studied before the flight. Preliminary results with robot arm kits at MIT STAR Lab have shown that the form factor of the CubeSats - if greater than 3U - and the robustness of the COTS robot arms - if no customizations are made - require additional ground tests to resolve thermal issues associated with the potential overheating of robot arm motors. Therefore, we intend to include a thermal management system for thermal control. Despite the fact that the modularized spacecraft components, including propulsion and sensor payloads, will not be pre-integrated on-the-ground and will be housed in a spacecraft locker, the components will be subject to the same amount of vibration testing.

2.4 Summary

The greatest benefit of on-orbit assembly is the ability to tailor propulsion capability, battery power, and on-the-ground vibration testing. One reason to prefer a modular, assembled-on-orbit approach is that it defeats/hampers an adversary’s ability to know what is coming. A configurable system that can take on a multitude of forms and capabilities as needs arise, confers a significant advantage – an adversary can not effectively respond to an unknown and dynamic capability. The “overhead” associated with SWAP allocated to the assembly process is offset by the ability to reload with specific modules (either to replenish those depleted by use, or to update to newer capabilities), and adapt to unforeseen needs, e.g. not limited to the few configurations provided by pre-integrated CubeSats. In addition to rapid-response single- or multi-U CubeSat form factors, this approach would be extensible to larger, higher performance space assets, such as apertures, through incremental on-orbit assembly advancements with the goal of being as simple as snapping together LEGO bricks. Sample mission capabilities include different spacecraft configurations to address a wide spectrum of use cases. For example, the deployment of RF diagnostic sensors, VIS sensors, IR sensors, and propulsion units.

For cost-constrained missions relying on COTS components, it is usually preferable to use the radiation-tolerant approach at the level required for the mission and to implement a system-level design, screening, and process controls such as watchdogs and current monitors to improve reliability. An example of some goals during the technology demonstration for radiation tolerance might include having no destructive single-event effects, a manageable single-event upset rate, a functional unit up to the expected mission total irradiating dose (TID), and, following annealing, up to twice the expected mission dose. To illustrate an example, we use the OMERE freeware tool, which is dedicated to space environment and radiation effects on electronics [34]. Figure 12 shows that for a 500 km orbit with 98-degree inclination, a dose for one year assuming a launch date of January 1, 2023, is 10,000 rad/year. When needed,

shielding can be applied (possibly spot shielding on the affected component) to reduce the expected mission dose [35].

Figure 12. Sample Dosage from TRAD OMERE version 5. 3 Feasibility of COTS Robot Arms In Space 3.1 Introduction We review the current state-of-the-art of robot arms in space. We assess the feasibility of the on-orbit assembly of small satellites using Commercial-Off-The-Shelf (COTS) hardware without humans-in-the-loop. We select low-cost robot arms, LewanSoul xArm Robots with six Degrees of Freedom, and minimize on-orbit SmallSat assembly time by using the dexterous robot arms while satisfying the given power consumption and weight requirements at a given orbit. Thus, we employ multidisciplinary design optimization tools and methodologies focusing on the second key gap: testing and modifying commercial robotic assembly hardware suitable for small satellite assembly in space. Given that the search parameters in the Inverse Kinematics task for a robot with many degrees of freedom are constant, the Genetic Algorithm approach in combination with the robot simulation is used. We also describe the technology choices and redundancy levels of the different subsystems in this optimal on-orbit assembly design.

3.2 COTS Robot Arm Flight Heritage To date, most on-orbit assembly missions are not for small satellite on-orbit assembly, but instead are designed to support ISS experiments, exploration, and servicing (refuel or repair existing satellites) missions [36][37][38][39]. Previous missions such as the U.S. Defense

Advanced Research Projects Agency’s (DARPA) Orbital Express program [40], the DARPA Phoenix Program [41], and the Jet Propulsion Laboratory’s (JPL) Mars Insight mission [42]. Robotic manipulators, important for scientific experiments and the construction and maintenance of the ISS, have conducted on-orbit robotic assembly. Examples include the Shuttle Remote Manipulator System (SRMS) [43], also known as Canadarm, which is a 16.9-meter, seven degree of freedom (DOF) manipulator with a relocatable base; the National Space Development Agency of Japan’s (NASDA) Japanese Experiment Module (JEM) Remote Manipulator System (JEMRMS), which is a 9.91-meter, six DOF manipulator; and lastly, the European Robotic Arm (ERA), which is an 11-meter, seven DOF manipulator [44]. These manipulators employed very large robotic arms to deploy, maneuver, and capture payloads. Hirzinger’s patent on a multisensory robot was tested aboard the Columbia shuttle, which successfully worked in autonomous modes, and was teleoperated by astronauts, as well as in different telerobotic ground control modes [45][46]. In the area of autonomy, SPHERES Universal Docking Port (UDP) demonstrates autonomous docking maneuvers using small satellites [47] and AstroBees, the free-flying robots, provide a flexible platform for research on zero-g free-flying robotics [48].

Current missions (on-orbit or in development) include the Northrop Grumman MEV-1 and DARPA Robotic Servicing of Geosynchronous Satellites (RSGS) program [49]. RSGS aims to demonstrate satellite servicing mission operations on operational Geosynchronous Earth Orbit (GEO) satellites. RSGS uses the FREND project, which developed the state-of-the-art in autonomous rendezvous and docking with satellites not pre-designed for servicing, and was the precursor and inspiration for the DARPA RSGS program [50]. The DARPA/Naval Research Lab (NRL) team working on FREND focused on autonomous rendezvous and docking with satellites, which were not designed for servicing. The National Aeronautics and Space Administration (NASA) Goddard Space Flight Center’s (GSFC) RESTORE-L servicing mission [51], is also a robotic spacecraft equipped with the tools to rendezvous with, grasp, refuel, and relocate satellites to extend their lifespan. Lastly, NASA’s Dragonfly has also recently demonstrated a ground-based test of robotic satellite assembly [36][52] and Made In Space (MIS) received a large NASA contract to demonstrate on-orbit assembly using three robot arms to assemble 3-D printed parts in space, called the Archinaut mission [53].

Table 5. Shows the gaps in select current on-orbit assembly/servicing space missions

Radiation Tolerance—Robot arm sensors for on-orbit assembly missions are typically custom-built and radiation-hardened. Radiation-hardened components - for LEO - are required to have a rated radiation dose of 100 krad to > 1 Mrad, no Single Event Latchup (SEL), characterized single-event effects, and hermetically sealed packages [35]. A radiation-hardened component is engineered by its manufacturer to provide specific radiation performance and is produced using strict quality control, including periodic testing to the rated radiation dose, and part-level environmental screening for latent defects and infant mortality. Radiation-tolerance, an acceptable alternative for many small satellite applications, is required in electronic devices [54] to ensure the capability to operate within the demanding radiation and thermal extremes of the space environment. Robotic arm electronics, particularly for harsher radiation environments (outside LEO), need power-efficient high-performance radiation-tolerant processors and peripheral electronics [55].

3.3 Robot Arms for Assembly

3.3.1 Selection and Timing Having purchased robot arms in the under $500 range, with damaged servo motors by the first test of the concept, we assessed a list of replacement servo motors (see Table 5). We define low-cost for the lab prototype as under $500 for all robots, boards, and parts. Thus, in order to stay within the bounds of a low-cost system, we selected the HiWonder servo motors, which are used on the LewanSoul xArm robots.

Table 5. Select list of common low-cost motors for robot arm use.

Low-cost robotic arms such as the Lewansoul xArm shown in Figure 13 are controlled using servo motors, which are not typically used for space missions. Given that the robots will be housed in and perform functions in a spacecraft locker, we continue to use the servo motors as an adequate lab prototype test for feasibility. As we progress to space qualification, appropriate motors for space operations will be used. Robotic arms of similar size and weight come in a range of prices. A major difference between the robot arms available off-the-shelf is the use of powerful motors and sophisticated control systems. The more sophisticated robot arms are able to move with greater precision due to these characteristics.

Figure 12. (a) Lewansoul xArm Robot with 6-DOF (b) Robot Arm with dimensions. (Source: LewanSoul)

We recognize that these (and similar) COTS robotic arms can be customized by adding additional sensors or swapping particular components such as a motor or link. The software used to control the arms is also usually supplied with customization for controlling system parameters; however, a different control computer and real-time operating system could be used. The interaction between the control parameters and the physical dexterity can be complex due to communication latencies and multi-tasking using the operating system. Thus, we make assumptions and verify using the existing physical prototype. Since most space robot arms used in space tend to be custom-built, we anticipate we will encounter challenges designing robot arms (and its environment) that would match an existing product and does not require a custom build, given in-space satellite assembly requirements.

Figure 13. Simulation of two xArm robots in PyBullet with 2 DOF

To restrict the scope of the design optimization, we first test a model simulation of two degrees of freedom. Figure 13 shows a 2-DOF simulation of the xArm robot arm in PyBullet. We know that the simulation framework (PyBullet) is able to accommodate this level of fidelity in simulations because the framework has precedent [56]. The model simulation returns 19.09 seconds, from a starting point of 91 seconds. While not optimal, the output value is reasonable because the robot arm requires 5 seconds to grasp and 10 seconds to move an object to a drop-off location, and less than 5 seconds to snap-assemble the part. Therefore, in order to grasp and move an object, the robot arm, which is positioned within 2 mm of the target and drop-off locations, 19 seconds to grasp, move and drop-off an object is correct. However, the global optimal value might be out of reach due to power constraints on the servo motors on the robot arms.

During simulation with different parameters, we see that using a powerful motor at high proportional gains results in faster (more optimal) time values, but consumes more power. Conversely, using a high gain value with a weak motor results in oscillations at the take time to dampen out to within the 2 mm tolerance and hence result in higher time values. This simulation is for a single step in a series of steps that are needed for the full assembly of a satellite. In later iterations, task planning to sequence the assembly steps are added and obtain similar results. Next, we modeled six degrees of freedom. Using six motors instead of two motors resulted in higher power calculations with about the same assembly time. A comparison of power and assembly time is provided in Table 6.

Table 6. Simulation results for 2-DOF and 6-DOF robot performing the same task with the same motor parameters

Robot Initial Assembly Time Energy Used Peak Power Used

2-DOF 91 seconds 220.2 Watt-seconds 13.0 Watts

6-DOF 51 seconds 451.1 Watt-seconds 33.5 Watts

We discover that the arm with 6-DOF uses more power while performing the same task at the same speed with greater accuracy. These tasks include grasping a part from a shelf and bringing it to the assembly area and snapping two parts together, using some assumptions on force and alignment required for assembling LEGO-like parts together. This leads to the selection of a 6-DOF robot arm for this work. After trying the AL5D 4-DOF robot arm kit, which resulted in servo burnouts after less than 100 hours of tests, we conducted a second search for available low-cost robots. Table 7 lists the resulting robot arm options. The Lewansoul xArm robot arms offered a low-cost option with reliable results (more than 170 hours of tests before burnouts) and less power and thermal considerations.

Table 7: List of select available low-cost COTS robot arms

Human vs Robot Assembly Time—We contrast robotic assembly with CubeSat assembly requiring humans-in-the loop for assembly. CubeSats are usually assembled by a team of people and not robots. Hence, there is little baseline data available to assess how long it might take to assemble a CubeSat using robots. We begin by estimating how long it takes a human team to assemble a 1U CubeSat as a final integration step. Note that this is the final step after the common components and payload subsystems have been designed, manufactured, and are ready for integration.

Table 8. Assembly time of various CubeSats completed by human teams Satellite Assembly time by teams Data Source

NASA MarCo CubeSat Several months by a large team Email correspondence with JPL

Interorbital IOS 2 days by a team of 2 people Email correspondence with CubeSat 2.0 manufacturer

Planet Small Satellite One spacecraft per day Conference Paper [57]

MakerSat-1 5 minutes in International Space Conference Paper [58] Station by 1 astronaut

From estimates obtained in Table 8, we focus on MakerSat-1, a 1U CubeSat, which is the closest to our concept of using pre-developed subcomponents to rapidly assembly satellites (with or without variant payloads) with minimal human intervention in space using lightweight robotic arms. MakerSat-1 was designed with similar intentions for rapid assembly. The first version of MakerSat-1 was released from the International Space Station and was able to collect ionizing radiation particle count in-orbit and experiment on polymer degradation while operating in space for at least nine months [59]. (A video demonstration of assembly under five

minutes is available [60]). Thus, we use five minutes as our starting point for CubeSat assembly. To make our simulation similar to the MakerSat-1 assembly, we need at least 2 robot arms: one arm to hold the partly assembled satellite while using the other arm inserts and clicks together parts gathered from a shelf. We allow for further model refinement of robot arm functions as the grippers and different motors in the robotic arm need to be accurately modeled. Most importantly, we use five minutes as a metric for the on-orbit satellite assembly of a 1U CubeSat.

3.3.2 Design Optimization and Modeling The design objective is to optimize “buy and fly” robot arms while minimizing arm customization, which is a surrogate for cost. Through an optimization process, we aim to create a robotic assembly model suitable for integrating small satellites in space. This process focuses on the optimization of the on-orbit assembly time of small satellites [61], using a representation of Commercial-Off-The-Shelf (COTS) robot arms to snap together components in a spacecraft while minimizing humans-in-the-loop. We implement a robot arm assembly model in Python, relying on Inverse Kinematics [47] and a Genetic Algorithm-based optimization scheme [62], with time as the objective function, and three constraints: robot assembly volume, power consumption, and peak power. Each potential solution of the problem represents a vector of values

S = {α11, α21, … , αn1, ... , α1N, α2N, … , αnN} (6)

Since the choice of the objective function will have a decisive influence on the solution, we focus on minimizing assembly time. Assembly time is deemed to be a key performance metric as it is critical to the assertion that building small satellites on-orbit results in reduced budget and satellite development time on Earth. We minimize on-orbit small satellite assembly time by optimizing a design which constitutes dexterous robotic arms working to assemble components. The design variables selected, joint damping, motor force (torque), position gain and velocity gain, are used to model grasping a component and moving the component to the satellite assembly area of the spacecraft. The robot arms are required to be within a tolerance defined based on the assembly area dimensions (approximately 2 mm). Other constraints included in the optimization design are total power consumption, total mass, and the total budget (available to the mission). Parameters used in the model are robotic arm length, degrees of freedom of the robotic arm, and the communication baud rate.

3.3.2.1 Optimization Modules We identify several domains in which the simulations or analytical calculations could be performed as described in random order. 1. Articulated Rigid Body Dynamics: For each robotic arm, we create this simulation module by sourcing the parameters of COTS parts from experiments or vendor-supplied specification literature to fill in the design variables. The multi-body dynamics simulation also takes input from a layer simulation stage (loop) that simulates the control system by

taking forces and torques applied to the motors in the robotic arm assembly and calculating the robot state. 2. Task Sequence Planning [63]: We develop a package that lists the steps required for assembling a satellite from parts. Currently, the small satellite modular components are pre-manufactured and assembled using snap points; therefore, the robotic arm is programmed to sense, grasp and move the appropriate component to the assembly station in the right orientation for a given assembly step. No steps require soldering, welding, or gluing parts. 3. Control System: The output of the Task Sequence Planning module is routed to a control system that coordinates robots and plans paths that avoid collisions. The control system passes the output (path) of the module, to individual robot arm units and the total time required for assembly. We identify a control system simulation platform and expect to use classical PID simulation techniques that would be modified to disallow robot collisions with the help of a multi-body dynamics simulation module. This submodule can also output the motor peak power using estimates of power usage when a motor is instructed to move at a given velocity. 4. Cost Model: This analytical module estimates the cost of a given configuration with consideration of any non-recurring-engineering costs due to uncertainties, customizations, launch to orbit, deployment, and operations. We conceive that some configurations can swap out components such as sensors or motors from a given COTS starting point with custom software developed for coordinating multiple customized robotic arms. The cost model for the customizations we describe and for flying the system will make up the preliminary models for this optimization.

The resulting N2 matrix for the above components is depicted in Table 9. In this model, whole subsystems such as data communications and sensors are abstracted by the Control System and the robotic arm actuator systems are abstracted by the Articulated Rigid Body Dynamics module.

2 Table 9. N diagram aligned to related subsystems Spatial Control System Robotic Arm Cost and (x, p) Configuration Design Variables Design Weight of Parts Task Sequence Planning Target Positions Joint Control System Velocities Assembly Time, Power Articulated End Effector Rigid Body Positions Dynamics Cost Model Cost, Weight J(x, p) g(x, p)

The block diagram in Figure 14 shows feedback loops from the Design of Experiments (DOE) - see Section 3.3.3 - and between the Control System and Articulated Rigid Body Dynamics and all other modules. The Cost Model is a separate entity while Task Sequence Planning only has inputs based on the spatial configuration.

Figure 14. Robot Arm Assembly Time Optimization Block Diagram 3.3.2.2 Genetic Algorithm We use a Genetic Algorithm (GA) method [64][65] rather than a gradient-based method (due to the presence of discrete variables) to complete the optimization and obtain an optimal solution. The GA are stochastic optimization techniques introduced by Holland [66], which is inspired by genetics and natural selection. Genetic algorithms are well suited for problems where the search space is large yet with many acceptable solutions as is the case in this work. The trajectory space is large, but there are, barring exceptional cases, numerous acceptable paths going from xo to x1 without collision. GA iterates the following four steps until a solution is found:

1. Evaluation: Rank the population according to the value of F for each element of Sd . Decide if the best element can serve as an acceptable solution; if yes, exit 2. Selection: Use the function F to define a probability distribution over the population. Select a pair of elements randomly according to this probability distribution 3. Reproduction: Produce a new element from each pair using “genetic” operators 4. Replacement: Replace the elements of the starting population by better new elements produced in step 3.

An individual is a string containing parameters of the optimized object. In this case of this thesis, the individual is in the form of the vector S in equation (6). Many genetic operators [67] are available; however, the more commonly used are the mutation and the cross-over operators. The mutation operator consists of randomly flipping some bits of an element of the population. The mutation rate used is 0.1. The cross-over operator consists of first randomly choosing a place where to cut the two strings of bits, and then building two new elements from this pair by simply gluing the right and the left parts of the initial pair of strings. The crossover rate used is 0.7. The fitness function evaluation contains the simulation of the robot movement and the time function evaluation.

3.3.2.3 System Variables We implement a system model of the robot arm assembly system in Python, using an Inverse Kinematics library and a test function for the robot arm. The objective function, J, is assembly time, and the constraints are the robot assembly volume, g1, and power (electrical energy) consumption, g2, and peak power g3. The system model currently includes two of the three disciplinary modules: Rigid Body Dynamics, Control System, and Power Consumption. The Task Planning module is hard-coded manually. The Power Consumption module satisfies the need for control of servo motor power consumption. Servo motors are specified to have a no-load current and a maximum load. We use the inverse kinematics algorithm for the rigid body dynamics simulation. The task plan consists of two precise subtasks: grasping an object and moving the object to a drop-off location, where satellite assembly takes place. The robot arm end effector has to be located within 2 mm of the pickup and drop-off locations for at least 5 seconds to perform the required pickup and assembly operations. We demonstrate that the system can be executed in analysis mode through the design vector, x, below which consists of the four design variables: joint damping, motor force (Torque), position gain, and velocity gain.

Table 10. System Design Variables Design Variables Range Comments

Joint Damping 0.1 < j_d < 1 This is the electromechanical damping present in (j_d) (Nms/rad) the joint due to mechanical design.

Motor Force (mF) mF = 17, mF = 20, One of the off-the-shelf servo motors have two (Nm or kgf · cm) or mF = 22 torque options: 17 kgf · cm at 5 V and 22 kgf · cm at 7.4 V. Another servo motion option can provide 20 kgf · cm at 7.4 V, and we iterate with both as we optimize for assembly time.

Position Gain 0.03 < pos_gain < 1 This value corresponds to a PID controller (pos_gain) (mm) proportional gain value.

Velocity Gain 1 < vel_gain < 100 This value corresponds to a PID controller (vel_gain) (mm/s) derivative gain value.

In the current model, we assume that the robot arm is constrained to move within a space of

g1 = 1.1 m

This is automatically satisfied as the robot model has a fixed arm-length. The total power consumed is limited by the battery or other energy source available. A typical lithium-ion battery used in laptops stores about 50 W hr of energy which is about 180 kJ (kilo Joules). However, given that we anticipate assembling tens of satellites, and this is a single step in the assembly of a satellite, which has at least 10 steps, the constraint we chose is 180 kJ/100 = 180 J.

g2 ≤ 1800 J

The peak power available is determined by the electrical power systems within a spacecraft sub-module. Sometimes, this is generated using solar energy. We chose a peak power limit of 15 W per robot as we intend to have two robots in the system with a total power budget of 30 W. 30 W is justified based on the power availability in the ISS Nanoracks requirements [68]. We expect our assembly line to consume about the same amount of power. This is much lower than a typical industrial robotic arm. Hence, only smaller hobby-level robotic arms satisfy this constraint.

g3 ≤ 15 W

3.3.2.4 Assembly Time Feasibility We initially address the problem of achieving a feasible solution near our starting solution and delay considering the minimization of J until the first feasible design has been achieved. xo = (0.1, 17, 0.03, 2)

We learn that the initial design vector x is feasible because it satisfies the constraints, robot 0 assembly volume, g1, and power consumption and peak power, g2 = 144.29 J and g3 = 12.96 W. (see DOE results below for A2, B1, C2, D3). It also returns the value of 21.27 seconds, which is a first step in minimizing J, the robot arm assembly time. Since the design is in the feasible region, we verify that the system model has the capability to perform calculations and determine if the objective function, assembly time, can be reduced by a certain percentage and still remain feasible.

3.3.3 Design of Experiments (DOE)

4 Performing a DOE using an orthogonal array of L9(3 ), we efficiently explore the design space. The design variables were assigned the following notation: joint damping (A), Motor Force (B), Position Gain (C), and Velocity Gain (D). These factors were selected based on the key features of robotic arms we evaluated and key design inputs for our simulation model. The levels were determined by the availability of motors (e.g., for the motor force, we survey commercially available motors from the manufacturer, HiWonder), and examine the limits and best practices

for our chosen system model (based on the Pybullet module). This process was partly a trial-and-error process examining the inherent limits of the variables. The design variables listed above were given the levels listed in Table 11.

Table 11. List of levels for each factor Design Factor A1 A2 A3 B1 B2 B3 C1 C2 C3 D1 D2 D3

Level 0.1 1 10 17 20 22 0.03 0.3 3 2 1.5 1.2

Each combination of the orthogonal array created was then executed using our system model, with the design variables affecting different modules. The combinations along with corresponding observations are recorded in Table 12. Based on the combinations, the main effect of each of the factor levels was then evaluated. The levels which resulted in the optimal combination, i.e. in the shortest assembly time, are highlighted in Table 13.

Table 12. Orthogonal array created for the DOE with observations for each combination. Expt no. Total Peak Joint Motor Position Velocity Electrical Electrical Damping Force Gain Gain Assembly Energy Power A B C D time (s) (J) (W) 1 A1 B1 C1 D1 21.27 144.29 12.96 2 A1 B2 C2 D2 49.95 434.92 15.247 3 A1 B3 C3 D3 95.1 1565.86 16.77 4 A2 B1 C2 D3 57.43 444.06 12.96 5 A2 B2 C3 D1 89.29 1351.53 15.24 6 A2 B3 C1 D2 19.67 93.35 16.77 7 A3 B1 C3 D2 97.22 1234.42 12.96 8 A3 B2 C1 D3 20.98 110.33 15.24 9 A3 B3 C2 D1 43.04 656.79 16.77

Table 13. Main effects of each of the factors Design Factor A1 A2 A3 B1 B2 B3 C1 C2 C3 D1 D2 D3

Effect on 0.56 0.58 -1.14 3.76 -1.4 -2.2 -34.2 -4.74 38.9 -3.6 0.73 2.95 Assembly time 8 8 4 9 8 (s)

Based on the results in Tables 12 and 13, the optimal combination of levels for the factors is A3, B3, C1, D1. The resulting expected assembly time is 19.09 s. However, running the above combination through the model, the actual resulting assembly time is 20.01 s. This is most likely due to non-linear interaction between the different factors. Nonetheless, this is a recommended starting point (x ) for our numerical optimization. o

3.4 Observation To confirm the results from Section 3.3.3, we reran the optimization using the setup for several iterations, obtaining the following results, where J is optimal assembly time and the four design variables are identical to those introduced in Section 3.3: x* = [0.603 (damping), 2.157 N.m (max motor force), 0.035 (position gain), 1.615 (velocity gain)] J(x*) = 19.12 sec g1(x*) = 16.8 W < 30 W g2(x*) = 99.4 J < 1300 J

Examining these results, we find that the first diagonal of the Hessian (with respect to damping) was zero. On close inspection, we found this was the result of a bug in our code, whereby the relevant design variable for damping was set to 0.1 and was not changed by the algorithm throughout the iterations. On correcting the code and using a constraint of g ≤ 15 W, the new 1 optimal assembly time was close to J ≤ 50s. This assembly time is significantly higher than tmin our previous optimum, which, however, was expected with the power constraint. To fine-tune this, we varied the constraint maintaining the GA inputs and found that if we increased the constraint to 16 W, the optimum found by the GA at 100 generations and 20 individuals per generation was closer to 22 seconds. x* = ([7.549, 1.961, 0.157, 1.943]) J(x*) = 21.950 s g1(x*) = 15.247 W < 16 W g2(x*) = 187.993 J < 1300 J

One of the key issues we faced in the optimization is the presence of maximum motor force as a discrete variable; hence, the use of the GA method. This is because we chose from a set of discrete options from COTS motors. We assume the secondary motor characteristics (e.g. current drawn, from which power consumption is calculated) to be proportional to the COTS robot arm motor's force. Therefore, the deviated motor has the same torque to current ratio. Next, we calculate the diagonals of the Hessian using a Finite Difference Method, beginning

with a small delta in each variable, h = 0.1 and decreased to h = 0.01 and h = 0.001, etc. to check grid convergence, and use the central difference formula:

(7) The results for the diagonals of the Hessian are:

[ 9.0 50.4 1079.0 78.0 ] # h = 0.1 [ 200.0 1500.0 10300.0 200.0 ] # h = 0.01 [ 20000.0 70000.0 80000.0 20000.0 ] # h = 0.001 [2000000.0 2000000.0 2000000.0 2000000.0 ] # h = 0.0001

We see that as we decrease h, the double derivative “explodes”. It is suspected this could be due to the precision used in the simulation packages for kinematics. To keep the system to reasonable physical values, we use h = 0.1 as the basis for normalization. Given that in the diagonals of the Hessian, only the position gain value is greater than 100, the scaling required is as follows where the position gain is multiplied by 10:

[ 1.0 1.0 10.0 1.0 ]

We rerun the code with scaling = 1.0 and the best solution that resulted was:

SCALING = [ 1.0 1.0 1.0 1.0 ] x* = [1.516 (damping), 1.961 N.m (max motor force), 0.0524 (position gain), 1.929 (velocity gain)] J(x*) = 21.01 sec g1(x*) = 15.25 W < 16 W g2(x*) = 109.60 J < 1300 J

In Figure 15, we observe that there is a small difference in the optimum achieved - with and without scaling - which could be due to the random nature of genetic algorithms. The data for the GA iterations shows that in both the scaled and non-scaled cases, there are some mutations that result in deviation from optimal but the solution converges back to a similar optimum value. We hypothesize that our implementation of the genetic algorithm where the binary bits were spread between and minimum and maximum feasible values of the variable resulted in the inclusion of scaling. Therefore, despite the scaling being based on the Hessian being included, and where most of the scales were 1.0 and only one scale was 10.0, there is not much of a difference.

Figure 15. Genetic Algorithm results J(x) with penalty for constraints and iterations where every 20 iterations is a generation, with 2000 iterations in 100 generations

3.5 Summary This design objective reaches an optimal solution of 22 seconds for the assembly of each component part, with a penalty for constraints. It satisfies the feasibility of the second key gap: testing - verifying and validating - commercial robotic assembly for small satellite assembly in space. During the simulation, we see that using a given baseline servo motor (7 V) at high proportional gains results in an optimal assembly time of approximately 20 seconds per component assembly, compared to roughly double this time per component for a 1U CubeSat weighing 2 kg. The key parameter affecting our results proved to be the number of generations, rather than the population size. In this initial attempt, we did not alter the parameters controlling the mating. In our first attempts, due to limitations in available computational time, we used a population of 20 and 100 generations. In our initial run, we concluded that the optimum achieved is - given the relatively small number of population size - close to the global optimum. This can be inferred from the results of the DOE presented in Section 3.3.3 and considerations of physical limitations in the actual assembly setup (see Section 3.3.2). However, this improvement resulted in a 25% higher power consumption.

Oscillations and Lack of Damping—Conversely, using a high gain value with a lower voltage (5 V) motor results in oscillations and additional time required to dampen out to within the given tolerance, and results in increased assembly time. Since damping control is needed to prevent oscillations from becoming hazardous, the joint damping is set sufficiently large (0.1 < joint_damping < 1) so as to reduce the amplitude of the oscillations of the vibration modes and

facilitate accurate position tracking when needed. We observe that changing the joint damping (and position gain) affect these oscillations. Our results indicate we gain high frequency performance improvement by a joint damping increase such that lateral oscillation amplitude is significantly reduced. Additionally, we observe that low-cost robots must operate in low-wind areas or in boundary-layer flow near surfaces to prevent oscillations.

The benchmarked small satellite assembly time with a human-in-the-loop requires at least weeks to months of component assembly and integration time on Earth. We see that on-orbit assembly capability - within a spacecraft - optimized for a 1U functional CubeSat with 30 W of total power, would reduce the assembly time by an order of magnitude. Investigating initial simulations with robotic arm models, for a 1U CubeSat assembly, we show a 42% saving benefit in robotic assembly time. We recommend performing the above optimization process in the modelling and single-objective optimization by taking full advantage of the Inverse Kinematics technique for robotics programming, which in our work obtained through library functions offered by PyBullet. We also learn that performing single-objective optimization with better results can be obtained when a greater number of options are presented in the COTS motor range. Furthermore, when performing GA-based single-objective optimizations, we find that the generation number had a strong effect on results. We found that with further tuning of the GA parameters, primarily generation number, better results may be obtained.

The best solution for this discrete problem is a robotic assembly with an optimal CubeSat development and deployment process. The solution to this problem satisfies single-route constraints, collective constraints, and the mission budget constraint. A constraint that the on-orbit assembly must be conducted by two dexterous robot arms and must take five minutes or less to assemble a 10-component CubeSat is satisfied. We optimize the on-orbit assembly time of small satellites using dexterous COTS robot arms while satisfying the given power consumption and weight requirements and minimizing humans-in-the-loop. Assembly time is selected as it is critical to the assertion that building small satellites on-orbit results in reduced cost and satellite development time on Earth.

4 Robotic Assembly of a 1U CubeSat

4.1 Introduction

This section describes the approach, implementation, and test process by which two LewanSoul xArm Robots with 6-DOF (see Appendix for Data Sheet) and six servos were trained to sense, grasp, and assemble the CubeSat electromechanical boards.

4.2 Ground-Based Robotic Assembly

4.2.1 Robot Arm Sensor Evaluation The efficient use of sensors on dexterous robot arms is critical towards achieving a high-performance sensor/agility combination, particularly for space applications [69]. High performance metrics include a 95% success rate on indicators of task completion times, distance traveled, inverse motion, maximum velocities, amount of multi-axis control, and input control onset times along the three axes. The trade study evaluates five sensors (see Table 14) using weighted assessments for the maximum payload the sensor can grasp, degree of freedom offered, and weight of the sensor. Given that a Level 1 requirement includes the movement of a maximum payload of 2 kg, the sensors were rated with the highest weights going to the sensor to meet the 2 kg maximum payload requirement. Having six or more degrees of freedom offered on a COTS robot arm also meets the topological requirements for grasping components. Lastly, since the robot kit is required to weigh less than 3 kg, sensors that weighed the least were given a higher rating. When tallied, the weighted assessment outcome favors brushless motors and force-torque (FT) sensors, which are used at the end-effector (gripper).

Brushless motors are the preferred motors for space operations [70]. Most robotic applications require a multi-axis or six-axis FT sensor to give feedback to the robot about the end-effectors, which can be controlled along six axes (three translations and three rotations) [71]. To measure the effort in all six axes, the FT sensor usually combines information from a minimum of six unitary measuring elements such as strain gauges. Using the geometry of the measuring elements, the force and torque are computed along the axes and used in the robot control loop. FT sensors can also be leveraged for sensitive tasks including spiral and linear search, rotational insertion, and path recording [72][73].

Table 14. Sensor Study Outcome, where WA is the Weight Assessment of each parameter

Requirements—Sensors and generic servo motors are used for the movement and rotation of the joints. The following include final requirements - see Table 15 for a comprehensive requirements list - for the sensors and servo motors: ○ The system shall include one six-axis wrist force-torque sensor that measures the wrench (three forces and three torques) at the end-effector ○ Each of the four joint torque sensors shall include redundant strain gauge bridges that measure the output torque of each of the joints, attached to the output of each of the first four joints of the arm ○ The end-effector shall include link strain gauges that measure bending and twist strains for each of the links ○ Each servo motor shall have one motor current sensor that measures the motor current of each servo motor of the arm ○ Each motor shall be controlled using a motor controller board.

4.2.2 Approach Sensing and grasping parts by robot arms have been conducted in space since the 1970s [74][75][76] to aid astronauts with assembly or repair tasks [77]. The recent successful ground demonstration of NASA’s Dragonfly mission by Space Systems Loral (SSL) [78] highlights the feasibility of assembly without humans-in-the-loop with a custom-built robot arm. To grasp components, several COTS robot arms with impactive grippers [13][53] are assessed1.

Flow of Inputs and Outputs—The block diagram in (Figure 16) depicts the data connections from each servo motor to the controller board. The following block diagram depicts the flow of inputs and outputs from the robot arm kit. The FT Sensor is trained to receive software commands from a computer, which are passed to the Servo Controller board. The camera provides the pose of the 1U CubeSat components to the software to steer the capture trajectory and to determine when the component is within the robot arm’s capture envelope. The Servo Controller sends a command to the servo motors using amplifiers. The servo motors execute the command on the arm joint (shoulder, elbow or wrist) or sensor head rotation. The encoded action is sent back to the Servo Controller board, through the serial port, to the computer. The computer interprets the action and sends additional commands to the FT Sensor. While brushless direct current (DC) motors will be used for the space-qualified test, the LewanSoul pre-packaged kit-provided servo motors are used for the initial laboratory prototype.

1 Servo burnouts were encountered with other robot arm kits, specifically the Lynxmotion AL5D 4DOF Robot Arm Kit.

Figure 16. Robot Assembly Block Diagram depicting input and output flow from the system. (All servo motors serve the same function and possess the same characteristics.)

Requirements—For in-space robotic assembly to be feasible, we propose that the robot arms meet the Level 1 requirements in Table 15. All parts are expected to be examined for resilience in a space-relevant environment, by running a thermal vacuum test of all parts. Parts which cannot be space qualified will be swapped out or sealed, where necessary.

Table 15. Level 1 requirements for this body of work Requirements Rationale

The robot arms shall perform CubeSat For the “buy and fly” COTS arms to be feasible in assembly functions in a spacecraft space, the arms must be used in a locker with a thermal management system for thermal control

The robot arms shall sense, grasp, The objective of the research is to assemble a and assemble CubeSat components functional 1U CubeSat using both robot arms

Six degree-of-freedom (DOF) arms The selected topology provides sufficient with a kinematic configuration of maneuverability - forward/backward, up/down, yaw-pitch-pitch-pitch-yaw-roll left/right (in three perpendicular axes) combined with rotation about three perpendicular axes with 95% accuracy - to satisfy sense and grasp requirements, including partial single-fault tolerance, of 1U components

The robot arm joints shall be driven by Brushless motors present a feasible in-space option brushless motors, with a 30:1 gear without wear and tear associated with Foreign ratio and 256-count magneto-resistant Object Debris (FOD) encoders

Each robot arm shall weigh a The mass of the end-effector and inertia required to maximum of 3 kg move a 1U CubeSat

Each robot arm shall move a The mass of a 1U CubeSat, which is the final maximum mass of 2 kg assembled object, weighs a maximum of 2 kg

Each robot arm shall have a minimum The robot arms are expected to be enclosed with arm length of 1 m components within 1 m of reach

The robot arms shall use Inverse Inverse Kinematics is used to initialize a rotating Kinematics algorithms to sense and angle for each servo. Forward Kinematics is used to reach components compute the current target position. (It should be noted that Forward Kinematics is used to build a position relationship with the base-attached servo and the end-effector, also known as the impactive gripper.)

The robot arms shall use Velocity After comparing the current target position and goal Kinematics for target position error position to output an error, Velocity Kinematics is correction used to calculate the updated rotating angles. Velocity Kinematics is employed as a gradient to minimize error (to a threshold) and output rotating angles for each servo

The robot arms shall be mounted on a The first tests to assemble a CubeSat will be static platform for initial laboratory focused on assembly of a functional CubeSat. tests Further space qualification tests will assume a dynamic space environment

The robot arms shall be mounted on a Reaction wheels will be used to control the platform for space-qualified orientation of the base of the robot arms using a applications dynamics equation of motion for the system.

The robot arms shall sense target The camera provides the pose of the 1U CubeSat position using a camera components to the software to steer the capture trajectory and to determine when the component is within the robot arm’s capture envelope

4.2.3 Implementation The LewanSoul robots are selected because it is a low-cost COTS option. A Raspberry Pi camera is set atop a 1.5 ft tall post with an Arduino attached behind it. Red prototype boards in front of the two robot arms. The process begins with the Raspberry Pi camera capturing an image of the platform. OpenCV object detection [83] software libraries are used in a Python software program to identify the color-coded boards, calculating the center of the boards for grasp accuracy (by converting pixels to meters). After an image capture of the field, the pixel position of the boards’ center is calculated, resulting in two sets of (x, y) points in meters and pixels. The maximum range for the Lewansoul robot arms is +0.15 m to -0.15 m in the y-direction and 0 m to 0.3 m in the x-direction, which determines the placement of each arm and board stacks. Using Inverse Kinematics [47], the location values are detected and converted into a set of six angles. Given that there are six servos on each arm, the Raspberry Pi would send those angles to the Arduino for control of the arm through control of the six servos via the USB serial port. The arm proceeds to perform movements to grasp each board at target locations and begin assembly using specified location values. The process is repeated until a CubeSat has been assembled - see assembly sequence in Figure 17.

Figure 17: Sequence of Robot Arm Assembly of 1U CubeSat in under 8 minutes. 4.2.3.1 Mechanical Workmanship Several iterations of structural designs were necessary to align with the capabilities of the robotic arm and the lack of a human-in-the-loop. For instance, a robotically assembled structure, using a low-cost gripper, cannot use fasteners because the grippers are not small enough to pick up and install screws and latches. The end-effector’s ability to grip parts was a critical

design factor. Springs, screws, and parts smaller than 3 inches in diameter could not be gripped securely. Snaps were designed and used but required more torque than what is available in a low-cost robot to snap components securely into knobs. Therefore, a redesign of readily available CubeSat structures was necessary. After five iterations, we learned that magnets are indeed the best option to attach and assemble components to each other. We used additive manufacturing for design iterations for this work as it is effective for laboratory prototyping purposes. Figure 18 shows our current designs. We anticipate machining structural components for the flight demonstration. However, until a final solution is selected, we continue to iterate our designs for future Phases with 3D-printed parts.

Option 1 with rails and latches

Option 2 without side rails Figure 18. Two current best structural options

Figure 19. A rendition of the Camera Mount used on a 1.5 ft post to aid robotic assembly

After a feasible structure is selected, we create and use a representation of the assembly workspace (inside a spacecraft locker) to determine feasibility for robotic task execution. We approximate the assembly workspace and use a discrete model (see Figure 7) to capture the reachable space of the robot arms’ capabilities.

4.2.3.2 Robotic Algorithm To ensure the robot arms reach the target boards with a single calculation, open-loop control, which is faster than closed-loop control, is used. Control operations can be either closed-loop or open-loop. The key difference is feedback. An open-loop control system performs based on the input, and the output has no effect on the control action. However, a closed-loop control system looks at the current output and alters it to a desired condition. The control action in closed-loop systems is based on the output. Closed-loop control is best used when the measurements are feasible, and the process has a predictable response to an input control. It enables the process to be set on certain points within a given accuracy and automates correction to process disturbances. Yet with open-loop control, outputs rarely change and process disturbances are not the norm. Therefore, we select open-loop control as the better choice because no quantitative measurement is possible, as with an inaccessible or erratic process, and low-cost is a priority.

Software Serial Port on Arduino is used to control the six different servos, restricting the rotating limits for each servo first. The rotation range is between 0 and 240 degrees and the minimum increment, or accuracy, for each servo is 13.8 degrees. Using each servo’s unique ID number, their rotating duration and rotating position are controlled. In the Arduino code, we pre-defined several functions that move to the vertical initial position, move to target location based on input arguments, and move to bin location - move_to_initial(), move_to() and move_to_bin(), respectively. Serial Port is used to make Raspberry Pi 4 (RPi4) communicate with the Arduino. Six values are sent for each target location, one angle for each servo. The Arduino has only one serial port and needs to communicate with both the RPi3 and the six servos, so an additional hardware serial port was set up. A protocol requiring the RPi3 and Arduino to communicate and confirm messages was added to ensure all six values were sent

and for use as an error detection mechanism. Once complete, the camera would capture a new image of the boards to be processed.

Coverage Planning Functions—For task planning in 2D workspaces, we determine the viewpoints for the entire target surface using a randomized sampling. This randomized sampling as defined in the Traveling Salesman Problem (TSP) [16] enables three functions. The functions are the selection of components, assembly of components in required time (<50 seconds), and connect the components using the Genetic Algorithm in Section 3. We assume that path planning between specific goals dominates the runtime cost compared to the computation of approximate solutions to the TSP. It uses a lower bound estimation of the path length between goals to calculate candidate TSP solutions and uses the complete path planner for edges in candidate solutions.

Inputs:

Starget , target surface area A , All placement poses MR , Map of Reachability (predefined) Outputs: S , solutions list c , degree of coverage

T = Surfacepoints(Starget);

T coverage, all = Ø; R = findReachability (A, T , MR); S = []; while (T ∖T coverage, all =/ Ø ⋀ R =/ Ø do pmax = arg maxp∈A(||R(p)||);

(t, T coverage) = planCoverage(pmax, R(pmax));

A = A∖{pmax};

R = {(p′, T ′) ∈ A × P (T ) | T ′ = R(p′)∖T coverage}; R = {(p′, T ′) ∈ R | ||T ′|| > 0};

T coverage, all = T coverage, all ⋃ T coverage;

S = append(S, (pmax , t)); end ||T coverage, all|| c = ||T || ; return (S, c);

The robotic arm control algorithm [79] finds an appropriate solution to two key problems: path planning and robot arm placement. This is accomplished by using a divide and conquer strategy and optimization heuristic planning approaches to the reachability and the coverage problem.

The algorithm shows how we sample points from the target surface and use the points

T ⊂ Starget to estimate the progress of the coverage planning. We store all the points in the solutions in the set T coverage, all ⊆ T and align each pose (from the global set) p ∈ A ,with reachable target points from the predefined map of reachability. The main loop continues after this phase until R is empty or all target points are covered. Next we find the pose pmax , which includes the largest subset of the rest of the target points. We also use the coverage planner to find a trajectory t in as many points as possible in R(pmax) , which are stored in T coverage . Constraints like stability requirements are taken into account by the coverage planner. T coverage and p are removed from R by updating every entry (p′, T ′) ∈ R to remove the covered max points (p′, T ′∖T coverage). Entries with no reachable points are emptied during each timestep, which is 10 ms. Given the multi-step required, we use the Python time() function, to measure time and create a function to configure the clock and evaluate the microcontroller at 100 Hz. And for the last steps in the loop, we update the target points T by adding the points coverage, all in T coverage and adding (p , t) to the list of solutions. Upon completion of the while loop, max we find the degree of coverage.

4.3 Observations

The LewanSoul arms assembled structures and six prototype boards in under eight minutes. The robot arms were subjected to 170 hours of tests: all servo motors and rotation angles were tested to determine stability, accuracy, and feasibility of operation. We automated repetitive tests of each servo motor for over 120 hours, while the software for the satellite assembly was being programmed. There were initially errors in assembly as the robot arms kept missing the precise assembly area, structure spaces for board placement, and the correct angle for side boards. Therefore, while the boards were grasped within the first week of programming, we learned after five weeks of errors in placement to slow the speed of the arm movement by a factor of two as the robot arm approached the satellite assembly area. For instance, if the board was picked up by the robot arm moving in 1480 ms, we also move each servo motor (robot arm joint) in 1480 ms as the board approaches its final destination. When the board arrived at the assembly area, the board was lowered carefully into its intended position in 740 ms. Despite this slowdown, the robotic assembly of each component took approximately 22.25 seconds. It took the same amount of time to grasp mechanical structures as it did to grasp boards. Additional issues arose during the assembly process, such as loose grippers. The grippers became loose after over 100 hours of use and were not able to pick up the boards, which were sliding off the gripper pads. The grippers were subsequently tightened. On occasion, electrical tape was used on the gripper pads to retrain the gripper into a gripping position.

Figure 20. Robot Arm Power Consumption and repeatability of movements are predictable while the accuracy of the robot arms decreases after 120 iterations

Figure 21. PiCam Light Control for day and night

The camera lighting control was coded into the Python program; however, PiCam lighting control was used to ensure adequate lighting at all times (see Figure 21). Sometimes the LED did not work; tightening the bolts of the LED and camera, then restarting it solved the problem. Ultimately, errors were resolved, and the entire 1U CubeSat was assembled with no humans-in-the-loop in seven minutes and 39 seconds.

Using the Inverse Kinematics (IK) approach made for less intensive programming; however, using a robot arm as part of a larger system required a learning curve in robot automation and robotics programming. The Python code resulted in several hundreds of lines of code, which was human-intensive to create. There was a decline in the robot arm 95% accuracy requirement

after 120 iterations. We observed the robots become physically shaky and technically imprecise. For instance, although the robot arms were programmed with the correct coordinates, it kept missing the structure by 2 cm when installing a board. We added an error detection to the code and adjusted the distance for assembly in the assembly area to match 102-110% of the specified coordinates. All programming and CAD work was completed on an Apple Mac laptop with access to and use of standard Python libraries. The standard libraries used are pybullet, which includes calculateinversekinematics(), pybullet_data, math, time, datetime, and numpy. 4.4 Summary

Overall, the robots have shown the capacity to assemble a 1U lab prototype CubeSat in under eight minutes. However, power considerations require improved motors for ISS demonstration as servo motors burnout due to degradation after less than 200 hours of use. The end-effector (gripper) accuracy diminishes with time; therefore, exploration of precision (surgical) robots for flight is a required next step. Two COTS robot arms and servo motors have shown reliability concerns due to mechanical and degradation issues on the ground; therefore, conducting a future trade study on low-cost offerings for reliable motors and arms is key to moving forward.

Standardization of electromechanical CubeSat components for on-orbit assembly requires magnets and snaps for low-cost end-effectors. The potential for decreasing the lead time for CubeSat integration and assembly and savings in cost and schedule serve as justification to continue to refine and implement this work. It is clear that ultimately, the function rests with the robot arms. Available machines to support spacecraft development will foster faster scientific research and discoveries and would reduce schedule and cost (by an estimated 50%) associated with building a small satellite. We find that large custom-built robots are not the only vehicles for in-space robotic assembly. There is utility for precision robot companies to support aerospace robotic applications. As small satellites and constellation missions continue to evolve, demand for precise and rapid CubeSat assembly with no humans-in-the-loop will grow.

5 Summary and Future Work

5.1 Summary

On-orbit robotic assembly missions typically involve humans-in-the-loop and use large custom-built robotic arms designed to service existing modules. The concept of on-orbit robotic assembly of modularized CubeSat components supports use cases, such as rapidly placing failed nodes within a constellation of satellites and monitoring damaged assets in Low Earth Orbit. This work describes the potential and approach to on-orbit robot assembly of small satellites using low-cost robot arms. We show the feasibility of the robotic assembly of a 1U CubeSat and optimize for robotic assembly time. We demonstrate the laboratory prototype assembly of a 1U CubeSat and analyze the systems engineering process for the on-orbit

assembly of small satellites. The ground-based lab prototype has shown that robotic arm assembly of modularized components could be proven as a viable option for a new class of CubeSats. The assembly process used two dexterous COTS robot arms to assemble modular CubeSat boards fastened with magnets into a small satellite. The assembly steps for a 1U satellite, using open-loop control and a Python software program, required approximately five minutes to complete.

5.1.1 Flight Hardware Selection Observations and lessons learned from feasibility studies, analyses, and the robot arm demonstration have informed several flight considerations and highlighted the need for several future work efforts, such as investigating improved subsystems. For instance, considering precise (surgical) robot arms in the same form factor as the LewanSoul robot arms to overcome accuracy and precision issues and exploring durable motors for the flight demonstration, with low risk for burnout. We will train these new robot arms to sense, grasp, and assemble CubeSat flight modules. We also need to conduct a trade study on low-cost COTS robot arms versus precision surgical robot arms as the latter is likely to be costly and may negate the low-cost goal of the research. An optimization model, which simulates next-generation design and performance, to ensure energy optimization per CubeSat assembly will be conducted. We also intend to conduct environmental testing of the robot arms and assess the thermal and power budgets for lifetime expectation and self-maintenance. In addition, we use a spacecraft locker with thermal management control to reduce the risk of thermal concerns. Steps to improve the torque of the robot arms will be included in the space qualification requirements. Three activities must be conducted for a flight model. These activities are 1. The modularization of sensor payloads 2. The design and test of the locker, shelving and storage units for component modules including robotic arm accessibility 3. The build and test of FlatSat component modules.

5.1.2 Implications for In-Space Manufacturing The transferable technology includes a new CubeSat standardization of mechanical, electrical, power, and thermal components, the modularity of key spacecraft elements with different selectable sensors and/or propulsion units and a custom-built spacecraft locker that can be deployed at various orbit-agnostic locations such as in LEO and GEO for asset monitoring and constellation reconstitution (see Section 5.2). A comparison with the alternative - placing ready-made CubeSats in an on-orbit locker - has been made in Section 2.2.4 with a focus on packaging efficiency for launch. We show that a custom-configured locker filled with components for on-orbit assembly is more efficient by 2x. Reusability of CubeSat electrical/mechanical components and propulsion systems can help systems evolve to create different form factors.

We assume a free-flying spacecraft locker with as many as 120 CubeSats per locker is a reasonable expectation in LEO after the completion of the ISS technology demonstration. The

following are mission scenarios that might be included in the 120-CubeSat per free-flying locker. Communication variants to provide coverage for the scenarios below include crosslink (laser, RF), downlink (laser, RF), uplink (laser, RF), and single software-defined radio module with suitable Omni and High-Gain antennas for S- and X-bands. ● A single spacecraft with mission sensors, which could be Earth-pointing, space-pointing for Space Situational Awareness (SSA), IR/Synthetic Aperture Radar (SAR)/RF detection, dual-use or signals intelligence (SIGINT), etc. ● Two spacecraft for tip-and-cue, stereo imaging, change detection, or communications relay ● Three spacecraft for formation missions requiring synthetic aperture, multi-sensor intelligence (int), etc. ● Many spacecraft for swarm missions with massive redundancy, Position Navigation and Timing (PNT) replacement, and communications network.

5.1.3 Relevance and Benefits Reusability of CubeSat electrical/mechanical components and propulsion systems can help systems evolve to create different form factors. There have been subsystem-focused spacecraft as part of a swarm, limited by pre-built or pre-integrated spacecraft components. No program currently offers the ability to respond to emerging needs with any of the above configurations, which could result in high-performance target acquisition and unmatched pointing and stabilization accuracy.

The concept of operations for modular CubeSats assembled in space would partition the spacecraft into modules, which would be configurable into a wide variety of applications. Future use cases using different sensors on the spacecraft with variations in communications, sensors, propulsion, etc. would benefit multiple applications including constellation reconstitution and LEO and GEO asset monitoring as described below:

Discrete Building Blocks Application—Using Gershenfeld’s research on building blocks and discrete assembly [80], robotic assembly could be used to build a version of the Autonomous Assembly of a Reconfigurable Space Telescope (AAReST) mission [81]. AAReST has been developed by CalTech to solve the problem of manufacturing space-based optical telescopes with large primary apertures by autonomously assembling small independent spacecraft, each with its own mirror, while in orbit. The free-flyer concept is extensible to larger mission architectures, such as the concept of having large modular apertures [82]. If each of these mirrors is manufactured to have an identical initial shape and then adjusted upon assembly, a substantial reduction in manufacturing costs can be realized (CalTech).

GEO Application—For example, there is a specific GEO asset, which is broken or intercepted. The owner of the asset needs a closer look. An on-orbit assembled CubeSat with propulsion capability, and power could be rapidly deployed as a solution. The spacecraft locker located in GEO, with the capability for protection, would respond in less than six hours by robotically

assembling the CubeSat(s) required with the appropriate propulsion and battery capability and deploying the CubeSat(s) to the compromised asset.

LEO Application—If there exists an issue with a LEO asset, and an inspection is required quickly, the spacecraft locker in LEO could robotically assemble a CubeSat with an RF sensor to listen, a radar, or optical capability to respond. There may be a need for two propulsion systems or chemical propulsion to arrive at the LEO location as quickly as possible. The spacecraft locker in LEO - a smart locker with all components at the ready - would require no wait-time or launch from the ground. The spacecraft locker could assemble and deploy the needed CubeSat solution within hours for rapid-response. Note that if there exists pre-integrated spacecraft on-the-ground, a launch manifest, with a minimum of 35 days, is still required.

Figure 22. Example of LEO asset monitoring by a CubeSat robotically assembled on-orbit

Constellation Application—Several future cloud networks like DARPA’s BlackJack intend to produce using a satellite constellation that makes use of several nodes. If a node goes down, there are two options for recovery. The node needs to be replaced, or the number of satellites on a plane would need to be enlarged to close the link. The spacecraft locker would be available to robotically assemble a CubeSat with provided payload requirements to replace the node within hours.

Figure 23. Example of a constellation reconstitution by a CubeSat robotically assembled on-orbit

5.2 Future Work

As CubeSat subsystems continue to mature, the project will evaluate relevant components and payloads for robotic assembly testing and analysis. Future work will be focused on three objectives: 1. The introduction of a new CubeSat structural standard. The standard uses modular and reconfigurable electromechanical components, which includes providing propulsion capability, should the CubeSat need to change orbits. 2. The demonstration of space-qualified robotic assembly of a 1U CubeSat. A key step for space qualification involves the calculation of the link budget. The link budget is a theoretical calculation of the end-to-end performance of the communications link. It is calculated in four steps a. Finding the required signal strength at the receiver input - a function of the Modulation Technique and the desired BER b. Calculating the noise received by the antenna c. Defining the reference point to compute the performance of the link budget d. Using the signal-to-noise ratio (SNR) to determine the required margins have been achieved. 3. The tailoring of the systems engineering process to robotic small satellite assembly with no humans-in-the-loop.

5.2.1 Optimization Analyses for Assembled CubeSats One of the outstanding research studies is finding the optimal CubeSat power requirements and propulsion sizing to enable the CubeSats to maneuver to their destination on-orbit after assembly and deployment. For instance, determining the fuel requirements to go from 550 km in

a sun-synchronous orbit to 650 km requires different fuel needs than a CubeSat deployed from 550 km to 425 km. Preparing for such maneuvers require a propulsion feasibility study for the assembled CubeSats that includes optimization of delta-V maneuvers at the cost of relatively little propellant for CubeSats, a simulation of propellant efficiency of electric or chemical CubeSat-sized thrusters, and also the feasibility of miniaturized chemical propulsion modules.

5.2.2 Spacecraft Development Process System resources such as mass, power, and data rate will be allocated per subsystem and margined appropriately using the standard NASA System Engineering process. All mission areas will be scrutinized, risks identified, the payload’s driving electrical, mechanical, thermal, and software interfaces identified, and spacecraft requirements defined. In addition to requirements and interface development, we will track compliance, manage risk, and resolve technical issues. Addressing issues such as the closure of action items, hardware discrepancies, test anomalies, etc. following NASA’s approved ISO9000 process. Technologically mature components will be used to demonstrate performance requirements initially with only routine environmental qualification required to reach TRL 7 before preparations for space operations. We intend to launch at room temperature and under ambient atmospheric pressure, greatly simplifying launch qualification.

5.2.3 Space Qualification We continue this work with a research focus on implementing space-qualifying parts for a ground-based demonstration of the assembly of a functional 1U CubeSat in a relevant space environment. The robot arms will undergo environmental testing to assess thermal constraints, materials properties, power budget, and lifetime expectation. In addition, the robot arms and modular CubeSat components will undergo thermal vacuum chamber tests for survivability to meet TRL 7. Lastly, we present future work for a space-qualified prototype of the system - two dexterous robot arms and modular electromechanical CubeSat parts - to demonstrate the technology in a relevant space environment. This future work includes a closed-loop implementation, color coding, and sorting by the robot arms for different components and the exploration of a jukebox-inspired on-orbit shelving unit.

Table 16. Future space qualification tests to ensure operation in a space-relevant environment. Space Qualification Test Goals

To assure that the robot arms can survive Vacuum Survivability vacuum without rupturing in a vacuum environment

To assure that the robot arms and spacecraft Vacuum Operation locker can perform predictability in a vacuum environment

To control with heaters to have an operational Thermal Vacuum environment across various temperature (0 C to 40 C)

To understand the effects of space-like radiation Radiation Testing and interrupted assembly on the spacecraft locker and on-orbit robotic assembly

To understand how the performance of the Zero G Testing spacecraft locker change and impact robotic assembly in a microgravity environment

6 References

[1] Doggrell, Les. Operationally responsive space: a vision for the future of military space. AIR UNIV MAXWELL AFB AL AIRPOWER JOURNAL, 2006.

[2] Northrop Grumman. "Companies demonstrate groundbreaking satellite life-extension service." [Online]. Available: https://news.northropgrumman.com/news/releases/northrop-grumman-successfully-completes-h istoric-first-docking-of-mission-extension-vehicle-with-intelsat-901-satellite

[3] Flores-Abad, Angel, et al. "A review of space robotics technologies for on-orbit servicing." Progress in Aerospace Sciences 68 (2014): 1-26.

[4] Kerzhner, Aleksandr A., et al. "Architecting cellularized space systems using model-based design exploration." AIAA SPACE 2013 Conference and Exposition. 2013.

[5] Hill, Lisa, et al. "The Market for Satellite Cellularization: A historical view of the impact of the satlet morphology on the space industry." AIAA SPACE 2013 Conference and Exposition. 2013.

[6] Barnhart, David, et al. "Changing satellite morphology through cellularization." AIAA SPACE 2012 Conference & Exposition. 2012.

[7] Jaeger, Talbot, and Walter Mirczak. "Satlets-the building blocks of future satellites-and which mold do you use?." AIAA SPACE 2013 Conference and Exposition. 2013

[8] Ceccacci, Anthony, Dye, Paul. “Contingency Shuttle Crew Support (CSCS)/Rescue Flight Resource Book.” National Aeronautics and Space Administration (2005): 89.

[9] Kawasaki, Kazuyoshi. "Overview of JEM-EF on ISS." Proceedings of the RIKEN Symposium. Saitama. 2008.

[10] Steimle, Per C., et al. "Commercial Approach to Research Outside the International Space Station-A Small Size Precursor Service For Future In-Orbit Testing." AIAA SPACE 2014 Conference and Exposition. 2014.

[11] Steimle, Christian, and Uwe Pape. "ISS External Payload Platform-a new opportunity for research in the space environment." 40th COSPAR Scientific Assembly. Vol. 40.

[12] LeMaster, Edward, David Schaechter, and Connie Carrington. "Experimental demonstration of technologies for autonomous on-orbit robotic assembly." Space 2006. 2006. 7428.

[13] Sun, Yongjun, et al. "Design and optimization of a novel six-axis force/torque sensor for space robot." Measurement 65 (2015): 135-148.

[14] Walker, Michael W., and L-B. Wee. "Adaptive control of space-based robot manipulators." IEEE Transactions on Robotics and Automation 7.6 (1991): 828-835.

[15] Murbach, Marcus S., et al. "The SPQR as an Option for Returning Payloads from the ISS after the Termination of STS Flights." Proceedings of the 40th International Conference on Environmental System, AIAA-2010-6223. 2010.

[16] Applegate, David L., et al. The traveling salesman problem: a computational study. Princeton university press, 2006.

[17] Zuniga, David, et al. "Conceptual Development of a Payload Thermal and Pressure Control System for a Small Payload Quick Return Vehicle." 40th International Conference on Environmental Systems. 2010.

[18] Murbach, M. S., et al. "Modeling the Exo-Brake and the Development of Strategies for De-Orbit Drag Modulation." (2016).

[19] Roa, Máximo A., et al. "Robotic technologies for in-space assembly operations." Proc. 14th Symp. Adv. Space Technol. Robot. Autom.. 2017.

[20] Belvin, Wendel K., et al. "In-space structural assembly: Applications and technology." 3rd AIAA Spacecraft Structures Conference. 2016.

[21] Fiorillo, Fausto, et al. "Soft magnets for passive attitude stabilization of small satellites." IEEE Transactions on Magnetics 46.2 (2010): 670-673.

[22] Springmann, John C., Andrew Bertino-Reibstein, and James W. Cutler. "Investigation of the on-orbit conjunction between the MCubed and HRBE CubeSats." 2013 IEEE Aerospace Conference. IEEE, 2013.

[23] Rawashdeh, Samir Ahmed. "Passive attitude stabilization for small satellites." (2010).

[24] CubeSat Design Specifications, The CubeSat Program Std., Rev. 12, August 2009. [Online]. Available: http://cubesat.org/images/developers/cds rev12.pdf

[25] "Code of Federal Regulations Title 47 Part 15.247" in Federal Communications Commission Tech. Rep., Federal Communications Commission, 2015.

[26] Shimmin, Rogan, et al. "The successful PhoneSat WiFi experiment on the Soarex-8 flight." 2016 IEEE Aerospace Conference. IEEE, 2016.

[27] Selva, Daniel, and David Krejci. "A survey and assessment of the capabilities of Cubesats for Earth observation." Acta Astronautica 74 (2012): 50-68.

[28] Walker, Roger, et al. "Deep-space CubeSats: thinking inside the box." Astronomy & Geophysics 59.5 (2018): 5-24.

[29] NASA. “CubeSat Launch Initiative”. [Online]. Available: https://www.nasa.gov/content/about-cubesat-launch-initiative

[30] Spaceflight. “Schedule and Pricing”. [Online]. Available: https://spaceflight.com/schedule-pricing/

[31] Nanoracks. “Frequently Asked Questions”. [Online]. Available: https://nanoracks.com/resources/faq/

[32] Virgin Orbit. “Service Guide”. [Online]. Available: https://virginorbit.com/wp-content/uploads/2019/09/ServiceGuide_Sept2019.pdf

[33] NASA. “International Space Station Basics”. [Online]. Available: https://www.nasa.gov/pdf/179225main_ISS_Poster_Back.pdf

[34] Trad.fr. OMERE Installation File. [Online]. Available: http://www.trad.fr/download/packages/OMERE_Install.exe

[35] Sinclair, Doug, and Jonathan Dyer. "Radiation effects and COTS parts in SmallSats." (2013).

[36] Piskorz, D. A. N. I. E. L. L. E., and K. Jones. "On-Orbit Assembly of Space Assets: A Path to Affordable and Adaptable Space Infrastructure." The Aerospace Corporation(2018).

[37] Katz, Daniel S., and Raphael R. Some. "NASA advances robotic space exploration." Computer 36.1 (2003): 52-61.

[38] Putz, Peter. "Space robotics in Europe: A survey." Robotics and Autonomous Systems 23.1-2 (1998): 3-16.

[39] Weisbin, Charles R., and Guillermo Rodriguez. "NASA robotics research for planetary surface exploration." IEEE Robotics & Automation Magazine 7.4 (2000): 25-34.

[40] Whelan, David A., et al. "Darpa orbital express program: effecting a revolution in space-based systems." Small Payloads in Space. Vol. 4136. International Society for Optics and Photonics, 2000.

[41] Barnhart, David, et al. "Phoenix program status-2013." AIAA SPACE 2013 conference and exposition. 2013.

[42] Smrekar, Sue, and B. Banerdt. "The InSight mission to Mars." The 8th Mars Conference. Vol. 18. 2014.

[43] Sallaberger, Christian, Space Plan Task Force, and Canadian Space Agency. "Canadian space robotic activities." Acta astronautica 41.4-10 (1997): 239-246.

[44] Laryssa, Patten, et al. "International space station robotics: a comparative study of ERA, JEMRMS and MSS." 7th ESA Workshop on Advanced Space Technologies for Robotics and Automation. 2002.

[45] Hirzinger, Gerd, et al. "Sensor-based space robotics-ROTEX and its telerobotic features." IEEE Transactions on robotics and automation 9.5 (1993): 649-663.

[46] Hirzinger, G., et al. "Robotics and mechatronics in aerospace." 7th International Workshop on Advanced Motion Control. Proceedings (Cat. No. 02TH8623). IEEE, 2002.

[47] Rodgers, Lennon, Simon Nolet, and David W. Miller. "Development of the miniature video docking sensor." Modeling, Simulation, and Verification of Space-based Systems III. Vol. 6221. International Society for Optics and Photonics, 2006.

[48] Bualat, Maria, et al. "Astrobee: Developing a free-flying robot for the international space station." AIAA SPACE 2015 Conference and Exposition. 2015.

[49] Parrish, J. "Robotic Servicing of Geosynchronous Satellites (RSGS)." Defense Advanced Research Projects Agency (DARPA).[Online]. Available: https://www. darpa. mil/program/robotic-servicing-of-geosynchronous-satellites.

[50] B.E. Kelm, et al. FREND: Pushing the Envelope of Space Robotics. Space Research and Satellite Technology. 2008 NRL Review.

[51] Reed, Benjamin B., et al. "The restore-L servicing mission." AIAA SPACE 2016. 2016. 5478.

[52] Lymer, John, et al. "Commercial application of in-space assembly." AIAA SPACE 2016. 2016. 5236.

[53] Patane, Simon, John Schomer, and Michael Snyder. "Design Reference Missions for Archinaut: A Roadmap for In-Space Robotic Manufacturing and Assembly." 2018 AIAA SPACE and Astronautics Forum and Exposition. 2018.

[54] Kingsbury, R., et al. "TID tolerance of popular CubeSat components." 2013 IEEE Radiation Effects Data Workshop (REDW). IEEE, 2013.

[55] Keys, Andrew, et al. "A review of NASA's radiation-hardened electronics for space environments project." AIAA SPACE 2008 Conference & Exposition. 2008.

[56] James, Stephen, et al. "Sim-to-real via sim-to-sim: Data-efficient robotic grasping via randomized-to-canonical adaptation networks." Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2019.

[57] Gilmore, Cheser, et al. "Flexible, High Speed, Small Satellite Production." (2019).

[58] Grim, Braden, et al. "MakerSat: A CubeSat Designed for In-Space 3D Print and Assembly." (2016). 30th Annual Conference on Small Satellites.

[59] Earth Observatory Portal Directory. “MakerSat”. [Online]. Available: https://directory.eoportal.org/web/eoportal/satellite-missions/m/makersat

[60] NNU. “NNU’s MakerSat-1 CubeSat Assembly.” [Online]. Available: https://youtu.be/shLPETczsF4

[61] Sternberg, David, et al. "Multidisciplinary system design optimization of on orbit satellite assembly architectures." 2015 IEEE Aerospace Conference. IEEE, 2015.

[62] Števo, Stanislav, Ivan Sekaj, and Martin Dekan. "Optimization of robotic arm trajectory using genetic algorithm." IFAC Proceedings Volumes 47.3 (2014): 1748-1753.

[63] Spensieri, Domenico, et al. "Optimal robot placement for tasks execution." Procedia CIRP 44.Supplement C (2016): 395-400.

[64] Goldberg, David E., and John Henry Holland. "Genetic algorithms and machine learning." (1988).

[65] Eiben, Agoston E., and James E. Smith. Introduction to evolutionary computing. Vol. 53. Berlin: springer, 2003.

[66] Holland, John. "Adaptation in natural and artificial systems: an introductory analysis with application to biology." Control and artificial intelligence (1975).

[67] Davidor, Yuval. "Analogous crossover." Proceedings of the Third International Conference on Genetic Algorithms. 1989.

[68] Nanoracks. “How to Build a NanoLab Payload.” [Online]. Available: https://nanoracks.com/wp-content/uploads/How-to-Build-a-NanoLab-Payload.pdf

[69] Hirzinger, Gerd, et al. "On a new generation of torque controlled light-weight robots." Proceedings 2001 ICRA. IEEE International Conference on Robotics and Automation (Cat. No. 01CH37164). Vol. 4. IEEE, 2001.

[70] Murugesan, S. "An overview of electric motors for space applications." IEEE transactions on industrial electronics and control instrumentation 4 (1981): 260-265.

[71] Li, Y. F., and X. B. Chen. "On the dynamic behavior of a force/torque sensor for robots." IEEE Transactions on Instrumentation and Measurement 47.1 (1998): 304-308.

[72] Tsujimura, Takeshi, and Tetsuro Yabuta. "Object detection by tactile sensing method employing force/torque information." IEEE Transactions on robotics and Automation 5.4 (1989): 444-450.

[73] Liu, Guangjun, et al. "A base force/torque sensor approach to robot manipulator inertial parameter estimation." Proceedings. 1998 IEEE International Conference on Robotics and Automation (Cat. No. 98CH36146). Vol. 4. IEEE, 1998.

[74] Watson, Judith J., Timothy J. Collins, and Harold G. Bush. "A history of astronaut construction of large space structures at NASA Langley Research Center." Proceedings, IEEE Aerospace Conference. Vol. 7. IEEE, 2002.

[75] Doggett, William. "Robotic assembly of truss structures for space systems and future research plans." Proceedings, IEEE Aerospace Conference. Vol. 7. IEEE, 2002.

[76] Bruner, Wesley, Carlos Enriquez, and Sreekumar Thampi. "Mechanism analysis and verification approach for ISS truss assembly." 37th Aerospace Mechanisms Symp. 2004.

[77] Hastings, Daniel E., and Carole Joppin. "On-orbit upgrade and repair: The hubble space telescope example." Journal of spacecraft and rockets 43.3 (2006): 614-625.

[78] NASA, Tech Demonstration. "NASA’s Dragonfly Project Demonstrates Robotic Satellite Assembly Critical to Future Space Infrastructure Development." (2017).

[79] Paus, Fabian, et al. "A combined approach for robot placement and coverage path planning for mobile manipulation." 2017 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). IEEE, 2017.

[80] Langford, Will, et al. "Hierarchical assembly of a self-replicating spacecraft." 2017 IEEE Aerospace Conference. IEEE, 2017.

[81] Underwood, Craig, et al. "Using CubeSat/micro-satellite technology to demonstrate the Autonomous Assembly of a Reconfigurable Space Telescope (AAReST)." Acta Astronautica 114 (2015): 112-122.

[82] Karlow, Brandon, et al. "Tradespace investigation of strategic design factors for large space telescopes." Journal of Astronomical Telescopes, Instruments, and Systems 1.2 (2015): 027003.

[83] Druzhkov, P. N., et al. "New object detection features in the OpenCV library." Pattern Recognition and Image Analysis 21.3 (2011): 384.

Appendix

LewanSoul xArm Robot User Manual and Data Sheet

67 xArm User Manual Warming tips 1.When the robotic arm moves, please keep your fingers away from the range of motion, prevent from getting hurt. If it operates normally, disconnect the power firstly. 2. Please remember to tun off the switch if there is something wrong with servo and examine whether the servo wire loose or not. 3. Please don't forcibly twist the joint when the robotic arm is powered on so that it will not cause any joint damage. 4. Robotic arm's servo that we used is a high-precision device and also a consumable so that it needs to be replaced after a long time use. 5. The heat of servo will raise if the robotic arm keeps running for a long time. You should make the robotic arm take a rest until it totally cool down so that it can keep on running. Please remember to turn off the switch while you are not using it. 6. In the case of power-on, do not forcefully pull on each joint. If you need to adjust, please connect the USB and click on the motor in the software to power off. 7. When connecting to Bluetooth, connect directly in the APP. Do not connect in the phone settings. 8. If you do not use the robot arm for a long time, be sure to close the control board switch and disconnect the battery connector to prevent the battery from being damaged. 9. If the xArm emits a " DiDiDi" sound during use, that is the low-voltage alarm circuit in the circuit starts working, please check if the power adapter is properly powered. 10. If you find other control methods are normal during use, but the handle and mouse control does not respond, please re-plug. The signal interface or data head on the servo control board jack. 11. If you connect the MCU outside, please refer to the secondary development communication protocol and communication program included with our data, and strictly abide by the need to perform it (this function is only applicable to customers with sufficient programming basis and function) 12. If you still have any questions, please feel free to contact us at [email protected]. Catalog

Warming tips 1 Introduction...... 1 1.1 Product introduction...... 1 1.2 Features...... 1 2 Main assembly...... 2 2.1 Product list...... 2 2.2 Product parameters ( Scratch/Arduino)...... 3 2.2 Assembly and wiring...... 3 3 Serial servo controller and servo...... 5 3.1 Serial servo controller...... 5 3.2 Serial bus servo...... 6 4 Install...... 7 4.1 xArm PC software...... 7 4.2 Mobile phone APP...... 9 5 Control methods and Programming...... 10 5.1 Computer control (Computer programming)...... 10 5.1.1 Normal mode...... 10 5.1.2 Servo test...... 16 5.2 Mobile phone App control...... 18 5.3 Handle control...... 23 5.3.1 How to connect wireless handle...... 23 5.3.2 function of wireless handle...... 24 5.4 Mouse control(Support wired mouse and wireless mouse)...... 26 5.5 Hand offline control (Manual programming )...... 27 6 Secondary development...... 29 6.1 Overview...... 29 6.2 WeMake Software...... 30 6.2.1 What’s WeMake Software...... 30 6.2.2 How to install WeMake on your computer...... 30 6.2.3 Install the driver...... 35 6.2.4 Gameplay and Programs...... 37 6 Contact us...... 41 7 Troubleshooting...... 42 8 The Historical version of the user manual...... 44 1 Introduction 1.1 Product introduction xArm is a programmable mechanical arm with feedback, it contains six high-life serial servos. Each servo can display temperature, position, voltage. Servo with RGB indicator. Observe the working status of the servo. Unique link structure design and oxidation blasting surface treatment make its body more beautiful and cool.It supports computer programming control, mobile phone and joystick control, and can also be manually programmed offline. The tutorial and development materials are very detailed. I believe this xArm can bring you a lot of knowledge and fun. We have prepared a second development kit, which contains more than a dozen electronic modules and structural components. For details, refer to Chapter 6. The robot not only provides The opportunity for hands-on assembly is even more a robot for learning programming. This robot has many advantages from design to workmanship and development. Its unique design, excellent workmanship, and after several updates and optimization, it can complete multiple tasks and develop gameplay, and more gameplay are waiting for you to discover. Hope that xArm can be a good partner in your study and life!

1.2 Features A Powerful power: Using serial bus servo LX-15D as a power source for robotic arms. Full metal gear, high precision imported potentiometer. Torsional force, precise angle. Servo support angle read back, voltage feedback, temperature feedback, alarm indicator and servo protecting . B Powerful master control system: Robotic controller uses ARM core CPU, built-in Bluetooth module and 16M Storage memory, single action group can hold 510 actions. Better experience programming fun. C Simple wiring scheme: Direct connection 7.5V DC power adapter, no need for any voltage regulator module. The handle receiver uses terminal design, plug and play, so greatly reduces the difficulty of wiring and saves time. D Suction cup design: Using the vacuum chuck, the robot arm can be stably fixed on the table to prevent the robot arm from slipping due to movement. E Various programming methods and control methods:Support mobile programming, computer programming and offline manual programming and support mouse, mobile phone, handle, computer control. F Extensive development: Support for secondary development of Scratch/Arduino, providing rich tutorials

1 2 Main assembly 2.1 Product list

Full metal structure bracket 1pc USB cable 1pc Power adapter 1pc handle receiver 1pc PS2 wireless handle 1pc serial bus servo controller 1pc LX-15D serial bus servo 5pcs

2 2.2 Product parameters ( Scratch/Arduino) Weight About 1100g

Programming method Scratch, Arduino

Bluetooth module Support

Package Dimensions 185*170*430mm

Input Ultrasonic sensor module, touch button module, infrared module,sound sensor, Line-tracking sensor, potentiometer module Output Digital tube module, LED lattice module, RGB LED module, Mechanical arm

Offline mode Bluetooth module

Microprocessor Arduino UNO

Power supply Input:AC100-240V-50/60Hz Output:DC 7.5V

2.2 Assembly and wiring

(1) We provide detailed 3D animation to show you how to assemble and wiring the robotic arm, please refer to the link and QR code.

3 Link QR code

http://bit.ly/2L6ys8a

Lesson 2 xArm assembly

http://bit.ly/2slbzXx

Lesson 3 Wiring

4 3 Serial servo controller and servo 3.1 Serial servo controller

Wireless handle interface: Connect handle receiver. Buzzer with low voltage alarm: Low voltage alarm has prompt function, if the power supply is below 5V, the servo controller will make sound of beep(DIDI), please replace the battery or charge the battery in time. USB connector: Connect xArm with computer. Communication interface of secondary development:Support secondary development (It can directly connect to some SCM like Arduino and Raspberry Pi.) Offline run button: The robot runs action group automatically; 1. Download action files that need to be run offline to No.100 action group 2. Press the flexible button on the controller 3. Press once to offline run button once; press and hold for 3 seconds (until the blue light flashes) and it will run all the time. 4. Restart the controller to remove the cycle run. Servo connection port: Connect bus servo; Controller switch: Control the power on the controller; DC power jack: Connect power adapter; Bluetooth: Matching on mobile phone’s Bluetooth; LED power indicator: Marked the work status of controller. The light keeps red, which means the controller power supply in a normal state. LED signal indicator: Turn on switch and light showing green. But when a signal is sent, the light will start to flash until the action group is done.

5 3.2 Serial bus servo

Servo LX-15D(Essential parameter) Product name: LX-15D Serial Bus Intelligent Servo Product weight: 43.3g Product size: 44.02mm*22.92mm*27.00mm Rotation speed: 0.18sec/60degree(4.8v) 0.15sec/60degree(6v) Servo accuracy: 0.24degree Corner range: 0-240degree(deviation30 degree) Stall torque: 15kg.cm(6v) 17kg.cm(7.4v) Servo ID: 0-253(user settings) Storage: Power down and save user settings Work voltage:5-8.4V Length of wire:10cm, other Feedback features: Support Control style: Serial Communication baud rate: 115200 Motor type: Carbon (310:1) Gear type: Metal Parameter feedback: Temperature, Voltage, Position

6 4 Install

4.1 xArm PC software Here is the link and QR code of xArm PC software: link QR code

http://bit.ly/2BY4u6h

Open the website link or scan the QR code. Select “ xArm setup V2.2” to download. (1) Please open the Installation package and download it on your computer.

(2) Installation steps

To select the “ Create a desktop shortcut” and click “ Next” to continue.

7 The installer now prepare to install xArm into your computer click install to “ Next” with this installer, you want to review or change the settings, please click “ Back”.

The xArm installation wizard finishes. The installer has installed xArm into your computer, this application can be run by selecting the installed shortcut. Click “ Finish” exit the installer.

8 4.2 Mobile phone APP Here are the link and QR code concerning mobile phone app of xArm:

Types Android System iOS System Link http://bit.ly/2Fvg3jr https://apple.co/2Cv7ovh

QR code

(1) Please open the Installation package and download it on your mobile phone.

(2) After successful installation, you will see this icon on your mobile phone.

9 5 Control methods and Programming 5.1 Computer control (Computer programming) Open the PC software, you can see the page like this. “ Normal mode” and “ Servo Test”. USB cable to connect the computer Adapter to connect socket

5.1.1 Normal mode Here is the interface of PC software:

10 The introduction of servo xArm has 6 servos, the order of the servos by number from up to bottom: ID:1, ID:2, ID:3, ID:4, ID:5, ID:6. When connect successfully, we can drag the slider to change the position of the robotic arm.The range of servo 1 is 0-1000.

11 Action group Select the action group number, range 0~230. For example, selected action group number is 10 , click download button , then the No.10 action group will be download to controller. When you add action group number is 10 on you phone APP, it will run the No.10 action group

The edited action group is downloaded to the controller and After selecting the the controller will action group number, save the action group click this button and the information. corresponding action group information in Erase all action group in the controller can be controller. deleted. Tips: Be careful! Click this button and all group actions on you control will be erased.

Press this button to let the Stop action group operation. controller run the corresponding numbered action group

12 Display the deviation in the controller Deviation Tips: xArm needs to adjust the deviation of the servo. It is because of the existence of the position value and the deviation value, so the actual position of the servo should be the position + deviation.

When the deviation of each servo is adjusted, click it and the all deviations will be downloaded to

The reset deviation will not change the deviation parameter in the controller, only the deviation parameter in the reset interface is 0 when you click again to read the deviation. The actual deviation in the controller will be displayed again in the interface.

Run online

When you connect xArm and add a series of actions, you need to test your actions consistently, you can click this button to test, check the loop can always cycle your edited action.

The servo parameter is 1500. Back to middle position.

13 Action file

Open the previously saved action file with the unified suffix name .rob. After opening, action items will be loaded into the interface.

When you design your own action content, you need to save these actions in the form of a file for the next time. The suffix is .rob

You can open multiple action group files and chain them together

(1) Language

The software automatically recognizes languages(According to the system language), supports Simplified Chinese, Traditional Chinese, and English, and can also be manually switched. (2) Connection button you can see a red light. Is it the connection indication.when you connect the PC software to the controller,it will change to green and you can begin your programming.

No connection Connected or connection failed

(3) Servo slider

ID number Servo position slider

Position of servo

Deviation value of servo Servo deviation slider

14 Note: The servo slider can be dragged freely, with a range of 0-1000, the range of deviation is -125-125. (4) Action adjustment

Index: Action sequence number Time(ms): The longer the required running time, the slower the action.

The time for the action group to run. The longer the time, the slower the action(ms). We can adjust action group to run by time.

Turn off motor power.

To read the position of servo.

Record servo position value and action time information as an action item.

Select an action to delete.

After adjusting the servo value, click this button to update the selected action

Insert an action group action before the selected action group

15 5.1.2 Servo test

Note: 1. Before adjustment the servo, make sure that the servo controller is connected only one servo, otherwise it may cause a conflict. 2. If the servo control board is connected with all the servos during adjustment. Then , click “Apply” icon, all the servos being set to the same ID. After it, all the servos are running at the same time, the xArm is not working properly.

the ID number of servo (1.Select the servo number being tested) (2.Reset number for the servo)

the deviation of servo

16 Angle range adjustment (the range is 0-1000)

If you select Led warning, when temperature, voltage or position higher than you set , the LED will flash. Voltage adjustment ( the range is 4.5-12) Temperature adjustment( the range is 50-100 )

“ Read status” will display voltage, temperature, position of servo. There are two modes: Servo mode and Motor mode.

17 Please select the mode before the test . There is “Speed adjustment” in the motor mode, the range is -1000 to 1000. There are “ Time adjustment ”and “ Position adjustment” in the servo mode. The time adjustment range is 0-3000, the position adjustment range is 0-1000.

5.2 Mobile phone App control (Take Android as an example) (1) Open the mobile phone and you will see this page. There are three parts. My xArm, Create and My action.

1. If you click the My xArm , you can connect xArm by Bluetooth. Please connect the power and turn on the power switch. The LED1 is bright. Open mobile phone APP and Bluetooth, search for xArm (Please remember using the bluetooth inside our phone app rather than using the one of the system.)

18 Select xArm and click it , Bluetooth indicator is blue which means the robot connected successfully

Here is a introduction of the 3 part of the icon: 1. If you click My xArm, it is a mobile programming process. Enter the programming mode, please adjust servos angle and add to the action group. You will see the picture below:

19 “Bluetooth” Reset servo back to icon middle position 500 “ Back” icon

Servo 2 Servo 1 Servo 3

Servo 4

Servo 5

Servo 6

Servo Instructions

Servo 1 Mechanical paw “Close” and “ Release” ( the range is 0-1000)

Servo2 xArm Left and Right rotation( the range is 0-1000)

Servo3 xArm Down and Up movement( the range is 0-1000)

Servo4 xArm Back and Forward movement( the range is 0-1000)

Servo5 xArm Back and Forward movement( the range is 0-1000)

Servo6 xArm Left and Right rotation( the range is 0-1000)

20 If you click Custom button in the lower left corner, you will see the screen shown below:

If you select “ Cancel” and back to initial page. But select “ Add”, you can add action group. Input action name and action group number,then to click “ Ok” . You have added action groups. You can add action that you have programmed before into xArm if you click Add, then you can operate it on your xArm.

21 2. If you click Create button, you will see the screen shown below:

If you click the Actions button, you can store actions you have added. If you click About us button, it will show the version about the App and some other information, you will see the screen below:

3. If you click My action button, you will see the screen below: Click it you can download and save the action you have added.

To display action you have added.

Turn off power of motor. Note: After performing the operation of motor power down, the xArm joint will become loose. Place the arm in a Add to action current operation of smooth and open place the servo. to avoid damage.

22 Loop run the added action group. 5.3 Handle control

5.3.1 How to connect wireless handle

(1) First, connect wireless handle receiver to controller and open the switch on the xArm.

(2) The handle requires 2 AA batteries(self-provided), open the power switch of the handle. When the two LED lights on simultaneously, the connection is finished. Then you can run the action group saved by upper computer software.

23 5.3.2 function of wireless handle There are two modes in wireless handle: action group mode and single servo mode. The following instruction the two modules. A action group mode instruction Action group mode is the default mode. In this mode, every button of wireless handle corresponds to one action group. We can download action group to servo controller and make servo controller execute one certain.

B single servo mode instruction What if we want to change it to single servo mode? Click “Select” button first, keep pressing it and check “start” button, after hearing a sound of “beep”, it has changed single servo mode.

24 Note 1. You need to insert handle receiver into the pot, and then switch on before showing. (if you want to knowledge about using wireless handle to control xArm, please click it:

Link QR code

http://bit.ly/2IQLdal

25 5.4 Mouse control(Support wired mouse and wireless mouse)

Whether it is a wireless mouse or a wired mouse, it can be manipulated. Using the cable to connect them. After being connected the xArm can be directly controlled. The rotation of each joint of the robotic arm by moving the mouse. We provide detailed video to show you how to control xArm by mouse, please refer to the link and QR code.

Link QR code

http://bit.ly/2l4yAdK

Lesson 9 Mouse control

Control the servo 1 and the Moving the mouse wheel release or close of the mechanical gripper

Click the left button and move to left or right servo2 being controlled

Pressing right button move Control the servo3 forward or backward

26 Forwards or backwards with left button Control the servo4

Without clicking any buttons only forward or control the servo5 and backward or moving to the servo6 left or to the right

5.5 Hand offline control (Manual programming )

We provide detailed video to show you how to program xArm’s action by hand, please refer to the link and QR code. Link QR code

http://bit.ly/2H6G6gm

Lesson 14 How to program xArm’s action by hand

1. Turn on the switch.

2. Long pressing the “ program” button and you hear a sound of beep means you can use your hand to control xArm.

3. After designing one action, you need to press “ program” button again until finally. 4. If you finish all the actions do not forget to click “ program” button again, which means recording all the actions. 5. Click “ run” button, the xArm will be run actions.

27 Note: The function of this part is different from other control methods. It does not need to be programmed through mobile phones, computers, etc. It can be programmed directly by hand. This means that xArm can be programmed manually offline to make it feedback manual control of a series of operations.

28 6 Secondary development 6.1 Overview This sensor and module kit is only for xArm robotic arm, It can't be used alone, you need to use it with xArm robotic arm. To make xArm more functional and creative, we have prepared a secondary development package for everyone. With more than a dozen electronic modules and structural components, we can use Scratch or Arduino programming to implement various ideas and gameplay. We provide you with ten secondary development games for xArm, each with detailed program documentation and video tutorials. Help everyone to learn it! Here is the secondary development icon, link and QR code: Icon link QR code

http://bit.ly/2BY4u6h

Secondary development gameplay of xArm robotic http://bit.ly/2BFiMYJ arm

Here we briefly introduce the ten gameplay of secondary development and the sensors used in these ten methods. Gameplay: NO.1 One-way Detect, NO.2 Multi-way Detect, NO.3 Distance Detection, NO.4 Sound Control, NO.5 Touch Control, NO.6 Dot Matrix Display, NO. 7 Gesture Control, NO.8 Infrared Remote Control, NO.9 Adjust Speed, NO.10 Coloured Lamp by Knob. Sensor: Ultrasonic sensor module, touch button module, infrared module,sound sensor, line tracking sensor module, potentiometer module, digital tube module, LED matrix module, RGB LED module.

29 Software: WeMake

6.2 WeMake Software 6.2.1 What’s WeMake Software WeMake is a graphical programming tool based on Scratch 2.0, which is developed by our company. We can use this software to control. Through WeMake programming we can achieve the interaction between software and the physical world to make xArm do corresponding response according to the changes in the environment. WeMake's simple operability makes it possible for everyone to build their own intelligent robots without having to learn esoteric electronic knowledge.

6.2.2 How to install WeMake on your computer You can download the installation file of WeMake.

Table 1 Icon link QR code

http://bit.ly/2BY4u6h

Open installation file and select installation path. Click “ Next”.

30 Select Destination Location. The installer will install WeMake into the following folder. Click Next to continue, if you want to select other folder, click”Browse”.

31 The installer is now ready to install WeMake into your computer. Click install to continue with this installer, if you want to review or change the settings, please click “ Back”.

Installing. The installer is installing WeMake into your computer, please wait.

32 The WeMake installation wizard finishes. The installer has installed WeMake into your computer, this application can be run by selecting the installed shortcut. Click "Finish" exit the installer.

Next, we introduce WeMake. The figure below is the main interface for action editing,

33 the script block module in the middle, and the edit page on the right.

First of all, we need to select the Arduino driver in the connection tab of the interface and choose 32-bit or 64-bit according to your computer.

Use a USB cable to connect the computer to the xArm, and then check the serial port on the connection tab to see if it is connected. Different computers may have different ports( Don’t choose COM1), you can open the Device Manager, expand “Ports ( COM & LPT) ” .

34 6.2.3 Install the driver Use the WeMake at the first time, you should install the driver. Select the corresponding path in Menu> Connect> Install Driver

Open the driver installation interface.

35 Wait for the installation to finish. After the installation is complete, the window will close automatically. If the connection is successful, the script page lights will also show a green light.

36 Then select Car Board in the control board (must check, otherwise it will not be able to edit the action)

6.2.4 Gameplay and Programs

We provide detailed video to show you how to gameplay and programming about xArm, please refer to the link and QR code. link QR code

http://bit.ly/2BFiMYJ Lesson 3-Lesson31 Introduction gameplay

（Take gameplay 10 as an example） (1) Click on the robot module under the script in the middle of the screen.

37 Note: If you want to edit it yourself, you must first drag out the WeMake main program section. You can edit the module yourself, or you can drag the tutorial code file attached to the xArm data into the interface to load it. Take gameplay 10 coloured lamp by knob as an example( LED lattice module, RGB LED module), we use drag and drop to the right of the main interface. As shown below:

Gameplay 10: Control the action group through potentiometer Hardware principle of Touch button: Touch button, that is, the capacitive touch button. Capacitive touch button can be identified by a capacitor switch when a conductive object, such as a finger, enters into an electric field. Hardware principle of RGB indicator: RGB indicator is a light-emitting components and it can emit red, green and blue light. Users can control the ratio of red, green and blue respectively, or mix them into different colors. Hardware principle of potentiometer: The red potentiometer is an adjustable electronic component. The voltage and current can be changed through rotating or sliding, and the current can be used to control the system.

RGB module

38 Potentiometer module

Touch button module Software Command Script Type Command Comment Set the intensity of the red, green and Robots blue lights on the RGB indicator module Robots Get the value of potentiometer

Robots Get the situation of touch button Set the running speed of robot’s action Robots group Control the running times of the Robots specified action group

Create a Target: The potentiometer value is divided into three phrase, which corresponds to three RGB lights. After pressing the touch button, it can perform different action groups according to the potentiometer value.

39 After you import the gameplay program into xArm, you can let it execute gameplay. Here we give a YouTube link and QR code to xArm's secondary development, you can watch the related videos yourself:

40 6 Contact us

1. We hope that you can carefully read the instructions and watch the video instruction so that you can have a good command of xArm. 2. Thank you for your support and purchasing LewanSoul products. If there is anything that you do not understand, please feel free to contact us. Website: www.lewansoul.com Forum: www.lewansoul.com/forum Email: [email protected]

41 7 Troubleshooting 1.Turn on the power and xArm beeping like “Di Di Di” Solution: The power supply voltage is too low. (1) Please check whether the USB cable is used to connect the computer to the xArm directly. The USB cable is only for information transmission and cannot be used as a power cable, but it can be powered by an adapter and a battery. (2) If you use battery, please note that after a long time, the battery will have a certain loss, the battery voltage will reduce and power shortage, please replace the battery in time. (3) When selecting an adapter for power, please check whether the correct adapter is used and the output voltage can achieve the requirements. 2. Click the Bluetooth button to search for no Bluetooth devices. Solution: First, please make sure your xArm work well. And to allow location permission during installation or go to Permissions Management to set location permissions, and restart the xArm and reconnect the APP. 3. The wireless handle can not control xArm. Solution: First, you should check the handle receiver into the pot. Then turn on and make sure light work well. Connect it again. 4. The PC software always shows no connection Solution: This issue may be caused by anti-virus software. PC software be considered is a virus. Resulting in the killing of anti-virus software. Please turn off the antivirus software or add our software to the white list of antivirus software to try it out. 5. After installation of xArm PC software, operation failed . Solution: It may be due to anti-virus software deleting the file. Please close software and install again. 6. If you did something wrong with the "test servo" page and now all the servos are running at the same time and do not know how to reset it. Solution: The issue is due to the servo control board is connected with all the servos during adjustment. (1) You should make sure that the servo control board is connected with only one servo. (2) Then, click “Apply” icon to test servo again.

(3) if you want to know more information please click the following link: http://www.lewansoul.com/product/detail-135.html to get xArm user manual-5

42 Control methods and Programming

43 8 The Historical version of the user manual

Version Modification Instructions Modifier date The add information: V2.2 2018.6.19 (1) Troubleshooting Carey (2) 5.1.2 servo test (3) The introduction of servo