# AutonomROS: A ReconROS-based Autonomonous Driving Unit

Christian Lienen1, Mathis Brede2, Daniel Karger3, Kevin Koch4, Dalisha Logan5,
Janet Mazur6, Alexander Philipp Nowosad7, Alexander Schnelle8, Mohness Waizy9,
and Marco Platzner10  Department of Computer Science
Paderborn University
Germany
Email<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

Autonomous driving has become an important research area in recent years, and
the corresponding system creates an enormous demand for computations.
Heterogeneous computing platforms such as systems-on-chip that combine CPUs
with reprogrammable hardware offer both computational performance and
flexibility and are thus interesting targets for autonomous driving
architectures. The de-facto software architecture standard in robotics,
including autonomous driving systems, is ROS 2. ReconROS is a framework for
creating robotics applications that extends ROS 2 with the possibility of
mapping compute-intense functions to hardware.

This paper presents AutonomROS, an autonomous driving unit based on the
ReconROS framework. AutonomROS serves as a blueprint for a larger robotics
application developed with ReconROS and demonstrates its suitability and
extendability. The application integrates the ROS 2 package Navigation 2 with
custom-developed software and hardware-accelerated functions for point cloud
generation, obstacle detection, and lane detection. In addition, we detail a
new communication middleware for shared memory communication between software
and hardware functions. We evaluate AutonomROS and show the advantage of
hardware acceleration and the new communication middleware for improving
turnaround times, achievable frame rates, and, most importantly, reducing CPU
load.

###### Index Terms:

Robotics, FPGA, ROS 2, ReconROS

##  I Introduction

Autonomous driving is a rapidly evolving and important area of research [1],
which has the potential to fundamentally impact our transportation systems by,
for example, significantly reducing traffic accidents [2, 3, 4, 5], congestion
[4, 5, 6], and carbon dioxide emissions [4, 7, 8].

One of the major technical challenges that could impede the widespread
adoption of autonomous driving is the high computational cost involved [9,
10]. The computing demands for autonomous driving are exceptionally rigorous.
Vehicles must continuously sense, process, and analyze their environment in
real-time, make decisions, and execute them reliably and precisely. Providing
the required computational performance is expensive, and the resulting costs
could make autonomous vehicles unaffordable for many people, especially as the
technology is still in its early stages of development [4]. Additionally, the
necessary electrical power needed for the computations can be substantial
[10]. This poses a particular problem for electric vehicles and can result in
reduced ranges or larger and heavier batteries. Moreover, the more complex
autonomous driving systems become [11], the less reliable they become, and
system failures may occur [12].

One promising technology that addresses the computational cost challenge of
autonomous driving is reconfigurable hardware. Reconfigurable hardware devices
such as field-programmable gate arrays (FPGAs) comprise programmable logic and
memory blocks and allow for exploiting parallelism in computations on several
levels. Many modern FPGAs are systems-on-chip, including dedicated processors
and even embedded GPUs. Compared to microprocessors, FPGAs exhibit massive
parallelism, making them ideal for computationally intensive functions such as
those seen in autonomous driving, e.g., [13, 14], object detection [15, 16] or
localization [17]. Moreover, FPGAs can be highly energy-efficient [18, 19,
20]. Compared to application-specific integrated circuits (ASICs), the key
advantage of FPGAs is their flexibility, as they can be reprogrammed for
different functions.

Our work focuses on making hardware acceleration based on FPGAs available for
robotics systems. Supporting widely used software architectures and
programming abstractions is of utmost importance for the successful adoption
of reconfigurable hardware technology. The standard software framework for
modern robotics applications is ROS, the robot operating system, or ROS 2
[21]. At the architecture level, ROS foresees the functional decomposition of
an application into nodes, which are then linked via many-to-many or one-to-
one communication paradigms.

In the last years, several approaches for integrating reconfigurable hardware
into ROS-based applications have been proposed [22, 23, 24, 25, 26]. One of
these approaches is our own development ReconROS [27], which allows for
mapping complete ROS nodes to hardware while preserving the software
programming model for both hardware and software nodes.

This paper presents AutonomROS, an autonomous driving unit based on ReconROS.
AutonomROS serves as a blueprint for a more extensive ReconROS-based
application combining state-of-the-art open-source ROS 2 packages, custom-
developed ROS 2 software nodes, and ROS 2 nodes completely mapped to hardware.
In particular, we make the following novel contributions:

  * •

We present a new zero-copy communication middleware for ReconROS, based on
Iceoryx, that greatly improves the performance of shared-memory inter-process
communication between hardware and software nodes.

  * •

We demonstrate hardware acceleration for the functions point cloud
computation, obstacle detection, and adoption lane following. We show that
AutonomROS is infeasible on the selected system-on-chip without hardware
acceleration.

  * •

We show the suitability of ReconROS for developing larger robotics
applications comprising existing software packages, ROS 2 software nodes, and
nodes accelerated in hardware.

The remainder of the paper is structured as follows: Section II provides
background about ROS 2-based architectures for autonomous driving and
ReconROS. Section III presents our new and efficient shared memory
communication layer for ReconROS. In Section IV, we elaborate on the
architecture of AutonomROS and its hardware-accelerated components. Section V
presents an experimental evaluation, and Section VI concludes the paper and
sketches ideas for feature work.

##  II Background

In recent years, there has been much research in the field of architectures
for autonomous driving. In this section, we first briefly introduce some
relevant projects for autonomous driving and then provide background on
ReconROS, the framework used by AutonomROS.

###  II-A Autonomous Driving Architectures

In 2015, the Autoware Foundation started the Autoware.ai project, which aimed
to propose a functional software architecture for autonomous driving based on
ROS 1 as an open-source project. Later, Autoware.ai was transferred to the
Autoware.auto project [28], now based on ROS 2, that provides a complete
system stack for autonomous driving, including, e.g., functions for
perception, planning, and control. Currently, Autoware.auto focuses on parking
scenarios. The integration of FPGAs and the switch to a heterogeneous compute
platform was shown in a follow-up project started by one of the Autoware.ai
founders [29]. Besides the architecture, the follow-up project also includes
the specification and development of compilers, the operating system,
middleware, and applications.

In another work, Reke et al. [30] proposed a self-driving architecture on ROS
2 that focuses on safe and reliable real-time behavior while preserving the
main advantages of ROS, e.g., standardized message formats and distributed
architecture. However, the proposed architecture does not include hardware
acceleration and requires a desktop-class CPU for execution.

Several FPGA-based architectures for autonomous driving were presented in, for
example, [31, 32, 33, 15, 34, 35]. All these architectures have in common that
they are designed for a rather limited scenario and do not rely on ROS 2 and
state-of-the-art packages for autonomous driving, such as Navigation 2.

Additionally, there is work dealing with implementing and optimizing
individual components of an autonomous driving architecture. Examples are
provided in [36, 37]. In [36], the authors present a lane line detection
component for autonomous driving running on an embedded GPU. After color space
transformation and filtering, the street lane is approximated by polynomial
regression. The work is limited to the vision system of the autonomous driving
architecture. The authors of [37] describe a hardware-accelerated
implementation of a lane detection algorithm on a Zynq-7000 System-on-Chip.
The algorithm relies on edge detection on the input camera image, followed by
a Hough transformation. Again, this work only considers the lane detection
component.

###  II-B ReconROS

ReconROS [38, 39] is a framework for implementing ROS 2 applications on
heterogeneous compute platforms comprising a multi-core CPU and a
reconfigurable hardware fabric and accelerating robotics application
components on the reconfigurable hardware. ReconROS combines the ReconOS
reconfigurable hardware operating system [40] with ROS 2.

Figure 1: ReconROS Architecture (from [41])

Figure 1 sketches the hardware/software architecture of ReconROS. A ROS 2
application comprises a set of hardware nodes (HW node) and software nodes (SW
node). HW nodes are assigned to specific rectangular regions on the
reconfigurable fabric denoted as reconfigurable slots (RS). Each
reconfigurable slot connects to the operating system kernel via an operating
system interface (OSIF) and a lightweight software thread, the delegate
thread. The delegate carries out operating system calls on behalf of the
hardware node. Further, each reconfigurable slot connects to shared memory via
a memory interface (MEMIF). This way, hardware nodes can access the shared
virtual memory space, including any memory-mapped peripherals.

ReconROS extends the Linux operating system and enables the execution of ROS 2
nodes in hardware and software through the ReconROS stack and the ReconROS
API. The ReconROS stack expands the capabilities of ReconOS by introducing
ROS-related objects, such as ROS publishers or subscribers. Therefore,
hardware and software nodes can interact with other ROS 2 nodes leveraging
regular ROS 2 communication paradigms. Hence, communication is standardized,
and integrating hardware-accelerated components into an existing ROS 2
application is greatly facilitated.

The ReconROS API is available for both software and hardware nodes and
provides a consistent programming model across the software/hardware boundary.
Hardware nodes can even be assigned to specific reconfigurable slots at
runtime, allowing for dynamic mapping of a ROS application to nodes running in
software and hardware.

When a hardware node wants to leverage ROS 2 communication, it starts the
interaction by sending a corresponding command via its OSIF to its delegate
thread. Examples of such commands are a subscription to a ROS 2 topic or a
request for a ROS 2 service. The delegate thread relays the command to the
ReconROS stack and blocks until lower ROS 2 layers complete the processing of
the requested command. When a message is received, the delegate is unblocked
and transmits the location of the message in the main memory through the OSIF
to the hardware node. The hardware node can then access the message through
its MEMIF.

##  III ReconROS Shared-Memory Communication

A critical improvement of ROS 2 over ROS 1 was the introduction of an
exchangeable communication layer based on well-established data distribution
services (DDS). A developer can select between various available DDS
implementations with different properties. Several DDS implementations rely on
standard sockets as the default communication mechanism. Sockets are the most
flexible option and enable both intra-platform and inter-platform
communication. When intra-platform or even inter-process communication is
required, a loopback adapter is employed to transfer data to the same or other
processes. This flexibility is paid for with lowered performance since the
loopback mechanism results in overheads due to several data copy operations
involved.

To mitigate such overheads, the Iceoryx [42] communication middleware for ROS
2 was introduced. Iceoryx is an intra-process communication middleware
enabling zero-copy data transmission between processes on the same platform.
The disadvantage of Iceoryx, however, is that it comes with significant
limitations, e.g., there is no support for ROS 2 services and actions. Since
many larger software packages for ROS 2, e.g., Navigation 2, rely on these
communication paradigms, the field of application for Iceoryx would be
limited. Fortunately, Iceoryx is also part of the CycloneDDS middleware that
allows for simultaneously using socket-based and shared-memory-based
communication. When selecting shared memory for communication, the topic to
which the ROS 2 nodes publish and subscribe has to adhere to the following
constraints: (i) the message has a fixed length, (ii) a suitable QoS
configuration is selected, (iii) the topic has at most 127 subscriptions, and
(iv) a publisher has at most eight loaned messages simultaneously.

We have chosen the CycloneDDS middleware, with the integrated Iceoryx, as the
basis for AutonomROS. Since Iceoryx requires a slightly different programming
model than standard ROS 2 communication, we had to extend ReconROS to support
the zero-copy communication scheme of Iceoryx. When using Iceoryx, a
publishing node must first request a memory chunk from the middleware for
communication with other nodes. The publishing node can write its message into
the received memory chunk and execute the corresponding publishing function
call if successful. Similar to standard ROS 2 subscribers, the subscribing
node can block for a new message. However, after receiving it, the subscriber
returns the message to the middleware to enable the re-usage of the message
chunk.

Figure 2: ReconROS API (red) extended by operations for zero-copy data
transfers between nodes (yellow)

Figure 2 shows the resulting extensions in the ReconROS API. Overall, we
extended ReconROS by four function calls: ROS_BORROW requests a memory chunk
from Iceoryx, ROS_PUBLISH_LOANED publishes the message after the message has
been written to the message chunk, ROS_SUBSCRIBE_TAKE_LOANED tries to read a
message, and ROS_SUBSCRIBE_RETURN_LOANED returns the read message to Iceoryx
so that the memory chunk can be re-used.

##  IV Autonomous Driving Unit Architecture

Figure 3 shows the top-level overview of the architecture of the AutonomROS
autonomous driving unit. Besides providing its indented functionality, the
architecture also aims to demonstrate that our ReconROS framework for creating
robotics applications enables efficient hardware acceleration while
maintaining the programming abstractions of ROS 2 and the ability to integrate
larger ROS 2 software packages.

AutonomROS comprises seven main components: The Obstacle Detection component
and its preprocessing component Point Cloud Generation detect obstacles in
front of the car, and the Lane detection analyzes lanes. The Navigation Stack
subsequently uses this information, which sets commands for steering control
and the desired speed. The Localization component fuses different external
sensors, e.g., inertial measurement units or wheel encoders, that provide
information about the actual movement and the current position based on a
static map. The Vehicle Communication component handles communication with the
infrastructure around the car, e.g., a traffic light controller. It uses
information about the vehicle’s actual position from the Localization
component to determine if the car is approaching an intersection. An entrance
request is sent if the vehicle wants to enter an intersection. Eventually, the
vehicle is allowed to enter the intersection. This permission is provided to
the Navigation Stack component. The Cruise Control component controls the
car’s speed in a control loop leveraging a PID controller. The reference value
of the control loop is the desired speed from the Navigation Stack. The
difference between this reference value and the actual speed from the
Localization component serves as the measured error for the PID controller.
The output of the controller is forwarded to the engine of the vehicle.

Three of the components, Point Cloud Generation, Obstacle Detection, Lane
Detection, show high computational demands with significant amounts of data
processed and are thus suitable for hardware acceleration. We discuss these
components in more detail on the algorithmic level in Subsections IV-B, IV-C,
and IV-D. These components are developed in C/C++ and can either be compiled
using GCC for software execution, or synthesized with Xilinx Vitis HLS for
hardware execution.

Three more components, Localization, Vehicle Communication, and Cruise
Control, are custom-designed for AutonomROS and mapped to ROS 2 software
nodes. Finally, the component Navigation Stack is based on Nav2, an open-
source ROS 2 package. We elaborate on this component in Subsection IV-A.

Figure 3: Architecture of the AutonomROS autonomous driving unit. Hardware-
accelerated components are highlighted in blue color Figure 4: AutonomROS
Navigation Stack

###  IV-A Navigation Stack

Figure 4 details the Navigation Stack component. It consists of the components
Behavior, Planner, Global Map, Controller, and Local Obstacle Map. The whole
component uses localization information for position estimation, which is
crucial for all its sub-components. The Behavior component defines how the car
should behave in different situations. It receives a goal position, which
represents to which location the vehicle should drive. Additionally, it uses
the intersection information to decide whether the car must stop in front of
an intersection. These decisions result in different control commands for the
Planner and Controller. Among others, the Planner receives a goal position
that the car should reach from the Behavior component. The Planner calculates,
based on static map information from the Global Map and the car’s current
position, a path from the current position to the goal position. This path is
then handed to the Controller. The Controller component also receives control
commands from the Behavior component. These commands include whether the car
should follow the path, lane, or stop because an intersection is blocked. The
component calculates a steering control command and the desired speed based on
the path or lane information. Additionally, the Controller uses information
from a local map from the Local Obstacle Map to check whether an obstacle is
in the way, and if so, stops the car.

###  IV-B Point Cloud Generation

The Point Cloud Generation component receives depth information from an
external sensor, e.g., a 3D camera, and calculates a point cloud from the
depth and corresponding color images. The Obstacle Detection component uses
the resulting point cloud to detect obstacles in front of the car. Calculating
a 3D point cloud involves analyzing and processing a depth image to generate a
comprehensive representation of a physical object or environment in 3D. For
point cloud computation, the first step is to merge the depth and the color
image. Since pixels in the depth image are independent, this task can be
easily parallelized and is ideally suited for hardware acceleration with
ReconROS.

Our hardware implementation of the component initially receives the camera’s
projection matrix $P$ as shown in Equation 1. This matrix is needed to
transform pixels from the depth image into the 3D world. It comprises the
focal lengths $(fx,fy)$, the principal point $(cx,cy)$, and information about
the relative position of the second camera to the first $(Tx,Ty)$ [43]. The
matrix is published as a ROS 2 CameraInfo message by the camera’s wrapper
node. We need to gather this matrix only once before the actual runtime loop
starts because the matrix does not change as long as the camera is not
switched.

$\displaystyle P$ $\displaystyle=\begin{bmatrix}fx&0&cx&Tx\\\ 0&fy&cy&Ty\\\
0&0&1&0\end{bmatrix}$ (1)

In the runtime loop, we transform all pixels of an incoming image with their
coordinates $x$, $y$, and depth $w$ to their 3D world coordinates $X$, $Y$,
and $Z$. To this end, we first determine intermediate variables $u=x\cdot w$
and $v=y\cdot w$ and then apply Equations 2 \- 4, which are taken from the
description of the CameraInfo message of ROS [43].

$\displaystyle X$ $\displaystyle=\frac{u-cx\cdot w-Tx}{fx}$ (2) $\displaystyle
Y$ $\displaystyle=\frac{v-cy\cdot w-Ty}{fy}$ (3) $\displaystyle Z$
$\displaystyle=w$ (4)

###  IV-C Obstacle Collision

Obstacle detection is typically done by computing a cost map layer based on
the generated point cloud. Within the Navigation 2 package, a so-called Voxel
Layer constitutes the default cost map layer. However, the Voxel Layer
sequentially iterates over every point in the point cloud, which is slow.
Thus, we have decided to replace the Voxel Layer by (i) processing the
obstacle detection in hardware and (ii) handling the resulting data in the
Navigation 2 package by a customized cost map layer.

The process of converting the point cloud into an obstacle grid is split into
the following four steps: First, we transform the image from the camera’s
coordinate system into the car’s base coordinate system based on a fixed
transformation matrix. Second, we select all points in a predefined volume in
front of the car and consider only the points in this ”obstacle box” in the
following steps. Since points higher than the car and points far away from the
front or the sides of the vehicle need not be considered, this selection helps
save on computations. Third, we project the points within the obstacle box to
the ground, i.e., to the $xy$-plane. Finally, we discretize the obstacle box
to a grid and assign to each grid cell the number of points of the original
point cloud that map to the cell. The discretization reduces the required
memory for representing obstacles from $4.7$ MB for the point cloud to $234$
Byte for the grid. In addition, the discretization reduces noise from the
camera’s depth sensor, which could result in false-positive detections of
obstacles.

Most of the involved processing is performed pixel-parallel. The final grid is
published to a ROS 2 topic to make it usable for the custom cost map layer in
the Navigation 2 package that runs in the software.

###  IV-D Lane Detection

The Lane Detection component includes multiple computationally expensive image
processing steps, e.g., the perspective and color thresholding transformation.
Our component implementation involves several steps and relies on the open-
source Vitis Image processing library
111https://github.com/Xilinx/Vitis_Libraries.git.

The first step transforms the incoming image from the RGB to the HSV color
space. The transformation supports processing different color values
independent of the environment’s saturation or lighting. The next step applies
color thresholding to identify the image’s white and yellow areas.
Thresholding for both colors is processed in parallel, resulting in one
grayscale image representing yellow and white pixels in the original image.
The following step performs a warp transformation to the grayscale image based
on a fixed transformation matrix to get a bird’s view of the represented
scene. After warp transformation, a decision is taken considering the number
of pixels for each of the two colors, whether to follow the street’s white or
yellow lane. Subsequent processing focuses on the selected color.

Then, we perform a polynomial least-squares regression on the lane to
eliminate interfering falsely detected pixels and establish an equation for
the lane marking. Based on the $N$ pixels with coordinates $(x_{n},y_{n})$
that represent the lane and $k$ as the polynomial order to fit, we compute the
desired polynomial coefficients $\vec{a}=[a_{0}\dots a_{k}]^{T}$ by solving
the equations system as shown in Figure 5.

$\begin{bmatrix}N&\dots&\sum_{k=0}^{N}x_{n}^{k}\\\ \vdots&\ddots&\vdots\\\
\sum_{n=0}^{N}x_{n}^{k}&\dots&\sum_{k=0}^{N}x_{n}^{2k}\end{bmatrix}\cdot\vec{a}=\begin{bmatrix}\sum_{n=0}^{N}y_{n}\\\
\vdots\\\ \sum_{n=0}^{N}y_{n}x_{n}^{k}\\\ \end{bmatrix}$ (5)

For implementing the Lane Detection component, we have determined that the
second-order polynomial shown in Equation 6 is suitable.

$f_{l}(x)=a_{2}\cdot x^{2}+a_{1}\cdot x+a_{0}$ (6)

To estimate the final trajectory, the resulting polynomial has to be shifted
to the middle of the image and transformed into the car’s base coordinate
system.

For more efficient computation of the final trajectory, we use 30 equally-
distributed points along the height of the image ($x_{i}=i\cdot 480/30$,
$i=0..29$) and compute 30 function values $y_{i}=f_{l}(x_{i})$ (Equation 6).

Using the resulting 30 coordinates $(y_{i},x_{i})$, the equation system 5 is
solved again for a target polynomial function $f_{t}(x)$ (Equation 7).

$f_{t}(x)=a_{3}\cdot x^{3}+a_{2}\cdot x^{2}+a_{1}\cdot x+a_{0}$ (7)

##  V Evaluation

In this section, we first report on the evaluation setup, including a real-
world model car used for driving experiments to test the functionality of the
AutonomROS driving unit. Then, we present architecture exploration experiments
to evaluate the performance of different DDS versions and the hardware
acceleration.

###  V-A Evaluation Setup

We execute AutonomROS on a Zynq UltraScale+ MPSoC ZCU104 evaluation board. The
board contains a system-on-chip architecture with a quad-core ARM Cortex-A53,
a dual-core Cortex-R5 real-time processor, a Mali-400 MP2 embedded graphics
processing unit, and programmable logic (PL). For our evaluations, we used the
quad-core CPU and the programmable logic. The board runs Ubuntu 20.04 in
combination with ROS 2 galactic and ReconROS.

Figure 5: Model car platform

We have mounted the evaluation board on a model car platform shown in Figure
5. The model car platform is based on a modified commercial remote-controlled
car in which the control and sensor systems have been replaced. The actuators
for the steering and the drive were preserved. Regarding sensors, the platform
includes two cameras, one for color information and one 3D camera providing
depth and color information, an inertial measurement unit (IMU) for measuring
acceleration data, and a wheel encoder for gaining speed data. Regarding
actuators, the platform exhibits interfaces to drive the engine and the car’s
steering. Further, the evaluation board is equipped with a wireless LAN
interface for data exchange with other vehicles and the infrastructure, e.g.,
the traffic lights controller. We have set up a $5m\times 5m$ grid of streets
with two intersections to mimic real-world environmental test conditions.
Additionally, we have set up a central infrastructure server that acts as a
traffic lights controller and handles requests for crossing intersections. We
have built two model cars to evaluate the AutonomROS functionality involving
multiple vehicles.

###  V-B Performance Evaluation

Table I summarizes the results of the performance measurements for the
hardware-accelerated components Point Cloud Generation, Obstacle Detection,
and Lane Detection. For these processing components, the test setup includes
two ROS 2 nodes, one node publishing camera data, and one node including the
actual processing. The table lists different architecture configurations, the
total CPU load in % of four cores, the achieved frames per second (FPS), and
the turnaround time. The turnaround time represents the node’s raw computation
time, which, in contrast to the FPS metric, is not limited by the input signal
rate.

Component |  Architecture configuration |  CPUa | FPS |  Turnaround time (ms)
---|---|---|---|---
Point Cloud Generation @640x480 depth image |  ReconROS SW without Iceoryx |  180–220 | 9–12 | 83–111
ReconROS HW without Iceoryx |  180–210 | 13–14 | 71–76
ReconROS SW with Iceoryx |  90–110 | 29–30 | 11–15
ReconROS HW with Iceoryx |  64–78 | 29–30 | 17–18
Obstacle Detection |  ReconROS SW with Iceoryx |  50–60 | 29–30 | 15–17
ReconROS HW with Iceoryx |  4–8 | 29–30 | 9–11
Lane Detection |  ROS 2 SW with Iceoryx |  170–190 | 29–30 | 27–31
ReconROS hw with Iceoryx |  24–38 | 29–30 | 9–18

aCPU load in % of 4 cores

TABLE I:  Performance measurements for the hardware-accelerated components of
AutonomROS.

#### Point Cloud Generation

Two are two main observations: First, using the zero-copy Iceoryx middleware
is highly beneficial, as expected, for both software and hardware mappings of
the component. The CPU load and the achieved FPS are improved by roughly
$2\times$, and the turnaround time decreased by $7.5\times$ compared to
standard ROS 2 communication. Adding hardware acceleration without a zero-copy
communication middleware gives a minimal advantage. Second, using Iceoryx and
hardware acceleration reduces the CPU load further, while the achieved FPS is
bound by the camera’s maximum frame rate of around 30 frames per second. The
turnaround time is slightly higher because of overheads for data transmission
into the programmable logic.

#### Obstacle Detection

Here, we compare the software and hardware configurations with Iceoryx. Both
configurations achieve the maximum FPS. For the hardware-mapped node, the CPU
utilization of the component decreases significantly by a factor of
$12.5\times$, and the turnaround time is about $1.6\times$ lower compared to
the implementation in software.

#### Lane Detection

We compare a ROS 2 software implementation with a ReconROS hardware
implementation. Compared to ReconROS SW implementation, this node relies on a
standard ROS 2 C++ implementation, including the ROS executor enabling the
event-driven programming model. Again, hardware acceleration results in a
significant reduction of the CPU load and turnaround times.

The main conclusion of the measurements reported in Table I is that for intra-
platform communication, using a zero-copy communication middleware such as
Iceoryx is of utmost importance to maintain performance. Moreover, effective
hardware acceleration relies on such a middleware. The reported measurements
are only for two ROS 2 nodes. Mapping the overall AutonomROS unit of Figure 3
entirely to software would exceed the maximum CPU utilization of 400 %. Thus,
running the presented AutonomROS on the chosen system-on-chip platform is only
possible with hardware acceleration.

##  VI Conclusion and Future Work

In this paper, we have presented AutonomROS, a ReconROS-based unit for
autonomous driving. AutonomROS integrates a ROS 2 open-source package for
navigation with custom-developed software nodes for localization, cruise
control, and vehicle communication and hardware-accelerated nodes for point
cloud generation, obstacle detection, and lane detection. We have also
introduced a new communication middleware for ReconROS that boosts the
performance of shared memory communication between software and hardware
nodes. Hardware acceleration combined with the new communication middleware
results in significant performance improvements, measurable turnaround times,
and achievable frame rates, but most pronounced in reduced CPU utilization
with up to $12.5\times$ for selected ROS 2 nodes.

In feature work, we plan to extend the AutonomROS driving unit with more
advanced functionality, such as ORB-SLAM and GPS for localization or Advanced
Driver Assistance Systems (ADAS). The advanced functionality should increase
the potential for hardware acceleration.

## References

  * [1] E. Yurtsever, J. Lambert, A. Carballo, and K. Takeda, “A survey of autonomous driving: Common practices and emerging technologies,” _IEEE access_ , vol. 8, pp. 58 443–58 469, 2020.
  * [2] M. Bertoncello and D. Wee, “Ten ways autonomous driving could redefine the automotive world,” _McKinsey & Company_, vol. 6, 2015.
  * [3] I. Barabas, A. Todoruţ, N. Cordoş, and A. Molea, “Current challenges in autonomous driving,” _IOP Conference Series: Materials Science and Engineering_ , vol. 252, no. 1, p. 012096, 2017.
  * [4] I. Yaqoob, L. U. Khan, S. A. Kazmi, M. Imran, N. Guizani, and C. S. Hong, “Autonomous driving cars in smart cities: Recent advances, requirements, and challenges,” _IEEE Network_ , vol. 34, no. 1, pp. 174–181, 2019.
  * [5] S. Parida, M. Franz, S. Abanteriba, and S. Mallavarapu, “Autonomous driving cars: future prospects, obstacles, user acceptance and public opinion,” in _Advances in Human Aspects of Transportation: Proceedings of the AHFE 2018 International Conference on Human Factors in Transportation, July 21-25, 2018, Loews Sapphire Falls Resort at Universal Studios, Orlando, Florida, USA 9_. Springer, 2019, pp. 318–328.
  * [6] P. Sun and A. Boukerche, “Challenges and potential solutions for designing a practical pedestrian detection framework for supporting autonomous driving,” in _Proceedings of the 18th ACM Symposium on Mobility Management and Wireless Access_ , 2020, pp. 75–82.
  * [7] U. Montanaro, S. Dixit, S. Fallah, M. Dianati, A. Stevens, D. Oxtoby, and A. Mouzakitis, “Towards connected autonomous driving: review of use-cases,” _Vehicle system dynamics_ , vol. 57, no. 6, pp. 779–814, 2019.
  * [8] P. Kopelias, E. Demiridi, K. Vogiatzis, A. Skabardonis, and V. Zafiropoulou, “Connected & autonomous vehicles–environmental impacts–a review,” _Science of the total environment_ , vol. 712, p. 135237, 2020.
  * [9] X. Zhao, P. Sun, Z. Xu, H. Min, and H. Yu, “Fusion of 3d lidar and camera data for object detection in autonomous vehicle applications,” _IEEE Sensors Journal_ , vol. 20, no. 9, pp. 4901–4913, 2020.
  * [10] S. Liu, L. Liu, J. Tang, B. Yu, Y. Wang, and W. Shi, “Edge computing for autonomous driving: Opportunities and challenges,” _Proceedings of the IEEE_ , vol. 107, no. 8, pp. 1697–1716, 2019.
  * [11] J. Chen, B. Yuan, and M. Tomizuka, “Model-free deep reinforcement learning for urban autonomous driving,” in _2019 IEEE intelligent transportation systems conference (ITSC)_. IEEE, 2019, pp. 2765–2771.
  * [12] H. Lu, Q. Liu, D. Tian, Y. Li, H. Kim, and S. Serikawa, “The cognitive internet of vehicles for autonomous driving,” _IEEE Network_ , vol. 33, no. 3, pp. 65–73, 2019.
  * [13] Y. Li, S. E. Li, X. Jia, S. Zeng, and Y. Wang, “Fpga accelerated model predictive control for autonomous driving,” _Journal of Intelligent and Connected Vehicles_ , vol. 5, no. 2, pp. 63–71, 2022.
  * [14] S. Du, T. Huang, J. Hou, S. Song, and Y. Song, “Fpga based acceleration of game theory algorithm in edge computing for autonomous driving,” _Journal of Systems Architecture_ , vol. 93, pp. 33–39, 2019.
  * [15] A. Kojima, “Autonomous driving system implemented on robot car using soc fpga,” in _2021 International Conference on Field-Programmable Technology (ICFPT)_. IEEE, 2021, pp. 1–4.
  * [16] C. Hao, A. Sarwari, Z. Jin, H. Abu-Haimed, D. Sew, Y. Li, X. Liu, B. Wu, D. Fu, J. Gu _et al._ , “A hybrid gpu+ fpga system design for autonomous driving cars,” in _2019 IEEE International Workshop on Signal Processing Systems (SiPS)_. IEEE, 2019, pp. 121–126.
  * [17] Q. Liu, Z. Wan, B. Yu, W. Liu, S. Liu, and A. Raychowdhury, “An energy-efficient and runtime-reconfigurable fpga-based accelerator for robotic localization systems,” in _2022 IEEE Custom Integrated Circuits Conference (CICC)_. IEEE, 2022, pp. 01–02.
  * [18] M. Qasaimeh, K. Denolf, J. Lo, K. Vissers, J. Zambreno, and P. H. Jones, “Comparing energy efficiency of cpu, gpu and fpga implementations for vision kernels,” in _2019 IEEE international conference on embedded software and systems (ICESS)_. IEEE, 2019, pp. 1–8.
  * [19] B. Li, S. Pandey, H. Fang, Y. Lyv, J. Li, J. Chen, M. Xie, L. Wan, H. Liu, and C. Ding, “Ftrans: energy-efficient acceleration of transformers using fpga,” in _Proceedings of the ACM/IEEE International Symposium on Low Power Electronics and Design_ , 2020, pp. 175–180.
  * [20] D. Haripriya, K. Kumar, A. Shrivastava, H. M. R. Al-Khafaji, V. Moyal, and S. K. Singh, “Energy-efficient uart design on fpga using dynamic voltage scaling for green communication in industrial sector,” _Wireless Communications and Mobile Computing_ , vol. 2022, 2022.
  * [21] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” _Science Robotics_ , vol. 7, no. 66, 2022.
  * [22] Y. Sugata, T. Ohkawa, K. Ootsu, and T. Yokota, “Acceleration of Publish/Subscribe Messaging in ROS-Compliant FPGA Component,” in _Proc. of the 8th International Symposium on Highly Efficient Accelerators and Reconfigurable Technologies (HEART2017)_. ACM, 2017.
  * [23] T. Ohkawa, Y. Sugata, H. Watanabe, N. Ogura, K. Ootsu, and T. Yokota, “High Level Synthesis of ROS Protocol Interpretation and Communication Circuit for FPGA,” in _Proc. 2019 IEEE/ACM 2nd International Workshop on Robotics Software Engineering (RoSE)_ , 2019, pp. 33–36.
  * [24] V. Mayoral-Vilches, S. M. Neuman, B. Plancher, and V. J. Reddi, “RobotCore: An Open Architecture for Hardware Acceleration in ROS 2,” _arXiv preprint arXiv:2205.03929_ , 2022.
  * [25] A. Podlubne and D. Göhringer, “FPGA-ROS: Methodology to Augment the Robot Operating System with FPGA Designs,” in _Proc. International Conference on ReConFigurable Computing and FPGAs (ReConFig)_ , 2019.
  * [26] M. Eisoldt, S. Hinderink, M. Tassemeier, M. Flottmann, J. Vana, T. Wiemann, J. Gaal, M. Rothmann, and M. Porrmann, “ReconfROS: Running ROS on Reconfigurable SoCs,” in _Proc. 2021 Drone Systems Engineering and Rapid Simulation and Performance Evaluation: Methods and Tools Proceedings_. ACM, 2021, p. 16–21.
  * [27] C. Lienen, M. Platzner, and B. Rinner, “Reconros: Flexible hardware acceleration for ros2 applications,” in _2020 International Conference on Field-Programmable Technology (ICFPT)_. IEEE, 2020, pp. 268–276.
  * [28] “autowautoware - the world’s leading open-source software project for autonomous driving,” https://github.com/autowarefoundation/autoware, accessed: 2023-08-30.
  * [29] H. Chishiro, K. Suito, T. Ito, S. Maeda, T. Azumi, K. Funaoka, and S. Kato, “Towards heterogeneous computing platforms for autonomous driving,” in _2019 IEEE International Conference on Embedded Software and Systems (ICESS)_. IEEE, 2019, pp. 1–8.
  * [30] M. Reke, D. Peter, J. Schulte-Tigges, S. Schiffer, A. Ferrein, T. Walter, and D. Matheis, “A self-driving car architecture in ros2,” in _2020 International SAUPEC/RobMech/PRASA Conference_. IEEE, 2020, pp. 1–6.
  * [31] Y. Nitta, S. Tamura, and H. Takase, “A study on introducing fpga to ros based autonomous driving system,” in _2018 International Conference on Field-Programmable Technology (FPT)_. IEEE, 2018, pp. 421–424.
  * [32] R. Yamamoto, Y. Izumi, R. Aono, T. Nagahara, T. Tanaka, W. Liao, and Y. Mitsuyama, “Development of autonomous driving system based on image recognition using programmable socs,” in _2021 International Conference on Field-Programmable Technology (ICFPT)_. IEEE, 2021, pp. 1–4.
  * [33] T. Tanaka, I. Ikeno, R. Tsuruoka, T. Kuchiba, W. Liao, and Y. Mitsuyama, “Development of autonomous driving system using programmable socs,” in _2019 International Conference on Field-Programmable Technology (ICFPT)_. IEEE, 2019, pp. 453–456.
  * [34] E. Jones, K. Pepper, A. Li, S. Li, Y. Zhang, and D. Bailey, “Autonomous driving developed with an fpga design,” in _2019 International Conference on Field-Programmable Technology (ICFPT)_. IEEE, 2019, pp. 431–434.
  * [35] T. Wu, W. Liu, and Y. Jin, “An end-to-end solution to autonomous driving based on xilinx fpga,” in _2019 International Conference on Field-Programmable Technology (ICFPT)_. IEEE, 2019, pp. 427–430.
  * [36] J. A. B. Palma, M. N. I. Bonilla, and R. E. Grande, “Lane line detection computer vision system applied to a scale autonomos car: Automodelcar,” in _2020 17th International Conference on Electrical Engineering, Computing Science and Automatic Control (CCE)_ , 2020, pp. 1–6.
  * [37] M. Gopinathan, R. Soundarrakumar, A. Kalaiselvi, A. Mohideen _et al._ , “Implementation of lane detection in autonomous vehicle using fpga,” in _2022 International Conference on Emerging Trends in Engineering and Medical Sciences (ICETEMS)_. IEEE, 2022, pp. 141–147.
  * [38] C. Lienen, M. Platzner, and B. Rinner, “ReconROS: Flexible Hardware Acceleration for ROS2 Applications,” in _2020 International Conference on Field-Programmable Technology (ICFPT)_ , 2020, pp. 268–276.
  * [39] C. Lienen and M. Platzner, “Design of Distributed Reconfigurable Robotics Systems with ReconROS,” _ACM Trans. Reconfigurable Technol. Syst._ , vol. 15, no. 3, dec 2022.
  * [40] E. Lübbers and M. Platzner, “ReconOS: Multithreaded Programming for Reconfigurable Computers,” _ACM Transactions on Embedded Computing Systems_ , vol. 9, no. 1, pp. 8:1–8:33, 2009.
  * [41] C. Lienen and M. Platzner, “Task mapping for hardware-accelerated robotics applications using reconros,” in _2022 Sixth IEEE International Conference on Robotic Computing (IRC)_ , 2022, pp. 148–155.
  * [42] “iceoryx - true zero-copy inter-process-communication,” https://github.com/eclipse-iceoryx/iceoryx, accessed: 2023-08-30.
  * [43] “Camerainfo raw message definition,” http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/CameraInfo.html, accessed: 2023-08-30.


††thanks: Current address: National High Magnetic Field Laboratory, Los Alamos
National Laboratory, Los Alamos, NM 87545, USA

# Electrical switching of antiferromagnetic CoO | Pt across the Néel temperature

M. J. Grzybowski<EMAIL_ADDRESS>Department of Applied Physics,
Eindhoven University of Technology, 5600 MB Eindhoven, the Netherlands
Institute of Experimental Physics, Faculty of Physics, University of Warsaw,
ul. Pasteura 5, PL-02-093 Warsaw, Poland  C. F. Schippers  Department of
Applied Physics, Eindhoven University of Technology, 5600 MB Eindhoven, the
Netherlands  M. E. Bal  K. Rubi  U. Zeitler  High Field Magnet Laboratory
(HFML -EMFL), Radboud University, 6525 ED Nijmegen, the Netherlands  M. Foltyn
Institute of Physics, Polish Academy of Sciences, Aleja Lotnikow 32/46, Warsaw
PL 02668, Poland  B. Koopmans  H. J. M. Swagten  Department of Applied
Physics, Eindhoven University of Technology, 5600 MB Eindhoven, the
Netherlands

###### Abstract

One of the most important challenges in antiferromagnetic spintronics is the read-out of the Néel vector state. High current densities up to 108 Acm-2 used in the electrical switching experiments cause notorious difficulty in distinguishing between magnetic and thermal origins of the electrical signals. To overcome this problem, we present a temperature dependence study of the transverse resistance changes in the switching experiment with CoO | Pt devices. We demonstrate the possibility to extract a pattern of spin Hall magnetoresistance for current pulses density of $5\times 10^{7}\text{A}\,\text{cm}^{-2}$ that is present only below the Néel temperature and does not follow a trend expected for thermal effects. This is the compelling evidence for the magnetic origin of the signal, which is observed using purely electrical techniques. We confirm these findings by complementary experiments in an external magnetic field. Such an approach can allow determining the optimal conditions for switching antiferromagnets and be very valuable when no imaging techniques can be applied to verify the origin of the electrical signal.

††preprint: AIP/123-QED

Intensive interest in electrical manipulation of antiferromagnetism is caused
by their potential appealing applications such as efficient and magnetic-
field-robust data storage [1] or long-range spin transport [2]. The electrical
current can be used to control the spin axis of antiferromagnets. Numerous
physical mechanisms can be responsible for that process [3, 4, 5, 6].
Experimental studies of antiferromagnetic oxides demonstrate the dominating
role of the thermomagnetoelastic effect [7, 8, 9], in which magnetic
reorientation is driven by thermally induced strain. In principle, the
reorientation of the Néel vector ($\bf{n}$) can be probed by either
anisotropic magnetoresistance (AMR) or spin Hall magnetoresistance (SMR), the
effects relying on resistivity dependence on the angle between $\bf{n}$ and
current density or spin accumulation, respectively [10, 11, 12]. However, a
notorious difficulty in electrical probing is the presence of non-magnetic
thermal effects such as inhomogeneous heating or electromigration that can
contribute to the measured resistance [13, 14, 15]. It creates the need to use
imaging techniques to provide the unambiguous proof of magnetic reorientation
and show the correspondence between the electrical signals and the domains
reorientation [16, 17, 18, 8]. Unfortunately, magnetic imaging techniques
often exhibit complexity and surface sensitivity which limits their practical
application in antiferromagnetic devices.

However, any electrical signal pattern of magnetic origin, that is resulting from the reorientation of antiferromagnetic spins, should be present only in magnetically ordered antiferromagnetic phase unlike non-magnetic thermal effects, that should be present in the ordered as well as in the disordered, paramagnetic state. Hence, in this study we propose to compare the electrical switching experiment at different temperatures, in particular below and above the Néel temperature $T_{\text{N}}$, by which we will gather crucial and unambiguous information about the presence of a genuine reorientation of the antiferromagnetic spin system. The antiferromagnetic CoO thin-films we are using have an experimentally easily accessible $T_{\text{N}}$ that is close to room temperature and exhibits in-plane biaxial anisotropy [19, 9] making it a perfect material choice for the proposed study. Indeed, we determine that the magnetic reorientation in CoO | Pt can be detected electrically for current pulses of around $50\,\text{MA}\,\text{cm}^{-2}$ as in this regime the electrical patterns disappear above $T_{\text{N}}$. This is further confirmed with the electrical switching experiment in the external magnetic field. The results are critically important for complex structures comprising antiferromagnets (AFs), where the AF is only one of many layers buried far from the top interface [20, 21] and where the use of magnetic imaging is very challenging.

To realize the experimental goal, 8 arm cross devices (Fig. 1) were prepared by e-beam lithography and ion milling from CoO thin-films of 5 nm thickness. They were grown by reactive DC magnetron sputtering at 430 ∘C on MgO (001) single crystals with Pt top layer of 5 nm thickness that has been deposited at room temperature. The LEED pattern proves a good crystalline quality and XPS shows a spectrum typical for CoO [22]. We adopt the value of $T_{\text{N}}=272\pm{5}\,\text{K}$ that was determined by the point in which the spin-flop transition disappears in the temperature-dependent spin Hall magnetoresistance studies of analogous CoO | Pt samples [22]. Therefore, an experiment performed in the temperature range $T\in[240\,\text{K},305\,\text{K}]$ will cover both interesting regimes: below and above the $T_{\text{N}}$ as well as in the vicinity of the critical point.

Figure 1: Micrograph of the device used for electrical switching experiments.
The dark regions correspond to the insulating etched trenches whereas the
remaining part is formed from a CoO layer grown on MgO (001) and capped with
Pt. Red and yellow arrows symbolize the direction of the current pulses
applied using 6 contacts, along magnetic easy axes of CoO $[110]$ and
$[1\overline{1}0]$, respectively. The white arrow depicts the probing current
direction.

The electrical switching experiment consists of two parts. During the pulsing,
a sequence of high-density current pulses $\mathbf{J}$ is applied. Each pulse
has a length of $3\,\text{ms}$. At T = $240\,\text{K}$, each sequence consists
of 5 pulses of $3\,\text{ms}$, separated by 5 seconds; at higher temperatures
each sequence consists of a single pulse. The pulses are expected to cause a
reorientation of the Néel vector $\bf{n}$. The pulses are applied along two
orthogonal axes, $[110]$ or $[1\overline{1}0]$ (Fig. 1), which are the
magnetic easy directions [19, 9, 22] that are preferred by spins. During the
probing, transverse resistance is measured with a small current magnitude
(0.25 mA, corresponding to current density of $0.6\,\text{MAcm}^{-2}$) 1
second after each pulsing sequence using a lock-in amplifier. The
reorientation of the Néel vector should be reflected in transverse resistance
variations due to SMR. The experiment is performed for different magnitudes of
current pulses $J$ and at different temperatures. The results are presented in
the form of relative transverse resistivity changes $\Delta R_{\text{xy}}/R$
as a function of pulse number where $\Delta R_{\text{xy}}$ is the change of
the transverse resistance upon reorientation of the pulsing direction and $R$
is mean longitudinal resistance which is $21.6\,\Omega$ at $T=240\,\text{K}$.
The direction of the current pulse is changed between the two perpendicular
easy axes after every 5 pulses whereas probing is always performed in the same
configuration. The values of $J$ describing different experimental data sets
are calculated by dividing the current that is stabilized during the pulsing
by the narrowest cross-section.

Figure 2:  Transverse resistance patterns recorded in electrical switching
experiment for pulses with the highest current densities. The direction of the
current pulse changes every 5 sequence as depicted by the red and yellow
arrows that reflect the geometrical configuration presented in Fig. 1. The
lines on the plot are guides for the eye.

The experimental results for the largest current density in the range of
$J_{\text{t}}\in[89,92]\,\text{MA}\,\text{cm}^{-2}$ yield saw-tooth like
patterns of transverse resistivity typical for thermal non-magnetic effects
(Fig. 2). This can be concluded from its presence above $T_{\text{N}}$ as
shown by the data set collected at $T=305\,\text{K}$ (orange). Moreover, this
type of signal exhibits a magnitude that increases with ambient temperature
and exceeds $10^{-4}$. This magnitude is larger above $T_{\text{N}}$ than for
the antiferromagnetic phase. No saturation of the signal with the increasing
number of pulses of the same type was observed. Such behavior is caused by
non-homogeneous current distribution within the device. The pulsing procedure
creates non-equivalent current density points in the corners of the device
[13]. It results in different local heating and non-zero transverse voltage
during the probing. Apart from such temperature gradient [13, 14] also Seebeck
effect [13] and structural changes like electromigration [14] or
recrystallization [15] may play an important role in contributing to the
electrical probing signal. For the smallest current magnitudes of pulsing
(below $40\,\text{MA}\,\text{cm}^{-2}$) no significant variations of $\Delta
R_{\text{xy}}/R$ is recorded at any temperature.

The most interesting results are obtained for intermediate values of the
current pulse magnitude. Close to
$J_{\text{m}}\in[47,56]\,\text{MA}\,\text{cm}^{-2}$ a pattern of $\Delta
R_{\text{xy}}/R$ appears, which is present only below $T_{\text{N}}$ (Fig. 3).
The pattern collected for this range of current magnitudes is reproducible
after days of performing multiple experiments with higher currents and at
higher temperatures. Its presence below $T_{\text{N}}$ and absence above it
can be a strong indication of its magnetic origin in contrast to the data
recorded for the highest current densities (Fig 2).

Figure 3:  Transverse resistance pattern recorded for $52\,\text{MAcm}^{-2}$.
A switching pattern is only present below $T_{\text{N}}$ (blue squares). The
pattern is reproducible (white-blue circles) after several days of other
switching experiments performed at higher $T$ and with larger $J$. The pattern
is absent above $T_{\text{N}}$ (red). The lines on the plot are guides for the
eye.

To highlight that distinct physical mechanisms are responsible for the
appearance of the signal in different current density regimes, the temperature
dependence of the transverse resistance patterns in the electrical switching
experiment are summarized in Fig. 4. It shows that the thermal effects,
crucial in the highest current densities ($J_{\text{t}}$), result in the
increasing magnitude of the signal with temperature. This is not the case for
the moderate current densities ($J_{\text{m}}$), where the signal is clearly
decreasing between $T\in[240\,\text{K},\,260\,\text{K}]$ and it is practically
undetectable above $T_{\text{N}}$. These tendencies are reproducible among
different devices (Fig. 4). They allow suspecting the resistance variations
detected for $J_{\text{m}}$ are caused by the spin reorientation in AF CoO.
This is finally verified in the switching experiment in the external magnetic
field.

Figure 4:  Relative transverse resistance changes $\Delta R_{\text{xy}}/R$ in
electrical switching experiment as a function of temperature recorded for
$J_{\text{m}}$ (pink) and $J_{\text{t}}$ (black) and two different devices A
and B (squares and circles, respectively). The lines are guides for the eye.

Unambiguous proof of the magnetic origin of the electrical signal for
$J_{\text{m}}$ is provided by the switching experiment in the external
magnetic field. The reorientation of spins in an antiferromagnet can be
suppressed by a strong magnetic field that sets the AF in the spin flop state.
It can occur for $B$ strong enough to overcome the anisotropy. For a thin-
films of CoO at $T=240\,\text{K}$ the spin flop field state can be reached at
$7\,\text{T}$ when $B\parallel[110]$ [22]. Even if electrical current switches
the spin axis of the antiferromagnet it should immediately come back to the
initial state due to the spin flop induced by the magnetic field once the
current pulse is turned off. Meanwhile, thermal effects, in principle, are not
dependent on the magnetic field. Therefore, by studying the magnetic field
dependence of the electrical switching patterns it is possible to identify the
magnetic component of the signal. Similar approaches to use a magnetic field
to validate the origin of the electrical signal have been used in hematite [7]
and CoO [9].

The in-field experiment shows that the electrical switching pattern for
$J_{\text{m}}$ disappears upon increasing magnetic field (Fig. 5b), whereas
the thermal pattern remains nearly unchanged as expected. The resistance
changes for $J_{\text{m}}$ at $5\,\text{T}$ are diminished and above this
value they become undetectable. Moreover, the response of the system to the
magnetic field is anisotropic - such dependence is not observed for
$B\parallel[100]$ (Fig. 5a). It is in agreement with the anisotropy of thin
films of CoO, in which $[100]$ is a magnetic hard direction and the magnetic
field of $10\,\text{T}$ does not cause perpendicular alignment
$\mathbf{n}\perp\mathbf{B}$ in this geometrical configuration [22].

Figure 5:  The magnetic field dependence of the mean transverse resistance
changes $\Delta\overline{R_{\text{xy}}}$ in the switching experiment recorded
for $50\,\text{MA}\,\text{cm}^{-2}$ (violet) and
$90\,\text{MA}\,\text{cm}^{-2}$ (black) for the magnetic field parallel to the
(a) $[100]$ hard magnetic direction and (b) $[110]$ easy magnetic direction.
The experiment was conducted at $T=240\,\text{K}$. Lines on the plot are
guides for the eye.

Therefore, the signal obtained for $J_{\text{m}}$ can be interpreted as spin
Hall magnetoresistance (SMR). The sign of the resistance variations
corresponds to setting $\mathbf{n}\parallel\mathbf{J}$. This is different from
another study of CoO electrical switching [9] and may suggest that an
antidamping torque mechanism is responsible for the antiferromagnetic
reorientation [6]. However, it has to be noted that even the same
thermomagnetoelastic mechanism can result in different end states of
$\mathbf{n}$ depending on device design and experimental geometry [8].

Finally, we estimate the temperature increase of the CoO layer in the device
region due to the electrical pulses by a 3D finite element method model [23].
It reveals that the $T_{N}$ is not exceeded during the pulsing at
$T=240\,\text{K}$ presented in Fig. 3 and the temperature rise for
$50\,\text{MAcm}^{-2}$ is around $7\,\text{K}$. It means that the device
remains in the antiferromagnetic state during the whole experiment. It is also
true even for such high current densities as $92\,\text{MAcm}^{-2}$ at
$T=240\,\text{K}$. Most of the heat is dissipated in the first few
milliseconds after the pulsed current is turned off. Still, a slight
temperature increase is present even for long timescales typical for probing.
Together with the symmetry of the device design, this can produce patterns of
the electrical signal visible at elevated current densities and at high
temperatures as shown in Fig. 2.

In summary, we demonstrate that it is possible to determine whether a signal
in an electrical switching experiment of an antiferromagnet is of magnetic
origin, using purely electrical techniques. The method relies on comparing the
signal at temperatures above and below the Néel temperature. Finally, we
validated the study by performing the experiment in a strong external magnetic
field. Such an approach can allow determining the optimal experimental
conditions for switching antiferromagnets and be very valuable when no imaging
techniques can be applied.

We acknowledge J. Francke, B. van der Looij and G. Basselmans for technical
help; R. Lavrijsen and M. Zgirski for helpful discussions and J. Dedding for
the measurements of $T_{N}$. We acknowledge support from HFML-RU, member of
the European Magnetic Field Laboratory (EMFL). Sample fabrication was
performed using NanoLabNL facilities. The research was funded by the Dutch
Research Council (NWO) under Grant 680-91-113. The research was funded in part
by National Science Centre, Poland under Grant 2021/40/C/ST3/00168 and grant
2019/34/E/ST3/00432. For the purpose of Open Access, the author has applied a
CC-BY public copyright licence to any Author Accepted Manuscript (AAM) version
arising from this submission.

## References

  * Olejník  _et al._ [2017] K. Olejník, V. Schuler, X. Marti, V. Novák, Z. Kašpar, P. Wadley, R. P. Campion, K. W. Edmonds, B. L. Gallagher, J. Garces, M. Baumgartner, P. Gambardella, and T. Jungwirth, “Antiferromagnetic CuMnAs multi-level memory cell with microelectronic compatibility,” Nature Communications 8 (2017).
  * Lebrun  _et al._ [2018] R. Lebrun, A. Ross, S. A. Bender, A. Qaiumzadeh, L. Baldrati, J. Cramer, A. Brataas, R. A. Duine, and M. Kläui, “Tunable long-distance spin transport in a crystalline antiferromagnetic iron oxide,” Nature 561, 222–225 (2018).
  * Wadley  _et al._ [2016] P. Wadley, B. Howells, J. Zelezny, C. Andrews, V. Hills, R. P. Campion, V. Novak, K. Olejnik, F. Maccherozzi, S. S. Dhesi, S. Y. Martin, T. Wagner, J. Wunderlich, F. Freimuth, Y. Mokrousov, J. Kune, J. S. Chauhan, M. J. Grzybowski, A. W. Rushforth, K. W. Edmonds, B. L. Gallagher, and T. Jungwirth, “Electrical switching of an antiferromagnet,” Science 351, 587–590 (2016).
  * Baldrati  _et al._ [2019] L. Baldrati, O. Gomonay, A. Ross, M. Filianina, R. Lebrun, R. Ramos, C. Leveille, F. Fuhrmann, T. R. Forrest, F. Maccherozzi, S. Valencia, F. Kronast, E. Saitoh, J. Sinova, and M. Klaüi, “Mechanism of neél order switching in antiferromagnetic thin films revealed by magnetotransport and direct imaging,” Physical Review Letters 123, 177201 (2019).
  * Moriyama  _et al._ [2018] T. Moriyama, K. Oda, T. Ohkochi, M. Kimata, and T. Ono, “Spin torque control of antiferromagnetic moments in NiO,” Scientific Reports 8, 14167 (2018).
  * Chen  _et al._ [2018] X. Z. Chen, R. Zarzuela, J. Zhang, C. Song, X. F. Zhou, G. Y. Shi, F. Li, H. A. Zhou, W. J. Jiang, F. Pan, and Y. Tserkovnyak, “Antidamping-Torque-Induced Switching in Biaxial Antiferromagnetic Insulators,” Physical Review Letters 120, 207204 (2018).
  * Zhang  _et al._ [2019] P. Zhang, J. Finley, T. Safi, and L. Liu, “Quantitative Study on Current-Induced Effect in an Antiferromagnet Insulator/Pt Bilayer Film,” Physical Review Letters 123, 247206 (2019).
  * Meer  _et al._ [2021] H. Meer, F. Schreiber, C. Schmitt, R. Ramos, E. Saitoh, O. Gomonay, J. Sinova, L. Baldrati, and M. Kläui, “Direct Imaging of Current-Induced Antiferromagnetic Switching Revealing a Pure Thermomagnetoelastic Switching Mechanism in NiO,” Nano Letters 21, 114–119 (2021).
  * Baldrati  _et al._ [2020] L. Baldrati, C. Schmitt, O. Gomonay, R. Lebrun, R. Ramos, E. Saitoh, J. Sinova, and M. Kläui, “Efficient Spin Torques in Antiferromagnetic CoO/Pt Quantified by Comparing Field- And Current-Induced Switching,” Physical Review Letters 125, 77201 (2020).
  * Hoogeboom  _et al._ [2017] G. R. Hoogeboom, A. Aqeel, T. Kuschel, T. T. M. Palstra, and B. J. van Wees, “Negative spin Hall magnetoresistance of Pt on the bulk easy-plane antiferromagnet NiO,” Applied Physics Letters 111, 052409 (2017).
  * Fischer  _et al._ [2018] J. Fischer, O. Gomonay, R. Schlitz, K. Ganzhorn, N. Vlietstra, M. Althammer, H. Huebl, M. Opel, R. Gross, S. T. B. Goennenwein, and S. Geprägs, “Spin Hall magnetoresistance in antiferromagnet/heavy-metal heterostructures,” Physical Review B 97, 014417 (2018).
  * Baldrati  _et al._ [2018] L. Baldrati, A. Ross, T. Niizeki, C. Schneider, R. Ramos, J. Cramer, O. Gomonay, M. Filianina, T. Savchenko, D. Heinze, A. Kleibert, E. Saitoh, J. Sinova, and M. Kläui, “Full angular dependence of the spin Hall and ordinary magnetoresistance in epitaxial antiferromagnetic NiO(001)/Pt thin films,” Physical Review B 98, 024422 (2018).
  * Chiang  _et al._ [2019] C. C. Chiang, S. Y. Huang, D. Qu, P. H. Wu, and C. L. Chien, “Absence of Evidence of Electrical Switching of the Antiferromagnetic Néel Vector,” Physical Review Letters 123, 227203 (2019).
  * Churikova  _et al._ [2020] A. Churikova, D. Bono, B. Neltner, A. Wittmann, L. Scipioni, A. Shepard, T. Newhouse-Illige, J. Greer, and G. S. D. Beach, “Non-magnetic origin of spin Hall magnetoresistance-like signals in Pt films and epitaxial NiO/Pt bilayers,” Applied Physics Letters 116, 022410 (2020).
  * Matalla-Wagner  _et al._ [2020] T. Matalla-Wagner, J.-M. Schmalhorst, G. Reiss, N. Tamura, and M. Meinert, “Resistive contribution in electrical-switching experiments with antiferromagnets,” Physical Review Research 2, 033077 (2020).
  * Grzybowski  _et al._ [2017] M. J. Grzybowski, P. Wadley, K. W. Edmonds, R. Beardsley, V. Hills, R. P. Campion, B. L. Gallagher, J. S. Chauhan, V. Novak, T. Jungwirth, F. Maccherozzi, and S. S. Dhesi, “Imaging Current-Induced Switching of Antiferromagnetic Domains in CuMnAs,” Physical Review Letters 118, 057701 (2017).
  * Wadley  _et al._ [2018] P. Wadley, S. Reimers, M. J. Grzybowski, C. Andrews, M. Wang, J. S. Chauhan, B. L. Gallagher, R. P. Campion, K. W. Edmonds, S. S. Dhesi, F. Maccherozzi, V. Novak, J. Wunderlich, and T. Jungwirth, “Current polarity-dependent manipulation of antiferromagnetic domains,” Nature Nanotechnology 13, 362–365 (2018).
  * Gray  _et al._ [2019] I. Gray, T. Moriyama, N. Sivadas, G. M. Stiehl, J. T. Heron, R. Need, B. J. Kirby, D. H. Low, K. C. Nowack, D. G. Schlom, D. C. Ralph, T. Ono, and G. D. Fuchs, “Spin Seebeck Imaging of Spin-Torque Switching in Antiferromagnetic Pt/NiO Heterostructures,” Physical Review X 9, 041016 (2019).
  * Cao  _et al._ [2011] W. N. Cao, J. Li, G. Chen, J. Zhu, C. R. Hu, and Y. Z. Wu, “Temperature-dependent magnetic anisotropies in epitaxial Fe/CoO/MgO(001) system studied by the planar Hall effect,” Applied Physics Letters 98, 262506 (2011).
  * Wang  _et al._ [2015] Y. Wang, X. Zhou, C. Song, Y. Yan, S. Zhou, G. Wang, C. Chen, F. Zeng, and F. Pan, “Electrical control of the exchange spring in antiferromagnetic metals,” Adv. Mater. 27, 3196–3201 (2015).
  * Goto  _et al._ [2016] M. Goto, K. Nawaoka, S. Miwa, S. Hatanaka, N. Mizuochi, and Y. Suzuki, “Electric field modulation of tunneling anisotropic magnetoresistance in tunnel junctions with antiferromagnetic electrodes,” Japan. J. Appl. Phys. 55 (2016), 10.7567/JJAP.55.080304.
  * Grzybowski  _et al._ [2021] M. J. Grzybowski, C. F. Schippers, O. Gomonay, K. Rubi, M. E. Bal, U. Zeitler, B. Koopmans, and H. J. M. Swagten, “Antiferromagnetic Hysteresis above the Spin Flop Field,” arXiv:2109.00093 (2021).
  * [23] Supplementary Information .