# FogROS: An Adaptive Framework
for Automating Fog Robotics Deployment

Kaiyuan (Eric) Chen1, Yafei Liang1, Nikhil Jha1, Jeffrey Ichnowski1, Michael
Danielczuk1,
Joseph Gonzalez1, John Kubiatowicz1, Ken Goldberg1,2 1Department of Electrical
Engineering and Computer Science, University of California, Berkeley, CA, USA
2Department of Industrial Engineering & Operations Research, University of
California, Berkeley, CA, USA {kych, debbieliang-123, nikhiljha, jeffi,
mdanielczuk, jegonzal, kubitron<EMAIL_ADDRESS>
###### Abstract

As many robot automation applications increasingly rely on multi-core
processing or deep-learning models, cloud computing is becoming an attractive
and economically viable resource for systems that do not contain high
computing power onboard. Despite its immense computing capacity, it is often
underused by the robotics and automation community due to lack of expertise in
cloud computing and cloud-based infrastructure. Fog Robotics balances
computing and data between cloud edge devices. We propose a software
framework, FogROS, as an extension of the Robot Operating System (ROS), the
de-facto standard for creating robot automation applications and components.
It allows researchers to deploy components of their software to the cloud with
minimal effort, and correspondingly gain access to additional computing cores,
GPUs, FPGAs, and TPUs, as well as predeployed software made available by other
researchers. FogROS allows a researcher to specify which components of their
software will be deployed to the cloud and to what type of computing hardware.
We evaluate FogROS on 3 examples: (1) simultaneous localization and mapping
(ORB-SLAM2), (2) Dexterity Network (Dex-Net) GPU-based grasp planning, and (3)
multi-core motion planning using a 96-core cloud-based server. In all three
examples, a component is deployed to the cloud and accelerated with a small
change in system launch configuration, while incurring additional latency of
1.2 s, 0.6 s, and 0.5 s due to network communication, the computation speed is
improved by $2.6\times$, $6.0\times$ and $34.2\times$, respectively. Code,
videos, and supplementary material can be found at
https://github.com/BerkeleyAutomation/FogROS.

##  I Introduction

Power, weight, and cost considerations often mean robots do not include
computing capabilities capable of running large-scale multi-core CPU-based,
graphics processing unit (GPU)-based, field-programmable gate array
(FPGA)-based, or tensor processing unit (TPU)-based algorithms. For example, a
light-weight drone with an attached gripper that uses a GPU-based grasp-
planning module to compute grasp points for picking up objects [3] or perching
[32], requires access to a GPU that the drone would not have onboard. While
nearby computers can provide the necessary computing capabilities, this
practice can be complex to set up, scale, and is prone to over-provisioning.
Instead, we propose a framework based on the _Fog Robotics_ [11, 40, 39] idea
of balancing between the compute available at the edge and in the cloud. This
framework, _FogROS_ , is an extension of the Robot Operating System (ROS) [31]
that, with minimal effort, allows researchers to deploy components of their
software to the cloud, and correspondingly gain access to additional computing
cores, GPUs, FPGAs, and TPUs, as well as predeployed software made available
by other researchers.

ROS Master Sensor Node Control Node Edge  Grasp Planner Node Motion Planner
Node . VPC Grasp Target TopicSensor TopicPlan TopicGPU CPU CPU CPU CPU  (a)
FogROS Application on VPC

ROS Master Sensor Node Control Node Proxy Node Proxy Node Edge  Grasp Planner
Node Motion Planner Node . Cloud  ROS Master Sensor TopicPlan TopicSensor
TopicPlan TopicGPU CPU CPU CPU CPU  (b) FogROS Application with Proxy

Figure 1: FogROS Applications and Communications. ROS applications using
FogROS run nodes on the cloud or on an edge computer with a small change to
the configuration script. FogROS sets up the cloud computers and the secure
communication channels between the edge computer and the cloud, either through
a virtual private cloud (VPC) or through transparent proxying.

ROS, at its core, is a platform in which software components (_nodes_)
communicate with each other via a publication/subscription (pub/sub) system.
Individual nodes can publish messages to named _topics_ and subscribe to other
named topics to get messages published by other nodes. In practice, these
nodes all run on the robot and perhaps a nearby computer. For example, on a
robot, a sensor node publishes to a sensor topic, a planning node subscribes
to the sensor topic and compute a plan based on the sensor messages, and then
publishes messages that another node uses to execute the plan (Fig. 1).

With FogROS, a researcher can use the same code, and make a small change to a
configuration file to select components of the edge computer software to
deploy to cloud-based computers. On launch, FogROS provisions a cloud-based
computer, deploys the nodes to it, and then transparently passes the pub/sub
communication between the edge computer and the cloud. The only observable
differences are: (1) the pub/sub latency increases, and (2) the cloud-deployed
components can compute faster given the additional computing resources. The
increased latency means that not all components will benefit from being
deployed to the cloud, in particular, any component with real-time
requirements (e.g., a motor controller) or any component that requires little
computing power, should not be deployed to the cloud. On the other hand, for
many applications, the increased computation speed may enable new robot
capabilities, speed up tasks, and allow for higher accuracy in tasks such as
object detection or segmentation due to the use of larger models.

FogROS also supports launching pre-built automation container images. These
container images contain all the software and dependencies required to run a
program. To date, many academic and industrial open-source communities
leverage container services, such as Docker [6], to distribute their
applications. FogROS can deploy robot automation containers to the cloud
without explicitly configuring the environment and hardware, facilitating ease
of containerized software reuse.

This paper makes three contributions: (1) FogROS, an open-source extension to
ROS that allows user-friendly and adaptive deployment of software components
to cloud-based computers; (2) a method to pre-deploy containerized FogROS
software that allows commonly-used software to be quickly integrated into
applications; and (3) application examples evaluating the performance of
FogROS deployment.

###  I-A Design Principles

FogROS aims to adhere to the following design principles:

#### Transparent to software

FogROS should preserve ROS abstractions and interfaces. Applications should
notice no difference between cloud-deployed and on-board nodes (other than the
latency of message processing).

#### Flexible computing resources

Different nodes require different computing capabilities. Some nodes benefit
from additional computing cores, while others benefit from access to a GPU.
FogROS should make selecting the appropriate configuration simple.

#### Minimal configuration required

Running software nodes on a cloud-based computer should be as easy as running
them on the edge computer.

#### Pre-deployed nodes

Some useful nodes require extensive setup, installation of a dependency
structure, and may have conflicting dependency versions. FogROS should make it
possible to use pre-deployed containerized software through configuration.

#### Flexible Networking

Different networking options may have different availability, performance,
setup time, and costs associated. FogROS should allow the user to select the
networking options best suited to their application.

#### Security and Isolation

The communication between cloud and on-board nodes should be secure, and
FogROS should close ports that expose software to compromise.

##  II Related Work

Cloud computing has emerged as an attractive and economically viable [13]
resource to offload computation for robot automation systems with minimal
onboard computing power. [18] survey the capabilities, research potential, and
challenges of cloud robotics, as well as applications such as grasp planning,
motion planning, and collective robot learning, that might benefit from the
computational power of the cloud. Grasp planning and motion planning have both
shown to be amenable to cloud computation. [17], [40], and [21] generate robot
grasp poses in the cloud by implementing parallelizable Monte-Carlo sampling
of grasp perturbations [15, 16, 19] while [23] explore cloud grasp pose
computation that maintains privacy of proprietary geometries. In motion
planning, [20] introduce path planning as a service (PPaaS) for on-demand path
planning in the cloud and use Rapyuta to share plans among robots. [4] and
[12] both devise methods for splitting motion planning computation between the
cloud and the edge computer [11, 1]. In addition to providing computing
resources, the cloud can also facilitate sharing and benchmarking of
algorithms and models between edge computers [38] for grasping, motion
planning, or computer vision.

To leverage cloud resources, many in academia and industry endeavor to connect
edge computers to the cloud. Example approaches include using SSH port
forwarding [7] or VPN-based proxying [22] to support unmodified ROS
applications to share a single ROS master. FogROS builds on these approaches,
and adds automation of ROS node deployment to the cloud and a virtual private
cloud (VPC), saving time over prior approaches that require manual
configuration of network access rules and IP addresses. For example, setting
up a VPN-based proxying requires more than 12 steps for configuration and 37
steps for verification [7]. The complex manual configurations scale poorly and
are error-prone. ROSRemote [30] and MSA [43] replace the ROS communication
stack with custom Pub/Sub designs. Although edge computers can communicate
with nodes owned by other ROS masters, these systems require heavy code
changes to ROS applications. FogROS, as an option, leverages rosbridge [5], an
open-source webserver that enables an edge computer to interact with another
ROS environment with JSON queries. Given diverse attempts to connect edge
computers to the cloud, [42] and [34] call for a unified and standardized
framework to handle cloud-robot data interactions. FogROS aims to be a
painless solution to this open issue by allowing unmodified ROS applications
to be launched on the cloud with minimal additional configurations.

Sharing a similar vision as FogROS, RoboEarth [41] is a successful example
where edge computers share information on the cloud. However, in their use
cases, edge computers mainly use the shared database on the cloud, and do not
benefit from the powerful cloud computing resources. Rapyuta [26] and AWS
Greengrass [2] provide pipelines to deploy pre-built ROS nodes to edge
computers or robots. Both platforms build ROS nodes or Docker images on the
cloud, and push the built images to robots that are registered with their
platforms. FogROS considers the reversed direction of Rapyuta and AWS
Greengrass. Instead of pushing the computation from cloud to robots, FogROS is
a lightweight platform that allows developers to rapidly prototype
applications and gain quick access to extensive computing resources, without
conforming to an additional framework.

##  III Background

In this section, we provide a brief background on the building blocks of
FogROS, including (A) cloud-based computing, (B) ROS and its pub/sub system,
and (C) how ROS-based robotic systems are configured and launched.

###  III-A Cloud Computing

Cloud-based computing services, such as Amazon Web Services (AWS), Google
Cloud, and Microsoft Azure, offer network accessible computers of various
specifications to be rented on a per-time-unit basis. Setting up a service
typically requires a one-time registration and a credit card. Registered users
can setup, reconfigure, turn on, turn off, and tear down virtual computers in
the cloud. This can be done either through a web-browser interface, or
programmatically through a network-based application programming interface
(API). Computer configuration options include: amount of memory, amount of
processing cores, type and amount of GPUs, and inclusion of custom processing
hardware such as field-programmable gate arrays (FPGAs) and tensor processing
units (TPUs). FogROS uses the AWS cloud service API to setup a cloud-based
computer, deploy ROS and the code, secure network communications, and then run
the node.

###  III-B ROS and Pub/Sub

In ROS, _nodes_ (software components) communicate with each other using a
pub/sub (publication and subscription) system. Nodes register as publishers
and/or subscribers to named communication channels called _topics_. Each topic
has message type that determines what data is sent over the channel. For
example, a ROS node that monitors the joint state (e.g., angles) through
sensors, would publish messages of type JointState on an appropriately named
topic, and that topic would only contain JointState messages. When a node
publishes a sequence of messages to a topic, all registered subscribers will
receive the message in the same sequence they were published.

Coordination of the publishers and subscribers to topics is maintained by the
ROS _Master_ [33]. The ROS Master exposes network API that allows nodes to
connect over a network and register/unregister themselves as publishers and
subscribers to topics. During the registration process, publishers get the
current list of subscribers, and subscribers get the current list of
publishers. Publishers may then connect directly to already-registered
subscribers, and subscribers may connect directly to already-registered
publishers.

Once publishing and subscribing nodes are directly connected to each
other111As an implementation optimization, ROS nodes on the same machine can
communicate via a shared-memory queue, instead of using a network., publishing
nodes serialize message-specific data structure to a sequence of bytes and
sends the bytes over the connection. When subscribing nodes receive the
sequence of bytes, they deserialize the bytes to the message-specific data
structure and process the message.

However, existing ROS pub/sub communication has several limitations: (1) all
the nodes have to share the same master to communicate (inter-master
communication is not supported by ROS pub/sub protocol stack, and one has to
use out-of-band protocols for communicating across masters); (2) although it
is possible to join nodes from multiple machines to share a single master, the
communication for ROS is not secured, and users must configure security
protocols.

###  III-C ROS Launch Scripts

Robot systems can be comprised of a complex graph of nodes communicating with
each other via pub/sub. To consolidate an automation system deployment into a
single file, ROS supports a launch configuration file. This file specifies
which nodes are to be launched by code entry point, and allows for optional
remapping of topic names (e.g., so that code written to process a standard
message type can produce it from a topic with a name not known/specified when
the code was written). Listing 1 is an example launch script that launches a
client node and a server node from the mpt_ros package locally.

Listing 1: ROS Launch Script Example

⬇

<launch>

<!-- Run client node \-->

<node name="client" pkg="mpt_ros" type="client" output="screen" />

<!-- Run server node-->

<node name="server" pkg="mpt_ros" type="server" output="screen" />

</launch>

FogROS extends the launch script capabilities to allow the specification of
which nodes to deploy in the cloud and on what machine type.

##  IV Approach

To meet the design principles, FogROS (1) extends ROS launch scripts to
include an option of where to deploy and run a ROS node, the only place that
requires user configurations; (2) provisions cloud-based computers, securely
pushes the code or containers to them, and runs the code; (3) sets up one of
two networking options (VPC or Proxy) to transparently and automatically proxy
the pub/sub communication between the edge computer and the cloud; (4)
provides introspection infrastructure for monitoring network conditions; and
(5) supports launching containerized FogROS nodes from pre-built Docker
images.

###  IV-A Launch Script Extensions

FogROS uses standard ROS launch scripts as the user interface. Users specify
which nodes are to be deployed and what type of cloud computing instance is
used in the same launch file as the nodes that users want to deploy locally.
They can push multiple nodes to the cloud at the same time by providing the
path to a separate launch script. FogROS parses the launch script, finds and
collects all the packages in the script, and pushes them to the cloud
computer. As part of the configuration process, users can optionally specify a
bash script that installs dependencies outside of the FogROS launch process
(e.g., mirroring the steps to install dependencies on the edge computer).

Listing 2 provides an example of a FogROS launch script that serves the same
functionality as Listing 1, but with the server node running on a cloud
computer. Local ROS nodes, such as client, are launched as before. With
FogROS, the user specifies the launch file that contains the server node
(server.launch), the type of cloud computer (c5.24xlarge), and optionally, a
setup script (init.bash).

Listing 2: FogROS Launch Script Example

⬇

<launch>

<!-- Run client node as before \-->

<node name="client" pkg="mpt_ros" type="client" output="screen" />

<!-- Run server node w/ FogROS-->

<node name="server" pkg="fogros" type="fogros_launch.py" >

<rosparam>

instance_type: c5.24xlarge

launch_file: server.launch

env_script: init.bash

</rosparam>

</node>

</launch>

###  IV-B Cloud-Computer ROS Nodes

Figure 2: Sequence Diagram of FogROS Deployment Process. Users only need to
input the launch file, and FogROS automates the provisioning, deployment, code
execution, and network setup sequence.

When FogROS launches cloud-based nodes, it performs the following sequence of
steps that result in ROS nodes running on a cloud computer with messages being
transparently proxied between the edge computer and the cloud computer:

  1. 1.

Provision and start a cloud computer with the capabilities from the launch
file and pre-loaded with ROS

  2. 2.

Push code for ROS nodes to the cloud computer

  3. 3.

Run the environment setup script

  4. 4.

Set up secure networking (via Proxy or VPC)

  5. 5.

Launch the pushed code

Before FogROS provisions a cloud computer, it uses the cloud service provider
API to create security rules to set up a secure computing infrastructure
suitable for ROS application configuration. It closes network ports not needed
for communication between nodes. Then it provisions the cloud computer with a
specified location and type. To speed up the launching process, FogROS
specifies an image pre-loaded with the core ROS libraries to run on the cloud
computer. As part of the launch process, FogROS generates and installs secure
credentials on the cloud computer, and gets its public internet protocol (IP)
address.

Once the computer is started, using the IP address and secure credentials,
FogROS recursively copies the ROS code to the cloud computer securely over a
secure shell (SSH) [44] connection, optionally runs the user-specified setup
script, and builds the code on the cloud. With the code ready to run, FogROS
then starts the configured secure networking components for VPC (Sec. IV-C) or
proxying (Sec. IV-D), and runs the ROS nodes in the cloud.

###  IV-C Networking: Virtual Private Cloud

To allow the edge computer and cloud-based computers to communicate securely
with each other, FogROS automates the setup of a Virtual Private Cloud (VPC).
A VPC secures point-to-point communication between cloud computers by
assigning private IPs that are only accessible for other nodes within the VPC.
FogROS creates a Virtual Private Network (VPN) between the edge computer and
the VPC. A VPN is a secure network communication channel provided by the
operating system. With this setup, from the perspective of a ROS node, all
nodes appear as though they are on the same private network.

FogROS automates the setup of the VPC and the VPN when it provisions the cloud
computers to run the ROS nodes, by using the cloud service providers API to:
(1) create a VPC instance and a security group for it, (2) establish
credentials for the cloud-computers that will participate in the VPC, (3)
configure the cloud computers to use the VPC for cloud-to-cloud communication,
and (4) set up a VPN endpoint to which the edge computer will connect. Once
set up, the cloud service provider manages the VPC, while FogROS manages the
VPN. As part of the setup process, FogROS sets a unique private IP address for
each of the computers participating, so that the ROS nodes can establish
connections between computers.

###  IV-D Networking: Pub/Sub Proxying

In addition to VPC networking, FogROS also supports a proxied-network option
that enable communication between the edge computer and the cloud. This option
is available for cases where the VPC solution may be unavailable due to
service provider restrictions or costs, or when an additional level of
isolation between the edge computer and the cloud is desired. There are also
performance differences (see Section V) when considering the network options,
and a user of FogROS may wish to measure performance in their application
before choosing a suitable option.

In FogROS, a proxy consists of two ROS nodes, one running in the edge computer
and one running on the cloud. These nodes connect directly to each other via a
secure network connection, and register as publishers and subscribers to
topics on the ROS Master running on each computer. When a proxy node receives
a message from a subscription, it sends it to the other proxy node, which then
publishes it to the subscribers registered on its ROS Master.

Figure 3: Automatic Pub/Sub Proxy. The proxy tunnels the traffic only if there
is an active subscriber.

There are two options for FogROS to identify topics to proxy: (1) user-
specified in the configuration file, or (2) automated. If topics are specified
by the user in the configuration file, FogROS subscribes and publishes to the
topics specified. If the user does not specify topics, FogROS communicates
with the ROS Master on each end and identifies which topics have registered
subscribers and publishers. When a topic has a publisher on one end, and a
subscriber on the other, the ROS proxy nodes coordinate with each other to
proxy the associated topic (see Fig. 3). While the automated process is
simpler to setup for the developer, it may result in increased setup time as
the proxy nodes coordinate the setup of proxied topics, or wasted bandwidth on
topics that do not need proxying.

###  IV-E Network Monitoring

With the proxying network option, FogROS also provides interfaces to monitor
network conditions via ROS topics /fogros/latency and /fogros/throughput on
both the edge computer and the cloud. These interfaces do not introduce
additional overhead unless an active subscriber subscribes to them. Users can
also inspect and interact with ROS topics with standard ROS tools such as
rostopic. In addition, FogROS provides the same fault tolerance as ROS running
locally, where ROS nodes can re-join the pub/sub communication after network
interruption.

###  IV-F Pre-Built ROS Nodes

FogROS also supports launching containerized ROS nodes with a similar
interface to the FogROS launch script extension described in Section IV-A.
While an increasing number of ROS developers are using pre-built docker images
to host ROS nodes, this functionality is not natively supported by ROS. With
FogROS, users can specify the name of a publicly-available image on DockerHub
as well as the destination machine on which they want to launch it. FogROS
then uses a template environment setup script to pull and run the image on the
specified machine. It analyzes the machine type and configures the docker run
command to match the hardware (e.g., GPU) available on the computer.

Listing 3 shows an example launch script for a Dex-Net grasp planning node in
a docker image. FogROS provisions and starts a cloud computer (g4dn.xlarge)
with a GPU, pulls the dexnet:gpu image from DockerHub [6], and attaches the
docker container to the GPU, and runs it.

Listing 3: FogROS Docker Container Example

⬇

<launch>

<!-- Dex-Net Docker Image w/ FogROS \-->

<node name="dexnet" pkg="fogros" type="fogros_docker.py" output="screen">

<rosparam>

docker_image: keplerc/dexnet:gpu

machine_type: g4dn.xlarge

</rosparam>

</node>

</launch>

##  V Evaluation

Here we present three example applications on FogROS: (A) visual SLAM, (B)
Dex-Net grasp planning and (C) multi-core motion planning. The nodes, topics,
and split between a single-core edge computer with 2GB RAM and the cloud are
shown in Fig. 4. In addition to showing the network latency and performance
with FogROS, we highlight the simplicity and minimal configuration of
deploying these applications.

(a) VSLAM (b) Grasp Planning (c) Motion Planning

Figure 4: Example FogROS applications in experiments. In experiments, we run 3
sample applications, each with one node accelerated by cloud computing, with
the nodes and topics shown here. For brevity, we only depict the VPC-based
solution here, but we also experiment with the proxy-based solution.

###  V-A Visual SLAM Service

| Edge |  Cloud — FogROS — Network
---|---|---
Scenario | FPS | Create (s) | FPS | Create (s) | VPC (s) | Proxy (s)
fr1/xyz | 16.6 | 2.9 | 25.2 | 1.2 | 0.4 | 0.6
fr2/xyz | 14.7 | 2.1 | 30.2 | 0.8 | 0.4 | 0.6
fr1/desk | 15.6 | 2.8 | 23.8 | 2.0 | 0.4 | 0.6
TABLE I:  SLAM with FogROS. We benchmark FogROS on 3 different visual SLAM
scenarios, and record the frame-per-second (FPS) and the latency in creating a
new map (Create) in seconds on the local edge computer (using one-core CPU)
and a cloud-computer with 36-core CPU. We also record the average network time
in seconds for transmitting raw video frames to the cloud computer. FogROS
demonstrates up to 2.0x improvement on FPS and 2.6x improvement on new map
creation time than using only edge computer.

ORB-SLAM2 [27] is a visual simultaneous localization and mapping system that
uses monocular video input. In this experiment, a Camera Node publishes a
$640\times 480$ resolution video with each frame 48 KiB on average to the
cloud (Fig. 4a). On the cloud an ORB-SLAM2 node subscribes to the video feed
[36] and computes a pointcloud map along with the current estimated location
within the map, which are sent back to the robot. For more details on the ORB-
SLAM2 algorithm, we refer readers to the paper and open-source code available
from [27].

To configure FogROS to work with ORB-SLAM2, we build ROS docker images and
push them to Dockerhub [6]. We wrote a bash script to pull and run the docker
image and include its path as in Listing 2; FogROS then runs the script when
configuring the environment. After initialization, FogROS sets up and secures
communication between the robot and the cloud SLAM server.

To evaluate the performance of FogROS when deploying ORB-SLAM2, we compare the
cloud-deployed performance to an edge-computer-only implementation. We select
a 36-core cloud-computer (AWS c4.8xlarge) for the ORB-SLAM2 node, and compare
it with ORB-SLAM2 running on a one-core edge computer We report frames-per-
second (FPS) and latency that creates the first map (in seconds) [28]. Table I
suggests that cloud-based SLAM can achieve higher FPS, meaning that it can
aggregate more data and produce higher quality maps in a real-time setting.
Cloud-based SLAM also has less latency in generating a new map.

###  V-B Dex-Net Grasping Service

Grasp analysis computes the contact point(s) for a robot gripper that maximize
grasp reliability—the likelihood of successfully lifting the object given
those contact points. To plan grasps on rigid objects in industrial bins using
an overhead depth camera, we use an open-source implementation of the fully-
convolutional grasp-quality convolutional neural network (FC-GQ-CNN) [35, 25]
from Dex-Net[24]. We wrap FC-GQ-CNN in a ROS node and deploy it to the cloud
along with pretrained neural-network weights as a Docker image. We refer the
reader to [35] and [25] for details and code for the neural network and
grasping environment.

This node subscribes to 3 input topics containing a scene depth image and mask
for objects to be grasped, and a message of type sensor_msgs/CameraInfo
containing camera intrinsics. Internally, the node feeds this to FC-GQ-CNN,
which outputs a grasp pose and associated estimate of grasp quality. The node
wraps these outputs, along with the gripper type and coordinates in image
space, into a gqcnn_ros/GQCNNGrasp message, and publishes it.

While the node can be run both locally or in the cloud, using cloud GPU
instances as opposed to a CPU for neural-network inference can greatly reduce
computation time. In either case, the node is wrapped inside of a Docker
container, reducing the need for resolving dependency issues between deep-
learning libraries, CUDA, OS, and ROS versions. The pretrained models in the
image is intended for a setup similar to that shown in Figure 5; variations in
camera pose, camera intrinsics, or gripper type may require retraining the
underlying model for accurate predictions.

We run FogROS with the Dex-Net docker image using the launch file in Listing
3. We compare grasp planning times across 10 trials using both the CPU onboard
the edge computer and FogROS with the Docker images on the cloud. We also show
compute times when using a compressed depth image format to transfer images
instead of transferring raw images to the cloud directly. For the latter case,
images are compressed and decompressed using the republish node from the
image_transport ROS package [14]. Table II shows the results for both
compressed and uncompressed image transport between the nodes.

Figure 5: Grasp Planning: A robot with an overhead depth camera and either a suction or parallel jaw gripper (left) must plan a grasp on one of the objects in the bin beneath it given an RGBD image observation (middle). Examples of planned grasps (green) and their q-values are shown for both parallel jaw and suction grippers (right). | Edge | Cloud | FogROS VPC | FogROS Proxy
---|---|---|---|---
Scenario | Only | Compute | Network | Total | Network | Total
Compressed | 7.3 | 0.6 | 0.6 | 1.2 | 0.8 | 1.4
Uncompressed | 7.5 | 0.6 | 0.7 | 1.3 | 0.9 | 1.5
TABLE II: Dex-Net Grasp Planning with FogROS. We benchmark Dex-Net on 10
trials, and record the compute time in seconds on the local edge computer
(using CPU only), and the total (compute + network) time for using a 4-core
cloud computer with a single Nvidia T4 GPU. FogROS demonstrates up to 6.0x
improvement with VPC and 5.7x improvement with proxy than using only edge
server.

###  V-C Multi-Core Motion Planning

Figure 6: Motion Planning Scenarios. We run OMPL [37] motion planning problems as benchmarks. Left-to-right: Apartment, Cubicles, Home, and Twistycool. In these problems, the robot is a rigid-body object that must, through rotation and translation, find a collision-free path through the environment, from a start pose to a goal pose. | Edge | Cloud | FogROS VPC | FogROS Proxy
---|---|---|---|---
Scenario | Only | Compute | Network | Total | Network | Total
Apartment | 157.6 | 4.2 | 0.4 | 4.6 | 0.7 | 5.0
Cubicles | 35.8 | 1.4 | 0.3 | 1.7 | 0.6 | 2.1
Home | 161.8 | 6.2 | 0.3 | 6.5 | 0.6 | 6.8
TwistyCool | 167.9 | 5.1 | 0.4 | 5.5 | 0.6 | 5.7
TABLE III: Multi-core Motion Planning with FogROS. We benchmark FogROS on 6
different motion planning scenarios using the same multi-core motion planner,
and record the compute time in seconds on the local edge computer, and the
total(compute + network) time for using a 96-core computer in the cloud.
FogROS demonstrates up to 34.2x improvement with VPC and 31.52x improve with
proxy than using only edge server.

Motion planning computes a collision-free motion for a robot to get from one
configuration to another. Sampling-based motion planners randomly sample
configurations and connect them together into a graph, rejecting samples and
motions that are in collision. These planners can be scaled with additional
computing cores.

Using FogROS, we deploy a multi-core sampling-based motion planner [8, 10] to
a 96-core computer in the cloud to solve motion planning problems from the
Open Motion Planning Library (OMPL) [37] (see Fig. 6). This planner node
subscribes to topics for the collision model of the environment and motion
plan requests (Fig. 4c). When the planner node receives a message on any of
these topics, it computes a motion plan, and then publishes it to a separate
topic. For more details on the multi-core motion planner, we refer the reader
to the paper and the open-source code by [10]. To configure FogROS to work
with multi-core motion planner, we record the steps we use to setup the
dependencies (e.g., FCL [29] and Nigh [9]) in a script. By providing the
script, we configure FogROS similar to Listing 2.

We compare the planning time as the difference between publishing a motion
plan request message, and receiving the plan result message, and show the
results in Table III. The same motion planning problem is solved in a fraction
of the time on the cloud when compared to using the edge computer. If the
motion planner is asymptotically-optimal (finds shorter/better plans the
longer it runs and with more CPU cores), then one could potentially run the
motion planner for the same amount of time but get a better path using the
cloud. [1] explored and shown the benefit of using the tradeoff between more
cores and the resulting motion plan optimality.

##  VI Conclusion

We present FogROS, a user-friendly and adaptive extension to ROS that allows
developers to rapidly deploy portions of their ROS system to computers in the
cloud. FogROS sets up a secure network channel transparent to the program
code, allowing applications to be split between edge and the cloud with little
to no modification. In experiments, we show that the added latency associated
with pushing software components to the cloud is small when compared to the
time gained from using high-end computers with many cores and GPUs in the
cloud. However, in some simple tasks, using high-end cloud servers may lead to
marginal benefits and can be considered as an overkill.

In future work, we will address the interactions of multiple hardware systems
with different ROS masters, and handle the decentralized communication
efficiently and securely. We will also support real-time compression on the
proxy connection between edge computer and cloud to help reduce latency
especially on low-bandwidth connections.

## Acknowledgements

This research was performed at the AUTOLAB at UC Berkeley in affiliation with
the Berkeley AI Research (BAIR) Lab, and the CITRIS “People and Robots” (CPAR)
Initiative. The authors were supported in part by donations from Google,
Siemens, Toyota Research Institute, Autodesk, Honda, Intel, Hewlett-Packard,
and VMWare. This material is based upon work supported by the National Science
Foundation Graduate Research Fellowship Program under Grant No. DGE 1752814
and NSF/VMware Partnership on Edge Computing Data Infrastructure (ECDI), NSF
award 1838833. Any opinions, findings, and conclusions or recommendations
expressed in this material are those of the authors and do not necessarily
reflect the views of the sponsors. We thank our colleagues who provided
helpful feedback and suggestions, in particular Joseph M. Hellerstein and
Alvin Cheung.

## References

  * [1] Raghav Anand et al.  “Serverless Multi-Query Motion Planning for Fog Robotics”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2021
  * [2] “AWS IoT Greengrass” Accessed: 2021-02-15, https://aws.amazon.com/greengrass/
  * [3] Spencer B Backus, Lael U Odhner and Aaron M Dollar  “Design of hands for aerial manipulation: Actuator number and routing for grasping and perching”  In _Proc. IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)_ , 2014, pp. 34–40  IEEE
  * [4] Kostas Bekris, Rahul Shome, Athanasios Krontiris and Andrew Dobson  “Cloud automation: Precomputing roadmaps for flexible manipulation”  In _IEEE Robotics & Automation Magazine_ 22.2, 2015, pp. 41–50
  * [5] C. Crick, G. Jay, S. Osentoski and O.. Jenkins  “ROS and Rosbridge: Roboticists out of the loop”  In _2012 7th ACM/IEEE International Conference on Human-Robot Interaction (HRI)_ , 2012, pp. 493–494  DOI: 10.1145/2157689.2157846
  * [6] “Docker” Accessed: 2021-02-15, http://docker.com/
  * [7] Sami Salama Hussen Hajjaj and Khairul Saleh Mohamed Sahari  “Establishing remote networks for ROS applications via Port Forwarding: A detailed tutorial”  In _International Journal of Advanced Robotic Systems_ 14.3 SAGE Publications Sage UK: London, England, 2017, pp. 1729881417703355
  * [8] Jeffrey Ichnowski and Ron Alterovitz  “Scalable multicore motion planning using lock-free concurrency”  In _IEEE Trans. Robotics_ 30.5, 2014, pp. 1123–1136
  * [9] Jeffrey Ichnowski and Ron Alterovitz  “Concurrent Nearest-Neighbor Searching for Parallel Sampling-based Motion Planning in SO(3), SE(3), and Euclidean Spaces”  In _Workshop on the Algorithmic Foundation of Robotics (WAFR)_ Springer, 2018
  * [10] Jeffrey Ichnowski and Ron Alterovitz  “Motion Planning Templates: A Motion Planning Framework for Robots with Low-power CPUs”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2019
  * [11] Jeffrey Ichnowski et al.  “Fog Robotics Algorithms for Distributed Motion Planning Using Lambda Serverless Computing”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2020, pp. 4232–4238
  * [12] Jeffrey Ichnowski, Jan Prins and Ron Alterovitz  “Cloud-based Motion Plan Computation for Power-Constrained Robots”  In _Workshop on the Algorithmic Foundation of Robotics (WAFR)_ Springer, 2016
  * [13] Jeffrey Ichnowski, Jan Prins and Ron Alterovitz  “The economic case for cloud-based computation for robot motion planning”  In _Robotics Research_ Springer, 2020, pp. 59–65
  * [14] “image_transport”, wiki.ros.org/image_transport
  * [15] Ben Kehoe, Dmitry Berenson and Ken Goldberg  “Estimating part tolerance bounds based on adaptive cloud-based grasp planning with slip”  In _Proc. IEEE Conf. on Automation Science and Engineering (CASE)_ , 2012, pp. 1106–1113
  * [16] Ben Kehoe, Dmitry Berenson and Ken Goldberg  “Toward cloud-based grasping with uncertainty in shape: Estimating lower bounds on achieving force closure with zero-slip push grasps”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2012, pp. 576–583
  * [17] Ben Kehoe et al.  “Cloud-based robot grasping with the google object recognition engine”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2013, pp. 4263–4270
  * [18] Ben Kehoe, Sachin Patil, Pieter Abbeel and Ken Goldberg  “A survey of research on cloud robotics and automation”  In _IEEE Trans. Automation Science and Engineering_ 12.2, 2015, pp. 398–409
  * [19] Ben Kehoe, Deepak Warrier, Sachin Patil and Ken Goldberg  “Cloud-based grasp analysis and planning for toleranced parts using parallelized Monte Carlo sampling”  In _IEEE Trans. Automation Science and Engineering_ 12.2, 2014, pp. 455–470
  * [20] Miu-Ling Lam and Kit-Yung Lam  “Path planning as a service PPaaS: Cloud-based robotic path planning”  In _Proc. IEEE Int. Conf. on Robotics and Biomimetics (ROBIO)_ , 2014, pp. 1839–1844
  * [21] Pusong Li et al.  “Dex-Net as a service (DNaaS): A cloud-based robust robot grasp planning system”  In _Proc. IEEE Conf. on Automation Science and Engineering (CASE)_ , 2018, pp. 1420–1427
  * [22] Jia Zhi Lim and Danny Wee-Kiat Ng  “Cloud based implementation of ROS through VPN”  In _Int. Conf. on Smart Computing & Communications (ICSCC)_, 2019, pp. 1–5  IEEE
  * [23] Jeffrey Mahler et al.  “Privacy-preserving grasp planning in the cloud”  In _Proc. IEEE Conf. on Automation Science and Engineering (CASE)_ , 2016, pp. 468–475
  * [24] Jeffrey Mahler et al.  “Dex-Net 2.0: Deep learning to plan robust grasps with synthetic point clouds and analytic grasp metrics”  In _Proc. Robotics: Science and Systems (RSS)_ , 2017
  * [25] Jeffrey Mahler et al.  “Learning ambidextrous robot grasping policies”  In _Science Robotics_ 4.26 AAAS, 2019, pp. eaau4984
  * [26] Gajamohan Mohanarajah, Dominique Hunziker, Raffaello D’Andrea and Markus Waibel  “Rapyuta: A cloud robotics platform”  In _IEEE Trans. Automation Science and Engineering_ 12.2, 2014, pp. 481–493
  * [27] Raul Mur-Artal and Juan D Tardós  “ORB-SLAM2: An open-source slam system for monocular, stereo, and RGB-D cameras”  In _IEEE Trans. Robotics_ 33.5, 2017, pp. 1255–1262
  * [28] Luigi Nardi et al.  “Introducing SLAMBench, a performance and accuracy benchmarking methodology for SLAM”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2015, pp. 5783–5790
  * [29] Jia Pan, Sachin Chitta and Dinesh Manocha  “FCL: A general purpose library for collision and proximity queries”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2012, pp. 3859–3866
  * [30] Alyson Benoni Matias Pereira, Ricardo Emerson Julio and Guilherme Sousa Bastos  “ROSRemote: Using ROS on Cloud to Access Robots Remotely”  In _Robot Operating System (ROS)_ Springer, 2019, pp. 569–605
  * [31] Morgan Quigley et al.  “ROS: an open-source Robot Operating System”  In _ICRA workshop on open source software_ 3.3.2, 2009, pp. 5
  * [32] P Ramon-Soria et al.  “Autonomous landing on pipes using soft gripper for inspection and maintenance in outdoor environments”  In _Proc. IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)_ , 2019, pp. 5832–5839
  * [33] “ROSMaster”, http://wiki.ros.org/rosmaster
  * [34] Olimpiya Saha and Prithviraj Dasgupta  “A comprehensive survey of recent trends in cloud robotics architectures and applications”  In _Robotics_ 7.3 Multidisciplinary Digital Publishing Institute, 2018, pp. 47
  * [35] Vishal Satish, Jeffrey Mahler and Ken Goldberg  “On-Policy Dataset Synthesis for Learning Robot Grasping Policies Using Fully Convolutional Deep Networks”  In _IEEE Robotics & Automation Letters_, 2019
  * [36] J. Sturm et al.  “A Benchmark for the Evaluation of RGB-D SLAM Systems”  In _Proc. IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)_ , 2012
  * [37] Ioan A. Şucan, Mark Moll and Lydia E. Kavraki  “The Open Motion Planning Library”  In _IEEE Robotics & Automation Magazine_ 19.4, 2012, pp. 72–82  URL: http://ompl.kavrakilab.org
  * [38] Ajay Kumar Tanwani, Raghav Anand, Joseph E Gonzalez and Ken Goldberg  “RILaaS: Robot inference and learning as a service”  In _IEEE Robotics & Automation Letters_ 5.3, 2020, pp. 4423–4430
  * [39] Ajay Kumar Tanwani et al.  “A fog robotics approach to deep robot learning: Application to object recognition and grasp planning in surface decluttering”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2019, pp. 4559–4566  IEEE
  * [40] Nan Tian et al.  “A cloud robot system using the dexterity network and Berkeley robotics and automation as a service (BRASS)”  In _Proc. IEEE Int. Conf. Robotics and Automation (ICRA)_ , 2017, pp. 1615–1622
  * [41] Markus Waibel et al.  “RoboEarth”  In _IEEE Robotics & Automation Magazine_ 18.2, 2011, pp. 69–82
  * [42] Jiafu Wan et al.  “Cloud robotics: Current status and open issues”  In _IEEE Access_ 4, 2016, pp. 2797–2807
  * [43] Binhuai Xu and Jing Bian  “A Cloud Robotic Application Platform Design Based on the Microservices Architecture”  In _Int. Conf. on Control, Robotics and Intelligent System_ , 2020, pp. 13–18
  * [44] T Ylonen and C Lonvick  “The Secure Shell (SSH) Protocol Architecture”  RFC Editor, Internet Requests for Comments, 2006, pp. 1–29  URL: https://www.rfc-editor.org/rfc/rfc4251.txt


#  Vanishing of black hole tidal Love numbers from scattering amplitudes

Mikhail M. Ivanov<EMAIL_ADDRESS>School of Natural Sciences, Institute for
Advanced Study, 1 Einstein Drive, Princeton, NJ 08540, USA  Zihan Zhou
<EMAIL_ADDRESS>Department of Physics, Princeton University, Princeton,
NJ 08540, USA

###### Abstract

We extract the black hole (BH) static tidal deformability coefficients (Love
numbers) and their spin-0 and spin-1 analogs by comparing on-shell amplitudes
for fields to scatter off a spinning BH in the worldline effective field
theory (EFT) and in general relativity (GR). We point out that the GR
amplitudes due to tidal effects originate entirely from the BH potential
region. Thus, they can be separated from gravitational non-linearities in the
wave region, whose proper treatment requires higher order EFT loop
calculations. In particular, the elastic scattering in the near field
approximation is produced exclusively by tidal effects. We find this
contribution to vanish identically, which implies that the static Love numbers
of Kerr BHs are zero for all types of perturbations. We also reproduce the
known behavior of scalar Love numbers for higher dimensional BHs. Our results
are manifestly gauge-invariant and coordinate-independent, thereby providing a
valuable consistency check for the commonly used off-shell methods.

Introduction.— The worldline point-particle effective field theory for
gravitational wave sources is a modern toolbox for precision waveform
calculations Goldberger and Rothstein (2006a, b); Porto (2016a); Goldberger
(2022). The increasing interest to these calculations is fueled by recent
discoveries of gravitational waves from black hole (BH) binaries Abbott  _et
al._ (2016). In the EFT each compact object in a binary is approximated as a
point particle at leading order, while the finite-size effects are captured by
the higher-derivative operators on the worldline. These operators generate
multipolar corrections to the point mass potential. The most general worldline
theory for a perturbed spherically symmetric body at leading order in
derivatives of the long-wavelength metric field is given by

$S_{\rm pp}=-m\int d\tau+c_{E}\int d\tau E_{\mu\nu}E^{\mu\nu}+c_{B}\int d\tau
B_{\mu\nu}B^{\mu\nu}\,,$ (1)

where $m$ is the mass of a compact body, $E_{\mu\nu}$ and $B_{\mu\nu}$ are the
electric (parity even) and magnetic (parity odd) parts of the Weyl
tensor.111We work in the unit system $G=c=\hbar=1$. The dimensionfull Wilson
coefficients $c_{E,B}$ measure the gravitational response of the body to
external tidal fields in the quadrupolar sector. A simple response calculation
shows that the action (1) generates the following Newtonian potential
$\Phi_{N}$ Kol and Smolkin (2012); Cardoso  _et al._ (2019); Hui  _et al._
(2020); Charalambous  _et al._ (2021a) (schematically),

$\Phi_{N}=\frac{m}{r}-\sum_{m=-2}^{2}\mathcal{E}_{2m}r^{2}\left(1-\frac{c_{E}}{r^{5}}\right)\,,$
(2)

where $\mathcal{E}_{2m}$ are tidal harmonic coefficients, we assumed a long
distance limit and ignored the magnetic part for simplicity. This expression
coincides with a classic Newtonian definition of the static tidal response,
which is controlled by the static deformability coefficients, “Love numbers”
Poisson and Will (2014); Binnington and Poisson (2009). Thus, $c_{E,B}$
provide us with a gauge-invariant definition of Love numbers in general
relativity (GR). In order to extract the Love numbers for a particular object,
one needs to match some quantity calculated in the full theory (GR) and the
EFT.

The Love numbers capture details of body’s internal structure, e.g. they
depend on the equation of state for neutron stars Flanagan and Hinderer
(2008). For BHs, however, the application of the EFT leads to a surprising
result. Matching the EFT and GR calculations for BH static perturbations
implies that their Love numbers vanish identically in GR in four dimensions
Damour and Nagar (2009); Binnington and Poisson (2009); Kol and Smolkin
(2012); Hui  _et al._ (2020); Chia (2020); Charalambous  _et al._ (2021a).
This is in sharp contrast with the dimensional analysis (Wilsonian
naturalness), suggesting that $c_{E,B}\sim r_{s}^{5}$, where $r_{s}$ is the
Scwarzschild radius. The vanishing of the EFT Wilson coefficients for BHs has
been a major puzzle in BH physics for many years Porto (2016b), see
Charalambous  _et al._ (2021b); Hui  _et al._ (2022a, b); Charalambous  _et
al._ (2022) for proposals addressing this problem.

The vanishing of black hole Love numbers is however, still a controversial
topic. The problem is that this result is obtained by comparing certain static
field profiles in GR with the corresponding EFT off-shell one-point functions
that are calculated in a particular coordinate system. In theory, this should
not be a problem as one is free to choose any quantity for matching and the
result should not depend on whether this quantity is gauge-invariant or not.
In practice, however, the matching in specific gauges may be difficult, and
often leads to conflicting conclusions, see e.g. a recent debate in the
literature on whether the Love numbers vanish for Kerr black holes Poisson
(2015); Le Tiec and Casals (2020); Chia (2020); Charalambous  _et al._
(2021a), and discussions on interference between the tidal effects and Post-
Newtonian corrections Kol and Smolkin (2012); Poisson (2020); Charalambous
_et al._ (2021a); Creci  _et al._ (2021); Ivanov and Zhou (2022). This leaves
room for doubt about results of the off-shell Love number extraction, see e.g.
Gralla (2018); Kim  _et al._ (2022).

To avoid any confusion, it is desirable to match the EFT and GR by comparing
manifestly gauge invariant quantities, such as amplitudes to elastically
scatter off a BH geometry in GR versus an S-matrix element in the EFT. One can
easily estimate that the Love operator contributes to the graviton-BH cross-
section at order $\sim\omega^{8}c_{E}^{2}\sim\omega^{8}r_{s}^{10}$. Since the
EFT is valid when $r_{s}\omega\ll 1$, this term is much smaller than the
leading long-range (Newtonian) contribution $\sim r_{s}^{2}$, and also than
relativistic corrections to that contribution. The total cross-section should
be of the form, schematically

$\sigma_{\rm
GR}(\omega)=\underbrace{r_{s}^{2}}_{\text{Newton}}\underbrace{(1+(r_{s}\omega)^{2}+...)}_{\text{rel.
corrections}}+\underbrace{r_{s}^{10}\omega^{8}}_{\text{finite size}}\,.$ (3)

The smallness of the finite-size contribution makes it hard to extract. At
face value, one needs to compute the full GR cross-section to the fifth Post-
Minkowski (PM) order in black hole perturbation theory (BHPT). In addition,
one needs to calculate the EFT amplitude at the same 5PM, which is a four loop
calculation in the EFT nomenclature,222Strictly speaking, the leading finite-
size contribution in (3) is a 3PM term that comes from the interference
between the Love number and the Newtonian amplitudes. This, however, will be
irrelevant for our further discussion.  see Kälin and Porto (2020); Kälin  _et
al._ (2020); Cheung and Solon (2020); Bern  _et al._ (2021a, b) for recent
progress in these calculations, including tidal effects.

In this Letter we show that in fact, there is a consistent approximation to
BHPT, where the total cross-section is given exclusively by the finite-size
operators. Using this approximation, the matching with the EFT can be
performed entirely at the tree level.

General EFT for Kerr black holes.— A general astrophysical relevant BH is
described by the Kerr metric Kerr (1963). The Kerr black hole has two horizon,
$r_{\pm}=M\pm\sqrt{M^{2}-a^{2}}$, where $M$ and $a$ denote BH mass and spin.
Within the EFT, the worldline action inherits symmetries of the underlying
gravitational background, i.e. the EFT for spinning black holes must have
axial symmetry. In the context of static tides it is sufficient to incorporate
this fact by promoting the Love numbers in (1) to tensors Goldberger  _et al._
(2020); Charalambous  _et al._ (2021a), i.e. considering the following EFT for
metric perturbations,

$S_{\text{finite size}}=\int
d\tau~{}\lambda^{i^{\prime}j^{\prime}}_{ij}E^{ij}E_{i^{\prime}j^{\prime}}+\text{magnetic}\,,$
(4)

where we have switched to the BH rest frame, and
$\lambda^{i^{\prime}j^{\prime}}_{ij}$ is a symmetric real matrix. The above
local EFT coupling only captures conservative effects. In order to account for
dissipation we introduce the coupling between the long-wavelength tidal field
and the composite mass quadrupole $Q_{ij}(X)$ Goldberger and Rothstein
(2006b); Goldberger  _et al._ (2020); Ivanov and Zhou (2022),

$S_{\rm diss}=\int d\tau~{}Q_{ij}(X)E^{ij}+\text{magnetic}\,,$ (5)

where $X$ are gapless degrees of freedom on the horizon. Actions (4) and (5)
can be used to compute, e.g. a potential contribution to the Weyl curvature
scalar for $\ell=2$ Charalambous  _et al._ (2021a) (schematically),

$\begin{split}&\psi^{(\ell=2)}_{0}\sim\sum_{m=-2}^{2}{}_{2}Y_{\ell
m}(\theta,\phi)\mathcal{E}_{2m}\left(1-\frac{k^{(2)}_{2m}+i\nu^{(2)}_{2m}}{r^{5}}\right)\,,\end{split}$
(6)

where ${}_{2}Y_{\ell m}$ is the spin-weighted spherical harmonic,
$k^{(2)}_{2m}$ is a real coefficient related to
$\lambda_{ij,i^{\prime}j^{\prime}}$, whist $\nu^{(2)}_{2m}$ is a real number
generated by the time-reversal odd (non-conservative) part of the retarded
correlator $\langle Q_{ij}Q_{i^{\prime}j^{\prime}}\rangle_{\text{ret}}$
Charalambous  _et al._ (2021a). The factor in front of the $r^{-5}$ term in
Eq. (6) is called the response coefficient. Note that its real part captures
the conservative effects (Love numbers), while the imaginary part is
responsible for BH absorption (dissipation numbers) Chia (2020); Charalambous
_et al._ (2021a).

The local action (4) can be generalized to the case of a generic test field
with an angular multipole $\ell$ and a positive integer spin $s$. The most
general leading order EFT action needed to reproduce the effect of static Love
numbers and their spin-0 and spin-1 analogs is given by

$\begin{split}\sum_{\ell=s}\frac{1}{2\ell!}\int
d\tau\Bigg{[}&\lambda^{(0)}{}^{L}_{L^{\prime}}\partial_{\langle
L\rangle}\phi\partial^{\langle L^{\prime}\rangle}\phi\\\
&+\lambda^{(1)}{}^{L}_{L^{\prime}}\partial_{\langle
L{-1}}E_{i_{\ell}\rangle}\partial^{\langle
L^{\prime}{-1}}E^{i^{\prime}_{\ell}\rangle}\\\
&+\lambda^{(2)}{}^{L}_{L^{\prime}}\partial_{\langle
L{-2}}E_{i_{\ell-1}i_{\ell}\rangle}\partial^{\langle
L^{\prime}{-2}}E^{i^{\prime}_{\ell-1}i^{\prime}_{\ell}\rangle}\Bigg{]}\,,\end{split}$
(7)

where we have omitted the magnetic contributions for brevity,
$L=i_{1}...i_{\ell}$ is the multi-index,
$\partial_{L}\equiv\partial_{i_{1}}...\partial_{i_{\ell}}$, $\langle L\rangle$
denotes the trace-free part, $E^{i}$ and $\phi$ are test electric and scalar
fields.

The Wilson tensors $\lambda^{(s)}{}^{L^{\prime}}_{L}$ have previously been
extracted by comparing the static EFT off-shell one-point functions like (6)
with BHPT calculations, which implied that all such tensors vanish identically
Chia (2020); Charalambous  _et al._ (2021a). In contrast, the dissipation
numbers $\nu^{(2)}_{\ell m}$ we found to be non-zero Le Tiec and Casals
(2020). These results, however, were obtained in a coordinate-dependent
fashion. Now we show how the Love numbers and dissipation numbers can be
extracted from the on-shell scattering and absorption cross-sections in a
gauge-invariant manner.

Scattering off a Kerr black hole in general relativity.— The scattering by
rotating black holes is an old and well studied subject Matzner and Ryan
(1978); Futterman  _et al._ (1988); Dolan (2008). We present only few
essential elements in this Letter and leave other details for future work
Ivanov and Zhou . Consider a wave of a spin-$s$ test field impinging along the
axis of a Kerr BH. The scattering cross-section is given by

$\frac{d\sigma}{d\Omega}=|f_{s}(\theta)|^{2}+|g_{s}(\theta)|^{2}\,,$ (8)

where $\theta$ is the scattering angle, $f_{s}(\theta)$ and $g_{s}(\theta)$
are helicity-conserving and helicity-reversing amplitudes, respectively. Their
partial wave expressions are given by

$\left\\{\begin{array}[]{ll}f_{s}(\theta)\\\
g_{s}(\theta)\end{array}\right\\}=\frac{\pi}{i\omega}\sum_{P=\pm
1}\sum_{\ell=s}^{\infty}\left\\{\begin{array}[]{ll}{}_{-s}S^{s}_{\ell}(\theta,a\omega)\\\
{}_{-s}S^{s}_{\ell}(\pi-\theta,a\omega)P(-1)^{\ell+s}\end{array}\right\\}{}_{-s}S^{s}_{\ell}(0,a\omega)[\eta_{\ell
s}^{P}\exp(2i\delta^{P}_{\ell s})-1]\,,$ (9)

where $P=\pm 1$ is parity, ${}_{-s}S^{m}_{\ell}(\theta,a\omega)$ are spin-
weighted spheroidal harmonics Teukolsky (1972, 1973), $\exp(2i\delta^{P}_{\ell
s})$ is the scattering phase, $\eta_{\ell s}^{P}$ is the transmission factor
that captures absorption by the BH horizon.

The transmission coefficients and scattering phases are extracted from a
separable equation for perturbations around Kerr black holes known as the
Teukolsky equation Teukolsky (1972, 1973). Each type of perturbations is
encapsulated in a specific Newman-Penrose (NP) scalar that can be used to
compute a corresponding energy flux. In order to compute the scattering cross-
section we need the NP scalars with spin weights $(-s)$, which factorize as

$\psi_{-s}=e^{im\phi}e^{-i\omega
t}{}_{-s}S_{\ell}^{m}(\theta;a\omega){}_{-s}R_{\ell m}(r)\,.$

For the physically relevant solution, the radial part ${}_{-s}R_{\ell m}$
satisfies the purely in-going boundary condition at the BH horizon and has the
following asymptotic at spatial infinity ($r_{*}$ is the tortoise coordinate),

${}_{-s}R_{\ell m}\sim\underbrace{B^{\text{(inc)}}_{-s\ell m}r^{-1}e^{-i\omega
r_{*}}}_{\text{ingoing wave}}+\underbrace{B^{\text{(refl)}}_{-s\ell
m}r^{2s-1}e^{i\omega r_{*}}}_{\text{outgoing wave}}\,,$ (10)

where $B^{\text{(inc)}}_{-s\ell m}$ and $B^{\text{(refl)}}_{-s\ell m}$ are
complex constants. The phase shifts are given by

$\eta^{P}_{\ell s}e^{2i\delta^{P}_{\ell
s}}=(-1)^{\ell+1}\frac{A_{s}}{(2\omega)^{2s}}\frac{B^{\text{(refl)}}_{-s\ell
s}}{B^{\text{(inc)}}_{-s\ell s}}\,,$ (11)

where $A_{s}$ are normalization factors related to the Starobinsky-Teukolsky
constants Ivanov and Zhou .

The constants $B^{\text{(inc)}}_{-s\ell s}$ and $B^{\text{(refl)}}_{-s\ell s}$
should be extracted from the solution of the appropriate Tekolsky equations.
Mano, Suzuki, and Takasugi (MST) have constructed such solutions in a
systematic low-frequency expansion Mano  _et al._ (1996); Mano and Takasugi
(1997). The solution takes the form of an infinite series over hypergeometric
functions in the near zone (potential) region, and of an infinite series of
Coulomb wavefunctions in the far zone (wave) region. $B^{\text{(inc)}}_{-s\ell
m}$ and $B^{\text{(refl)}}_{-s\ell m}$ are determined by matching these two
series. The MST solution is a linear combination of modes labeled by the
“renormalized” angular momentum $\nu=\ell+O(\epsilon^{2})$, where
$\epsilon\equiv 2M\omega$ is the PM expansion parameter, and $\ell\geq s$ is
the usual integer angular momentum number.

The partial wave amplitude in the sector $\nu$ and $s$, formally to all powers
in frequency, is given by

$\begin{split}&\frac{B^{\text{(refl)}}_{s\ell m}}{B^{\text{(inc)}}_{s\ell
m}}=\frac{1}{\omega^{2s}}{\color[rgb]{0,0,1}\underbrace{\frac{1+ie^{i\pi\nu}\frac{K_{-\nu-1}}{K_{\nu}}}{1-ie^{-i\pi\nu}\frac{\sin(\pi(\nu-s+i\epsilon))}{\sin(\pi(\nu+s-i\epsilon))}\frac{K_{-\nu-1}}{K_{\nu}}}}_{\text{Near
zone}}}{\color[rgb]{1,0,0}\underbrace{\times\frac{A_{-}^{\nu}}{A_{+}^{\nu}}e^{i\epsilon(2\mathop{\rm
ln}\nolimits\epsilon-({1-\kappa}))}}_{\text{Far zone}}}\,,\end{split}$ (12)

where $\kappa=\sqrt{1-a^{2}/M^{2}}$, and $A_{+}$,
$A_{-},~{}K_{\nu},~{}K_{-\nu-1}$ are some $\epsilon$-dependent coefficients.
Crucially, the above expression factorizes into two distinctive contributions.
The first term (in blue) comes from the matching between the potential and the
wave region expansions. It is sourced by the perturbed gravitational potential
in the near zone and hence contains information about finite-size effects
encoded in the multipole expansion of BH perturbations. The second term (in
red) stems from the solution of the Teukolsky equation in the wave zone. By
construction, it contains PM terms due to non-linearity of gravity but no
information about the BH finite size structure. Crucially, this separation
holds only in linear BHPT.

Figure 1: Diagrammatic interpretation of the elastic scattering amplitude in
the EFT and its representation in terms of the near zone and far zone parts in
GR. Curly lines stand for off-shell gravitons. The vertical straight lines
depict the worldline. External legs correspond to external spin-$s$ on-shell
fields. The upper diagrams stem from the EFT finite-size action. The lower
diagrams describe the scattering of the on-shell fields off background
potential modes in the far region.

The interpretation of Eq. (12) within the EFT is not straightforward. We may
associate the two terms in Eq. (12) with two sets of EFT diagrams shown in Fig
1. The wave zone term captures the scattering of on-shell gravitons off the BH
geometry. Naively, it is this part that maps onto the EFT PM loop expansion.
Indeed, if we ignore the potential zone contribution and retain the 1PM
corrections from the radiation zone, we recover the Newtonian answer, e.g.

$\frac{d\sigma^{\rm
GR}}{d\Omega}\Big{|}_{\text{1PM}}=\frac{M^{2}}{\sin^{4}\left(\frac{\theta}{2}\right)}\left(\cos^{8}\left(\frac{\theta}{2}\right)+\sin^{8}\left(\frac{\theta}{2}\right)\right)\,,$
(13)

for a Schwarzschild BH and for the spin-2 field. This result can be reproduced
with the tree-level EFT diagrams analogous to the one shown in Fig. 1 Bautista
_et al._ (2021); Saketh and Vines (2022); Ivanov and Zhou . In contrast, the
near field contribution in Eq. (12), physically, incorporates finite-size
effects. Specifically, the first order near zone expansion should capture the
static Love number contribution. The relativistic $\epsilon$\- corrections to
this result correspond to the graviton-dressed Love number diagrams and
frequency-dependent local worldline operators
$\sim\lambda_{\ell(\omega^{2})}\dot{E}^{2}_{ij}$ (“dynamical Love numbers”)
Charalambous  _et al._ (2021a); Ivanov and Zhou (2022), shown in Fig. 1. These
appear starting at second order in the near zone expansion.

The above arguments suggest that the separation between the near zone and far
zone contributions should hold in the EFT. This may not be true if EFT loop
diagrams produce logarithmic divergences that should be renormalized by the
Love number.333Here we employ dimensional regularization, where non-
logarithmic divergence vanish identically. The logarithms then indicate the
mixing between loops and finite-size operators in the EFT, which complicates
the matching with the GR results.444For general renormalized angular momentum
$\nu$ there are no logarithms in the near zone part of GR amplitudes, and
hence there is no ambiguity. The logarithmic corrections appear only in the
limit $\nu\to\ell\in\mathbb{N}$. This is akin to dimensional regularization.
Strictly speaking, a full calculation is needed in this case. However, since
logarithms should be present both in the EFT and UV calculations, one may
identify the scheme-independent (running) part of the Love numbers from the GR
solution. In what follows we will see that for four dimensional Kerr BH
scattering there are no logs and thus no mixing, and hence the matching
between the EFT and GR is unambiguous.

Scattering in the near zone approximation.— Let us neglect the PM terms
completely and compute the cross-section entirely from the near zone term.
This amounts to using an approximate BHPT solution obtained through the
leading order matching of the potential and radiation regions Starobinskiǐ
(1973); Starobinskiǐ and Churilov (1974); Page (1976); Chia (2020)555This
solution can be recovered as the $\epsilon\to 0$ limit of Eq. (12).. At this
order one matches the first order near zone solution with the zeroth order far
zone solution (describing a free motion with an angular momentum $\ell$) in an
overlapping region where both solutions are valid. Note that this
approximation is unacceptable from the practical point of view as it misses
the leading order contributions in (3). However, it is perfectly suitable for
our goal to extract the finite size effects.

In the leading near zone approximation the parity-even and parity-odd phase
shifts take the same expressions and hence the helicity reversing amplitude
vanishes. Assuming that the scattering is perturbative, the total cross-
section in the partial wave approach can be decomposed into the elastic and
absorptive contributions:

$\begin{split}&\sigma_{\rm
elastic}=\frac{4\pi}{\omega^{2}}\sum_{\ell=s}^{\infty}(2\ell+1)\sin^{2}\delta_{\ell
s}\,,\\\ &\sigma_{\rm
abs}=\frac{\pi}{\omega^{2}}\sum_{\ell=s}^{\infty}(2\ell+1)\Big{(}1-\eta_{\ell
s}^{2}\Big{)}\,.\end{split}$ (14)

Performing a matching calculation, we get

$\begin{split}&\eta_{\ell s}e^{2i\delta_{\ell s}}=\\\
&1+i(-1)^{s}\frac{(\ell+s)!(\ell-s)!}{(2\ell)!(2\ell+1)!}\Big{(}2\omega(r_{+}-r_{-})\Big{)}^{2\ell+1}\mathcal{I}_{-s\ell
s}\,,\end{split}$ (15)

where $\mathcal{I}_{s\ell m}$ is the harmonic near zone response function Chia
(2020); Charalambous  _et al._ (2021a),

$\mathcal{I}_{s\ell
m}=i(-1)^{s+1}P_{+}\frac{(\ell+s)!(\ell-s)!}{(2\ell)!(2\ell+1)!}\prod_{j=1}^{\ell}\left(j^{2}+4P_{+}^{2}\right)\,,$
(16)

and $P_{+}\equiv\frac{am-2{r}_{+}{\omega}}{r_{+}-r_{-}}$. With Eq. (15), we
get

$\displaystyle\eta_{\ell s}$
$\displaystyle=1-(-1)^{s}\frac{(\ell+s)!(\ell-s)!}{(2\ell)!(2\ell+1)!}\Big{(}2\omega(r_{+}-r_{-})\Big{)}^{2\ell+1}{\rm
Im}\mathcal{I}_{-s\ell s}~{},$ (17) $\displaystyle\delta_{\ell s}$
$\displaystyle=\frac{1}{2}(-1)^{s}\frac{(\ell+s)!(\ell-s)!}{(2\ell)!(2\ell+1)!}\Big{(}2\omega(r_{+}-r_{-})\Big{)}^{2\ell+1}{\rm
Re}\mathcal{I}_{-s\ell s}~{}.$

Since ${\rm Re}\mathcal{I}_{-s\ell s}=0$ for Kerr BHs, we conclude that the
scattering phase shift is zero for all spins $s$ and multipoles $\ell$, to all
orders of the BH spin,

$\sigma^{\rm GR}_{\rm elastic,\ell}=0\,.$ (18)

Comparing this with the EFT result from the local action (7) we conclude that
all static Kerr Love numbers vanish identically, in agreement with previous
off-shell calculations Chia (2020); Charalambous  _et al._ (2021a).

As far as absorption is concerned, it is straightforward to see from Eq. (14)
that

$\begin{split}\sigma_{\rm
abs,\ell}=&\frac{2(-1)^{s}\pi}{\omega^{2}}(2\ell+1)\frac{(\ell+s)!(\ell-s)!}{(2\ell)!(2\ell+1)!}\\\
&\times\Big{(}2\omega(r_{+}-r_{-})\Big{)}^{2\ell+1}{\rm Im}\mathcal{I}_{-s\ell
s}\,.\end{split}$ (19)

This generalizes the result of Page (1976) for the $\ell=s$ case. Note that
the imaginary part of the response coefficient generates the absorption cross-
section and is directly linked with the EFT dissipation numbers (6) Chia
(2020); Goldberger  _et al._ (2020); Charalambous  _et al._ (2021a); Ivanov
and Zhou (2022).

Love numbers of higher dimensional BHs.— Love numbers do not vanish in general
for BHs in spacetimes with a number of dimensions $d$ greater than four Kol
and Smolkin (2012); Hui  _et al._ (2020). Let us perform their explicit
matching from near zone scattering amplitudes. For simplicity, we focus on
scalar fluctuations of higher dimensional static BHs. The corresponding phase
shift is given by

$\eta_{\ell}e^{2i\delta_{\ell}}=1+i\frac{2^{1-\hat{d}-2\ell}\pi(r_{+}\omega)^{\hat{d}+2\ell}}{\Gamma(\frac{\hat{d}}{2}+\ell)\Gamma(1+\frac{\hat{d}}{2}+\ell)}\mathcal{I}_{\ell}\,,$
(20)

where $\hat{d}\equiv d-3$, $\hat{\ell}\equiv\ell/\hat{d}$, and the response
function

$\mathcal{I}_{\ell}=\frac{\Gamma(-2\hat{\ell}-1)\Gamma(1+\hat{\ell})\Gamma(1+\hat{\ell}-\frac{2ir_{+}\omega}{\hat{d}})}{\Gamma(-\hat{\ell})\Gamma(2\hat{\ell}+1)\Gamma(-\hat{\ell}-\frac{2ir_{+}\omega}{\hat{d}})}~{}.$
(21)

From this equation, we get

$\displaystyle\eta_{\ell}$
$\displaystyle=1-\frac{2^{1-\hat{d}-2\ell}\pi(r_{+}\omega)^{\hat{d}+2\ell}}{\Gamma(\frac{\hat{d}}{2}+\ell)\Gamma(1+\frac{\hat{d}}{2}+\ell)}{\rm
Im}\mathcal{I}_{\ell}\,,$ (22) $\displaystyle\delta_{\ell}$
$\displaystyle=\frac{2^{-\hat{d}-2\ell}\pi(r_{+}\omega)^{\hat{d}+2\ell}}{\Gamma(\frac{\hat{d}}{2}+\ell)\Gamma(1+\frac{\hat{d}}{2}+\ell)}{\rm
Re}\mathcal{I}_{\ell}~{}.$

On the EFT side, the worldline action

$S_{\text{finite size}}=\int
d\tau\sum_{\ell=0}^{\infty}\frac{\lambda_{\ell}^{s=0}}{2\ell!}\Big{(}\partial_{\langle
L\rangle}\phi\Big{)}^{2}$ (23)

yields the following tree-level scattering amplitude in the orbital sector
$\ell$,

$\begin{split}iT&=i\frac{\lambda_{\ell}^{s=0}}{\ell!}\omega^{2\ell}\frac{\ell!(\hat{d}-2)!!}{(2\ell+\hat{d}-2)!!}\frac{(\ell+\hat{d}-1)!}{\ell!(\hat{d}-1)!}P_{\ell}^{(d)}(\cos\theta)\,,\end{split}$
(24)

where $P_{\ell}^{(d)}$ are generalized Legendre polynomials. Comparing this
with the phase shift from the UV theory (22), we obtain

$\lambda_{\ell}^{s=0}=(-1)^{\ell}\frac{\pi^{\frac{d-1}{2}}}{2^{\ell-2}}\frac{\Gamma\left(\frac{5-d}{2}-\ell\right)}{\Gamma\left(\frac{5-d}{2}\right)\Gamma\left(\frac{d-3}{2}\right)}r_{+}^{2\ell+d-3}{\rm
Re}\mathcal{I}_{\ell}\,,$ (25)

which identically coincides with the result of off-shell matching from Hui
_et al._ (2020). Note that according to Eq.(21) the Love numbers vanish if
$\hat{\ell}$ is an integer, exhibit the classical renormalization group
running if $\hat{\ell}$ is half integer, and are constant numbers
$O(r_{+}^{2\ell+d-3})$ otherwise, in full agreement with the off-shell results
Kol and Smolkin (2012); Hui  _et al._ (2020).

Conclusions.— We have matched on-shell amplitudes of massless fields
scattering off BHs in the worldline EFT and the near zone approximation of
BHPT. We have found that the static tidal Love numbers vanish for four
dimensional spinning (Kerr) black holes to all orders of the black hole spin.
Our results are gauge-invariant, and hence they remove any uncertainty as to
the validity of the previous results based on the coordinate-dependent off-
shell matching.

We have also reproduced the known behavior of the spin-0 Love numbers of BHs
in a general number of dimensions. This is an important consistency check of
our approach and of the former off-shell calculations. We stress that the
mapping between the EFT and GR potential and wave regions does not work if
Love numbers run logarithmically. Nevertheless, we can still extract the
scheme-independent part from the full GR solution in this case Ivanov and Zhou
.

Two facts are key to the matching of elastic cross-sections: the realization
that finite-size effects originate from the BH near region, and the absence of
logarithms. These have allowed us to bypass both a full calculation of four
loop corrections in the EFT, and the construction of the Teukolsky equation
solution at the 5PM order. It would be interesting to extend our results to
the time-dependent local worldline couplings (“dynamical Love numbers”), which
are non-zero for four dimensional Kerr black holes Charalambous  _et al._
(2021a). These correspond to a second order near zone approximation. It is
also important to understand the implications of the Love symmetry for on-
shell observables. Indeed, the Love symmetry explains the vanishing of Love
numbers in the off-shell calculations as a result of an algebraic constraint
Charalambous  _et al._ (2021b). It would be curious to see if this constraint
manifests itself at the level of on-shell scattering amplitudes.

Acknowledgments. We thank Horng Sheng Chia, Sergei Dubovsky, and Gregor Kälin
for helpful discussions. We are grateful to Panos Charalambous, Alfredo
Guevara, Lam Hui, Austin Joyce, Julio Parra-Martinez for their comments on the
draft. We are especially grateful to Rafael Porto for detailed feedback on the
draft.

## References

  * Goldberger and Rothstein (2006a) W. D. Goldberger and I. Z. Rothstein, Phys. Rev. D 73, 104029 (2006a), arXiv:hep-th/0409156 .
  * Goldberger and Rothstein (2006b) W. D. Goldberger and I. Z. Rothstein, Phys. Rev. D 73, 104030 (2006b), arXiv:hep-th/0511133 .
  * Porto (2016a) R. A. Porto, Phys. Rept. 633, 1 (2016a), arXiv:1601.04914 [hep-th] .
  * Goldberger (2022) W. D. Goldberger, in  _2022 Snowmass Summer Study_ (2022) arXiv:2206.14249 [hep-th] .
  * Abbott  _et al._ (2016) B. P. Abbott _et al._ (LIGO Scientific, Virgo), Phys. Rev. Lett. 116, 061102 (2016), arXiv:1602.03837 [gr-qc] .
  * Kol and Smolkin (2012) B. Kol and M. Smolkin, JHEP 02, 010 (2012), arXiv:1110.3764 [hep-th] .
  * Cardoso  _et al._ (2019) V. Cardoso, L. Gualtieri, and C. J. Moore, Phys. Rev. D 100, 124037 (2019), arXiv:1910.09557 [gr-qc] .
  * Hui  _et al._ (2020) L. Hui, A. Joyce, R. Penco, L. Santoni, and A. R. Solomon, (2020), arXiv:2010.00593 [hep-th] .
  * Charalambous  _et al._ (2021a) P. Charalambous, S. Dubovsky, and M. M. Ivanov, (2021a), arXiv:2102.08917 [hep-th] .
  * Poisson and Will (2014) E. Poisson and C. M. Will,  _Gravity: Newtonian, Post-Newtonian, Relativistic_ (Cambridge University Press, 2014).
  * Binnington and Poisson (2009) T. Binnington and E. Poisson, Phys. Rev. D 80, 084018 (2009), arXiv:0906.1366 [gr-qc] .
  * Flanagan and Hinderer (2008) E. E. Flanagan and T. Hinderer, Phys. Rev. D 77, 021502 (2008), arXiv:0709.1915 [astro-ph] .
  * Damour and Nagar (2009) T. Damour and A. Nagar, Phys. Rev. D 80, 084035 (2009), arXiv:0906.0096 [gr-qc] .
  * Chia (2020) H. S. Chia, (2020), arXiv:2010.07300 [gr-qc] .
  * Porto (2016b) R. A. Porto, Fortsch. Phys. 64, 723 (2016b), arXiv:1606.08895 [gr-qc] .
  * Charalambous  _et al._ (2021b) P. Charalambous, S. Dubovsky, and M. M. Ivanov, Phys. Rev. Lett. 127, 101101 (2021b), arXiv:2103.01234 [hep-th] .
  * Hui  _et al._ (2022a) L. Hui, A. Joyce, R. Penco, L. Santoni, and A. R. Solomon, JCAP 01, 032 (2022a), arXiv:2105.01069 [hep-th] .
  * Hui  _et al._ (2022b) L. Hui, A. Joyce, R. Penco, L. Santoni, and A. R. Solomon, (2022b), arXiv:2203.08832 [hep-th] .
  * Charalambous  _et al._ (2022) P. Charalambous, S. Dubovsky, and M. M. Ivanov, (2022), arXiv:2209.02091 [hep-th] .
  * Poisson (2015) E. Poisson, Phys. Rev. D 91, 044004 (2015), arXiv:1411.4711 [gr-qc] .
  * Le Tiec and Casals (2020) A. Le Tiec and M. Casals, (2020), arXiv:2007.00214 [gr-qc] .
  * Poisson (2020) E. Poisson, (2020), arXiv:2012.10184 [gr-qc] .
  * Creci  _et al._ (2021) G. Creci, T. Hinderer, and J. Steinhoff, Phys. Rev. D 104, 124061 (2021), [Erratum: Phys.Rev.D 105, 109902 (2022)], arXiv:2108.03385 [gr-qc] .
  * Ivanov and Zhou (2022) M. M. Ivanov and Z. Zhou, (2022), arXiv:2208.08459 [hep-th] .
  * Gralla (2018) S. E. Gralla, Class. Quant. Grav. 35, 085002 (2018), arXiv:1710.11096 [gr-qc] .
  * Kim  _et al._ (2022) J.-W. Kim, M. Levi, and Z. Yin, Phys. Lett. B 834, 137410 (2022), arXiv:2112.01509 [hep-th] .
  * Kälin and Porto (2020) G. Kälin and R. A. Porto, JHEP 11, 106 (2020), arXiv:2006.01184 [hep-th] .
  * Kälin  _et al._ (2020) G. Kälin, Z. Liu, and R. A. Porto, Phys. Rev. Lett. 125, 261103 (2020), arXiv:2007.04977 [hep-th] .
  * Cheung and Solon (2020) C. Cheung and M. P. Solon, Phys. Rev. Lett. 125, 191601 (2020), arXiv:2006.06665 [hep-th] .
  * Bern  _et al._ (2021a) Z. Bern, J. Parra-Martinez, R. Roiban, E. Sawyer, and C.-H. Shen, JHEP 05, 188 (2021a), arXiv:2010.08559 [hep-th] .
  * Bern  _et al._ (2021b) Z. Bern, J. Parra-Martinez, R. Roiban, M. S. Ruf, C.-H. Shen, M. P. Solon, and M. Zeng, Phys. Rev. Lett. 126, 171601 (2021b), arXiv:2101.07254 [hep-th] .
  * Kerr (1963) R. P. Kerr, Phys. Rev. Lett. 11, 237 (1963).
  * Goldberger  _et al._ (2020) W. D. Goldberger, J. Li, and I. Z. Rothstein, (2020), arXiv:2012.14869 [hep-th] .
  * Matzner and Ryan (1978) R. A. Matzner and J. Ryan, M. P., APJ 36, 451 (1978).
  * Futterman  _et al._ (1988) J. A. H. Futterman, F. A. Handler, and R. A. Matzner,  _Scattering from black holes_ (1988).
  * Dolan (2008) S. R. Dolan, Class. Quant. Grav. 25, 235002 (2008), arXiv:0801.3805 [gr-qc] .
  * (37) M. M. Ivanov and Z. Zhou, in preparation .
  * Teukolsky (1972) S. Teukolsky, Phys. Rev. Lett. 29, 1114 (1972).
  * Teukolsky (1973) S. A. Teukolsky, Astrophys. J. 185, 635 (1973).
  * Mano  _et al._ (1996) S. Mano, H. Suzuki, and E. Takasugi, Prog. Theor. Phys. 95, 1079 (1996), arXiv:gr-qc/9603020 .
  * Mano and Takasugi (1997) S. Mano and E. Takasugi, Prog. Theor. Phys. 97, 213 (1997), arXiv:gr-qc/9611014 .
  * Bautista  _et al._ (2021) Y. F. Bautista, A. Guevara, C. Kavanagh, and J. Vines, (2021), arXiv:2107.10179 [hep-th] .
  * Saketh and Vines (2022) M. V. S. Saketh and J. Vines, (2022), arXiv:2208.03170 [gr-qc] .
  * Starobinskiǐ (1973) A. A. Starobinskiǐ, Soviet Journal of Experimental and Theoretical Physics 37, 28 (1973).
  * Starobinskiǐ and Churilov (1974) A. A. Starobinskiǐ and S. M. Churilov, Soviet Journal of Experimental and Theoretical Physics 38, 1 (1974).
  * Page (1976) D. N. Page, Phys. Rev. D 13, 198 (1976).