#  _Robowflex_ : Robot Motion Planning with _MoveIt_ Made Easy

Zachary Kingston Lydia E. Kavraki Department of Computer Science, Rice
University, Houston, TX, 77005, USA<EMAIL_ADDRESS>This work was
supported in part by NSF 1718478, NSF 2008720, NSTRF 80NSSC17K0163, and Rice
University Funds.

###### Abstract

_Robowflex_ is a software library for robot motion planning in industrial and
research applications, leveraging the popular _MoveIt_ library and Robot
Operating System (ros) middleware. _Robowflex_ takes advantage of the ease of
motion planning with _MoveIt_ while providing an augmented api to craft and
manipulate motion planning queries within a single program. _Robowflex_ ’s
high-level api simplifies many common use-cases while still providing access
to the underlying _MoveIt_ library. _Robowflex_ is particularly useful for 1)
developing new motion planners, 2) evaluation of motion planners, and 3)
complex problems that use motion planning (e.g., task and motion planning).
_Robowflex_ also provides visualization capabilities, integrations to other
robotics libraries (e.g., dart and Tesseract), and is complimentary to many
other robotics packages. With our library, the user does not need to be an
expert at ros or _MoveIt_ in order to set up motion planning queries, extract
information from results, and directly interface with a variety of software
components. We provide a few example use-cases that demonstrate its efficacy.

##  I Introduction

Robotic manipulators are becoming ever more prevalent—in the near future, we
will begin to see robots in the household, search-and-rescue scenarios, and
other forms of service. These manipulators are tasked with increasingly
complex goals and environments, blending discrete task planning and continuous
motion planning to find a sequence of achievable actions. A core component of
any autonomous system that operates within the “real world” is _motion
planning_ [1, 2, 3], which can find feasible motion that satisfies task
requirements (e.g., reaching the goal, satisfying some motion constraint,
etc.). However, it is difficult in general to tailor a specific motion
planning algorithm to a particular use-case, evaluate its capabilities, or
modify and integrate it within a broader system.

There have been many efforts to develop motion planning software systems that
are applicable to general manipulators. A popular and robust library for
motion planning is _MoveIt_ [4], which is built on top of the ubiquitous Robot
Operating System (ros) framework [5]. _MoveIt_ has four key advantages: it is
widely adopted throughout industry and research, it is easy to setup for new
robots and over 150 different robot configurations are already available [6],
it is easy to integrate with a broader ros enabled system, and it has a large
and vibrant open source community. However, due to _MoveIt_ ’s massive scope
and abstract architecture, many tasks are difficult for both engineers and
researchers. For example, it can be difficult to evaluate and develop planning
algorithms, extend a planner’s functionality, extract low-level information
from planners, or use a planner within the scope of a broader planning
algorithm, e.g., task and motion planning [7].

This paper introduces _Robowflex_ , a software library designed to simplify
the use of _MoveIt_ for industrial and research applications of motion
planning. _Robowflex_ is a high-level api that enables easy manipulation of
robots, collision environments, planning requests, and motion planners.
_Robowflex_ “wraps” the underlying core library of _MoveIt_ within a c++
library and provides many utilities that simplify the use and evaluation of
motion planners. _Robowflex_ can then be used for motion planning through
_MoveIt_ , while providing direct access to the implementation (that is, not
through ros messaging). The key advantage of this approach is the ability to
1) develop self-contained scripts to evaluate motion planning, 2) retain the
capability of easy system integration through ros when necessary, and 3)
implement integrated algorithms that use motion planning extensively (e.g.,
task and motion planning). _Robowflex_ is also a unifying framework, and
provides low-level access to a number of auxiliary modules that integrate
other libraries, e.g., ompl [8], dart [9], ros Industrial’s Tesseract [10],
and visualization with Blender [11]. For example, these integrations enable
comparison of _MoveIt_ ’s rrtConnect against Tesseract’s TrajOpt on the same
scene in a single, short script. We demonstrate the usefulness of _Robowflex_
in a few example use-cases, such as benchmarking for motion planning
experiments and an industry-focused use-case of evaluating Robonaut 2 walking
from nasa. _Robowflex_ is open-
source111https://github.com/KavrakiLab/robowflex, is documented
online222https://kavrakilab.github.io/robowflex/, and has been used in a
number of publications [12, 13, 14, 15, 16, 17, 18, 19].

##  II Background

_Robowflex_ is primarily built around _MoveIt_ [4], a generic software library
designed to provide motion planning and mobile manipulation capabilities to
ros [5] enabled robots. _MoveIt_ has been successfully used with many robots,
such as the PR2 [20], Fetch [21], and even nasa’s Robonaut 2 [22]. _MoveIt_
also provides a setup assistant to easily configure new, novel robots for
motion planning [6]. Within the robotics community, _MoveIt_ is widely used
within research and industrial applications [23]. _MoveIt_ provides a core
abstract representation surrounded by a suite of _plugins_ , providing the
capability to easily swap components. In particular, _MoveIt_ provides a
number of default motion planning plugins: sampling-based motion planning [1,
2, 3] through ompl [8], and a number of trajectory optimization planners
(e.g., [24, 25]).

Typically, users interact with _MoveIt_ through the provided MoveGroup
program, which leverages _MoveIt_ ’s plugin-based architecture to provide a
flexible, configurable motion planning service in a ros environment for a
configured robot. This is recommended for most users333https://ros-
planning.github.io/moveit_tutorials/. While convenient for basic motion
planning tasks, MoveGroup falls short when used outside the scope of basic
motion planning. MoveGroup uses a number of configuration files and ros
parameters through launch files to setup an instance for robot motion
planning. Users can interact with MoveGroup through ros messages to request
motion plans. For basic applications of motion planning, this paradigm is
sufficient. However, for more advanced applications of motion planning, such
as profiling or evaluating detailed aspects of a motion planner, changing
parameters or components of a planner, or extracting more information from
planners, it is insufficient. To edit or improve the capabilities of _MoveIt_
, users must either edit or create plugin classes, which can be complicated
for those who are unfamiliar with _MoveIt_ ’s internal structure. Moreover, if
users just want to use _MoveIt_ as a library, there are many parameters to
load and configure (e.g., urdf, srdf, joint limits, kinematics plugins,
planner configurations, etc.). _Robowflex_ provides a MoveGroup-like interface
as a high-level api, while also providing full access to underlying data,
enabling access to these underlying structures to either modify or
inspect444Note that _MoveIt_ cpp (https://ros-
planning.github.io/moveit_tutorials/doc/moveit_cpp/moveitcpp_tutorial.html)
and https://github.com/PickNikRobotics/moveit_boilerplate provide simple
interfaces to load _MoveIt_ structures internally, but lack the abstraction,
isolation, io support, and support modules provided by _Robowflex_..

_Robowflex_ aims to support motion planning research. In particular, many
motion planning algorithms for high-dimensional manipulators are _sampling-
based algorithms_. Sampling-based planning algorithms relax completeness
guarantees to instead afford probabilistic completeness, but can solve high-
dimensional problems significantly more efficiently in practice [1, 2, 3]. A
popular library used by many software frameworks for motion planning is the
Open Motion Planning Library (ompl) [8]. ompl provides implementations of many
state-of-the-art motion planners through a common interface. ompl is a primary
research environment for many researchers to implement novel motion planning
ideas, and support of ompl is paramount for many benchmarking applications
[26]. However, augmenting or customizing ompl is difficult in many cases for
real robotic systems, due to the difficulty of accessing the internals of the
library through typical interfaces, such as _MoveIt_. _Robowflex_ provides
library-level access to ompl, which is essential for rapid development and
testing of novel motion planning techniques. Moreover, it is possible to
develop novel planners within the _Robowflex_ framework that are not tied to
_MoveIt_ or ompl.

Additionally, _Robowflex_ has the ability to support more complex robotic
algorithms that use motion planning as a subroutine. For example, a common
application of motion planning outside the scope of a single query is _task
and motion planning_ (tamp), e.g., [27, 28, 7]. There also has been work in
integrating tamp-like approaches in _MoveIt_ , e.g., [29], however this
approach only resolves the motions for a predetermined sequence of actions.
tamp combines classical ai task planning with motion planning, generating a
sequence of valid actions the robot should accomplish, and also generating
their corresponding feasible motion. Critically, tamp requires both evaluating
many motion plans (to validate each action in the task plan) as well as
feeding information back into the task planner (to indicate what plans should
not be attempted again due to motion infeasibility). Both of these
requirements involve a deeper introspection into the motion planning process,
something that is at odds with the design of MoveGroup.

There are many excellent robotic software frameworks that include motion
planning that are compatible with ros through wrappers. _Robowflex_
systematizes the idea of wrapping a planning framework away from ros while
still using native ros components, enabling minimal use of ros if desired
while still supporting the full ros stack. OpenRAVE [30] is a fully featured
motion planning framework. However, it is not actively developed and does not
have the level of community support available in _MoveIt_ and ros. Similarly,
klamp’t [31] is an all-in-one toolbox that specializes in handling contact.
The goal of klamp’t is similar to _Robowflex_ , but provides its own
environment, albeit with ros adapters. The Robotics Library [32] is an all-in-
one library for robot modeling and real-time planning, but lacks the ability
to connect to the broader robotics ecosystem through ros. _Robowflex_ strives
to integrate with other robotics libraries through additional modules.
Currently, _Robowflex_ has a module that models kinematics with dart [9] for
motion planning, similar to how aikido [33] uses dart to model kinematics.
_Robowflex_ also supports Tesseract [10], a package by ros industrial designed
for use of TrajOpt [25] and other planners.

As stated above, the benefit of using _MoveIt_ over the above libraries is
that _MoveIt_ is easy to integrate with new robots, easy to integrate with a
ros system, and is actively developed with a large open source community.

##  III The _Robowflex_ Library

_Robowflex_ is intended for use in research, education, and industry.
_Robowflex_ is informed by the following design goals:

  1. 1.

_Clarity of Interface_ : Provide an easy to understand interface that meshes
with intuitive understanding of the concepts involved in motion planning.

  2. 2.

_Minimize ros_: Encapsulate the use of ros as much as possible such that it is
easy to write independent programs.

  3. 3.

_Leverage _MoveIt_ ’s Ubiquity_: By basing itself on _MoveIt_ , many robots
already are supported in _Robowflex_ out of the box. The use of _MoveIt_ also
enables the connection of _Robowflex_ scripts effortlessly to a greater ros
system if desired.

  4. 4.

_Unrestricted Access and Integration_ : While still providing a high-level
api, provide access to all underlying structures so that users are not
hampered by the use of _Robowflex_ in any way. A key advantage _Robowflex_
provides is that all the underlying data structures used in _MoveIt_ , ompl,
or other libraries can all be accessed, modified, and used to the extent the
user needs. _Robowflex_ provides a common interface and adapters to convert
between the representations used by each library.

  5. 5.

_Consistency Across Versions_ : _Robowflex_ provides adapters such that
_Robowflex_ code is not tied to a specific version of ros or _MoveIt_
codebase. _Robowflex_ code compiles for versions from ros Indigo to ros Noetic
and beyond.

At a high-level, _Robowflex_ provides wrappers around core _MoveIt_ concepts
so that it is easy to create and manage robots, scenes, and planners within a
script. The primary building blocks of _Robowflex_ is the representation of
the robot’s kinematics, the collision environment, and the motion planner.
Although other facades to _MoveIt_ exist, _Robowflex_ provides a higher level
of encapsulation and abstraction that allows users who are unfamiliar with the
particulars of _MoveIt_ ’s library to still achieve complex programming tasks.
Moreover, these core features are supported by a suite of helper functions and
classes, such as input-and-output helpers for a variety of formats,
benchmarking utilities, visualization within RViz, and more. Surrounding the
core library are also auxiliary modules that support other robotics libraries,
and support seamless integration of transferring robots and environments in
_Robowflex_ into native formats.

###  III-A Input and Output

Many complicated robotic problems require large amounts of file input and
output (io), e.g., for system configuration, loading problems and scenes, and
much more. For ease of use, _Robowflex_ provides many helper functions for io
of common file-types used in a ros system. _Robowflex_ contains functions for
the following, among others:

#### Files and ros Packages

It is common in scripting for files to be opened or created, especially files
that exist in ros packages that are specified with package uris. _Robowflex_
provides helper functions to resolve file paths and to either open or create
said file.

####  xml Files

Many configuration files in robotics are written in Extensible Markup Language
(xml) or in the macro xml language xacro. _Robowflex_ provides helper
functions to load these files (including unprocessed xacro) into a program, as
well as inject changes on the fly.

####  yaml Files

It is common to save and load ros messages as yaml files. However, there is no
easy way to load or save ros messages to and from yaml within c++. _Robowflex_
enables broad yaml conversion compatible with ros Python and ros topic echoes.
Many _Robowflex_ classes accept ros messages as input to populate data
structures, e.g., motion planning requests, robot states, and more. This makes
it easy to load problems using yaml files.

####  ros Parameters

Many ros programs use and rely on the parameter server, a distributed key-
value store available to any ros program. As a result, it is sometimes
difficult to have multiple programs running simultaneously that might require
similarly named parameters, leading to issues with managing proper namespaces.
By default, _Robowflex_ creates an anonymous namespace so that many instances
of _Robowflex_ code can run on a ros system simultaneously. Moreover, there
are helpful functions for loading yaml files onto the parameter server,
something that is typically only available through the ros launch interface,
making it easy to have scripts load their necessary information.

There are many other useful io features such as reading and writing ros bag
files, hdf5 files, and converting between various transformation
representations.

###  III-B Robot Kinematics

It is common to describe the kinematics and geometry of a robot via the
Universal Robot Description Format (urdf). Moreover, _MoveIt_ requires the
Semantic Robot Description Format (srdf) file, which describes additional
properties such as what links are allowed to collide with each other in
planning, what groups of joints should be used for planning, and what parts of
the robot are the end-effector. There are also additional configuration files
associated with loading a _MoveIt_ robot, such as a yaml file that describes
kinematics plugins and additional joint limits of the robot. Typically, most
robots are configured through the _MoveIt_ setup assistant wizard and generate
a ros package containing all relevant configuration files. Moreover, there are
complicated ros launch files that contain many of the configuration parameters
necessary to start MoveGroup, and in order to modify the behavior of _MoveIt_
, both the program and launch file need to be modified.

_Robowflex_ takes care of all the necessary legwork to load the appropriate
files necessary to configure a robot without the need for a launch file.
Moreover, _Robowflex_ enables loading multiple robots within the same program,
and duplicating robots if necessary. An example of loading a robot follows:

⬇

1 namespace rx = robowflex;

2 auto wam7 = //

3 std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rx$\mkern
5.0mu\colon\mkern-8.0mu\colon$Robot>("wam7");

4 wam7$\rightarrow$initialize( //

5 "package://barrett_model/robots/wam_7dof_wam_bhand.urdf.xacro", // urdf

6 "package://barrett_wam_moveit_config/config/wam7_hand.srdf", // srdf

7 "package://barrett_wam_moveit_config/config/joint_limits.yaml", // joint
limits

8 "package://barrett_wam_moveit_config/config/kinematics.yaml" // kinematics

9 );

After loading, this robot can then be used for motion planning with _MoveIt_.
Moreover, it is easy to load multiple robots within a single program—with
default _MoveIt_ , this process can become convoluted.

###  III-C Collision Environment

The robot can be used to initialize a planning scene, which contains the
collision geometry of the environment. The scene can be used for adding and
moving collision objects, computing collisions, and distance to collision. For
example, scenes can be loaded from yaml files, which encode full planning
scenes:

⬇

1 auto scene = std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rx$\mkern
5.0mu\colon\mkern-8.0mu\colon$Scene>(wam7);

2 scene$\rightarrow$fromYAMLFile( //

3 "package://robowflex_library/yaml/scene.yml");

Scenes can also be created by adding collision objects programatically:

⬇

1 auto scene = std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rx$\mkern
5.0mu\colon\mkern-8.0mu\colon$Scene>(wam7);

2 auto geometry = //

3 rx$\mkern 5.0mu\colon\mkern-8.0mu\colon$Geometry$\mkern
5.0mu\colon\mkern-8.0mu\colon$makeCylinder(0.025, 0.1);

4 auto pose = //

5 rx$\mkern 5.0mu\colon\mkern-8.0mu\colon$TF$\mkern
5.0mu\colon\mkern-8.0mu\colon$createPoseXYZ( //

6 -0.268, -0.826, 1.313, // position

7 0., 0., 0.)); // XYZ Euler

8 scene$\rightarrow$updateCollisionObject( //

9 "cylinder", geometry, pose);

Note that many scenes can be loaded simultaneously, can be copied and
modified, and saved and loaded to and from disk.

###  III-D Motion Planner

_MoveIt_ uses a plugin-based system to load a motion planning pipeline, which
consists of many planning adapters that filter and process the request and
output trajectory given by a planning plugin, which actually computes the
motion plan. A few default implementations are provided within _Robowflex_ ,
such as the default ompl planning pipeline plugin and a means to load any
compatible _MoveIt_ planning plugin. A helper class is provided to help build
a motion planning request for a planner, which simplifies the design of
complex goal and path constraints, as well as setting start and goal states.
This helper class can also save and load motion planning requests to disk, for
possible later evaluation or easy setup.

Given a scene and a planning request, the planner can solve the problem. Many
planners can be loaded simultaneously and used in tandem. Moreover,
_Robowflex_ supports inserting new planners, either through _MoveIt_ ’s api or
its own.

###  III-E Example Script

⬇

1 // Create a default Fetch robot.

2 auto fetch = std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rx$\mkern
5.0mu\colon\mkern-8.0mu\colon$FetchRobot>();

3 fetch$\rightarrow$initialize();

4

5 // Create an empty scene.

6 auto scene = std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rx$\mkern
5.0mu\colon\mkern-8.0mu\colon$Scene>(fetch);

7

8 // Create the default planner for the Fetch.

9 auto planner = //

10 std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared< //

11 rx$\mkern 5.0mu\colon\mkern-8.0mu\colon$OMPL$\mkern
5.0mu\colon\mkern-8.0mu\colon$FetchOMPLPipelinePlanner>(fetch);

12 planner$\rightarrow$initialize();

13

14 // Create a motion planning request.

15 auto request = //

16 std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rx$\mkern
5.0mu\colon\mkern-8.0mu\colon$MotionRequestBuilder>( //

17 planner, "arm_and_torso");

18

19 // Set the start state.

20 fetch$\rightarrow$setGroupState("arm_and_torso",

21 {0.05, 1.32, 1.40, -0.2, 1.72, 0, 1.66, 0});

22 request$\rightarrow$setStartConfiguration( //

23 fetch$\rightarrow$getScratchState());

24

25 // Set the goal state.

26 fetch$\rightarrow$setGroupState("arm_and_torso",

27 {0.27, 0.5, 1.28, -2.27, 2.24, -2.77, 1, -2});

28 request$\rightarrow$setGoalConfiguration( //

29 fetch$\rightarrow$getScratchState());

30

31 // Set the desired planner.

32 request$\rightarrow$setConfig("RRTConnect");

33

34 // Do motion planning!

35 auto result = planner$\rightarrow$plan( //

36 scene, request$\rightarrow$getRequest());

37 if (result.error_code_.val //

38 != moveit_msgs$\mkern 5.0mu\colon\mkern-8.0mu\colon$MoveItErrorCodes$\mkern
5.0mu\colon\mkern-8.0mu\colon$SUCCESS)

39 return 1;

40

41 return 0;

Figure 1: A code snippet demonstrating basic motion planning on a Fetch robot
[21], from a “stow” position of the arm to an “unfurled” position. Note this
does not use any ros messages, similar to the internals of _MoveIt_ ’s
MoveGroup program.

Fig. 1 shows a simple script for motion planning with _Robowflex_. This script
shows how to do a simple motion plan with a Fetch robot. The robot is loaded
on line 2— _Robowflex_ comes with some preconfigured robots that do the
necessary initialization automatically. An empty planning scene for the robot
is created on line 6. The standard ompl planner for the Fetch is created and
initialized in lines 9 to 12. A simple motion planning request, which unfurls
the Fetch’s arm from the stow position to the position shown in Fig. 4, is
created in lines 16 to 32. Finally, motion planning occurs on line 35. A
version of this script is available in the
repository555https://github.com/KavrakiLab/robowflex/blob/master/robowflex_library/scripts/fetch_test.cpp.

This simple script is akin to basic planning using the _MoveIt_ ’s
MoveGroupInterface class666https://ros-
planning.github.io/moveit_tutorials/doc/move_group_interface/move_group_interface_tutorial.html.
The critical difference is that, rather than having to use ros launch to run
an instance of the MoveGroup program and then communicate plans over ros
messages, all of _MoveIt_ ’s internal structures are loaded in the _Robowflex_
program777See https://ros-
planning.github.io/moveit_tutorials/doc/motion_planning_api/motion_planning_api_tutorial.html
for how this could be done without _Robowflex_. Also, see footnote 4 for other
helper classes that can set up planning without _Robowflex_.. Providing access
to these structures within a single program is a key benefit of _Robowflex_.
The scripting paradigm offered by _Robowflex_ is more amenable to rapid
testing and scripting than MoveGroup, which is designed primarily to be a
“live” component of a ros system extant in some world.

###  III-F Integrations

_Robowflex_ also provides a number of auxiliary modules that enable
compatibility with different robotics libraries.

####  ompl Integration

The _Robowflex_ ompl module provides deeper access for motion planning to the
default _MoveIt_ ompl motion planning plugin. This includes extracting the
underlying ompl setup for a given planning problem, which enables users to
modify the behavior of ompl planning without having to recompile either the
_MoveIt_ planning plugin or ompl. An example script for how to extract and
customize the underlying ompl planner used by _MoveIt_ is shown in Fig. 2.
With _Robowflex_ , it easy to use a custom planner or feature in ompl as
compared to integrating a new planner into _MoveIt_ (e.g., this was done in
[12, 13, 14]).

⬇

1 // Create an OMPL planner

2 auto planner = //

3 std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared< //

4 rx$\mkern 5.0mu\colon\mkern-8.0mu\colon$OMPL$\mkern
5.0mu\colon\mkern-8.0mu\colon$OMPLInterfacePlanner>(fetch);

5

6 // Extract underlying OMPL structures

7 auto context = //

8 planner$\rightarrow$getPlanningContext(scene, request);

9 auto ss = context$\rightarrow$getOMPLSimpleSetup();

10

11 // Customize OMPL planner

12 ss$\rightarrow$setPlanner($...$);

13 ss$\rightarrow$getStateSpace()$\rightarrow$setStateSamplerAllocator($...$);

Figure 2: A code snippet demonstrating how to use the _Robowflex_ ompl
integration to access internal ompl features.

####  dart Integration

The _Robowflex_ dart module provides an alternative to _MoveIt_ , by modeling
robots and scenes in the dart [9] framework with conversion back and forth to
_MoveIt_ constructs. The module provides an implementation of motion planning
through ompl, including motion planning with manifold constraints [15].
Moreover, this module provides an easy way to plan for multi-robot systems,
allowing arbitrary composition of _MoveIt_ enabled robots. This capability was
used by the multi-robot task-motion planning framework discussed in Sec. IV-B.
An example script demonstrating the dart module is given shown in Fig. 3.

⬇

1 namespace rd = robowflex$\mkern 5.0mu\colon\mkern-8.0mu\colon$darts;

2

3 // Convert MoveIt robot to Dart

4 auto dfetch1 = std$\mkern
5.0mu\colon\mkern-8.0mu\colon$make_shared<rd$\mkern
5.0mu\colon\mkern-8.0mu\colon$Robot>(fetch);

5

6 // Make a copy of Fetch for multi-robot planning

7 auto dfetch2 = dfetch1$\rightarrow$cloneRobot("other");

8 dfetch2$\rightarrow$setDof(4, 1); // Offset on X-axis

9

10 // Combine all kinematic structures into a world

11 auto world = std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rd$\mkern
5.0mu\colon\mkern-8.0mu\colon$World>();

12 world$\rightarrow$addRobot(dfetch1);

13 world$\rightarrow$addRobot(dfetch2);

14

15 // Plan using planning groups from both robots

16 rd$\mkern 5.0mu\colon\mkern-8.0mu\colon$PlanBuilder builder(world);

17 builder.addGroup("fetch", "arm_with_torso");

18 builder.addGroup("other", "arm_with_torso");

19

20 // Set start configuration for both Fetch robots

21 builder.setStartConfiguration({ //

22 0.05, 1.32, 1.4, -0.2, 1.72, 0, 1.66, 0, //

23 0.05, 1.32, 1.4, -0.2, 1.72, 0, 1.66, 0, //

24 });

25 builder.initialize();

26

27 // Set goal configuration and setup planning

28 auto goal = builder.setGoalConfiguration({ //

29 0.27, 0.5, 1.28, -2.27, 2.24, -2.77, 1, -2, //

30 0.27, 0.5, 1.28, -2.27, 2.24, -2.77, 1, -2, //

31 });

32 builder.setGoal(goal);

33 builder.setup();

34

35 // Solve using OMPL

36 if (builder.ss$\rightarrow$solve(30.0))

37 return 0;

38

39 return 1;

Figure 3: A code snippet demonstrating _Robowflex_ ’s dart module for multi-
robot motion planning. Here, the Fetch robot that was loaded in the prior
script (Fig. 1) is converted to dart and copied, created a multi-robot system.
A plan is generated in the composite space of both robots.

#### Tesseract Integration

The _Robowflex_ Tesseract module provides access to the ros Industrial
Consortium’s planning framework [10], which includes an implementation of the
TrajOpt planner [25]. Similar to the dart module, methods for converting data
(e.g., scenes and plans) back and forth are provided. _Robowflex_ ’s Tesseract
module was used in [16] to access and modify TrajOpt for comparison against
ompl planners.

####  MoveGroup Integration

The _Robowflex_ MoveGroup module provides an easy connection to a live
instance of _MoveIt_ ’s MoveGroup. This connection can be used to obtain the
current collision environment, publish plans to be executed, and generally
synchronize information between MoveGroup and a _Robowflex_ script.

#### Visualization with Blender

The _Robowflex_ visualization module makes it easy to render robots within
Blender [11], a tool for 3D modeling and animation. An example rendered still
is shown in Fig. 4. Moreover, it is easy to animate motion plans generated by
_Robowflex_ to create appealing visualizations and
videos888https://kavrakilab.github.io/robowflex/md__home_runner_work_robowflex_robowflex_robowflex_visualization_README.html.
This module has also been used to generate figures in [15, 12, 13].

Figure 4: A Fetch robot [21], rendered in Blender [11] using _Robowflex_ ’s
visualization module.

##  IV Example Use-Cases

Crucial to the particular use-cases listed here as well as many others,
_Robowflex_ simplifies the pipeline of creating, editing, inspecting, saving,
and loading motion planning problems (both collision environments and motion
planning requests). These capabilities are essential for many research and
industrial tasks that rely on reproducibility, experimentation, and debugging.

###  IV-A Benchmarking Motion Planners

Figure 5: Example benchmarking results from 200 runs of rrt* [34], an
asymptotically optimal algorithm, on the Fetch robot. The “best cost” path, in
this case the shortest length path found, is displayed over time. This
progress property of the planner is captured by _Robowflex_ ’s benchmarking,
using the planner from the ompl module. This plot was generated by using
Planner Arena101010http://plannerarena.org/ [26], which accepts ompl benchmark
output for interactive plotting.

A core use-case for _Robowflex_ is benchmarking motion planners in a variety
of planning scenes. The task of evaluating motion planners on realistic robots
in many environments, extracting detailed planner information, and collating
all collected data is difficult. _Robowflex_ provides a benchmarking tool that
enables easy benchmarking of different planners, scenes, and requests all
together. The tool enables configurable benchmark output in a number of
formats. For example, a default format provided is the ompl benchmark log
output, so output is compatible with the standard ompl benchmarking suite and
tools [26]. In additional, recall that _Robowflex_ supports loading both
environments and requests from disk, making it easy to craft datasets for
evaluation. As new planners are developed, targeted benchmarking can be done
for many planner properties, a contribution to the motion planning community
due to the difficulty of setting up consistent benchmarking criteria. For
example, the following could be added after line 32 of Fig. 1 to benchmark the
motion planning request instead of planning:

⬇

1 rx$\mkern 5.0mu\colon\mkern-8.0mu\colon$Benchmarker benchmarker;

2 benchmarker.addBenchmarkingRequest( //

3 "example", scene, planner, request);

4

5 benchmarker.benchmark({ //

6 std$\mkern 5.0mu\colon\mkern-8.0mu\colon$make_shared<rx$\mkern
5.0mu\colon\mkern-8.0mu\colon$OMPLBenchmarkOutputter>( //

7 "example/")});

Moreover, benchmarking can capture _progress properties_ of a motion planner,
if properly exposed. These properties are important for profiling the
performance of asymptotically (near-)optimal motion planning algorithms, such
as rrt* [34]. An example is shown in footnote 10. _Robowflex_ ’s benchmarking
was used in [15, 17, 12, 13, 19, 14, 16].

Compared to _MoveIt_ ’s built in benchmarking capabilities111111https://ros-
planning.github.io/moveit_tutorials/doc/benchmarking/benchmarking_tutorial.html,
_Robowflex_ provides a self-contained means of benchmarking that is more
easily extendable. _MoveIt_ ’s benchmarking requires use of ros Warehouse for
constructing benchmark datasets as opposed to _Robowflex_ ’s simple file
storage, and does not easily support planning scenes with obstacle variation,
which is important for learning-based methods. For example, [13, 19] take
advantage of these two features by running _Robowflex_ benchmarking instances
in containers federated over many machines. Moreover, _Robowflex_ enables
creation of custom metrics with access to underlying planner results (e.g,.
progress properties are not available in _MoveIt_ , properties of a particular
method), and can be run as a single script.

###  IV-B Task and Motion Planning

Figure 6: Two Fetch robots [21] displayed in RViz executing a task and motion
plan (tamp) to rearrange blocks. The motion planning component of this tamp
problem is done through the dart module of _Robowflex_. _Robowflex_ enables
the tamp algorithm to have integrated access to the motion planner, which
allows for trying many queries simultaneously, extracting collision
information, and more. Image courtesy of Tianyang Pan.

One of the strengths of _Robowflex_ is motion planning in isolation, that is,
being able to use many different instances of robots, scenes, and motion
planners all within the same script. This is essential to efficient task and
motion planning (tamp), as a tamp algorithm will evaluate many different
motion plans in a variety of scenes to find a feasible task-and-motion plan.
_Robowflex_ has been used as the motion planning component in a few tamp
algorithms (e.g., [18]), one of which is shown in Fig. 6. Here, _Robowflex_
and _Robowflex_ ’s dart module are leveraged to provide the motion planning
components necessary for a multi-robot tamp algorithm. Crucial to tamp is the
evaluation of many possible scene configurations— _Robowflex_ allows for many
copies of the collision environment to be considered in tandem. Moreover,
_Robowflex_ enables information on planning progress to be extracted from the
underlying planner, which is used to inform the task planner. Finally, the
dart module allows for multi-robot planning, as shown in Fig. 3.

###  IV-C Robonaut 2 and nasa

Figure 7: nasa’s Robonaut 2 inside of a module of the International Space
Station, visualized in RViz. For a given step between handrails, many possible
configurations are evaluated through _Robowflex_. Image courtesy of Misha
Savchenko and nasa.

_Robowflex_ has also been used by nasa for motion planning for Robonaut 2.
Robonaut 2 is a highly dexterous system, with many degrees of freedom. One of
the many motion planning challenges Robonaut 2 faces is climbing across
handrails in the International Space Station, as shown in Fig. 7. To this end,
_Robowflex_ was used to evaluate potential handrail grasps and the difficulty
of motion planning between different grasps to automate walking across the
station. _Robowflex_ provides the means to use, inspect, and evaluate custom
inverse kinematics solvers for Robonaut 2 and to benchmark the variety of
handrail grasp configurations and scenes. Additionally, _Robowflex_ was used
for the Robonaut 2 experiments and figure in [15]. As demonstrated by the
examples presented here, the affordances provided by _Robowflex_ are general
and broadly useful to different members of the robotics community.

##  V Discussion

We have presented _Robowflex_ , a c++ library that enables the use of _MoveIt_
in an easier, more flexible way for the creation of advanced robot software
for industry, research, and education. The core advantage that _Robowflex_
provides over the default distribution of _MoveIt_ is the ability to easily
access and modify core data structures within the program itself, rather than
through ros messages to the provided MoveGroup program. This also enables the
use of motion planning within more complex algorithms, such as task and motion
planning approaches. Moreover, _Robowflex_ provides a high-level api, enabling
many use-cases such as benchmarking and motion planning without any expertise
required. _Robowflex_ also has a number of auxiliary modules that provide
access to other robotics libraries and visualization tools, such as ompl,
dart, Tesseract, and Blender. Beyond motion planning software development, we
hope that _Robowflex_ will enable broader application and adoption of motion
planning algorithms and raise the level of experimental evaluation in
comparisons.

## Acknowledgments

We would like to thank Constantinos Chamzas, Carlos Quintero-Peña, Andrew
Wells, Bryce Willey, Juan David Hernández, Mark Moll, and the other members of
the Kavraki Lab for their helpful feedback and code. We would also like to
thank Misha Savchenko, Julia Badger, and the rest of the Robonaut 2 team at
nasa Johnson Space Center for their feedback.

## References

  * [1] H. M. Choset, S. Hutchinson, K. M. Lynch, G. Kantor, W. Burgard, L. E. Kavraki, and S. Thrun, _Principles of Robot Motion: Theory, Algorithms, and Implementation_. MIT Press, 2005.
  * [2] S. M. LaValle, _Planning Algorithms_. Cambridge University Press, 2006.
  * [3] L. E. Kavraki and S. M. LaValle, _Springer Handbook of Robotics_ , 2nd ed. Springer, 2016, ch. Motion Planning, pp. 139–162.
  * [4] I. A. Şucan and S. Chitta. (2011) MoveIt! [Online]. Available: http://moveit.ros.org
  * [5] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng, “ROS: an open-source robot operating system,” in _Wksp. on Open Source Software at ICRA_ , vol. 3, 2009.
  * [6] D. Coleman, I. A. Şucan, S. Chitta, and N. Correll, “Reducing the barrier to entry of complex robotic software: a MoveIt! case study,” _J. of Software Engineering for Robotics_ , vol. 5, no. 1, pp. 3–16, 2014\.
  * [7] N. T. Dantam, Z. Kingston, S. Chaudhuri, and L. E. Kavraki, “An incremental constraint-based framework for task and motion planning,” _Int. J. of Robotics Research_ , vol. 37, no. 10, pp. 1134–1151, 2018.
  * [8] I. A. Şucan, M. Moll, and L. E. Kavraki, “The Open Motion Planning Library,” _IEEE Robot. Autom. Magazine_ , vol. 19, no. 4, pp. 72–82, 2012.
  * [9] J. Lee, M. X. Grey, S. Ha, T. Kunz, S. Jain, Y. Ye, S. S. Srinivasa, M. Stilman, and C. K. Liu, “DART: Dynamic animation and robotics toolkit,” _J. of Open Source Software_ , vol. 3, no. 22, p. 500, 2018. [Online]. Available: https://doi.org/10.21105/joss.00500
  * [10] ROS-Industrial. (2017) Tesseract. [Online]. Available: https://github.com/ros-industrial-consortium/tesseract
  * [11] Blender Online Community. (2020) Blender—a 3D modelling and rendering package. Blender Foundation. Stichting Blender Foundation, Amsterdam. [Online]. Available: http://www.blender.org
  * [12] C. Chamzas, A. Shrivastava, and L. E. Kavraki, “Using local experiences for global motion planning,” in _IEEE Int. Conf. Robot. Autom._ , May 2019, pp. 8606–8612.
  * [13] C. Chamzas, Z. Kingston, C. Quintero-Pe$\tilde{\textrm{n}}$a, A. Shrivastava, and L. E. Kavraki, “Learning sampling distributions using local 3D workspace decompositions for motion planning in high dimensions,” in _IEEE Int. Conf. Robot. Autom._ , 2021, to Appear.
  * [14] È. Pairet, C. Chamzas, Y. Petillot, and L. E. Kavraki, “Path planning for manipulation using experience-driven random trees,” _IEEE Robot. Autom. Letters_ , 2021, to Appear.
  * [15] Z. Kingston, M. Moll, and L. E. Kavraki, “Exploring implicit spaces for constrained sampling-based planning,” _Int. J. of Robotics Research_ , vol. 38, no. 10–11, pp. 1151–1178, 2019.
  * [16] C. Quintero-Pe$\tilde{\textrm{n}}$a, A. Kyrillidis, and L. E. Kavraki, “Robust optimization motion planning for high-DoF robots under sensing uncertainty,” in _IEEE Int. Conf. Robot. Autom._ , 2021, to Appear.
  * [17] J. D. Hernández, M. Moll, and L. E. Kavraki, “Lazy evaluation of goal specifications guided by motion planning,” in _IEEE Int. Conf. Robot. Autom._ , May 2019, pp. 944–950.
  * [18] A. M. Wells, Z. Kingston, M. Lahijanian, L. E. Kavraki, and M. Y. Vardi, “Finite horizon synthesis for probabilistic manipulation domains,” in _IEEE Int. Conf. Robot. Autom._ , 2021, to Appear.
  * [19] M. Moll, C. Chamzas, Z. Kingston, and L. E. Kavraki, “HyperPlan: A framework for motion planning algorithm selection and parameter optimization,” _IEEE Robot. Autom. Letters_ , 2021, in Review.
  * [20] K. A. Wyrobek, E. H. Berger, H. M. Van der Loos, and J. K. Salisbury, “Towards a personal robotics development platform: Rationale and design of an intrinsically safe personal robot,” in _IEEE Int. Conf. Robot. Autom._ IEEE, 2008, pp. 2165–2170.
  * [21] M. Wise, M. Ferguson, D. King, E. Diehr, and D. Dymesich, “Fetch and Freight: Standard platforms for service robot applications,” in _Wksp. on Autom. Mobile Service Robots_ , 2016.
  * [22] W. Baker, Z. Kingston, M. Moll, J. Badger, and L. E. Kavraki, “Robonaut 2 and you: Specifying and executing complex operations,” in _IEEE Wksp. on Advanced Robot. and its Social Impacts_ , 2017.
  * [23] (2020) Moveit research roundup. [Online]. Available: https://moveit.ros.org/moveit/ros/2020/07/24/moveit-research-roundup.html
  * [24] M. Zucker, N. Ratliff, A. D. Dragan, M. Pivtoraiko, M. Klingensmith, C. M. Dellin, J. A. Bagnell, and S. S. Srinivasa, “CHOMP: Covariant hamiltonian optimization for motion planning,” _Int. J. of Robotics Research_ , vol. 32, no. 9-10, pp. 1164–1193, 2013.
  * [25] J. Schulman, Y. Duan, J. Ho, A. Lee, I. Awwal, H. Bradlow, J. Pan, S. Patil, K. Goldberg, and P. Abbeel, “Motion planning with sequential convex optimization and convex collision checking,” _Int. J. of Robotics Research_ , vol. 33, no. 9, pp. 1251–1270, 2014.
  * [26] M. Moll, I. A. Şucan, and L. E. Kavraki, “Benchmarking motion planning algorithms: An extensible infrastructure for analysis and visualization,” _IEEE Robot. Autom. Magazine_ , vol. 22, no. 3, pp. 96–102, 2015.
  * [27] L. P. Kaelbling and T. Lozano-Pérez, “Hierarchical task and motion planning in the now,” in _IEEE Int. Conf. Robot. Autom._ , 2011, pp. 1470–1477.
  * [28] S. Srivastava, E. Fang, L. Riano, R. Chitnis, S. Russell, and P. Abbeel, “Combined task and motion planning through an extensible planner-independent interface layer,” in _IEEE Int. Conf. Robot. Autom._ , 2014, pp. 639–646.
  * [29] M. Görner, R. Haschke, H. Ritter, and J. Zhang, “MoveIt! task constructor for task-level motion planning,” in _IEEE Int. Conf. Robot. Autom._ , 2019, pp. 190–196.
  * [30] R. Diankov, “Automated construction of robotic manipulation programs,” Ph.D. dissertation, Carnegie Mellon University, 2010.
  * [31] K. Hauser, “Robust contact generation for robot simulation with unstructured meshes,” in _Int. Symp. on Robotics Research_. Springer, 2016, pp. 357–373.
  * [32] M. Rickert and A. Gaschler, “Robotics Library: An object-oriented approach to robot applications,” in _IEEE/RSJ Int. Conf. on Intell. Robots and Syst._ , Sept. 2017, pp. 733–740.
  * [33] Personal Robotics Lab. (2016) Aikido. [Online]. Available: https://github.com/personalrobotics/aikido
  * [34] S. Karaman and E. Frazzoli, “Sampling-based algorithms for optimal motion planning,” _Int. J. of Robotics Research_ , vol. 30, no. 7, pp. 846–894, 2011.


A Lunar Backup Record of Humanity

Carson Ezell1⋆, Alexandre Lazarian2,3, & Abraham Loeb1

1Department of Astronomy, Harvard University

60 Garden Street, Cambridge, MA 02138, USA

2Department of Astronomy, University of Wisconsin-Madison

Madison, WI 53706, USA

3Centro de Investigación en Astronomía, Universidad Bernardo O’Higgins

Santiago, General Gana 1760, 8370993, Chile

⋆Correspondence to<EMAIL_ADDRESS>
###### Abstract

The risk of a catastrophic or existential disaster for our civilization is
increasing this century. A significant motivation for a near-term space
settlement is the opportunity to safeguard civilization in the event of a
planetary-scale disaster. A catastrophic event could destroy the significant
cultural, scientific, and technological progress on Earth. However, early
space settlements can preserve records of human activity by maintaining a
backup data storage system. The backup can also store information about the
events leading up to the disaster. The system would improve the ability of
early space settlers to recover our civilization after collapse. We show that
advances in laser communications and data storage enable the development of a
data storage system on the lunar surface with a sufficient uplink data rate
and storage capacity to preserve valuable information about the achievements
of our civilization and the chronology of the disaster.

##  1 Concept

A global catastrophic risk (GCR) is a “risk that might have the potential to
inflict serious damage to human well-being on a global scale”. [1] The most
severe GCRs include weapons of mass destruction, artificial pandemics,
supervolcanic eruptions, [2] or asteroid impacts. [3] Some of these risks also
pose existential threats to humanity. [4] Furthermore, recent exoplanet data
have suggested an abundance of potentially habitable planets, ranging from
0.03 to over 1 per Sun-like star. [5, 6] The absence of signatures of living
civilizations on exoplanets [7] might suggest that civilizations are fragile.

The National Aeronautics and Space Administration (NASA) plans to build its
Artemis Base Camp on the lunar surface by the end of the current decade, [8]
and China is similarly planning a research station on the lunar South Pole.
[9] SpaceX has designed a technical roadmap for the settlement of Mars. [10]
We can equip early space settlers with a record of human activity to improve
the prospects of civilization recovery if a terrestrial catastrophe occurs. We
propose a resilient, large-scale, lunar data storage system that utilizes
laser communications for receiving updated data about ongoing human activity.

The system would store the detailed records of our cultural, scientific,
technological, and ecological information. It would also contain documents and
imagery of mistakes and events leading up to the catastrophic disaster. Much
like the black box of an airplane, the backup system would preserve the
history of humanity after a catastrophe.

Before being transported to the lunar surface, the system could be loaded with
existing information about human civilization. Once on the moon, laser
communications could be used to transfer data to the system at high rates. The
system would store enough information to allow early space settlers to recover
civilization, both socially and biologically. Furthermore, stored genetic
information about other known species would allow our ecosystem to be
reconstructed.

The stored data should minimize biases and accurately portray human activities
and their consequences. The Voyager 1 and Voyager 2 probes, launched by NASA
in 1977, each carry a Golden Record that shares information about human
civilization with any extraterrestrial civilization that may be encountered by
them in the far future (Source: https://voyager.jpl.nasa.gov/golden-record/
(accessed on 29 September 2022)). While the Golden Record was designed to
represent human civilization, the content curation process required making
decisions about how we represent ourselves and who chooses, leading to
selection biases.[11] A lunar data backup would be more comprehensive than the
Golden Record, but the sources from where data are drawn can also have
selection biases. Actively sourcing records that are not already compiled in
accessible databases, including previously unwritten descriptions of technical
processes or cultural knowledge from underrepresented groups, would be a
necessary component of the data curation process. Social scientists and other
experts in inter-cultural communication are more well equipped than technical
experts to ensure a selection of content that represents all of humanity and
adequately portrays the information we wish to share, suggesting the need for
their involvement in the content curation process. [12] In some cases, the
preservation of physical artifacts—such as crop samples [13]—may also be
necessary to best represent our civilization and enable recovery.

Preserving records of the negative aspects of our civilization, including
conflict and the negligence of catastrophic risks, could guide a future
civilization to avoid making similar mistakes. If adequate knowledge is
preserved, especially details about the chronology of the disaster itself, the
survivors of the catastrophic event and future generations would have a deeper
concern for existential and catastrophic risks than our current civilization.
Future generations can then recover positive aspects of civilization while
exercising caution with respect to catastrophic or existential risks by
engaging in differential technological development.[4] The civilization that
recovers may have a higher probability of overcoming global challenges and
existential risks than our current civilization.

##  2 Challenges

Projects for the long-term preservation of data on Earth have been created in
many locations that may be safe in a disaster, such as in mines, on mountains,
and in the Arctic.[14] However, most existing projects aim to preserve
information for thousands to millions of years, and they are limited by the
lack of long-duration storage capabilities. [14] For example, the Memory of
Mankind project is building a large, long-term storage facility in a saltmine
that uses ceramic tablets as data carriers because their durability
significantly exceeds that of digital systems (Source: https://www.memory-of-
mankind.com/ (accessed on 22 October 2022)).

Another limitation of terrestrial data backup systems is that even remote
locations on Earth may not be safe in the event of a catastrophic disaster. In
addition, if survivors of the disaster are not aware of the backup storage
systems, the systems may not be discovered for a long time. A disaster that
leaves the Earth largely uninhabitable may also mean survivors in a self-
sufficient lunar settlement would be better equipped to recover civilization,
possibly on another celestial body.

Previous work has described possibilities for long-duration storage systems on
the moon which can survive catastrophic disasters and last millions of years,
but the challenges include developing long-term storage solutions and
communicating the information to future generations on Earth. [15] Our
proposal follows the trend toward the establishment of base camps on the lunar
surface itself. By preserving data for humans already on the lunar surface, we
eliminate the need for very long duration storage solutions or the
communication of information back to survivors on Earth.

Our proposal involves the technical challenges related to data storage and
data transmission capacity. The overall quantity of data in the world already
exceeds the data storage capacity significantly, and transmitting and storing
data on the lunar surface will be more constrained than terrestrial data
storage. The total volume of data created or copied worldwide was estimated at
$6.4\times 10^{22}$ bytes as of 2020, [16] and it is expected to increase to
$1.75\times 10^{23}$ bytes by 2025. [17] However, the global data storage
capacity was only about $6.7\times 10^{21}$ bytes in 2021. [18] Although this
demonstrates significant growth from a total storage capacity of $2.9\times
10^{20}$ bytes in 2007, [19] it is still an order of magnitude less than the
total data.

The urgency of GCRs suggests that we should include the backup system in our
earliest space settlement plans, limiting stored and transmitted data to the
most important information. We suggest storing books, academic research,
movies, earth imagery, and genetic information from known species. The
existing databases may provide large quantities of accessible information that
would be useful for civilizational recovery (see Table 1). Ongoing content
curation processes can contribute further records to the system over time to
promote the representation of all of humanity and ensure enough data are
preserved to enable a recovery. As the system ages or our storage capabilities
improve, the system can be upgraded by human or robotic operators on the lunar
surface.

Table 1: Initial stored data and data rate based on current information stored
in existing databases.

Category | Quantity | Stored Data (Bytes) ${}^{\text{a}}$ | Data Rate (Bytes/yr) ${}^{\text{b}}$
---|---|---|---
Books | $3\times 10^{7}$ | $6\times 10^{13}$ | $6.7\times 10^{12}$
Journal Articles | $8.45\times 10^{7}$ | $8.45\times 10^{13}$ | $4\times 10^{12}$
Films | $5.4\times 10^{5}$ | $1.08\times 10^{15}$ | $3\times 10^{13}$
Genetic Information ${}^{\text{c}}$ | N/A | $8.7\times 10^{15}$ | N/A
Earth Imagery ${}^{\text{d}}$ | N/A | $7.5\times 10^{14}$ | $9\times 10^{15}$

${}^{\text{a}}$ Sources: ISBNdb (https://isbndb.com/news (accessed on 5
September 2022)), IMDb (https://www.imdb.com/pressroom/stats/ (accessed on 5
September 2022)), International Association of Scientific, Technical and
Medical Publishers [20], Planet Labs (https://www.planet.com/faqs/ (accessed
on 5 September 2022)). ${}^{\text{b}}$ We estimated mean file sizes of books
(2 mb), journal articles (1 mb), and films (2 gb). ${}^{\text{c}}$ We consider
the number of catalogued species, [21] and we conservatively estimate the mean
genome size as the human genome size, [22] multiplying by a factor of 10 for
genetic diversity. ${}^{\text{d}}$ We consider collecting earth imagery data
from a single source and storing only the previous month, limiting the total
stored data.

###  2.1 Storage Capacity

The system must have sufficient capacity to store the necessary existing and
future data. Let $C_{i}$ be a category of information stored (e.g., books,
movies, journal articles, etc.) where $1<i<n$, let $q_{i}$ be the existing
quantity of bytes of data associated with category $i$, and let $r_{i}$ be the
growth rate of the total quantity of data (i.e., data rate/stored data) for
category $i$. Some categories of data demonstrate exponential growth, which is
enabled by the accelerating growth in data creation and collection in the era
of big data. [23] However, some categories may be better fit by a linear
growth model because rates of knowledge creation are constrained. Hence, we
let $a_{i}$ be an indicator variable where $a_{i}=1$ if the data for category
$i$ fit an exponential growth model and $a_{i}=0$ if the data fit a linear
growth model. We assume that the system must have sufficient capacity to store
all initial and future data until its capacity is increased. Then, the
necessary storage capacity of the system in bytes, $S$, is,

$S=\sum\limits_{i=1}^{n}q_{i}(a_{i}e^{r_{i}d}+(1-a_{i})(r_{i}d+1))\text{ ,}$
(1)

where $d$ is the duration of time, in years, before the system is replaced or
repaired.

Historically, space-based data systems (e.g., satellites) have served as data
relays rather than large data storage centers. [24] Because of the adverse
effects of the harsh conditions in outer space on equipment (e.g., radiation
and extreme temperatures), shielding systems and cooling equipment would need
to be developed before large-scale data storage would be feasible. Such
systems are already being considered by private organizations, including Cloud
Constellation and its satellite-based cloud infrastructure design known as
Space-Belt.[24] The establishment of permanent operations on celestial bodies,
such as the Artemis Base Camp, will also increase the demand for space-based
storage solutions and accelerate the technological development.

###  2.2 Data Transfer Rate

New data about ongoing human activity could be continuously transferred to the
system through laser communications from Earth. The data rate of sending new
data to the system must exceed the rate of new data production (See Figure 1).
Let $r_{U}$ be the data rate of uplink communications to the system. Then, the
necessary data rate, in bytes per year, is

$r_{U}=\sum\limits_{i=1}^{n}q_{i}r_{i}(a_{i}e^{r_{i}d}-a_{i}+1)\text{ .}$ (2)

Laser communications can be used to transmit data from ground stations to the
system at significantly higher rates than radiofrequency waves. [25] However,
the bandwidth of ground-to-space laser communications is limited by the
scintillation caused by optical turbulence, atmospheric absorption, beam
scattering, and the need for a clear line-of-sight path. [26, 27] Maintaining
multiple ground stations to transmit data can mitigate the negative effects of
cloud cover on transmission. A constant data stream at $622$ Mbps from a
ground station to the lunar surface—a rate which has been achieved by NASA’s
Lunar Laser Communications Demonstration (LLCD) [28, 29]—would be sufficient
to transmit over $10^{15}$ bytes/yr. This is sufficient to transmit all of the
aforementioned literature given the current growth rates. Near-term
improvements in data rates would enable the transmission of enough data to
include satellite imagery produced by the Dove and SkySat constellations
operated by Planet Labs (Source: https://www.planet.com/faqs/ (accessed on 31
August 2022)). We assume that redundant satellite imagery or higher-resolution
imagery from future earth observation (EO) satellites is not necessary for
transmission and storage.).

Laser communication data rates have historically demonstrated exponential
growth (See Figure 2), and a previous analysis suggests the U.S. Department of
Defense requires an increase in bits per second by an order of magnitude every
nine years. [30] NASA’s Artemis Program is also utilizing laser
communications, and its Orion EM-2 Optical Communications Terminal (O2O) will
be the first usage of optical communications for human spaceflight.[31] Future
systems can maintain the growth by leveraging new modulation schemes. The
existing techniques, such as pulse position modulation (PPM) and differential
phase-shift keying (DPSK) modulation, [32] have enabled our current
capabilities, and the usage of wavelength division multiplexing (WDM) may
enable even greater data rates.[33] Terrestrial fibers have already achieved
exa-bps ($10^{18}$ bits per second) using WDM,[34] and uplink transmissions to
satellites may experience similar increases in capabilities.

Figure 1: Projected data rate for new content given historical growth rates.
Figure 2: Maximum bandwidth of previous and planned NASA laser communications
demonstrations. [33]

##  3 Conclusion

Lunar exploration in the near future suggests the present is an optimal time
to consider the initial infrastructure for the first space bases. Early space
settlement designs should strongly consider the importance of catastrophic
risk mitigation, [35] including by developing the described data storage
system.

Whether the system enables civilization recovery still depends upon the self-
sufficiency of early space settlements or how effective they are as refuges
from catastrophic disasters.[36] Self-sufficiency can be achieved sooner if
existential risk mitigation is a motivating force for space development.
Ensuring space settlers have the capacity to begin the civilizational recovery
process—including access to spacecraft, energy, manufacturing, and critical
resources—can further increase recovery prospects. The data system’s chance of
surviving a catastrophe may be increased if the project is a shared,
international undertaking to reduce its vulnerability in a great power
conflict. International, inter-generational coordination would also enable
further initiatives to improve the prospects of the long-term future.

## References

  * [1] Bostrom, N. & Cirkovic, M. M.  _Global Catastrophic Risks_ (Oxford University Press, Oxford, New York, 2011).
  * [2] Mani, L., Tzachor, A. & Cole, P.  Global catastrophic risk from lower magnitude volcanic eruptions.  _Nature Communications_ 12, 4756 (2021).  URL https://www.nature.com/articles/s41467-021-25021-8.  Number: 1 Publisher: Nature Publishing Group.
  * [3] Westin, U., Ingdahl, W., Wariaro, V. & Shandwick, W.  Global Catastrophic Risks 2020 (2020).  URL https://globalchallenges.org/wp-content/uploads/Global-Catastrophic-Risks-2020-Annual-Report.pdf.
  * [4] Bostrom, N.  Analyzing Human Extinction Scenarios and Related Hazards.  _Journal of Evolution and Technology_ 9 (2002).
  * [5] Bryson, S. _et al._ The Occurrence of Rocky Habitable-zone Planets around Solar-like Stars from Kepler Data.  _The Astronomical Journal_ 161, 36 (2021).  URL https://ui.adsabs.harvard.edu/abs/2021AJ....161...36B.  ADS Bibcode: 2021AJ….161…36B.
  * [6] Hsu, D. C., Ford, E. B., Ragozzine, D. & Ashby, K.  Occurrence Rates of Planets Orbiting FGK Stars: Combining Kepler DR25, Gaia DR2, and Bayesian Inference.  _The Astronomical Journal_ 158, 109 (2019).  URL https://ui.adsabs.harvard.edu/abs/2019AJ....158..109H.  ADS Bibcode: 2019AJ….158..109H.
  * [7] Seager, S. & Deming, D.  Exoplanet Atmospheres.  _Annual Review of Astronomy and Astrophysics, vol. 48, p.631-672_ 48, 631 (2010).  URL https://ui.adsabs.harvard.edu/abs/2010ARA%26A..48..631S/abstract.
  * [8] NASA’s Plan for Sustained Lunar Exploration and Development.  Tech. Rep., National Aeronautics and Space Administration (2020).  URL https://www.nasa.gov/sites/default/files/atoms/files/a_sustained_lunar_presence_nspc_report4220final.pdf.
  * [9] Zou, Y., Xu, L. & Jia, Y.  A Tentative Plan of China to Establish a Lunar Research Station in the Next Ten Years 42, B3.1–34–18 (2018).  URL https://ui.adsabs.harvard.edu/abs/2018cosp...42E3886Z.  Conference Name: 42nd COSPAR Scientific Assembly ADS Bibcode: 2018cosp…42E3886Z.
  * [10] Musk, E.  Making Humans a Multi-Planetary Species.  _New Space_ 5, 46–61 (2017).  URL https://www-liebertpub-com.ezp-prod1.hul.harvard.edu/doi/10.1089/space.2017.29009.emu.  Publisher: Mary Ann Liebert, Inc., publishers.
  * [11] Schmitt, R. M.  _Archiving ”The Best of Ourselves” on the Voyager Golden Record: Rhetorics of the Frontier, Memory, and Technology_.  Master’s thesis, University of Colorado at Boulder, United States – Colorado (2017).  URL https://www.proquest.com/docview/1916508295/abstract/71D961D436FD4E56PQ/1.  ISBN: 9781369865141.
  * [12] Traphagan, J. W.  Should We Lie to Extraterrestrials? A Critique of the Voyager Golden Records.  _Space Policy_ 57, 101440 (2021).  URL https://www.sciencedirect.com/science/article/pii/S0265964621000321.
  * [13] Westengen, O. T., Jeppson, S. & Guarino, L.  Global Ex-Situ Crop Diversity Conservation and the Svalbard Global Seed Vault: Assessing the Current Status.  _PLOS ONE_ 8, e64146 (2013).  URL https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0064146.  Publisher: Public Library of Science.
  * [14] Guzman, M., Hein, A. M. & Welch, C.  Extremely Long-Duration Storage Concepts for Space.  _Acta Astronautica_ 130 (2016).
  * [15] Turchin, A. & Denkenberger, D.  Surviving global risks through the preservation of humanity’s data on the Moon.  _Acta Astronautica_ 146 (2018).
  * [16] IDC.  Worldwide Global DataSphere Forecast, 2021–2025: The World Keeps Creating More Data — Now, What Do We Do with It All?  Tech. Rep. #US46410421, IDC (2021).
  * [17] Reinsel, D., Gantz, J. & Rydning, J.  The Digitization of the World From Edge to Core.  IDC White Paper US44413318, Seagate (2018).  URL https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf.
  * [18] IDC.  Worldwide Global StorageSphere Forecast, 2021–2025: To Save or Not to Save Data, That Is the Question.  Tech. Rep. US47509621, IDC (2021).
  * [19] Hilbert, M. & López, P.  The World’s Technological Capacity to Store, Communicate, and Compute Information.  _Science_ 332, 60–65 (2011).  URL https://www.science.org/doi/abs/10.1126/science.1200970.  Publisher: American Association for the Advancement of Science.
  * [20] Johnson, R., Watkinson, A. & Mabe, M.  The STM Report: An overview of scientific and scholarly publishing (2018).  URL https://www.stm-assoc.org/2018_10_04_STM_Report_2018.pdf.
  * [21] Mora, C., Tittensor, D. P., Adl, S., Simpson, A. G. B. & Worm, B.  How Many Species Are There on Earth and in the Ocean?  _PLOS Biology_ 9, e1001127 (2011).  URL https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.1001127.  Publisher: Public Library of Science.
  * [22] Venter, J. C. _et al._ The Sequence of the Human Genome.  _Science_ 291, 1304–1351 (2001).  URL https://www.science.org/doi/full/10.1126/science.1058040.  Publisher: American Association for the Advancement of Science.
  * [23] Kaisler, S., Armour, F., Espinosa, J. A. & Money, W.  Big Data: Issues and Challenges Moving Forward.  In _2013 46th Hawaii International Conference on System Sciences_ , 995–1004 (2013).  ISSN: 1530-1605.
  * [24] Huang, H., Guo, S. & Wang, K.  Envisioned Wireless Big Data Storage for Low-Earth-Orbit Satellite-Based Cloud.  _IEEE Wireless Communications_ 25, 26–31 (2018).  Conference Name: IEEE Wireless Communications.
  * [25] Toyoshima, M. _et al._ Ground-to-satellite laser communication experiments.  _IEEE Aerospace and Electronic Systems Magazine_ 23, 10–18 (2008).  Conference Name: IEEE Aerospace and Electronic Systems Magazine.
  * [26] Majumdar, A. K.  Free-space laser communication performance in the atmospheric channel.  _Journal of Optical and Fiber Communications Reports_ 2, 345–396 (2005).  URL https://doi.org/10.1007/s10297-005-0054-0.
  * [27] Majumdar, A. K.  Introduction.  In Majumdar, A. K. & Ricklin, J. C. (eds.) _Free-Space Laser Communications: Principles and Advances_ , Optical and Fiber Communications Reports, 1–8 (Springer, New York, NY, 2008).  URL https://doi.org/10.1007/978-0-387-28677-8_1.
  * [28] Boroson, D. M. _et al._ Overview and results of the Lunar Laser Communication Demonstration.  In _Free-Space Laser Communication and Atmospheric Propagation XXVI_ , vol. 8971, 213–223 (SPIE, 2014).  URL https://www.spiedigitallibrary.org/conference-proceedings-of-spie/8971/89710S/Overview-and-results-of-the-Lunar-Laser-Communication-Demonstration/10.1117/12.2045508.full.
  * [29] DeVoe, C. E. _et al._ Optical overview and qualification of the LLCD space terminal.  In _International Conference on Space Optics — ICSO 2014_ , vol. 10563, 115–123 (SPIE, 2017).  URL https://www.spiedigitallibrary.org/conference-proceedings-of-spie/10563/105630F/Optical-overview-and-qualification-of-the-LLCD-space-terminal/10.1117/12.2304194.full.
  * [30] Dmytryszyn, M., Crook, M. & Sands, T.  Lasers for Satellite Uplinks and Downlinks.  _Sci_ 3, 4 (2021).  URL https://www.mdpi.com/2413-4155/3/1/4.  Number: 1 Publisher: Multidisciplinary Digital Publishing Institute.
  * [31] Seas, A. A., Robinson, B., Shih, T., Khatri, F. & Brumfield, M.  Optical Communications Systems for NASA’s Human Space Flight Missions (Chania, 2018).  URL https://ntrs.nasa.gov/citations/20180007086.  NTRS Author Affiliations: NASA Goddard Space Flight Center, Massachusetts Inst. of Technology NTRS Report/Patent Number: GSFC-E-DAA-TN60456 NTRS Document ID: 20180007086 NTRS Research Center: Goddard Space Flight Center (GSFC).
  * [32] Xu, C., Liu, X. & Wei, X.  Differential phase-shift keying for high spectral efficiency optical transmissions.  _IEEE Journal of Selected Topics in Quantum Electronics_ 10, 281–293 (2004).  Conference Name: IEEE Journal of Selected Topics in Quantum Electronics.
  * [33] Toyoshima, M.  Recent Trends in Space Laser Communications for Small Satellites and Constellations.  _Journal of Lightwave Technology_ 39, 693–699 (2021).  Conference Name: Journal of Lightwave Technology.
  * [34] Toyoshima, M. _et al._ Current status of research and development on space laser communications technologies and future plans in NICT.  In _2015 IEEE International Conference on Space Optical Systems and Applications (ICSOS)_ , 1–5 (2015).
  * [35] Gottlieb, J.  Space Colonization and Existential Risk.  _Journal of the American Philosophical Association_ 5, 306–320 (2019).  URL https://www.cambridge.org/core/journals/journal-of-the-american-philosophical-association/article/abs/space-colonization-and-existential-risk/B82206D1268B2C9221EEA64B6CB14416.  Publisher: Cambridge University Press.
  * [36] Beckstead, N.  How much could refuges help us recover from a global catastrophe?  _Futures_ 72, 36–44 (2015).  URL https://www.sciencedirect.com/science/article/pii/S0016328714001888.