CHARACTERIZATION OF ON-ORBIT ROBOTIC ASSEMBLY OF SMALL SATELLITES by 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
© Massachusetts Institute of Technology, 2020. All rights reserved
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
by
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
CHARACTERIZATION OF ON-ORBIT ROBOTIC ASSEMBLY OF SMALL SATELLITES by 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.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
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/m 2 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)
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
ωmax,SC = MOI SC n LL max,RW
(1)
where nL, the fraction reaction wheel momentum available is assumed to be 1, Lmax,RWis the maximum reaction wheel angular momentum, and MOISCis 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,SC = MOI SC τmax,RW
(2)
where τmax,RWis the maximum reaction wheel torque. The time required for a spacecraft slew from stationary to stationary is
t if Δθ Δslew= Δθ ωmax,SC + αmax,SC ωmax,SC ≥ α max,SC ω2 max,SC (3) t if Δθ Δslew= √ Δθ αmax,SC ≺ αmax,SC ω2 max,SC (4)
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
(Q ) Aεσ(T )
A Solar+ QIR+ QAlbedo + QElectronic = rad4 (5) given that Qsolaris zero and always pointing the radiator away from the sun; the radiator is coated with white paint such that ε = 0.83and α = 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 .85 (efficiency of electronics) 0.30 (percentage of orbit where payload operates) 0W (heat load).
0 × × 3
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 (On-Orbit Robotic Assembly)
Smart Deployer (no Robotic Assembly)
Development Timeline 12-24 months 24-48 months
Launch Timeline Minimum 35-day launch manifest (One launch)
Minimum 35-day launch manifest (one launch) Volume (number of Satellites in 177U Free-Flyer) 120 3U CubeSats (shelved/flat packed structures) 60 3U CubeSats (pre-assembled with
structures and rails upright) Spacecraft
Configurations
Various Limited (determined before
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.
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 CubeSat 2.0
2 days by a team of 2 people Email correspondence with manufacturer
Planet Small Satellite One spacecraft per day Conference Paper [57]
MakerSat-1 5 minutes in International Space Station by 1 astronaut
Conference Paper [58]
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.
Table 9. N2 diagram aligned to related subsystems
(x, p) Spatial Configuration Control System Design Variables Robotic Arm Design Cost and Weight of Parts Task Sequence
Planning Target Positions
Control System
Joint
Velocities Assembly Time, Power
End Effector Positions
Articulated Rigid Body
Dynamics
Cost Model Cost, Weight
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 x1without collision. GA iterates the following four steps until a solution is found: 1. Evaluation: Rank the population according to the value of Ffor each element of Sd.
Decide if the best element can serve as an acceptable solution; if yes, exit
2. Selection: Use the function Fto 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.
