archiveText

# Lighter-Than-Air Autonomous Ball Capture and Scoring Robot
Design, Development, and Deployment

Joseph Prince Mathew Dinesh Karri James Yang Kevin Zhu Yojan Gautam
Kentaro Nojima-Schmunk Daigo Shishika Ningshi Yao Cameron Nowzari All authors
are with the Electrical and Computer Engineering Department, George Mason
University, Fairfax, VA 22030, {jprincem<EMAIL_ADDRESS>
###### Abstract

This paper describes the full end-to-end design of our primary scoring agent
in an aerial autonomous robotics competition from April 2023. As open-ended
robotics competitions become more popular, we wish to begin documenting
successful team designs and approaches. The intended audience of this paper is
not only any future or potential participant in this particular national
Defend The Republic (DTR) competition, but rather anyone thinking about
designing their first robot or system to be entered in a competition with
clear goals. Future DTR participants can and should either build on the ideas
here, or find new alternate strategies that can defeat the most successful
design last time. For non-DTR participants but students interested in robotics
competitions, identifying the minimum viable system needed to be competitive
is still important in helping manage time and prioritizing tasks that are
crucial to competition success first.

##  I Introduction: Defend The Republic

Defend The Republic (DTR) is a national Lighter-Than-Air (LTA) robotics
competition that pits two teams (Red versus Blue) against each other in a
60-minute head-to-head match in which fleets of autonomous robots must capture
Green and Purple neutrally buoyant balls and move them through Circle, Square,
and Triangle goals suspended from the ceiling. An overview of the game with
all the elements are shown in Fig. 1. The environment being shape- and color-
coded allows easier perception so the teams can focus on advancing multi-agent
control and interaction problems.

The complete rules of the game allow flexibility for a myriad of different
control and game strategies including heterogeneous teams (where completely
different agents or robots are used cooperatively like a defending robot
passing a ball to an attacking robot that is perhaps faster and more suitable
for finding and scoring goals). However, this paper focuses on a single
minimally viable agent design and deploying a homogeneous team of them to
autonomously play DTR. It is expected that future competitions will see
specialized agents that can perform certain tasks better than others as the
competition evolves.

In considering the design and deployment of a new robot to enter a competition
in less than one year, it is critical to identify the most critical aspects of
the design and build a full minimum viable system as soon as possible. This
allows the team to become competitive as quickly as possible and once a base
functional design is found, future iterations need only to start building on
previously tried and tested methods.

The minimum capabilities required for a single LTA agent to successfully
capture a ball and move it through a goal are a basic level of aerial
locomotion, perception, and interaction with the environment in the form of a
method to move around neutrally buoyant balls.

Figure 1: Defend The Republic (DTR) game scenario showing two teams (Red
versus Blue) with green and purple balls scattered in the environment and
goals (one triangular, circular and square per side) in fixed locations. The
agents must capture these green balls and score by completely passing the ball
through the suspended goals.

It should be emphasized that the evolving design of this agent has been a very
iterative process with lots of trial and error as with any robotics
competitions. More specifically, while we identify the critical areas and
problems that need solutions as fast as possible, we only present our solution
at the time of the April 2023 competition and do not discuss earlier
implementation ideas in detail. We will comment on a few earlier design
choices to contrast certain earlier choices, we do not discuss any design
decisions and instead focus on George Mason University’s combination of
technologies that happened to be successful in April 2023.

In Section II we identify the minimum viable components necessary to perform
all the tasks needed to capture and score a ball in a game of DTR.

  1. (i)

Move around in 3D space for 30 minutes (one half);

  2. (ii)

Find and capture green/purple circular objects;

  3. (iii)

Find orange/yellow, square/circle/triangle-shaped goals and release the ball
through it.

In Section III we formalize the sequence of tasks our robots need to complete
in a conceptual model and present our software that ties all the hardware
together.

##  II Minimum Viable System and Hardware

We partition the required hardware into four components:

The sensors provide all the raw information available for perception and
control.

The actuators provide all the mechanisms for the agent to move and interact
with the world.

The envelope is the main helium-filled containment or balloon providing nearly
all the lift to the entire agent.

The gondola is the main structure that maintains the integrity of the entire
agent and potentially houses any required electronics.

A major challenge of most robotic competitions is the seamless integration of
all subsystems actually working together, at the same time. The most
sophisticated capturing and scoring robot cannot score a single goal if its
envelope isn’t large enough to support the helium needed to lift the robot
into the air. Being an LTA robot competition, a significant challenge of our
design problem is weight. The $200\unit{cu.ft}$ of helium limit per team means
the heavier a single robot is, the fewer robots we can have playing on our
team. The total weight of components used for the gondola, sensors, and
actuators must all be supported by an envelope large enough to provide the
required lift.

###  II-A Sensing

The color-coded game encourages visual data as a primary way of making sense
of the environment. In order to be able to identify different shapes and
colors in a large environment, an RGB camera is the natural first choice of
sensor. In our case we use a monocular USB camera (OV5640) mounted directly at
the front of our robot. In terms of minimum viability, no other perception is
needed (or used) in our design. Again it should be noted that it is expected
future designs can integrate other sensing mechanisms to further improve
individual agent performance and ultimately overall team performance.

For instance, a past design included a separate single point LIDAR sensor used
solely for detecting whether the robot was currently ‘holding’ a game ball or
not. Although this was useful and successful, the added weight was not worth
the minor improvements in performance as the single camera is still able to
help determine whether a ball is currently being held or not, albeit not as
reliably.

###  II-B Actuation

To enable our robot to reach any arbitrary point in a 3D environment, we use a
4-motor/propeller combination to allow unicycle-like control (2D position and
orientation) coupled with a propeller to allow vertical motion similar to [1,
2]. Fig. 2 shows the motor configuration.

To control the yaw of the robot, a differential drive mechanism was created
using a pair of motors and propellers $m_{1},m_{2}$ placed 1000mm apart.
Altitude/height control is performed using a third motor/propeller combo
$m_{3}$ mounted at the bottom of the robot that can produce vertical thrust.
Although the above three motors are sufficient for minimally endowing the
agent with its required capabilities, we are able to simplify our software
problem formalized in Section III-A by adding a fourth motor $m_{4}$ to the
back of the robot as the primary forward-thrust mechanism. This allows us to
decouple the yaw control and thrust control by delegating them to different
motors.

Figure 2: Simplified blimp diagram with motors and cage.

In order to effectively capture neutrally buoyant balls, we have one
additional brushless DC servo motor that actuates the gate or door of the cage
shown hanging under the envelope in Fig. 2. The cage is used to capture, hold,
and maneuver balls around the environment. Details about the cage design are
in Section II-C. The location of $m_{4}$ in Fig. 2 now enables a dual use not
only by providing the primary thrust to the agent, but also serving to blow
balls out of the cage to score a goal when operated in reverse.

###  II-C Gondola Structure

The gondola is a mechanical structure on the blimp which holds all the
electronics and actuators on the blimp. This is important in maintaining the
structural integrity of the robots and ensuring repeatability and uniformity
(reducing idiosyncrasy) across our fleet of agents. We use a $4\times 4\times
1000$mm carbon fiber rod and 3D printed components to mount the 4 motors and
the processing unit. Additionally, we have designed a cage that hangs
underneath the envelope as shown in Fig. 2. The cage is used by the robot to
capture balls and maneuver them around. Further details on the cage design are
in Appendix -D.

###  II-D Envelope Design

The envelope to hold helium that provides the primary lift for the agent as
dictated by the competition is made out of metalized film [3, 4]. In order to
have enough lift to support the payload on the agent, a custom envelope used
so we can choose its volume and shape. One side of the film is shiny, silver,
and uncolored made with Linear Low Density PolyEster (LLDPE), while the other
side has the color of our agent (either light blue or red) made with metalized
nylon. When the silver sides of the film are in contact and heated, an
airtight seal is created.

The total weight of our agent and its respective components used in this agent
are shown in Table I and came out to $645\unit{g}$. Since helium can in
general lift about 1 gram per liter (under ‘normal’ conditions of 25 degrees C
and 1 atm pressure) and the game must be played in sometimes varying
conditions, we add a 20% safety factor and created our envelope to hold about
$770$ liters. This ensures we have sufficient lift and can reach any point in
3D space, even in moderately varying environmental conditions. To deal with
varying conditions, we use pliable playdough to get our agent as close as
possible to neutrally buoyant, while also being able to very easily control
the center of gravity of the agent. Fig. 3 shows the final envelope used.
Details on how these envelopes are designed and produced are in Appendix -C.

Subsystem | Component | Weight ($\unit{g}$) | Cost ($)
---|---|---|---
Sensing | Camera | 15.3 | 35
Actuation | Motor and Prop. | 73.3 | 95
| Connectors | 7.2 | 10
| ESC | 26.6 | 30
| Gate servo | 4.3 | 2
Envelope | Mylar outer layer | 154 | 36
Gondola | Board | 71.4 | 380
| Board Holder | 14.8 | -
| Battery | 192.4 | 26
| Carbon Fiber Structure | 82.3 | 30
| Adhesive Tape | 3 | 2
| Total | 645 | 646
TABLE I: Breakdown of individual component weights and costs Figure 3:
Completed and inflated 3-fold envelope design.

##  III Minimum Viable System Conceptual Model

With our basic hardware selected to enable the minimum capabilities required
to be viable, we now formalize our problem and discuss our simple 4-mode
controller to autonomously play DTR depending on the evolving situation. The
intuitive idea is to sequentially move through the following 4 modes of
operation:

  1. (i)

Ball Search. ($\zeta=1$) Simply spin in circles until a green or purple object
is found.

  2. (ii)

Ball Capture. ($\zeta=2$) Use a tuned PD controller to drive the robot to the
found object.

  3. (iii)

Goal Search. ($\zeta=3$) Simply spin in circles until the desired orange or
yellow object is found.

  4. (iv)

Goal Score. ($\zeta=4$) Use a tuned PD controller to drive the robot to the
goal and release the ball.

Clearly, these operations should not always happen in a seamless sequence. For
instance if capturing a found ball fails in Step 2 and loses sight of the
ball, the agent should go back to Step 1. To simplify perception as much as
possible, we rely on a subsumption architecture-like control architecture to
create a 4 state finite automata, with higher levels of operation subsuming
the lower levels of operation [5, 6].

Algorithm 1 Mode Perception

Output current mode $\zeta\in\\{1,2,3,4\\}$, target error from center of frame
$e_{\text{yaw}},e_{\text{vert}}$ for modes $\zeta\in\\{2,4\\}$

$\gamma=0$(not holding ball) $\sigma=0$(not seeing ball)

1: mode $\zeta=1$ (Ball Search)

2: mode $\zeta=2$ (Ball Capture)

3:$e_{\text{yaw}}=$ horizontal error for ball

4:$e_{\text{vert}}=$ vertical error for ball $\chi=0$ (not seeing goal)

5: mode $\zeta=3$ (Goal Search)

6: mode $\zeta=4$ (Goal Score)

7:$e_{\text{yaw}}=$ horizontal error for goal

8:$e_{\text{vert}}=$ vertical error for goal

Thus rather than thinking about the tasks as an always sequential operation,
we instead enable simple perception to determine which behavior should be
driving the robot at any given time. We describe this architecture in levels
where the highest level controller should always take over the lower level
ones when they are able to.

Level 1: Search. When no target is available to the robot, it should wander
around until it finds something of interest.

Level 2: Go To. When a target of interest is found, it should go towards it.

Level 3: Capture. If the target is a ball, the robot should capture it in its
actuated cage when close enough.

Level 4: Shoot. If the target is a goal and the robot has a ball, it should
shoot the ball when it is close enough.

Let $\gamma\in\\{0,1\\}$ indicate whether the agent currently has a ball in
its cage or not.

Let $\sigma\in\\{0,1\\}$ indicate whether there is at least one ball in the
agent’s Field of View (FOV) or not.

Let $\chi\in\\{0,1\\}$ indicate whether there is at least one goal in the
agent’s FOV or not.

The current mode of operation of the agent can then be determined by Algorithm
1.

###  III-A Reduced Agent Model

Here we present a simple kinematic 2.5D model that ignores pitch and roll of
our agent. It should be noted that this model is not a good representation of
the true system and is only utilized to formally frame our problems and show
exactly how we implement their solutions on our real hardware.

The state of the robot is given by its 3D position $(x,y,z)$ and its 2D
orientation $\theta$. Fig. 4 shows the simplified model. Rather than thinking
of direct motor inputs, we consider the kinematics

$\displaystyle\dot{x}$ $\displaystyle=u_{1}\cos{\theta}$
$\displaystyle\dot{y}$ $\displaystyle=u_{1}\sin{\theta}$ (1)
$\displaystyle\dot{\theta}$ $\displaystyle=u_{2}$ $\displaystyle\dot{z}$
$\displaystyle=u_{3}$

where $u_{1},u_{2},u_{3}$ are all bounded by their hardware limits. The
immediate coupling of motor $m_{3}$ and kinematic input $u_{3}$ and
$m_{4},u_{1}$ directly controlling the height and forward thrust of the agent
are trivial, and the motors $m_{1},m_{2}$ used as a differential drive command
the yaw through $u_{2}$.

In equation (1), $\dot{x},\dot{y},\dot{z}$, and $\dot{\theta}$ is the velocity
of the robot in the x-direction, y-direction, z-direction, and angular
velocity about the z-axis in a global frame. It should be noted that this
global state will never be available to the agents in general and is only used
for us to formalize the control problems and present our solutions.

Figure 4: Kinematic model of the robot.

###  III-B Mode Detection and Basic Perception

Here we discuss how the agent estimates what mode it is in and how to process
the information needed in each mode.

Our simple control strategy only requires a minimal level of perception,
allowing the agents to know which of the 4 operational modes it should
currently be in by estimating the three binary variables $\gamma,\sigma,\chi$,
and where exactly the ball or goal of interest is depending on the mode.

Figure 5: Getting the errors $e_{\text{yaw}}$ and $e_{\text{vert}}$ that our
PD controllers drive to 0 (to effectively center the object of interest in the
center of the camera frame). Here we show 2 objects of interest: Green ball
and Orange Square Goal.

  1. (i)

Have Ball? $\gamma\in\\{0,1\\}$. The first thing the agent needs to keep track
of is whether it currently is holding a ball in its cage or not. One way to do
this using the camera, depending on the position of the camera relative to the
cage, is to determine whether the pixels in the camera frame that capture the
cage are green or purple (the color of game balls). Simple color detection
algorithms can be used to determine the RGB values of specified pixels and
comparing them against a tuned threshold [7]. However, to have more robust
detection in presense of background noise, we deployed a trained yolov5 model
[8] to detect balls and its relative size and position in the frame. The
details of the detection system is shown in appendix -E.

  2. (ii)

See Ball? $\sigma\in\\{0,1\\}.$ If the robot is not holding a ball $\gamma=0$,
then it needs to determine if it sees a ball or not. This is as simple as
checking whether it sees any green or purple in its video stream. Again here
we rely on the yolov5 object detection model to detect the green/purple balls.
The training set is tailored to the specific environment so as to enable
reliable detection. If a ball is seen $\sigma=1$, we need a method of
determining both the lateral/yaw offset $e_{\text{yaw}}$ and vertical offset
$e_{\text{vert}}$ from the center of the ball to the center of the camera
frame. Note for simplicity we are assuming the center of the camera frame
aligns with the center of the cage to properly capture the ball, but depending
on the relative position of camera and cage, the offset may be measured from a
different point in the camera frame. Fig. 5 shows a screenshot of a real
camera frame taken from a blimp during a live game and how
$e_{\text{yaw}},e_{\text{vert}}$ are measured. Exactly how we do this using
the camera is detailed in Appendix -E.

  3. (iii)

See Goal? $\chi\in\\{0,1\\}.$ If the robot is holding a ball $\gamma=$ then it
needs to determine if it sees a goal or not. This is as simple as checking
whether it sees any yellow or orange in its video stream. Similarly to when a
ball is found, we want to estimate the offsets
$e_{\text{raw}},e_{\text{vert}}$. However, estimating these quantities for the
goals are more challenging than the balls because they are hollow objects.
Fig. 5 shows a screenshot of a real frame where
$e_{\text{yaw}},e_{\text{vert}}$ must be estimated with respect to the center
of the hollow orange objects. In addition to the offsets the size of the goal
must also be estimated from the video stream which will be useful when scoring
the goal. The details of how we do this are in Appendix -E.

Algorithm 2 Ball/Goal Search

While $\zeta=1$ OR $\zeta=3$

$\zeta=1$(Ball search) and $~{}\sigma=1$(See ball)

1:gate = Open

2:gate = Closed

3:set $u_{2}=\bar{u}_{2}$ (spin around slowly)

4:set $u_{1}=\bar{u}_{1}$ (move forward while spinning)

5:alternate $u_{3}\in\\{-\bar{u}_{3},\bar{u}_{3}\\}$ to randomly move up and
down

Algorithm 3 Ball Capture

While $\zeta=2$

1:gate = Open

2:set $u_{1}=\bar{u}_{1}$ (move forward)

3:set $u_{2}$ PD controller on $e_{\text{yaw}}$

4:set $u_{3}$ PD controller on $e_{\text{vert}}$

Algorithm 4 Goal Score

While $\zeta=3$

1:gate = Closed

2:set $u_{1}=\bar{u}_{1}$ (move forward)

3:set $u_{2}$ PD controller on $e_{\text{yaw}}$

4:set $u_{3}$ PD controller on $e_{\text{vert}}$ Goal size greater than
threshold size

5:gate = Open

6:set $u_{1}=-\bar{u}_{1}$ (blow balls out)

###  III-C Control

Thanks to the design of our agent, we have a very simple controller for all 4
modes of operation.

Intuitively, the input $u_{1}$ is generally always set to $\bar{u}_{1}$, a
desired forward velocity to allow the agent to move forward like a Dubin’s
vehicle. The only time it changes $u_{1}=-\bar{u}_{1}$ to blow the balls out
when scoring a goal.

The input $u_{2}$ is used to steer or control the yaw of the robot. When
searching for a ball or goal, we simply full throttle $u_{2}=\bar{u}_{2}$ to
spin around until it sees something of interest in modes $\zeta=1,3$. When a
target (either ball or goal) is available, $u_{2}$ uses a simple PD controller
to drive $e_{\text{yaw}}\rightarrow 0$.

The input $u_{3}$ is used to control the altitude or height of the robot. When
searching for a ball or goal, we simply toggle
$u_{3}\in\\{-\bar{u}_{3},\bar{u}_{3}\\}$ randomly to move up and down using a
selected velocity in the 3D environment until it sees something of interest in
modes $\zeta=1,3$. When a target is available, $u_{3}$ uses a simple PD
controller to drive $e_{\text{vert}}\rightarrow 0$.

Finally, the cage gate control is actuated to be open only in modes
$\zeta=2,4$. In $\zeta=2$ the gate remains open all the time facilitating ball
capture. In $\zeta=4$, we have the gate open only when the agent is close to a
goal. This can be detected when the size of goal being tracked is above a
preset threshold that determined through experimentation.

Coupled with the basic perception system determining the mode of operation
$\zeta\in\\{1,2,3,4\\}$, this autonomous behavior of the robot is described
using a simple finite automata with the 4 modes shown in Fig. 8. This is a
continuous process until the robot powers off, or a human interrupt is
invoked.

The fully built agent in action is shown in Figs. 6 and 7.

Figure 6: Images of our deployed agent with one captured ball.

Figure 7: Image showing the motor on the back of the cage and the gate in the
front of the cage.

Figure 8: State Machine for Autonomous Behaviors

##  IV Lessons Learned and Future Recommendations

We detail some of the observations we made in the DTR competition conducted in
April 2023 at Eagle Bank Arena in George Mason University.

###  IV-A Gaining an Edge

The use of learning based object detection system in our robotic system made
detection of objects of interest in the game field very good. This was made
possible by the monolithic controller board design that allowed all the
complex processing systems to be miniaturized to as small as $72\unit{g}$ of
weight. It should be acknowledged that our strong performance was strongly
correlated to a change of venue in which there was a lot of background green
and yellow colors (as George Mason University hosted this competition for the
first time). More specifically, we relied on in-situ labeling and training of
objects of interest in the middle of the competition week to greatly improve
our perception capabilities.

###  IV-B Limitations and Room for Improvement

####  IV-B1 System Setup Time

The setup time for our entire fleet amounted to more than 2 days. This
includes inflating the envelopes, assembling the agents, balancing the agents,
testing basic motion and finally performing autonomous capture and score
tests. The small idiosyncrasies between each agent mean that we spend a lot of
time making minor tweaks so that all agents perform the ball capture and score
to a minimal degree. One of the major factors here is the experimental nature
of the project where the design of the system is constantly evolving and so
there are very few standardized parts. This leads to changing assembly
procedures that lead to these differences observed in agents.

Needing to manually tune each agent separately due to the small idiosyncrasies
is not scaleable. New approaches for both (i) consistency and speed of
designing and deploying agents and (ii) self-tuning methods are desired.

####  IV-B2 Variance in Lighting Condition vs Detection Performance

We have observed that the detection performance was heavily dependent on the
lighting condition of the arena. Naturally relying on in-situ labeling and
training is also not a scalable approach both in terms of setup time but more
importantly non-transferrability of robots meaning slight changes in the
environment may render algorithms trained earlier to be useless.

Using only a single sensor (RGB camera in this case) is a clear limitation. It
is desired to integrate other sensing mechanisms to aid in perception,
especially in scenarios where the RGB camera is weak. For example, the goals
are covered in retro-reflective tape and using an IR light source shining
directly onto the goal and using an IR camera for detection makes it much
easier to detect from farther away, which may serve as a more course-grained
sensor to help the robot get to positions where the camera can do its job
properly.

####  IV-B3 Aerodynamics of the Envelope Design

Admittedly one of our most lacking areas is good mechanical engineering
design. Controllability, specifically vertical stability (yaw control), was an
issue present in all agents. Without properly mechanical engineering analysis
and design methods (for instance CFD analysis), we ended up with a much
heavier agent than we would like. Propellers are also notoriously inefficient
and the efficiency and controllability of our agents should be greatly
improved through the use of different modes of propulsion such as control
surfaces.

It is desired to integrate better mechanical engineering practices and
aerodynamic trade-offs into our design choices.

####  IV-B4 Heterogeneous Fleets

While our team has explored a lot of different agent designs and even some
specialized roles, our team was basically carried in terms of actual point
scoring by the single agent design described in this paper.

The main strategy of our team was to deploy as many agents as possible capable
of executing the intended sequence with a non-zero probability. Unfortunately
this introduced plenty of issues such as 3 teammates fighting over the same
ball due to their low perception capabilities.

Besides just better coordination among a fleet of homogeneous agents, it is
desired to have a heterogeneous team of agents where different agents have
specialized roles and can work together to play DTR.

While our single agent here focused on reliably moving to precise locations to
capture balls and score goals with little room for errors, novel methods that
can deal with bad perception in other ways should be explored. While our
approach relied heavily on simply improving perception in any way possible to
allow our PD controllers to drive agents/balls to within a 5-10cm error
tolerance, other methods can rely on much larger capturing mechanisms to
tolerate much larger errors in perception (e.g., an aerial pursing net [9,
10]).

## Acknowledgements

This work was supported in part by the Department of the Navy, Office of Naval
Research (ONR), under federal grants N00014-20-1-2507 and N00014-23-1-2222.

## References

  * [1] S. Ferdous, A. Mohammadi, and S. Lakshmanan, “Developing a low-cost autonomous blimp with a reduced number of actuators,” 05 2019, p. 13.
  * [2] M. Burri, L. Gasser, M. Käch, M. Krebs, S. Laube, A. Ledergerber, D. Meier, R. Michaud, L. Mosimann, L. Müri, C. Ruch, A. Schaffner, N. Vuilliomenet, J. Weichart, K. Rudin, S. Leutenegger, J. Alonso-Mora, R. Siegwart, and P. Beardsley, “Design and control of a spherical omnidirectional blimp,” in _2013 IEEE/RSJ International Conference on Intelligent Robots and Systems_ , 2013, pp. 1873–1879.
  * [3] J. López, G. P, R. Sanz, and B. Wolfram, “Developing a low-cost autonomous indoor blimp,” _Journal of Physical Agents_ , vol. 3, 01 2009.
  * [4] G. Gorjup and M. Liarokapis, “A low-cost, open-source, robotic airship for education and research,” _IEEE Access_ , vol. PP, 04 2020.
  * [5] R. Brooks, “A robust layered control system for a mobile robot,” _IEEE Journal on Robotics and Automation_ , vol. 2, no. 1, pp. 14–23, 1986.
  * [6] R. Arkin, _Behavior-Based Robotics_. The MIT Press, 05 1998.
  * [7] H. Fleyeh, “Color detection and segmentation for road and traffic signs,” in _IEEE Conference on Cybernetics and Intelligent Systems, 2004._ , vol. 2, 2004, pp. 809–814.
  * [8] J. Redmon, S. Divvala, R. Girshick, and A. Farhadi, “You only look once: Unified, real-time object detection,” Tech. Rep., 2016. [Online]. Available: http://pjreddie.com/yolo/
  * [9] J. Rothe, M. Strohmeier, and S. Montenegro, “A concept for catching drones with a net carried by cooperative uavs,” in _2019 IEEE International Symposium on Safety, Security, and Rescue Robotics (SSRR)_ , 2019, pp. 126–132.
  * [10] “Tokyo police to deploy net-carrying drone to catch rogue drones,” https://www.nbcnews.com/tech/tech-news/tokyo-police-deploy-net-carrying-drone-catch-rogue-drones-n478596, accessed: 2023-09-02.
  * [11] Z. Zou, Z. Shi, Y. Guo, J. Ye, and S. Member, “Object Detection in 20 Years: A Survey,” may 2019. [Online]. Available: https://arxiv.org/abs/1905.05055v2
  * [12] Z. Q. Zhao, P. Zheng, S. T. Xu, and X. Wu, “Object Detection with Deep Learning: A Review,” _IEEE Trans. Neural Networks Learn. Syst._ , vol. 30, no. 11, pp. 3212–3232, nov 2019.
  * [13] R. Girshick, “Fast R-CNN,” in _Proc. IEEE Int. Conf. Comput. Vis._ , vol. 2015 Inter, 2015, pp. 1440–1448.
  * [14] S. Minaee, Y. Boykov, F. Porikli, A. Plaza, N. Kehtarnavaz, and D. Terzopoulos, “Image Segmentation Using Deep Learning: A Survey,” _IEEE Trans. Pattern Anal. Mach. Intell._ , vol. 44, no. 7, pp. 3523–3542, jul 2022.
  * [15] Y. Hu, J. Hugonot, P. Fua, and M. Salzmann, “Segmentation-driven 6D object pose estimation,” in _Proc. IEEE Comput. Soc. Conf. Comput. Vis. Pattern Recognit._ , vol. 2019-June. IEEE Computer Society, jun 2019, pp. 3380–3389.
  * [16] G. Jocher, A. Chaurasia, A. Stoken, J. Borovec, NanoCode012, Y. Kwon, K. Michael, TaoXie, J. Fang, imyhxy, Lorna, Z. Yifu, C. Wong, A. V, D. Montes, Z. Wang, C. Fati, J. Nadar, Laughing, UnglvKitDe, V. Sonck, tkianai, yxNONG, P. Skalski, A. Hogan, D. Nair, M. Strobel, and M. Jain, “ultralytics/yolov5: v7.0 - YOLOv5 SOTA Realtime Instance Segmentation,” Nov. 2022. [Online]. Available: https://doi.org/10.5281/zenodo.7347926
  * [17] T. Lin and R. Flynn, “Labelimg: a graphical image annotation tool,” 2020 - 2022. [Online]. Available: https://github.com/heartexlabs/labelImg

###  -C Envelope Design

Red and light blue rolls of film were used to make two sets of agents. Through
its heat sealing properties, when the LLDPE sides of the film are in contact
and heated, an airtight seal is created. This can be done with traditional
irons or even a heat gun. Our agents were manufactured using constant heat
roller sealers. The silver and color side of the film will not seal when
heated to each other. A self-sealing valve from Anagram was used to allow
inflation of the envelopes.

In past competitions, our envelopes have traditionally been 2-layered. This
means only 2 sheets of film were layered on top of each other and a seal was
created. The maximum width of our agents was restricted by the width of the
roll of film 111.76 cm (44 in). The width of the agents had to be slightly
less due to leaving a margin room for sealing and the width of the seal
itself. The only way to increase the volume of the envelopes was to increase
length, but this posed manufacturing challenges and it hindered the
aerodynamics of the agent for flight control (loss of pitch stability). To
resolve this, envelopes with an additional folded layer were manufactured to
increase volume without sacrificing aerodynamic stability. The backbone agent
envelopes were 3-layers. To achieve this, one sheet of the film is placed
down, with the silver side up. Ensure the sheets are as smooth and flat as
possible when taping it to a table. Creases and wrinkles raise the risk of
holes and tears when heat sealing over. Placing another sheet with the silver
side facing down, we then folded this sheet over itself in half. The fold
should be exactly over the center-line of the first sheet and the silver side
facing up. Do not tape the folded side down, only the edge. Lastly, place
another sheet over the other two sheets, with the silver side facing down. To
prevent melting and tearing of the film, a PTFE coated fiberglass fabric sheet
is placed over the sheets when sealing. When sketching the outline, ensure the
fold is the center-line of the agent. If not, the envelopes faces will not be
equally sized when inflated. Seal along the outline, but makes sure to leave a
gap for the valve. The folding method takes advantage of both sides of the
film. Heating the folded side creates multiple seals, while the colored
surface allows for the sides to be separated even when heated. Once the
envelope is cut from the excess material, take a valve and insert a thin strip
of teflon PTFE. This prevents the valve from sealing shut when sealing it to
the envelope. Below are the dimensions of our envelope in cm. (Approximately
630 g of lift was provided). Picture below as well

Figure 9: Dimensions used to manufacture the envelope. The internal fold line
here shows the inner layer folded along this line to create the 3 layered
envelope

###  -D Cage Design

The sides of the cage are made of $3\times 3\times 1000$mm carbon fiber rods.
The front face of the cage where the target is captured is square in shape and
has a side length of 600mm. This gives us an area of $3.6\times 10^{5}$mm2.
The targets are spherical and have a diameter of approximately $500mm$ which
gives a cross-section area of $1.96\texttimes 10^{5}$mm2. The reason for
making the cage’s frontal area bigger than the cross-section area of the
target is to tolerate impreciseness in the controller to an extent. In Fig. 6,
we show the cage frontal area versus the target cross-section area during the
capture (left) and that five targets can be captured simultaneously (right).
In figure 7, we show the motor mounted on the back of the cage and the gate
which is used to capture the target.

###  -E Improving Detection using YOLOv5

What we need for goal detection is the ability to incorporate the shape of
goals on top of existing color detection methods. More recently we have seen
use of learning based object detection frameworks used for detection of
complex objects in the visual data. Some of the object detection systems
gaining prominence in the last decade are [11, 12, 8, 13] with mode advanced
image segmentation techniques [14] that allow even 3D pose estimation in some
scenarios [15]. Our main focus in this paper will be on the popular ”You Only
Look Once” [8] single shot object detection framework and its application as
an target detection framework for the LTA agents that will be deployed for
DTR.

To detect objects (balls or goals) we deploy a pre-trained YOLOv5 [16] object
detection model. A YOLOv5 system has the ability to detect and localize
objects of a specific class in an image. This is done by employing a two-step
process: first a preliminary bounding box regression is performed followed by
predicting the class of object.

YOLOv5 employs anchor boxes (pre-defined boxes of different sizes and aspect
ratios) which are placed at various positions in the image and serve as
reference points for the network to predict bounding box coordinates, thereby
assisting in object localization. In the specific implementation of, YOLOv5,
the output layer generates a large number of bounding box proposals by
predicting offsets from the anchor box positions. These offsets represent the
coordinates for the top-left and bottom-right corners of the predicted
bounding boxes. Outside the neural network framework, we use non-maximum
suppression (NMS) to eliminate redundant bounding box proposals from the
network output and improve detection accuracy. NMS filters out overlapping
bounding boxes based on their confidence scores and overlap of bounding boxes
and selects the ones with the highest probabilities among clusters of bounding
boxes with a certain threshold of overlap. For each remaining bounding box,
YOLOv5 predicts the probability distribution across different object classes.
This is achieved using softmax activation on the class scores, indicating the
likelihood of each class being present within the bounding box.

Figure 10: Illustration of the bounding box around the detected target in the
FOV of the agent. The bounding box is used to extract the relative position of
the target from the agent.

In short, for any input image, YOLOv5 outputs three pieces of information for
each target $k$ detected: a bounding box around the detected target, the class
of the target and the confidence of detection as shown in figure 10. Let the
bounding box for the target $k$ (either a ball or a goal) be
$\widehat{y}^{bb}_{k}\in{}^{4}:=[\widehat{y}^{bbx^{-}}_{k},\widehat{y}^{bbx^{+}}_{k},\widehat{y}^{bby^{-}}_{k},\widehat{y}^{bby^{+}}_{k}]^{T}$
consisting of the bounds of the box in each orthogonal axes of the frame. We
can extract the relative position measurement
$\widehat{x}_{k}\in{}^{3}:=[\widehat{x}^{r}_{k},\widehat{x}^{\theta}_{k},\widehat{x}^{\psi}_{k}]^{T}$
of the object using the bounding box using:

$\displaystyle\widehat{x}_{k}=\begin{bmatrix}\sqrt{k^{r}/\left(({y}^{bbx^{+}}_{k}-\widehat{y}^{bbx^{-}}_{k})(\widehat{y}^{bby^{+}}_{k}-\widehat{y}^{bby^{-}}_{k})\right)}\\\
k^{\theta}({y}^{bbx^{+}}_{k}+\widehat{y}^{bbx^{-}}_{k})/2\\\
k^{\psi}({y}^{bby^{+}}_{k}+\widehat{y}^{bby^{-}}_{k})/2\end{bmatrix}$ (2)

where $k^{\theta}$ and $k^{\psi}$ is the transformation factor required to
change the pixel value of the detected object to bearing angles in the
horizontal and vertical axes respectively. $k^{r}$ is the transformation
factor that converts the pixel area to the distance to the target from the
camera frame. We obtain this from the calibration experiment for the camera.

####  -E1 Training Dataset

For training the YOLOv5 detection model, we need to create a dataset
consisting of all the objects we are interested in identifying. This process
of dataset creation uses labelled images. We collect a large number of images
containing the target objects and mark out exact bounding boxes of them. This
process uses a tool called LabelImg [17] which is a popular graphical image
annotation tool used for labeling and annotating objects in images. We show a
sample data labelling session in figure 11

In-situ training seems to have given us the edge over the competition this
time.

Figure 11: Using labelimg to create labelled datasets for images taken from
the Eagle Bank Arena. Here we show an orange square and orange triangle hoops
labelled

Our dataset has 8 classes in total consisting of balls (green and purple) and
goals (orange and yellow color; square, circle and triangle shape). While
creating these datasets we have inferred the following:

  * •

For each class of objects we need at least 200 images and about less than 400
images will do. All images of each class must be unique with very few
repetitions of background. It helps a lot to separate out images of each class
to different folders for easier labelling.

  * •

Images of the objects must include them at various distances from the camera.
Some images must be close, even clipped in the FOV, while the others must be
far away. This helps with improving detection performance at different
distances.

  * •

Some objects in the frame might falsely trigger the detection for a specific
class. One example of this is the fact that blooming from the bright lights
from eagle bank arena were detected as balls as the pattern created in the
bloom resembled a stretched out balloon. The way to mitigate this is to create
a dataset with these artifacts that trigger false positives without any
labelling on these (include at least one object that belongs to the actual
class in these images too). During training the regions without a label are
considered as background and hence penalize these erroneous detections.

  * •

While labelling make sure all the objects that are visible are labelled with
tight tolerance. Adding more background to the object bounding box increases
the chance for false detections.

For training we need to split the training images to test and train datasets.
To get the dataset to the final form required by the training, there is a
python script that compiles all the images, does a random split based on test
train ratio and finally compiles them to the structure required by the YOLOv5
training script.

####  -E2 FlySensei: Onboard vision processing system

Figure 12: Onboard Processing pipeline for LTA agents

We need to implement the detection algorithm on an LTA Agent that can capture
images and process them. To that end, we created a fully integrated solution
called FlySensei. We show the system in figure 12. This system uses a Google
Coral SOM, which runs the YOLOv5 model. The vision pipeline starts with a USB
camera that is placed in front of the agent. This captured image data is piped
to the Google coral. Here we run the YOLOv5 model that outputs the state
estimates of the target as mentioned on section -E. This state information is
used for the PID based motor command generation also mentioned in section -E.

To get a usable model for YOLOv5 that can be run on the Google Coral SOM, we
need to first train the model using the dataset created specifically for the
blimps. We found that the use of the following parameters yielded a model that
could be used: The input layer size for the network is $320\times 320\times
3$. This is an image of $320\times 320$ pixels. YOLOv5 has multiple model
complexities defined and we could go as high as the small model before the
model became too big to implement in google coral. The training was conducted
to 1000 epochs with a batch size of 32.

Figure 13: Vision pipeline on Google Coral SOM

The output model from training cannot be directly run on the Google Coral. The
system expects an int8 quantized TF Lite model that can run the network on the
TPU onboard. To achieve this we use an existing converter with the best
checkpoint of the trained network. To note here is that the neural network
does not include the NMS filter that is needed and so we have to implement a
version of that to run on the CPU side of the coral SOM. The full image
detection pipeline is shown in figure 13.


# A Preliminary Fluid-Structure Coupling of NekRS and MOOSE via Cardinal

A. Chaube1111corresponding author<EMAIL_ADDRESS>, A.J. Novak2, H.
Yuan2, E. Merzari3,
D.R. Shaver2, P.F. Fischer4, C.S. Brooks1
1Department of Nuclear  Plasma  and Radiological Engineering
University of Illinois Urbana-Champaign
<EMAIL_ADDRESS><EMAIL_ADDRESS>
2Argonne National Laboratory
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
3Ken and Mary Alice Lindquist Department of Nuclear Engineering
Pennsylvania State University
<EMAIL_ADDRESS>
4Department of Computer Science
University of Illinois Urbana-Champaign
<EMAIL_ADDRESS>
###### Abstract

Fluid-Structure Interaction (FSI) is a significant phenomenon in most nuclear
reactors, causing effects such as Flow-Induced Vibration (FIV) and thermally-
driven Core-Radial Expansion (CRE). We demonstrate that Cardinal, an open-
source coupling of NekRS and OpenMC to MOOSE, can be used for modelling FSI by
coupling the Tensor Mechanics Module from the Multiphysics Object Oriented
Simulation Environment (MOOSE) to NekRS’s Arbitrary Lagrangian-Eulerian (ALE)
solver. The solid mechanics-thermal hydraulics coupling is implemented using
efficient in-memory coupling and data transfers. We provide a preliminary
demonstration of these capabilities with a 3-D FSI benchmark for an elastic
block in crossflow.

###### keywords:

sodium-cooled fast reactor, core-radial expansion, fluid-structure interaction

##  1 INTRODUCTION

Fluid-Structure Interaction (FSI) has an extensive presence in disciplines
such as nuclear engineering, aerodynamics, hemodynamics, and energy-systems
engineering, where the interconnected dynamics of the fluid-solid interfaces
significantly impact physical outcomes [1]. In nuclear engineering, due to the
high flow-rates involved, Flow-Induced Vibration (FIV) can cause wear in heat
exchangers and reactor cores, which can have ramifications in terms of repair
costs, reduced performance, and safety [2]. In Sodium-cooled Fast Reactors
(SFRs), coupling between FSI and thermal expansion contributes to Core-Radial
Expansion (CRE), which is a complex multiphysics phenomenon that incorporates
neutronics, thermal-hydraulics, and solid mechanics. Fuel deformation and the
ensuing multiphysics interactions can cause fuel melting, as in the case of
Experimental Breeder Reactor (EBR)-I [3]; may induce power oscillations, one
hypothesis for events observed in Phénix [4]; or limit burnup due to
excessively warped fuel elements that cannot be removed from the core [5]. For
CRE in particular, Wozniak et al. [5] reviewed the available literature and
found that

> “No code system currently exists which tightly and robustly couples the
> neutronics, thermal hydraulics, and thermal mechanical physics with enough
> detail to fully resolve the complex core radial expansion reactivity
> feedback effects.”

As highlighted by Merzari et al. [6], there is a need to simulate FSI-induced
phenomena in advanced reactors and their components in order to accurately
assess the impact of FSI while complementing (often costly) experiments.

Cardinal [7, 8], an open source222https://cardinal.cels.anl.gov/ coupling of
OpenMC [9] and NekRS [10] to the Multiphysics Object Oriented Simulation
Environment (MOOSE) [11], can perform complex multiphysics simulations by
leveraging existing solvers that have been verified and validated. Its modular
design affords more flexibility than monolithic FSI solvers as it can
incorporate additional physics with relative ease. Cardinal also offers
several computational advantages, such as in-memory coupling, distributed
parallel meshes, and the construction of mesh mirrors to obviate the need for
strictly conformal meshes for interfacing in code coupling. The use of NekRS
allows the use of higher order elements, and GPU-acceleration of the
computationally expensive Computational Fluid Dynamics (CFD) solves.
Additionally, Cardinal can also leverage NekRS’s Arbitrary Lagrangian-Eulerian
(ALE) [1, 12] mesh solver. This is in contrast to the MOOSE Fluid-Structure
Interaction (FSI) module, which is currently limited to applications with
negligible fluid flow and small fluid domain displacements due to its reliance
on an acoustic FSI formulation [13].

Because Cardinal integrates NekRS and OpenMC to MOOSE in a general manner,
Cardinal can use MOOSE’s Tensor Mechanics module to model deformation of
structural materials coupled to OpenMC neutronics and NekRS thermal
hydraulics. However, as Cardinal has not yet been used for FSI applications, a
coupling framework between these modules must be implemented. This work will
create such a framework that can be used for high-fidelity FSI analyses. In
the near future, we intend to couple neutronics to our FSI solves as well.

We are demonstrating a preliminary version of our coupling using the geometry
and flow conditions from a 3D-FSI benchmark of an elastic block in crossflow
[14]. We discuss the coupling methodology, which is followed by a detailed
description of the benchmark. The results demonstrate the FSI coupling
functionality, and the fluid and solid solutions obtained. We conclude with a
discussion of priorities of future work.

##  2 METHODOLOGY

The objective of this work is to couple NekRS to MOOSE for FSI; this coupling
is achieved through Cardinal, the open-source interface between NekRS, OpenMC,
and MOOSE. OpenMC is not directly used in this paper, but further discussions
of the OpenMC–MOOSE coupling within Cardinal can be found in the literature
[7]. However, we note that a companion paper [15] in this conference has
incorporated unstructured mesh particle tracking in Cardinal via the DAGMC
library, which enables moving mesh problems for Monte Carlo radiation
transport. The remainder of this section introduces the basic NeKRS–MOOSE FSI
coupling, beginning with (i) how the data transfers are achieved and then
followed by (ii) a discussion on the coupled solve.

###  2.1 Spatial Data Transfers

Data transfers between NekRS and MOOSE occur using MOOSE’s Transfer system,
which provides myriad mesh-to-mesh communication options such as nearest node
maps, projections, interpolations, and more. These data transfers are designed
to be independent of the physical interpretation (e.g. heat flux, traction,
neutron flux, …) of the Degrees of Freedom (DOFs) being communicated between
meshes. In addition, MOOSE’s Transfer system does not mandate conformal meshes
among the individual “single physics” codes – each solver can use a unique
mesh. An example of a boundary nearest node transfer in MOOSE between two
physics applications is shown in Figure 1.

Figure 1: Example nearest-node MOOSE transfer from application $A$ to
application $B$.

In order for the MOOSE framework to send data in/out of NekRS, Cardinal copies
NekRS’s spectral element CFD mesh into a “mesh mirror” of type MooseMesh
(MOOSE’s unstructured mesh class). Because the mesh mirror is simply a copy of
the NekRS mesh, reading/writing DOFs between the mirror and NekRS’s internal
representation of solution vectors is straightforward because mappings between
element and node IDs are structured.

For a NekRS spectral mesh of order $N$, the Cardinal mesh mirror may be either
(i) a first order version of the NekRS mesh, (ii) a second order version of
the NekRS mesh, or (iii) exactly identical to the NekRS mesh. Options (i) and
(ii) require less memory than option (iii), at the expense of less resolution
in the data transfer. Regardless of the “order” of the mesh mirror, there are
two categories of mesh mirrors used. A volume mesh mirror creates a copy of
the entire volumetric mesh and is useful for transferring quantities such as a
volumetric heat source or fluid density, for neutronics feedback. A boundary
mesh mirror is a copy of the shared boundary between applications, and is
suitable for transferring heat fluxes and domain displacements. Figure 2
shows, for illustration, a boundary “mesh mirror” created by Cardinal for a
NekRS spectral mesh of polynomial order $N=4$.

We note that, contrasted with previous FSI couplings of Nek5000 to Diablo [6],
that our implementation does not impose any requirements on node/element
alignment between the fluid solver (NekRS) and the solid solver. Further, our
implementation may use either volume-based or boundary-based mesh mirrors. In
other words, FSI couplings of NekRS to MOOSE always communicate data through a
fluid-solid interface boundary, but the FSI physics can be optionally
superimposed on top of other volume-based physics feedback (such as coupling
to neutron transport).

Figure 2: Example NekRS CFD mesh (left), and different boundary mesh mirrors:
(i) first-order (middle-left), (ii) second-order (middle-right), and (iii)
exact (right).

###  2.2 Coupling Methodology

For FSI, NekRS and MOOSE tensor mechanics are coupled via Picard iteration
with a two-way data transfer to enforce continuity in boundary stress and
boundary velocity. NekRS sends wall traction $t$ to MOOSE,

$t_{i}=\left(-P\delta_{ij}+S_{ij}\right)n_{j}\ ,$ (1)

where $P$ is the NekRS fluid pressure, $S_{ij}$ is the NekRS rate-of-strain
tensor, and $\hat{n}$ is the unit normal on the fluid-solid interface. MOOSE
sends displacement $\vec{d}$ to NekRS, which is internally converted into a
boundary velocity using a first-order finite difference approximation,

$\vec{v}^{\ n}=\frac{\vec{d}^{\ n}-\vec{d}^{\ n-1}}{\Delta t}$ (2)

where $\vec{v}$ is the fluid-solid interface velocity, $n$ is the time step
index, and $\Delta t$ is the time step size. This boundary velocity is then
applied as a Dirichlet condition for the Arbitrary Lagrangian-Eulerian (ALE)
mesh solver.

We emphasize that this FSI implementation is preliminary, and only consists of
the bare minimum requirements for the velocity and stress boundary conditions
between the fluid and solid domains. Enhancements to improve stability and
convergence, such as implicit partitioned predictor-corrector schemes,
relaxation, and fictitious mass and damping, will be added in future work [6].

Initial testing of our implementation used user-prescribed function
displacements within MOOSE, where a boundary displacement is provided as a
generic function $f(x,y,z)$. This has allowed rapid development of FSI data
transfers without relying on a computationally intensive fully-coupled
structural mechanics solve. As an example, a test case with a swelling pipe is
presented in Figure 3. This case is also part of the Cardinal regression test
suite.

(a) MOOSE mesh, with solid displacement

(b) NekRS Mesh

Figure 3: Displacement transfer from the MOOSE mesh (left) to the spectral
mesh of NekRS (right) in a test case with a swelling pipe.

##  3 BENCHMARK

This section presents a proof-of-concept FSI simulation coupling NekRS CFD
with MOOSE tensor mechanics. We select a 3-D benchmark developed by Richter
[14] due to its (i) relatively simple geometry and (ii) steady solution.
Vibration-type FSI will require additional stability enhancements in Cardinal,
and are deferred to future work.

The Richter benchmark is based on goal-oriented error estimation using the
dual-weighted residual method [16] for an FSI problem mapped entirely to the
ALE domain to make the variational formulation of the FSI problem consistent
at the fluid-solid interface. The domain is a rectangular half-duct, with an
elastic block affixed within the duct in cross-flow. The solid domain has
zero-displacement boundary conditions specified at its base, and normal
displacement across the symmetric boundary is forbidden. The flow has a
Reynolds number of approximately 25. Two reference values with their error are
provided: the drag exerted along the x-direction on the obstacle by the fluid
and the x-displacement of the solid at a specified point. At the interface,
displacements and normal stresses are equalised.

Our problem setup is the same as the benchmark; meshes and boundary conditions
are shown in Fig. 4. The fluid problem is run within NekRS using Direct
Numerical Simulation (DNS), with incompressible flow and the full stress
formulation enabled, on a seventh-order mesh. The MOOSE Tensor Mechanics
module is set up to compute finite strain for an isotropic, elastic material
on a second-order mesh. The transient solves for solid mechanics are
preconditioned with a high-performance hybrid multigrid preconditioner [17].
The solid block has zero displacement boundary conditions specified on the
bottom, while the stress boundary conditions are applied to the solid as
traction computed within the fluid solver. The mesh displacement from the
solid is converted into mesh velocity for the ALE solver and applied
appropriately. The inlet and outlet boundary conditions are from the benchmark
specification.

(a) Fluid mesh (without Gauss-Lobatto-Legendre points) for NekRS.

(b) Second order solid mesh for tensor mechanics.

Figure 4: Meshes and boundary conditions used in the FSI solve.

The initial conditions for the fluid are derived by running the standalone
fluid problem without mesh movement until convergence, and applying the
resulting velocity and pressure fields to the NekRS simulation as initial
conditions. All data transfers occur between the solid and the fluid problem
through a second-order volume mesh mirror. While it is not strictly necessary,
both solid and fluid meshes are comprised of HEX20 elements. The meshes are
not conformal, as Cardinal can interpolate data between low- and high-order
meshes with sufficient accuracy. No stability enhancements such as relaxation
schemes were found to be necessary, likely due to the small magnitude of
displacements involved in the benchmark problem.

##  4 RESULTS

In this section, we describe the flow and the results obtained. We note that a
formal mesh refinement study has yet to be performed, and all results
presented here are preliminary and should be understood as a proof-of-concept.
The simulation was run until convergence on two Intel Xeon Platinum 8260 CPUs
running at 2.40GHz, which required approximately 3 hours of compute time.

As the FSI simulation commences, the object in cross-flow experiences a sudden
drag from the incompressible flow, deforming in the direction of the flow. The
block oscillates as the drag fluctuates, before settling into a steady state
after approximately 98 flow-throughs.

Figure 5: Displacements obtained for the FSI problem (magnified 200x). Figure
6: Velocity field from the ALE-based CFD solve for the Richter benchmark
problem.

The displaced solid domain, with the displacement magnitudes is shown in
Figure 5. The velocity field with streamlines for a seventh-order spectral
mesh is shown in Figure 6. A close-up of the displaced solid and fluid
solutions is shown in Figure 7. In order to best highlight the solid
deformation, displacement of the fluid mesh is not exaggerated in either Fig.
6 or 7, although the mesh is indeed deforming via the ALE solver. While the
results show comparable displacement and drag values to the benchmark, a
formal mesh refinement study is needed before we can fully assess the accuracy
of this particular Cardinal simulation.

Figure 7: Solid displacements (magnified 200x) superimposed with the velocity
solution on the moving fluid mesh.

##  5 CONCLUSIONS

A proof-of-concept coupling of NekRS and the MOOSE Tensor Mechanics module
within Cardinal is demonstrated for FSI applications. A simple block-in-
crossflow problem based on a 3D FSI benchmark was simulated, with data
transfers achieved across non-conformal low-order solid mechanics and high-
order CFD domains using MOOSE data transfers and lower order copies of the CFD
mesh called “mesh mirrors.” The two-way coupling was driven by traction
transfers from the fluid to the solid, and the transfer of mesh velocities
from the solid to the fluid. The preliminary results show that the coupled
solver is able to simulate velocity and displacement solutions for the FSI
problem. The solves are currently being performed on relatively coarse meshes
for ease of software development. For our simulations, we have used a total of
921,636 degrees of freedom, which is approximately an order of magnitude less
than the 7,600,775 degrees of freedom used in the benchmark itself. As next
steps, we will perform a mesh refinement study and compare predictions for
displacement and drag with the benchmark reference values. Large deformations,
contact, and neutronics will be addressed in future work.

## ACKNOWLEDGEMENTS

The submitted manuscript has been created by UChicago Argonne, LLC, Operator
of Argonne National Laboratory (”Argonne”). Argonne, a U.S. Department of
Energy (DoE) Office of Science laboratory, is operated under Contract No. DE-
AC02-06CH11357. The U.S. Government retains for itself, and others acting on
its behalf, a paid-up nonexclusive, irrevocable worldwide license in said
article to reproduce, prepare derivative works, distribute copies to the
public, and perform publicly and display publicly, by or on behalf of the
Government. The DoE will provide public access to these results of federally
sponsored research in accordance with the DOE Public Access Plan
(energy.gov/downloads/doe-public-access-plan). This material is based upon
work supported by Laboratory Directed Research and Development (LDRD) funding
from Argonne National Laboratory (ANL), provided by the Director, Office of
Science, of the U.S. DoE under Contract No. DE-AC02-06CH11357.

We gratefully acknowledge use of the Bebop cluster in the Laboratory Computing
Resource Center at Argonne National Laboratory.

## References

  * [1] T. Richter.  _Fluid-structure Interactions: Models, Analysis and Finite Elements_.  Springer, 1st ed. 2017 edition edition (2017).
  * [2] M. P. Païdoussis.  “A review of flow-induced vibrations in reactors and reactor components.” _Nuclear Engineering and Design_ , volume 74(1), pp. 31–60 (1983).
  * [3] J. H. Kittel, M. Novick, and R. F. Buchanan.  “The EBR-I Meltdown—Physical and Metallurgical Changes in the Core.” _Nuclear Science and Engineering_ , volume 4(2), pp. 180–199 (1958).
  * [4] B. Fontaine et al.  “Description and preliminary results of PHENIX core flowering test.” _Nuclear Engineering and Design_ , volume 241(10), pp. 4143–4151 (2011).
  * [5] N. Wozniak, E. Shemon, and J. Grudzinski.  “Review of Tools for Modeling Core Radial Expansion in Liquid Metal-Cooled Fast Reactors.” Technical Report ANL/NSE-20/41, 1755931, 164547 (2020).
  * [6] E. Merzari et al.  “High-Fidelity Simulation of Flow-Induced Vibrations in Helical Steam Generators for Small Modular Reactors.” _Nuclear Technology_ , volume 205(1-2), pp. 33–47 (2019).
  * [7] A. Novak et al.  “Coupled Monte Carlo and thermal-fluid modeling of high temperature gas reactors using Cardinal.” _Annals of Nuclear Energy_ , volume 177, p. 109310 (2022).
  * [8] E. Merzari et al.  “Cardinal: A Lower-Length-Scale Multiphysics Simulator for Pebble-Bed Reactors.” _Nuclear Technology_ , volume 207(7), pp. 1118–1141 (2021).
  * [9] P. K. Romano et al.  “OpenMC: A state-of-the-art Monte Carlo code for research and development.” _Annals of Nuclear Energy_ , volume 82, pp. 90–97 (2015).
  * [10] P. Fischer et al.  “NekRS, a GPU-Accelerated Spectral Element Navier-Stokes Solver.” (2021).  ArXiv:2104.05829.
  * [11] C. Permann et al.  “MOOSE: Enabling massively parallel multiphysics simulation.” _SoftwareX_ , volume 11 (2020).
  * [12] M. O. Deville, P. F. Fischer, and E. H. Mund.  _High-Order Methods for Incompressible Fluid Flow_.  Cambridge Monographs on Applied and Computational Mathematics (2002).
  * [13] S. Dhulipala et al.  “Development, verification, and validation of comprehensive acoustic fluid-structure interaction capabilities in an open-source computational platform.” _Earthquake Engineering & Structural Dynamics_, volume 51(10), pp. 2188–2219 (2022).
  * [14] T. Richter.  “Goal-oriented error estimation for fluid–structure interaction problems.” _Computer Methods in Applied Mechanics and Engineering_ , volume 223-224, pp. 28–42 (2012).
  * [15] A. Novak et al.  “Multiphysics Coupling of OpenMC CAD-Based Transport to MOOSE using Cardinal and Aurora.” In _Proceedings of M &C_ (2023).
  * [16] R. Becker and R. Rannacher.  “An optimal control approach to a posteriori error estimation in finite element methods.” _Acta Numerica_ , volume 10, pp. 1–102 (2001).  Publisher: Cambridge University Press.
  * [17] F. Kong et al.  “A Highly Parallel Multilevel Newton–Krylov–Schwarz Method with Subspace-Based Coarsening and Partition-Based Balancing for the Multigroup Neutron Transport Equation on Three-Dimensional Unstructured Meshes.” _SIAM Journal on Scientific Computing_ , volume 42(5), pp. C193–C220 (2020).