# Distributed Locking as a Data Type

Julian Haas  0000-0001-9959-5099 Technische Universität DarmstadtGermany ,
Ragnar Mogk  0000-0003-4583-1791 Technische Universität DarmstadtGermany ,
Annette Bieniusa  0000-0002-1654-6118 University of Kaiserslautern-
LandauGermany and  Mira Mezini  0000-0001-6563-7537 Technische Universität
DarmstadtGermany

###### Abstract.

Mixed-consistency programming models assist programmers in designing
applications that provide high availability while still ensuring application-
specific safety invariants. However, existing models often make specific
system assumptions, such as building on a particular database system or having
baked-in coordination strategies. This makes it difficult to apply these
strategies in diverse settings, ranging from client/server to ad-hoc peer-to-
peer networks.

This work proposes a new strategy for building programmable coordination
mechanisms based on the _algebraic replicated data types_ (ARDTs) approach.
ARDTs allow for simple and composable implementations of various protocols,
while making minimal assumptions about the network environment. As a case
study, two different locking protocols are presented, both implemented as
ARDTs. In addition, we elaborate on our ongoing efforts to integrate the
approach into the _LoRe_ mixed-consistency programming language.

##  1\. Introduction

Nowadays, most software is distributed in one way or the other to provide
features such as collaboration, multi-device synchronization, and access to
remote information. However, it is important to ensure that such applications
do not impede the “local” functionalities due to partial failures of remote
systems. Therefore, Kleppmann et al. (2019) propose the concept of _local-
first software_ and outline a set of ideals that such software should follow.
Operationally, these ideals imply that local-first software operates under
weaker consistency models such as eventual or causal consistency. This ensures
offline availability of all operations, regardless of network connectivity.

Local-first is suitable for many collaboration use cases. However, in large
applications dealing with various concerns, stronger guarantees may be
necessary _for certain parts of the software_. For instance, in a company-wide
project management system, planning may work local-first, while budget
requests must be enforced globally to maintain the _invariant_ that total
expenses remain below a certain threshold.

In this type of setting, it is difficult to find a consistency model that
suits the entire application. Using strong consistency models, which involve
coordination, sacrifices offline availability and conflicts with the
objectives of local-first applications. At the same time, weaker models often
cannot guarantee the application’s safety requirements. The best option is to
choose a design somewhere in the middle. However, how should developers
determine the appropriate consistency model for each part of their
application? In general, combining different consistency levels is a process
that is error-prone and requires expertise in both, the application domain and
distributed systems in general.

Dedicated mixed-consistency programming models such as LoRe (Haas et al.,
2024), ConSyst (Köhler et al., 2020), Blazes (Alvaro et al., 2014), and Carol
(Lewchenko et al., 2019) provide a solution: They offer built-in support for
mixed-consistency applications through special programming abstractions and
automated reasoning. They – and hybrid consistency systems (Balegas et al.,
2018; Gotsman et al., 2016; Li et al., 2012) – typically select between two
“modes” of operation: An eventually consistent mode that allows concurrent
execution, and a strongly consistent mode, where potentially conflicting
operations are coordinated.

These systems often employ a specific baked-in technique to coordinate
operations. For example, some (Alvaro et al., 2014; Köhler et al., 2020)
employ a centralized lock manager such as _Zookeeper_ (Hunt et al., 2010),
while others (Haas et al., 2024; Lewchenko et al., 2019; Li et al., 2012;
Gotsman et al., 2016) rely on a custom token-passing algorithm. Each
coordination technique makes specific system assumptions. One technique might
be better for a large number of participants while another is more suited for
extended offline periods. The “one size fits all” approach of existing mixed-
consistency solutions, makes it hard to write a program once and then deploy
it in different settings such as geo-replicated servers vs. peer-to-peer
networks.

We argue for programmable coordination mechanisms and in this work-in-progress
report elaborate on our ongoing efforts to enhance LoRe (Haas et al., 2024)
with such mechanisms. We propose modelling coordination protocols as
replicated data types following the _Algebraic Replicated Data Types_ (ARDT)
(Kuessner et al., 2023) approach. The ARDT-based approach has several
advantages. First, they facilitate the implementation of diverse protocols
through reuse and composition of existing components while posing minimal
requirements on the network environment. Second, they enable mixing and
combining protocols in the same application, guided by application specific
system and deployment assumptions. In this paper, we focus on mutual-exclusion
protocols, but we believe that the “protocols as ARDTs” approach is general
enough to support a wide range of existing coordination protocols and simple
enough to allow distributed systems experts to implement their own protocols
or to adapt existing ones.

In Section 2, we demonstrate how to implement mutual-exclusion protocols with
ARDTs. We discuss the benefits of the approach in Section 3 and look at ideas
for future work in Section 4. Finally, we discuss related work in Section 5.

##  2\. Mutual Exclusion with ARDTs

We provide background details about Algebraic Replicated Data Types (ARDTs)
(Kuessner et al., 2023) and then demonstrate how to use them for mutual-
exclusion.

###  2.1. Algebraic Replicated Data Types

An ARDT is a (Scala) algebraic data type111Algebraic data types are types
formed by composition of other types, most notably product types such as
tuples, structs, etc., additionally equipped with a merge function that has
the lattice properties (idempotent, commutative, associative). Specifically,
any Scala type like Set[Int] can be used as long as we can implement an
instance of Lattice[Set[Int]], where the Lattice interface provides the
mentioned merge function. Developers may use these types like any other
immutable Scala data type. As expected from algebraic data types, ARDTs
compose: We can declare new data structures where each individual component is
an ARDT, and in this case, the Scala compiler can even derive a corresponding
Lattice instance automatically.

Since ARDTs are immutable, calling a method such as add on a Set does not
mutate the underlying data structure itself. Instead, the call returns a
_delta_ that represents the effect of the state mutation. A runtime system
using ARDTs can then merge these deltas with the previous value to produce the
new current value. For example, if the current state is Set(1, 2), we can add
new value by merging Set(3). Note that always merging deltas implies that some
standard Set operations have no effect in the replicated setting; notably, we
need additional data to track removals. For sets, the ARDT library provides a
suitable DotSet – where dots are globally unique timestamps that are used to
track removals.

###  2.2. Token-Based Mutual Exclusion

We start with a simple token-based mutual exclusion protocol: each critical
operation that needs to be coordinated is assigned a token, and only the
replica (represented by a unique Uid) that currently has the token may execute
the critical operation. Replicas announce that they want to obtain the token
and the current owner of a token is expected to hand it over eventually.

#### Implementing the protocol

The data type definitions of our ARDT-based implementation are shown in
Listing 1. The token consists of a statement of ownership and a set of Uids.
The ownership is represented by the current owner’s Uid along with an epoch.
The epoch is used to decide which statement of ownership to keep while merging
– we only ever keep the newest one. This is reflected in the lattice
definition for Ownership; it derives an Ownership lattice from the natural
order of the epoch (represented by a 64-bit integer value). Specifically, we
use the lexicographic ordering on the Ownership type, which sorts by epoch
first. In case the epoch for two values is the same, a fallback based on the
ordering of the Uid type is used (which is arbitrary but consistent). As Token
is simply a product of two other ARDTs (Ownership and DotSet), its Lattice can
be derived automatically – by merging individual components while preserving
the structure. With this, we have defined the state of the ARDTs and can rely
on causally consistent replication.

⬇

1case class Ownership@(epoch: Long, owner: Uid)

3

4given Lattice[Ownership] = Lattice.fromOrdering(Orderings.lexicographic)

5given Lattice[Token] = Lattice.derived

Listing 1: Code for the Token data types. Important parts are highlighted.

⬇

1case class Token(os: Ownership, wants: DotSet[Uid]):

2 val unchanged: Token = Token(Ownership.unchanged, DotSet.unchanged)

3

4 def request@(using ReplicaId, Dots): Token =

7 val deltaSet = wants.addElem(replicaId)

8 Token(Ownership.unchanged, deltaSet)

9

10 def upkeep@(using ReplicaId): Token =

15 if !isOwner then unchanged

16 else selectFrom(wants) match

17 case None => unchanged

18 case Some(nextOwner) =>

19 Token(Ownership(os.epoch + 1, nextOwner), DotSet.unchanged)

20

21 def selectFrom(wants: DotSet[Uid])(using ReplicaId) =

22 wants.elements.maxOption.filter(id => id != replicaId)

Listing 2: Code for the Token protocol. Important parts are highlighted.

Next, we discuss the operations on this ARDT that provide mutual-exclusion
semantics (Listing 5). The API for the mutual-exclusion schemes consists of
four methods: (1) isOwner is called to check if the executing replica is the
current owner and thus may enter the critical section protected by this token;
(2) request is called when a replica wants to acquire the token; (3) release
is called when a replica no longer needs the token; (4) upkeep is called
regularly, specifically after releasing, and whenever the state changes due to
updates from the network.

The isOwner method checks if the local replicaId matches the owner stored in
the current value. The using syntax is a Scala feature to pass implicit
contexts around by type; we use it here for the local replica ID (accessed
with replicaId) to denote its special status (as opposed to the ID of any
other replica). When the ownership query returns true, we assume that the
current replica is the exclusive owner of that token, thus a critical
operation protected by the token may now execute safely.

The request and release methods add/remove the current replica from the set of
wants to denote interest in ownership. They “modify” the current state by
returning a delta, i.e., a value of type Token that describes the change. To
construct the request/release delta, we use the corresponding (delta
producing) methods on DotSet and wrap the resulting delta into a token with
unchanged ownership.

The upkeep method first checks if the calling replica is the current owner. If
this is the case, we arbitrarily select a nextOwner from the set of
current.wants. Otherwise, the unchanged delta is returned. If there is a
nextOwner that was selected, we increase the ownership epoch by one and return
the tuple as a new delta (together with the unchanged/empty set since the set
current.wants does not change in the upkeep method).

#### Correctness of the protocol

For mutual exclusion, we require that _at most one replica believes it is the
current owner_. Intuitively, this is true because the upkeep method transfers
ownership from one replica to another, similar to handing over a physical
token.

We reason about ARDTs as sets of deltas and about replicas as subsets of
observed deltas. Delayed/dropped deltas are modelled by subsets and
duplication/reordering of deltas does not matter because of the lattice
properties. For correctness of the mutual exclusion protocols, we additionally
require that each delta is produced by one of the operations, i.e., there are
no (undetected) bit flips or incorrect replicas.

We can prove the stated mutual exclusion property by induction on the creation
of deltas. To this end, let us consider ownership deltas -- pairs of an epoch
(a Long) and the _target owner_ (a Uid) of that epoch. Our induction invariant
is that if there is a delta $d$ with target owner $r$, then either (1) there
is no $d^{\prime}$ with $d<d^{\prime}$ (i.e., no other delta is greater --
here: from a more recent epoch -- according to the lattice order) or (2) $r$
has observed a $d^{\prime}$ with $d<d^{\prime}$. Intuitively, there exists
exactly one greatest delta222Note that the ownership lattice is a total order,
which is not true for all lattices. for which (1) is true, and thus the target
owner has not yet observed a greater delta. For every other ownership delta,
(2) is true because the delta has a corresponding transfer that must be
visible to the owner (who did the transfer). Thus, our invariant implies
mutual exclusion: the delta as in part (1) of the invariant has the only
potential owner as its target.

We initialize the system with a delta that assigns one of the replica IDs to
be the owner in the initial epoch, which trivially fulfills the invariant. In
any system where the invariant is fulfilled, only the replica that has
observed the greatest delta $d$ can be the owner, thus produce a (non-trivial)
ownership delta $d^{\prime}$. Thus, $d^{\prime}$ is the new greatest
delta333Specifically, due to the monotonicity properties of lattices, when
operations return smaller or equal deltas (such as all the unchanged deltas)
these are immediately discarded as they do not change the current state. in
the system, and both parts of the invariant are fulfilled444Invariant part (1)
is fulfilled for $d^{\prime}$ because there is no greater delta and part (2)
is fulfilled for $d$, because $d^{\prime}$ is immediately observed by the
generating replica $r$..

This simple protocol does not guarantee progress under (permanent) node
failure. In cases where the transfer of ownership does not happen -- e.g.,
because the current owner fails permanently -- the token transfer is stuck.

###  2.3. Voting-Based Mutual Exclusion

The second mutual exclusion algorithm is a simple majority-voting approach
assuming a fixed number of participants.

⬇

5case class Vote(owner: Uid, voter: Uid)

6case class Epoch[E](counter: Time, value: E)

7case class Voting(rounds: Epoch[DotSet[Vote]])

8

9given Lattice[Voting] = Lattice.derived

Listing 3: Data type definitions for the voting protocol.

Listing 3 shows the state definition of the Voting ARDT. We support multiple
rounds of voting, represented as the Epoch type. It works similarly to the
Ownership ARDT, except that when the epoch counter of two deltas are equal, we
merge the value stored in the epoch. This allows us to contain a set of votes
within the epoch. We use the same interface of four operations for mutual
exclusion. We only give a high-level overview of their behavior below -- the
full source code can be found in the Appendix in Listing 6.

isOwner checks if the current replica is the candidate with the most votes,
and if that candidate has a majority of the votes (assuming a fixed set of
voters).

request votes for the current replica itself if there are no existing votes.
Note that this implies that it is necessary to retry requesting -- as opposed
to the Token algorithm.

upkeep either (1) transitions to the next epoch if a majority is impossible,
(2) does nothing if the replica already voted, or (3) votes for the leading
candidate.

release, if called by the current owner, increases the epoch counter, thus
starting a new round of votes.

###  2.4. From Protocols to Applications

These examples illustrate how to encode mutual exclusion as a data type. We
have also implemented a protocol inspired by Raft (Ongaro and Ousterhout,
2014) as an ARDT, using leader election and then multiple voting rounds based
on proposals by that leader.

However, the goal of our endeavour is not to reinvent mutual exclusion or
coordination protocols, rather to make them available as a composable
abstraction in a program. The discussion so far implies that the LoRe runtime
will use one of the mutual-exclusion implementations to coordinate operations
when necessary, but we could also re-use components of existing protocols as
part of the application logic. For illustration, consider the Excl[T] type
below. Given a type T, it protects values of T through the Token algorithm;
the transform method may be used to change the protected value only if the
current replica owns the token.555The Excl type would need further methods to
handle the request/release/upkeep parts of the protocol.

⬇

9case class Excl[T](token: Token, v: T):

10 def transform(f: T => T) =

11 if token.isOwner then f(v)

12 else unchanged

Listing 4: Code for the Token protocol. Important parts are highlighted.

This allows a developer to make use of the token algorithm within some larger
data type. For example, if the application has many resources (many documents
in a document management system, or many paragraphs in a single document),
then we could specify that each resource is individually mutually exclusive
(variant A below), or that all resources are protected together (variant B
below). By making Excl parametric over the algorithm, we could even choose a
different algorithm for each individual resource.

⬇

9val resourcesA: Map[Id, Excl[Resource]]

10val resourcesB: Excl[Map[Id, Resource]]

Listing 5: Code for the Token protocol. Important parts are highlighted.

To recap, our approach allows developers to essentially implement fine-grained
application-specific consistency mechanisms without having to know the details
of the inner data types. Notably, the system automatically derives the
required lattice instances for all shown data types.

##  3\. Discussion

The ARDT-based implementation of mutual-exclusion protocols offers several
benefits, because it allows separation of concerns, while ensuring correctness
at the level of the data model of the application.

#### Composability

ARDTs are algebraic data structures that are commonly used in programming
languages: structs, records, tuples. Thus, ARDTs are first-class values
compatible with existing language features such as parametric polymorphism,
pattern matching, data structures666Basic ARDT set and dictionaries (maps) are
just the Scala set/map types, and third-party libraries. Notably, all the
examples we have shown in Section 2, perform just standard Scala data-
structure manipulation that should be immediately familiar to Scala developers
-- and none of this is specific to Scala.

Building on such language features makes ARDTs composable themselves. As a
first step, we have seen how this allows to build mutual-exclusion protocols
by re-using data-structures such as the Epoch or DotSet data type. This
principle then extends to the protocol implementations themselves: While the
Voting data type from Listing 6 is essentially a single round voting
represented as a set of votes, we extend it to a multi-round mechanism by
storing it in the Epoch type that handles multiple rounds abstractly.
Similarly, (a small extension of) the Excl data type from Section 2.4 can be
used to abstract over different mutual-exclusion implementations by swapping
out that part of the data type.

By implementing locking protocols as ARDTs we separate the information on
which we base decisions from the complexities related to low-level message
passing, such as unreliability and unordered communication. For instance, in
an ARDT protocol for leader election, “I vote for X” becomes an operation on a
data type; the developer does not have to specify how this information is
expressed as a message, nor to whom the message is sent, let alone thinking
about the order between voting and other operations. As we discuss next, this
separation also facilitates support for a broad range of network protocols.

#### Minimal Network Requirements

ARDTs are a good baseline for implementing diverse protocols, because they
pose minimal requirements to the network environment. Specifically, to ensure
safety they only require message integrity -- i.e., that messages are not
modified during transit -- and to ensure progress they require at-least-once
delivery. Everything else can be handled at a higher level of abstraction,
specifically, may be handled differently by each data type used in the system.

Notably, this allows us to support diverse network scenarios from WebSockets
and “broadcast between browser tabs” to delay tolerant networks where a
message may be stored on a medium and physically transported before arriving
at its destination. Alternatively, we could still choose to send all deltas to
a central server, ending up with the standard properties of a client/server
based application with offline functionality. While not every application will
need the full range of network support, we believe that having this option _by
default_ is the only road to ensure resilience in a digital society, where
“standard communication software” should keep working even in unexpected
circumstances.

#### Simplified Causality and Consistency Tracking

In many systems, coordination happens via an external mechanism (such as off-
the-shelf lock managers) sending coordination messages independently of the
data. Thus, there is the question of dependencies (e.g., causality and the
_happens before_ relation) between coordination messages and operations that
change the data. Expressing coordination as part of data types ensures
systematic treatment: Whenever a replica sends an update that releases a
certain lock, we can be sure that this update also contains the latest updates
to the data that was protected by the lock. In addition, having one locking
ARDT per protected resource (which can be different for each resource) allows
for very fine-grained tracking of causal dependencies.

##  4\. Outlook

Our current results are a first step for future work that progresses in two
directions. The first is about how to increase flexibility and convenience by
expanding the individual ARDTs we currently have into a library of software
components to design coordination protocols. The second is about expanding the
verification infrastructure to ensure that the additional flexibility is not
invalidated by the impossibility to ensure correctness of the resulting
system.

#### Libraries of Components for Coordination

Distributed systems have trade-offs and assumptions that are interwoven with
the design of an application. Thus, choosing a fitting protocol is not only a
matter of the system or the network properties. For example, a personal note-
taking application that synchronizes between the user’s devices may simply
assume a fixed number of known devices, while a chat or microblogging
application likely needs to allow participants to join or leave regularly. The
properties that need to be reflected in the application design include:

_Topology:_ How many replicas are there? How often does the number of replicas
change? Do we allow new replicas to join the network or do we even assume a
fixed number?

_Fault-Tolerance:_ How reliable are the network connections? How long and
often are replicas unreachable?

_Delay-Tolerance:_ How important are timely updates? How resilient is the
system against stale data?

A particular mutual exclusion protocol presents a single point in the design
space on multiple of these dimensions. The example protocols from Section 2
illustrate this: The token-passing protocol can deal with arbitrarily changing
topologies, but the token is easily “lost”, causing problems with fault-
tolerance in certain scenarios. The voting protocol improves on resilience
against vanishing nodes, but assumes a fixed number of replicas, and requires
communication with a majority of those replicas. More advanced protocols like
Raft (Ongaro and Ousterhout, 2014) and Paxos (Lamport, 1998; Kraska et al.,
2013; Lamport, 2005) improve these trade-offs in some dimensions compared to
our examples, but they are still bound by fundamental limitations and trade-
offs that exist in distributed systems. Furthermore, Bailis et al. (2012) note
that even assuming causal consistency globally can lead to scalability issues,
because it leads to causal dependencies that are not required by the
application semantics.

Overall, we (1) do need the consistency mechanism to be co-designed with the
application, we (2) should be able to make different trade-offs for different
parts of the application, and (3) have those parts compose without interfering
with one another. Moreover, (4) developers should not be required to reinvent
well-established protocols and systems such as Raft, Paxos, or other systems
that already fit their requirements. We do believe that ARDTs are well-
equipped to tackle these challenges. Specifically, we envision a library of
ARDTs that implement or interact with existing mechanisms for mutual
exclusion, and other strategies for consistency. This allows reuse (4) and
different trade-offs for different parts (2), while interoperability (3) is
ensured by expressing everything as an ARDT. Additionally, we see potential in
having smaller components as part of the library, such as voting and epochs.
These should enable fine-grained integration of trade-offs into the
application design (1). However, it is still an open question how composition
of smaller components would lead to consistent results. We look at a possible
solution to this next.

#### Automatic Verification and Protocol Selection

Our initial motivation for investigating mutual exclusion protocols was as
part of the LoRe verification system, which is currently able to check which
invariants may become invalidated due to concurrent operations, and insert the
necessary coordination automatically. In future work, we will consider
extensions of this verification infrastructure that integrate with the
approach discussed so far.

First, we will use LoRe’s existing infrastructure to verify the mutual
exclusion of protocols defined as ARDTs, such as the examples in Section 2, to
guarantee using them is correct. While formal verification of such correctness
is notoriously hard, there are promising results in related work that
verifying Raft is simplified when replacing message passing with replicated
state (Lewchenko and Kaki, 2023). The reason is similar to the correctness
proof of the example in Section 2, which abstracts away many of the ordering
concerns of message passing systems, and instead reasons about possible sets
of values.

As a second step, we aim to extend LoRe’s verification to assists with the
selection of protocols. To this end, we envision extending the programming
model with annotations beyond safety invariants that enable developers to
express systems/deployment constraints. By leveraging these annotations, we
envision it feasible for automated reasoning tools to choose a fitting
protocol or to support the programmer with a pre-selection of fitting choices.

Finally, we hope that future extensions of the verification mechanism in LoRe
will be able to take custom consistency mechanisms into account. Specifically,
instead of the multiple steps of designing a mutual-exclusion mechanism,
proving it correct, and then selecting the mechanism based on certain
constraints, we want LoRe to directly prove the invariants while taking the
specific ARDTs into account. This would enable very fine-grained protocols
that do guarantee application-specific invariants, without needing to adhere
to any generic correctness or mutual-exclusion guarantees.

##  5\. Related Work

Prior work (Lewchenko and Kaki, 2023; v. Gleissenthall et al., 2019; Farzan et
al., 2022; Honoré et al., 2022) has suggested several techniques to reduce the
complexity of message-passing when reasoning about distributed protocols, with
the approach by Lewchenko and Kaki (2023) even directly relying on modelling
consensus protocols as replicated state. This line of work aims at simplifying
the verification of specific protocols (in particular of consensus protocols).
It provides supportive evidence for our goal to avoid message passing in
modelling complex protocols. In contrast, our focus is on the design of a
principled approach to implement application-specific consistency protocols,
not verify existing ones.

Mixed-consistency has also been widely studied: Lewchenko et al. (2019)
_(Carol)_ use an existing replicated data store (IPFS) and every critical
operation has to be approved by every other replica in the system. Similarly,
Houshmand and Lesani (2019) _(Hamsaz)_ statically analyse conflicts and
coordinate them either with a total order broadcast protocol based on
consensus or through a locking protocol. Alvaro et al. (2014) _(Blazes)_
propose a program-analysis framework which operates on distributed dataflows.
Based on annotations, the system infers the program’s coordination
requirements and selects one of two coordination strategies: _Ordering_
enforces a global sequential ordering of critical operations through a
Zookeeper (Hunt et al., 2010) instance. _Sealing_ tries to limit coordination
to a partition of replicas which actually produce updates that are relevant
for the critical operation in question. If such a partition is available, the
replicas belonging to the partition participate in a voting protocol to
achieve consensus over the current state. Köhler et al. (2020) _(ConSysT)_
offer an information-flow type system, which distinguishes between _low_ and
_high_ availability objects. They use centralized master replicas to
synchronize data and to manage both levels of availability. For low
availability objects, the master hands out locks to replicas, which prevent
concurrent modifications. Balegas et al. (2015) _(Indigo)_ propose a database
middleware that coordinates critical operations through multi-level locks.
They offer the locking levels _shared forbid_ , _shared allow_ , and
_exclusive allow_ , which allows or forbids replicas the execution of certain
operations. In addition, they offer escrow reservations where certain
operations create rights and other operations consume rights. As long as a
replica holds the required rights, it can execute critical operations without
coordination. _IPA_ (Balegas et al., 2018) employs automatic compensations and
rollbacks in case an invariant violation is detected. De Porre et al. (2021)
_(ECROs)_ try to reorder non-commutative operations to repair invariant
violations. In case no safe reordering can be found, they resort to
coordination. Gallifrey by Milano et al. (2019) offers mixed-consistency
through branching and merging: Non-commutative operations create new branches
which can be merged synchronously (requiring coordination) or asynchronously
(requiring developer-specified compensations in case of conflicts).

## References

  * (1)
  * Alvaro et al. (2014) Peter Alvaro, Neil Conway, Joseph M Hellerstein, and David Maier. 2014.  Blazes: Coordination Analysis for Distributed Programs. In _2014 IEEE 30th International Conference on Data Engineering_. IEEE, 52--63.  https://doi.org/10.1109/ICDE.2014.6816639
  * Bailis et al. (2012) Peter Bailis, Alan Fekete, Ali Ghodsi, Joseph M. Hellerstein, and Ion Stoica. 2012.  The Potential Dangers of Causal Consistency and an Explicit Solution. In _Proceedings of the Third ACM Symposium on Cloud Computing_ _(SoCC ’12)_. Association for Computing Machinery, New York, NY, USA, 1--7.  https://doi.org/10.1145/2391229.2391251
  * Balegas et al. (2018) Valter Balegas, Sérgio Duarte, Carla Ferreira, Rodrigo Rodrigues, and Nuno Preguiça. 2018.  IPA: Invariant-Preserving Applications for Weakly Consistent Replicated Databases.  _Proceedings of the VLDB Endowment_ 12, 4 (Dec. 2018), 404--418.  https://doi.org/10.14778/3297753.3297760
  * Balegas et al. (2015) Valter Balegas, Sérgio Duarte, Carla Ferreira, Rodrigo Rodrigues, Nuno Preguiça, Mahsa Najafzadeh, and Marc Shapiro. 2015.  Putting Consistency Back into Eventual Consistency.  _Proceedings of the Tenth European Conference on Computer Systems - EuroSys ’15_ (2015), 1--16.  https://doi.org/10.1145/2741948.2741972
  * De Porre et al. (2021) Kevin De Porre, Carla Ferreira, Nuno Preguiça, and Elisa Gonzalez Boix. 2021.  ECROs: Building Global Scale Systems from Sequential Code.  _Proceedings of the ACM on Programming Languages_ 5, OOPSLA (Oct. 2021), 107:1--107:30.  https://doi.org/10.1145/3485484
  * Farzan et al. (2022) Azadeh Farzan, Dominik Klumpp, and Andreas Podelski. 2022.  Sound Sequentialization for Concurrent Program Verification. In _Proceedings of the 43rd ACM SIGPLAN International Conference on Programming Language Design and Implementation_ _(PLDI 2022)_. Association for Computing Machinery, New York, NY, USA, 506--521.  https://doi.org/10.1145/3519939.3523727
  * Gotsman et al. (2016) Alexey Gotsman, Hongseok Yang, Carla Ferreira, Mahsa Najafzadeh, and Marc Shapiro. 2016.  ’Cause I’m Strong Enough: Reasoning About Consistency Choices in Distributed Systems. In _Proceedings of the 43rd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages_. ACM, New York, NY, USA, 371--384.  https://doi.org/10.1145/2837614.2837625
  * Haas et al. (2024) Julian Haas, Ragnar Mogk, Elena Yanakieva, Annette Bieniusa, and Mira Mezini. 2024.  LoRe: A Programming Model for Verifiably Safe Local-first Software.  _ACM Transactions on Programming Languages and Systems_ 46, 1 (Jan. 2024), 2:1--2:26.  https://doi.org/10.1145/3633769
  * Honoré et al. (2022) Wolf Honoré, Ji-Yong Shin, Jieung Kim, and Zhong Shao. 2022.  Adore: Atomic Distributed Objects with Certified Reconfiguration. In _Proceedings of the 43rd ACM SIGPLAN International Conference on Programming Language Design and Implementation_ _(PLDI 2022)_. Association for Computing Machinery, New York, NY, USA, 379--394.  https://doi.org/10.1145/3519939.3523444
  * Houshmand and Lesani (2019) Farzin Houshmand and Mohsen Lesani. 2019.  Hamsaz: Replication Coordination Analysis and Synthesis.  _Proceedings of the ACM on Programming Languages_ 3, POPL (Jan. 2019), 74:1--74:32.  https://doi.org/10.1145/3290387
  * Hunt et al. (2010) Patrick Hunt, Mahadev Konar, Flavio P. Junqueira, and Benjamin Reed. 2010.  ZooKeeper: Wait-free Coordination for Internet-scale Systems. In _2010 USENIX Annual Technical Conference (USENIX ATC 10)_.  https://www.usenix.org/conference/usenix-atc-10/zookeeper-wait-free-coordination-internet-scale-systems
  * Kleppmann et al. (2019) Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. 2019.  Local-First Software: You Own Your Data, in Spite of the Cloud. In _Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software_ _(Onward! 2019)_. Association for Computing Machinery, New York, NY, USA, 154--178.  https://doi.org/10.1145/3359591.3359737
  * Köhler et al. (2020) Mirko Köhler, Nafise Eskandani, Pascal Weisenburger, Alessandro Margara, and Guido Salvaneschi. 2020.  Rethinking Safe Consistency in Distributed Object-Oriented Programming.  _Proceedings of the ACM on Programming Languages_ 4, OOPSLA (2020), 188:1--188:30.  https://doi.org/10.1145/3428256
  * Kraska et al. (2013) Tim Kraska, Gene Pang, Michael J. Franklin, Samuel Madden, and Alan Fekete. 2013.  MDCC: Multi-Data Center Consistency. In _Proceedings of the 8th ACM European Conference on Computer Systems_ _(EuroSys ’13)_. Association for Computing Machinery, New York, NY, USA, 113--126.  https://doi.org/10.1145/2465351.2465363
  * Kuessner et al. (2023) Christian Kuessner, Ragnar Mogk, Anna-Katharina Wickert, and Mira Mezini. 2023.  Algebraic Replicated Data Types: Programming Secure Local-First Software. In _37th European Conference on Object-Oriented Programming (ECOOP 2023)_ _(Leibniz International Proceedings in Informatics (LIPIcs), Vol. 263)_. Schloss Dagstuhl -- Leibniz-Zentrum für Informatik, Dagstuhl, Germany, 14:1--14:33.  https://doi.org/10.4230/LIPIcs.ECOOP.2023.14
  * Lamport (1998) Leslie Lamport. 1998.  The Part-Time Parliament.  _ACM Transactions on Computer Systems_ 16, 2 (May 1998), 133--169.  https://doi.org/10.1145/279227.279229
  * Lamport (2005) Leslie Lamport. 2005.  _Generalized Consensus and Paxos_.  Technical Report.  https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2005-33.pdf
  * Lewchenko and Kaki (2023) Nicholas V Lewchenko and Gowtham Kaki. 2023.  Distributed Consensus Algorithms as Replicated State Applications. In _Proceedings of the 10th Workshop on Principles and Practice of Consistency for Distributed Data_ _(PaPoC ’23)_.
  * Lewchenko et al. (2019) Nicholas V Lewchenko, Arjun Radhakrishna, Akash Gaonkar, and Pavol Černý. 2019.  Sequential Programming for Replicated Data Stores.  _Proceedings of the ACM on Programming Languages_ 3, ICFP (July 2019), 106:1--106:28.  https://doi.org/10.1145/3341710
  * Li et al. (2012) Cheng Li, Daniel Porto, Allen Clement, Johannes Gehrke, Nuno Preguic, and Rodrigo Rodrigues. 2012.  Making Geo-Replicated Systems Fast as Possible, Consistent When Necessary.  _OSDI’12 Proceedings of the 10th USENIX conference on Operating Systems Design and Implementation_ (2012), 265--278.
  * Milano et al. (2019) Mae Milano, Rolph Recto, Tom Magrino, and Andrew C Myers. 2019.  A Tour of Gallifrey, a Language for Geodistributed Programming. In _3rd Summit on Advances in Programming Languages (SNAPL 2019)_ , Vol. 136. Schloss Dagstuhl--Leibniz-Zentrum fuer Informatik, Dagstuhl, Germany, 11:1--11:19.  https://doi.org/10.4230/LIPIcs.SNAPL.2019.11
  * Ongaro and Ousterhout (2014) Diego Ongaro and John Ousterhout. 2014.  In Search of an Understandable Consensus Algorithm. In _2014 USENIX Annual Technical Conference (USENIX ATC 14)_. USENIX Association, Philadelphia, PA, 305--319.  https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro
  * v. Gleissenthall et al. (2019) Klaus v. Gleissenthall, Rami Gökhan Kıcı, Alexander Bakst, Deian Stefan, and Ranjit Jhala. 2019.  Pretend Synchrony: Synchronous Verification of Asynchronous Distributed Programs.  _Proceedings of the ACM on Programming Languages_ 3, POPL (Jan. 2019), 59:1--59:30.  https://doi.org/10.1145/3290372

⬇

12case class Voting(rounds: Epoch[DotSet[Vote]]):

13

14 def request@(using ReplicaId, Dots): Voting =

19 if !rounds.value.isEmpty then Voting.unchanged

20 else voteFor(replicaId)

21

22 def upkeep@(using ReplicaId, Dots): Voting =

28 val (id, count) = leadingCount

29 if checkIfMajorityPossible(count)

30 then voteFor(id)

31 else forceRelease

32

33 def forceRelease(using ReplicaId): Voting =

34 Voting(Epoch(rounds.counter + 1, DotSet.empty))

35

36 def voteFor(uid: Uid)(using ReplicaId, Dots): Voting =

37 if rounds.value.elements.exists { case Vote(id, _) => id == replicaId }

38 then Voting.unchanged // already voted!

39 else

40 val newVote = rounds.value.addElem(Vote(uid, replicaId))

41 newVote.map(rs => Voting(rounds.write(rs)))

42

43 def checkIfMajorityPossible(count: Int): Boolean =

44 val totalVotes = rounds.value.elements.size

45 val remainingVotes = Voting.participants - totalVotes

46 (count + remainingVotes) > Voting.threshold

47

48 def leadingCount(using ReplicaId): (Uid, Int) =

49 val votes: Set[Vote] = rounds.value.elements

50 votes.groupBy(_.owner).map((o, elems) => (o, elems.size)).maxBy((o, size)
=> size)

51

52object Voting:

53

54 val unchanged: Voting = Voting(Epoch.empty)

55

56 given Lattice[Voting] = Lattice.derived

57

58 val participants = 5

59 val threshold = (participants / 2) + 1

Listing 6: Code for the Voting protocol.


* Reiter (2018) Ehud Reiter. 2018.  A structured review of the validity of bleu.  _Computational Linguistics_ , 44(3):393–401.
  * Roitman et al. (2020) Haggai Roitman, Guy Feigenblat, Doron Cohen, Odellia Boni, and David Konopnicki. 2020.  Unsupervised dual-cascade learning with pseudo-feedback distillation for query-focused extractive summarization.  In _Proceedings of The Web Conference 2020_ , pages 2577–2584.
  * Rush et al. (2015) Alexander M Rush, Sumit Chopra, and Jason Weston. 2015.  A neural attention model for abstractive sentence summarization.  In _Proceedings of the 2015 Conference on Empirical Methods in Natural Language Processing_ , pages 379–389.
  * Sanh et al. (2021) Victor Sanh, Albert Webson, Colin Raffel, Stephen H Bach, Lintang Sutawika, Zaid Alyafeai, Antoine Chaffin, Arnaud Stiegler, Teven Le Scao, Arun Raja, et al. 2021.  Multitask prompted training enables zero-shot task generalization.  _arXiv preprint arXiv:2110.08207_.
  * Savery et al. (2020) Max Savery, Asma Ben Abacha, Soumya Gayen, and Dina Demner-Fushman. 2020.  Question-driven summarization of answers to consumer health questions.  _Scientific Data_ , 7(1):1–9.
  * See et al. (2017) Abigail See, Peter J Liu, and Christopher D Manning. 2017.  Get to the point: Summarization with pointer-generator networks.  In _Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers)_ , pages 1073–1083.
  * Song et al. (2019) Kaitao Song, Xu Tan, Tao Qin, Jianfeng Lu, and Tie-Yan Liu. 2019.  Mass: Masked sequence to sequence pre-training for language generation.  In _International Conference on Machine Learning_ , pages 5926–5936.
  * Su et al. (2020) Dan Su, Yan Xu, Tiezheng Yu, Farhad Bin Siddique, Elham J Barezi, and Pascale Fung. 2020.  Caire-covid: a question answering and query-focused multi-document summarization system for covid-19 scholarly information management.  _arXiv preprint arXiv:2005.03975_.
  * Su et al. (2021) Dan Su, Tiezheng Yu, and Pascale Fung. 2021.  Improve query focused abstractive summarization by incorporating answer relevance.  _arXiv preprint arXiv:2105.12969_.
  * Sutskever et al. (2014) Ilya Sutskever, Oriol Vinyals, and Quoc V Le. 2014.  Sequence to sequence learning with neural networks.  In _Advances in Neural Information Processing Systems_ , pages 3104–3112.
  * Tay et al. (2020) Yi Tay, Mostafa Dehghani, Dara Bahri, and Donald Metzler. 2020.  Efficient transformers: A survey.  _arXiv preprint arXiv:2009.06732_.
  * Vaswani et al. (2017) Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017.  Attention is all you need.  In _Advances in Neural Information Processing Systems_ , pages 5998–6008.
  * Vig et al. (2021) Jesse Vig, Alexander R Fabbri, and Wojciech Kryściński. 2021.  Exploring neural models for query-focused summarization.  _arXiv preprint arXiv:2112.07637_.
  * Wan and Xiao (2009) Xiaojun Wan and Jianguo Xiao. 2009.  Graph-based multi-modality learning for topic-focused multi-document summarization.  In _Twenty-First International Joint Conference on Artificial Intelligence_.
  * Wan and Zhang (2014) Xiaojun Wan and Jianmin Zhang. 2014.  Ctsum: extracting more certain summaries for news articles.  In _Proceedings of the 37th International ACM SIGIR Conference on Research and Development in Information Retrieval_ , pages 787–796.
  * Wang et al. (2008) Dingding Wang, Shenghuo Zhu, Tao Li, Yun Chi, and Yihong Gong. 2008.  Integrating clustering and multi-document summarization to improve document understanding.  In _Proceedings of the 17th ACM Conference on Information and Knowledge Management_ , pages 1435–1436.
  * Wang et al. (2007) Mengqiu Wang, Noah A Smith, and Teruko Mitamura. 2007.  What is the jeopardy model? a quasi-synchronous grammar for qa.  In _Proceedings of the 2007 Joint Conference on Empirical Methods in Natural Language Processing and Computational Natural Language Learning_.
  * Wang et al. (2020) Sinong Wang, Belinda Z Li, Madian Khabsa, Han Fang, and Hao Ma. 2020.  Linformer: Self-attention with linear complexity.  _arXiv preprint arXiv:2006.04768_.
  * Wang et al. (2018) Yizhong Wang, Kai Liu, Jing Liu, Wei He, Yajuan Lyu, Hua Wu, Sujian Li, and Haifeng Wang. 2018.  Multi-passage machine reading comprehension with cross-passage answer verification.  In _Proceedings of the 56th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers)_ , pages 1918–1927.
  * Wolf et al. (2019) Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Rémi Louf, Morgan Funtowicz, Joe Davison, Sam Shleifer, Patrick von Platen, et al. 2019.  HuggingFace’s Transformers: State-of-the-art natural language processing.  _ArXiv_ , abs/1910.03771.
  * Xenouleas et al. (2019) Stratos Xenouleas, Prodromos Malakasiotis, Marianna Apidianaki, and Ion Androutsopoulos. 2019.  Sum-qe: a bert-based summary quality estimation model.  In _Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP)_ , pages 6005–6011.
  * Xie et al. (2020) Yujia Xie, Tianyi Zhou, Yi Mao, and Weizhu Chen. 2020.  Conditional self-attention for query-based summarization.  _arXiv preprint arXiv:2002.07338_.
  * Xu and Lapata (2020a) Yumo Xu and Mirella Lapata. 2020a.  Abstractive query focused summarization with query-free resources.  _arXiv preprint arXiv:2012.14774_.
  * Xu and Lapata (2020b) Yumo Xu and Mirella Lapata. 2020b.  Coarse-to-fine query focused multi-document summarization.  In _Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP)_ , pages 3632–3645.
  * Xu and Lapata (2021) Yumo Xu and Mirella Lapata. 2021.  Text summarization with latent queries.  _arXiv preprint arXiv:2106.00104_.
  * Yang et al. (2015) Yi Yang, Wen-tau Yih, and Christopher Meek. 2015.  WikiQA: A challenge dataset for open-domain question answering.  In _Proceedings of the 2015 Conference on Empirical Methods in Natural Language Processing_ , pages 2013–2018.
  * Yao et al. (2015) Jin-ge Yao, Xiaojun Wan, and Jianguo Xiao. 2015.  Compressive document summarization via sparse optimization.  In _Twenty-Fourth International Joint Conference on Artificial Intelligence_.
  * Yao et al. (2017) Jin-Ge Yao, Xiaojun Wan, and Jianguo Xiao. 2017.  Recent advances in document summarization.  _Knowledge and Information Systems_ , 53(2):297–336.
  * Young et al. (2017) Tom Young, Devamanyu Hazarika, Soujanya Poria, and Erik Cambria. 2017.  Recent trends in deep learning based natural language processing.  _arXiv preprint arXiv:1708.02709_.
  * Yu et al. (2012) Xiaohui Yu, Yang Liu, Xiangji Huang, and Aijun An. 2012.  Mining online reviews for predicting sales performance: A case study in the movie domain.  _IEEE Transactions on Knowledge and Data Engineering_ , 24(4):720–734.
  * Yuan et al. (2021) Weizhe Yuan, Graham Neubig, and Pengfei Liu. 2021.  Bartscore: Evaluating generated text as text generation.  _arXiv preprint arXiv:2106.11520_.
  * Zaheer et al. (2020) Manzil Zaheer, Guru Guruganesh, Avinava Dubey, Joshua Ainslie, Chris Alberti, Santiago Ontanon, Philip Pham, Anirudh Ravula, Qifan Wang, Li Yang, et al. 2020\.  Big bird: Transformers for longer sequences.  _arXiv preprint arXiv:2007.14062_.
  * Zhang et al. (2019a) Jingqing Zhang, Yao Zhao, Mohammad Saleh, and Peter J Liu. 2019a.  Pegasus: Pre-training with extracted gap-sentences for abstractive summarization.  _arXiv preprint arXiv:1912.08777_.
  * Zhang et al. (2019b) Tianyi Zhang, Varsha Kishore, Felix Wu, Kilian Q Weinberger, and Yoav Artzi. 2019b.  Bertscore: Evaluating text generation with bert.  In _International Conference on Learning Representations_.
  * Zhong et al. (2021) Ming Zhong, Da Yin, Tao Yu, Ahmad Zaidi, Mutethia Mutuma, Rahul Jha, Ahmed Hassan, Asli Celikyilmaz, Yang Liu, Xipeng Qiu, et al. 2021.  Qmsum: A new benchmark for query-based multi-domain meeting summarization.  In _Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 5905–5921.
  * Zhong et al. (2015) Sheng-hua Zhong, Yan Liu, Bin Li, and Jing Long. 2015.  Query-oriented unsupervised multi-document summarization via deep learning model.  _Expert Systems with Applications_ , 42(21):8146–8155.
  * Zhou et al. (2021) Guangyou Zhou, Zhiwen Xie, Zongfu Yu, and Jimmy Xiangji Huang. 2021.  Dfm: A parameter-shared deep fused model for knowledge base question answering.  _Information Sciences_ , 547:103–118.


2021 xx March 2018

# A Novel Readout Scheme for Muon Tomography Application in Material
Identification

Subhendu Das  1,2 Sridhar Tripathy  1,2 Sandip Sarkar  1,2  Nayana Majumdar1,2
and Supratik Mukhopadhyay1,2  1Saha Institute of Nuclear Physics, Kolkata,
INDIA  2Homi Bhabha National Institute, Mumbai, INDIA

(xx January 2018)

###### Abstract

This work reports a cost-effective, multi-parameter readout and data-
acquisition system for a muon scattering tomography system based on Resistive
Plate Chambers (RPCs). Initial test measurements with a prototype Resistive
Plate Chamber were performed using a low-cost FPGA coupled to the NINO ASIC
for the event selection and handling data. The Time over-Threshold (TOT)
property of NINO ASICs has been used to achieve better position information
and achieve precise tracking capability. In our test setup, we try to build an
imaging setup using a single RPC and lead block, which covers some areas of
RPC. A glass RPC of dimension 30cm x 30cm, filled with a gas mixture of 95%
Freon and 5% Isobutane, equipped with two orthogonal panels of readout strips
of width 3 cm and pitch 3.2 cm, has been operated.

###### keywords:

Muon tomographyMuographyDetector Development xxxx/xxxxxxxx

††journal: JAIS-ID

##  1 Introduction

Muon tomography is a system for material identification utilizing multiple
Coulomb scattering suffered by cosmic ray muons while passing through a
matter. The resultant deflection from the original trajectory can be
represented by a Gaussian distribution dependent on several physical
properties of the matter and also the muon momentum. Thus the measurement of
the scattering angle by tracking the pre and post-interaction muon
trajectories enables one to identify the material.

Figure 1: Schamatic diagram of muon tomography system

We plan to use Resistive Plate Chambers (RPCs) for tracking muons before and
after their interaction. The Resistive Plate Chamber (RPC) is one of the most
popular gaseous detectors which is suitable for this purpose due to its simple
design, ease of construction, cost-effectiveness, along very good temporal,
spatial resolutions, and detection efficiency. The spatial resolution of the
RPC determines the precision in tracking and hence the quality of image
formation.

An FPGA-based multi-parameter data acquisition system has been developed in
this context for the collection of position information and subsequent track
reconstruction. FPGA-based DAQ system is a simple low-cost multi-parameter
scalable data acquisition system. This is useful for any kind of particle
tracking experiment and imaging application.

##  2 Readout Scheme

The tracking setup consists of some important components. A complete schematic
diagram of the DAQ has been shown in figure 2. NINO ASICs are used as front-
end electronics and FPGA in the back-end for storing the data. VHDL and Python
language are used to program FPGA and for acquiring the data respectively.
These components have been briefly described below.

Figure 2: Schematic diagram of the Data Acquisition System (DAQ)

###  2.1 Front-end Electronics

NINO ASICs are used as readout electronics, which is an ultra-fast front-end
preamplifier discriminator chip that has been developed for use in the ALICE
TOF detector. This ASIC chip has eight channels, each channel accepts signals
from the detector and provides LVDS (Low Voltage Differential Signal) output.
The output pulse width is dependent on the input signal charge and threshold
value of NINO. Using this NINO ASIC, INO Collaboration developed a board that
has been used for muon tracking experiments. This board also has eight
channels and an adjustable threshold regulator.

Figure 3: NINO Board

###  2.2 Back-end Electronics

For such front-end a suitable back-end and Acquisition is required that can
handle fast incoming LVDS signals from the NINO. For such a system FAGA is
very useful due to its large number of I/O, availability, and cost-
effectiveness. FPGA is a fabricated silicon device that can be electrically
programmed to become almost any kind of digital circuit or system. FPGA can be
considered as a simple logic device or a complete application. It contains
thousands of logic elements that can be wired in different configurations
according to the logical requirements of the application.

Figure 4: FPGA board with connector

Intel MAX10 FPGA has been used for this purpose due to its capability of
accepting LVDS signals as input and high bandwidth. The MAX 10 development
board is a compact FPGA development platform developed by TIFR. The board
contains Intel MAX 10 FPGA with 2000 Logic Elements (LEs), 108 memory blocks,
101 I/O pins, and a 50 MHz onboard clock. A connector board has been designed
to map LVDS connections between NINO and FPGA board with the required 100
$\Omega$ termination resistance.

###  2.3 Software Implementation

As discussed above FPGA is programmable hardware so the programming of FPGA is
an important task for this experiment. VHDL and Verilog are two hardware
description languages that are used to program FPGA. For this purpose, VHDL is
used as a programming language and Quartus prime software has been used to
compile and upload code to FPGA. UART protocol has been used to transfer data
from FPGA to the computer, which has been implemented on FPGA. To measure the
TOT output of NINO, a 500 MHz clock has been generated using a Phase-Locked
Loop (PLL). This clock helps to measure TOT with a maximum probable inaccuracy
of 2 ns. FPGA is programmed similar to an oscilloscope, a temporary FIFO
memory is used to store NINO input. A controller, which sends the trigger
signal for each nuon event to transmit the NINO data through the UART module
which stands for Universal Asynchronous Receiver/Transmitter. This data flow
algorithm has been implemented for all input channels inside the FPGA. The
schematic workflow of the FPGA has been illustrated in figure 5

Figure 5: Schematic diagram of the operation inside the FPGA

Python programming language has been used to acquire data on PC using COM port
and also for analysis and extracting position information of the muon track.
The data contains strip hits and the pulse width of each channel of each
NINOs. Input strips orientation is required to map the exact hit position.

##  3 Tests of the Read-out System

To verify the tracking capability, an experimental setup has been designed for
this readout system. One RPC detector, one FPGA Development Board, and two
NINO boards have been used for this test setup. The position of incoming
cosmic muon has been detected by using a test area of 8X8 strips of RPC
detector. The detector configuration and readout strips connections are shown
in figure and figure respectively.

Figure 6: Image of the experimental setup

###  3.1 Description of Test Setup

In our test setup, a glass-RPC of dimension 30cm x 30cm, filled with a gas
mixture of 95% Freon and 5% Isobutane, equipped with two orthogonal panels of
readout strips of width 3 cm and pitch 3.2 cm, has been operated. An 8-channel
ultra-fast front-end preamplifier discriminator chip NINO has been used to
obtain Time-Over-Threshold (TOT) outputs corresponding to the current signals
induced on the readout strips due to a muon event. For each readout plane, 1
NINO board has been connected to acquire signals from 8 strips. Total 16
strips and two NINOs have been used to cover 8 $\times$ 8 strips
configuration. Each NINO chip provides as outputs 8 pairs of LVDS (Low Voltage
Differential Signalling) signals which are suitable for low-power, high-speed
transmission with better noise immunity. For parallel post-processing and to
take advantage of this LVDS scheme, we have used an FPGA development board
with ALTERA MAX 10, which has dedicated pins for the direct acquisition of
LVDS analog signals. The FPGA is programmed to transfer the acquired data to
the computer using the UART protocol. The RPC data for muon events as
collected by the present readout scheme have been analyzed to estimate the
position information. The RPC has been placed in a horizontal plane to
maximize cosmic ray interaction. Two plastic scintillators with an overlapped
region that covers nearly 25 cm $\times$ 35 cm of the readout strips of the
RPC used as muon trigger. A lead block of dimension 12 cm $\times$ 10 cm
$\times$ 15 cm has been placed 6 cm above the middle of RPC. The image of the
experimental setup has been shown in figure 6.

###  3.2 Test Results

In our tracking experiment, multiple numbers of event data from two NINOs have
been used to get hit information along X and Y direction, so from this data
particle position in the 2D plane of dimension, 8x8 can be extracted. The
weighted mean position has been used for the multiple hit events. The valid
events have been filtered out using the strip hit and pulse width information.
For simplicity, Only avalanche events have been used for muon tracking. The
event with greater than four strip hits has been treated as a streamer event
and the event single-sided hit has been excluded from muon track. The hit
points have been put into 8 $\times$ 8 pixels for both background hits and
hits using lead block in line of muon tracks. The absorbed muon has been
calculated by subtracting absorbed data from background hits. Similar studies
have been carried out using the different positions of lead block middle and
edge of the RPC. The experimental data for muon absorption pattern for two
different positions have been shown in figure 7.

Figure 7: Experimental Muon Absorption

##  4 Comparison with Geant4 Simulation

In order to verify our experimental absorbed data by the lead block, a
simulation study has been carried out by Geant4 07  library, which is a well-
known simulation package for high energy and particle physics simulation.

A model, similar to our experimental setup containing one position-sensitive
gaseous ionization detector for detecting the muons has been constructed in
Geant4. The setup has been subjected to a limited exposure of the cosmic muon
flux received at the sea level using Cosmic Ray Library (CRY) 08 . The hits
obtained from the detector have been used to get the absorption pattern.

FTFP_BERT physics list has been used to propagate the particles throughout the
lead and detector. It takes care of all the electromagnetic and weak
interactions of the charged particles and gamma radiations. The hit
information from the detectors has then been extracted from the muon track.

###  4.1 Simulation Result

The images produced by the setup have been described above, The images have
been segmented into 8 $\times$ 8 pixels, each having an area of 3.2 $\times$
3.2 $cm^{2}$. Similar to the experimental method every hit point has been put
into 8 $\times$ 8 pixels for both cases. The absorbed muon has been calculated
by subtracting absorbed data from background hits for two different positions
of the lead block. The simulated data for muon absorption pattern for two
different positions have been shown in figure 8.

Figure 8: Simulated Muon Absorption

##  5 Conclusions

The FPGA-based DAQ prototype has been tested with NINO and RPC detector using
cosmic muon. The position of muon hit has been detected by using this DAQ. The
experimental results are similar to the simulated result. To get a better
position resolution, the authors have the plan to use a readout with a thinner
width and separation gap.

## Acknowledgements

The authors are thankful to Mr. Shaibal Saha and other members of our
laboratory for the experimental support and advice. The authors are extremely
grateful to the INO Collaboration for the support in electronics also thankful
to ANP Division, SINP, UGC and Govt. of India.

## References

  * [1] S. Tripathy et al., JINST 15, C11013 (2020)
  * [2] G. Jonkmans et al., Ann. Nucl. Energy 53, 267 (2013).
  * [3] K.N. Borozdin et al., Nature 442, 277 (2003).
  * [4] H.A. Bethe, Phys. Rev. 89, 1256 (1953).
  * [5] V.L. Highland, Nucl. Instrum. Meth. 129, 497 (1975).
  * [6] G.R. Lynch and O.I. Dahl, Nucl. Instrum. Meth. B 58, 6 (1991).
  * [7] GEANT4 collaboration, Nucl. Instrum. Meth. A 506, 250 (2003).
  * [8] C. Hagmann et al., IEEE Nuclear Science Symposium Conference Record, 1143–1146 (2007).


# An Overview of Robotic Grippers

## Authors

Mr Thomas J. Cairnes is a PhD candidate at University of Bristol. His main
area of research is the grasping and perception of soft, deformable objects
with underactuated hands<EMAIL_ADDRESS>
Mr Christopher J. Ford is a PhD candidate at the University of Bristol. His
research interests are focused on the use of tactile perception and feedback
for real-time grasping and manipulation of multi-fingered robotic hands.
<EMAIL_ADDRESS>
Dr Efi Psomopoulou is an Assistant Professor in the Dept. of Engineering
Mathematics at the University of Bristol. Her research interests are physical
robot interaction, grasping and manipulation<EMAIL_ADDRESS>
Prof. Nathan Lepora is a Professor of Robotics and AI in the Dept. of
Engineering Mathematics at the University of Bristol. His research interests
are robot dexterity, biomimetics and tactile sensing<EMAIL_ADDRESS>
##  I Introduction

The development of robotic grippers is driven by the need to execute
particular manual tasks or meet specific objectives in handling operations.
Grippers with specific functions vary from being small, accurate and highly
controllable such as the surgical tool effectors of the Da Vinci robot
(designed to be used as non-invasive grippers controlled by a human operator
during keyhole surgeries) to larger, highly controllable grippers like the
Shadow Dexterous Hand (designed to recreate the hand motions of a human).
Additionally, there are less finely controllable grippers, such as the iRobot-
Harvard-Yale (iHY) Hand or Istituto Italiano di Tecnoglia-Pisa (IIT-Pisa)
Softhand, which instead leverage natural motions during grasping via designs
inspired by observed bio-mechanical systems.

As robotic systems become more autonomous and widely used, it is becoming
increasingly important to consider the design, form and function of robotic
grippers.

##  II Basics of Robotic Grippers

While the designs of robotic grippers are varied, there are common descriptors
that can be used to separate them into groups that are informative about their
operating principles.

Anthropomimetic grippers aim to replicate the motion of the human hand, and
are inspired by the success of human dexterity to provide a familiar reference
point for intended motion. Alternatively, biomimetic but non-anthropomimetic
grippers take inspiration from other bio-mechanical structures to inform their
motion and control. Lastly, there are non-biomimetic grippers. This category
has not been investigated as much as grippers inspired by the huge range of
diversity in natural organisms but still provides examples of effective
grippers.

There are four general types of actuation in modern robotic grippers:
pneumatic grippers driven by compressed air, hydraulic grippers driven by
compressed fluid, electric grippers using motors and vacuum grippers relying
on some form of suction.

As mentioned in the introduction, it is important to consider grippers in two
overarching categories: Fully Actuated or Underactuated grippers. These terms
indicate the degree of control that can be expected from a gripper. A fully-
actuated gripper has every Degree of Freedom (DOF) directly controlled by a
motor or other actuation mechanism. Conversely, an underactuated gripper has
only some DOFs actively controlled while the rest react passively according to
the mechanical structure of the gripper.

Figure 1: Examples of Robotic Grippers. a) The Yale Openhand Model O: A
3-fingered anthropomimetic hand open-sourced from customising the iHY Hand and
developed at Yale University (Dollar et al 2017). b) The SDM Hand: A
4-fingered anthropomimetic gripper utilising compliant passive joints,
developed at Harvard University (Dollar et al 2007). c) The Shadow Dexterous
Hand: A fully actuated 5-fingered anthropomorphic hand developed by the Shadow
Robotics Company. d) The Pisa/IIT Softhand: A 5-fingered anthropomorphic hand
utilising rigid-passive links and a single actuator to achieve grasps; this
version has a biomimetic tactile fingertip developed at Bristol Robotic
Laboratory (Lepora  et al. 2021). e) A gecko-nspired adhesive gripper: A
biomimetic gripper developed to utilise electro-static forces to adhere to
objects, developed at the University of California (Glick et al 2018). f) An
inchworm-inspired soft gripper: The claws mimic the muscle structure of an
inchworm for climbing robots, developed in Guangdong University China (Li et
al 2017). g) A Universal Jamming Gripper: A gripper designed to use the unique
jamming properties of granular materials to grasp a range of objects,
developed at Cornell University (Brown et al 2010). h) An Origami-inspired
folding gripper: This gripper uses rigid-flexible links to grasp, developed at
The Harbin Institute of Technology (Liang et al 2021)

The simplest robotic grippers are fully actuated two-DOF grippers, often
referred to as parallel jaw grippers. The earliest was mounted on the Stanford
Arm (1969) and was originally hydraulic but later operated through DC motors.
In the following decades, industrialised adaptations of parallel jaw grippers
have been used widely in various picking and packing applications and are
still widely used today because of how straightforward and capable they are to
use.

### Anthropomimetic Grippers

This section focuses on anthropomimetic grippers, i.e. grippers that use
opposing multi-jointed fingers to form grasps similar to those humans may
perform.

An early example of an anthropomimetic gripper was the Graspar hand (1996), a
3-fingered hand comprised of mostly passive joints driven by an internal
pulley system. The Schunk and Barret 3-fingered hands (2007) were rigid and
fully actuated. This made them very controllable, however they had issues when
applied to a wide range of objects as their motions required precise control
of every joint, which made them difficult to control. These hands relied
almost exclusively on power grasps; i.e. grasps where the hand seeks to
completely envelope an object, as opposed to a precision grasp where contact
with the object is made with the fingertips of the hand.

A desire for smooth anthropomimetic motions to reduce control complexity, led
to underactuated hands utilising compliant passive joints. The 4-fingered
Shape Deposition Manufacturing (SDM) Hand (2010) was constructed almost
entirely of soft compliant materials all driven by a single motor. Its design
focused on creating anthropomimetic power grasps that maximise contact between
the fingers and an object, with the finger configuration resembling two soft,
compliant parallel jaw grippers. Passive, dislocatable joints enabled hand
designs that could produce natural and stable power grasps. In this way, one
joint may stop moving after making contact with an object, and the connected
joints in the chain can continue to move with the actuation until they contact
the object. This produces a grasp that maximises the contact area without
prior knowledge of the object, which is a property commonly referred to as
being adaptive.

There then followed hands optimised for power grasps using passive joints such
as Robotiq’s Adaptive Gripper (2013) and Kinova’s Jaco (2013). However, those
adaptive grippers were still fairly rigid in construction and had not
capitalised on the strengths shown by the SDM hand.

Consequently, the iHY Hand (2013) was designed for a range of specific tasks
to be achieved, not just grasping objects. This additional functionality
required the ability to perform precision and power grasps, requiring
individually actuated fingers and enough rigidity to perform tasks like
flicking switches. The iHY utilised 5 motors but was underactuated as it still
had 8 DOFs, making use of a rigid-flexible construction for compliant fingers.
The iHY hand was well suited for research applications, being simply
fabricated, and was open sourced as the GRABLAB Model-O while additionally
being commercialized as the Reflex Hand from RightHand Robotics.

Full anthropomorphism is achieved when a hand is 5-fingered, for example, the
Pisa/IIT SoftHand (2014) is a semi-soft, underactuated gripper intended to be
easily controllable whilst also applicable to a variety of grasping tasks. A
single motor results in the hand only having one grasping mode (a whole hand
enveloping grasp) with tendons routed through the hand, resulting in a grasp
that follows a ‘postural synergy’ which closely mimics the motion of a human
enveloping grasp. The rigid-flexible construction, dislocatable joints and
anthropomimetic design result in a gripper that is highly adaptive yet simple
to control. More recent versions have included additional control from a
second postural synergy, and an easily-fabricated 3D-printed version of the
SoftHand has been released, known as the BRL/Pisa/IIT SoftHand (2022).

At the opposite extreme in terms of actuation is the Shadow Dexterous Hand, a
highly actuated anthropomorphic gripper demonstrated as capable of replicating
human grasps during teleoperation due to its highly actuated nature. This has
been demonstrated in a teleoperation task where an operator solved a Rubik’s
Cube using a pair of the hands.

Anthropomimetic grippers offer a familiarity of control and design not found
in other types. Most notably due to the human hands development focused on
tool use and task completion. While the capabilities of other biomimetic
grippers are much more specialised, anthropomimetic grippers offer a much
wider range of application cases.

### Biomimetic Non-anthropomimetic Grippers

Traditionally, robotic grippers have been comprised of rigid links and hard
components, which offer precise control, better overall actuation strength and
efficient transfer of power through the system. However, natural systems make
use of rigid-flexible couplings, for example in the joints of the human body.
One of the earliest examples of a soft robotic gripper utilising rigid-
flexible links is Hirose’s soft gripper (1978), which resembled an Octopus
tentacle, and was the first gripper to passively adapt itself to an object’s
shape. Such rigid-flexible links would later become an important component in
some anthropomimetic grippers such as the Pisa/IIT SoftHand.

There are also many examples of entirely compliant grasping solutions in
nature, such as suction cups on cephalopod tentacles or adhesive ant-eaters
tongues. Non-anthropomimetic grippers inspired by mechanisms like these have
long been widely studied in the application of Soft Robotics, leading to
grippers that depart from the soft-rigid principle. For example, NASA’s gecko
gripper (2016) is based around gecko feet for holding flat objects in space.
The microscopic hairs on a gecko’s feet generate intermolecular forces (van
Der Waals forces), allowing adhesion without any liquid or surface tension.
NASA’s gripper operates on the same principle, making it suitable for moving
and orientating large panels or objects that would otherwise require an large
gripper to power grasp that would otherwise not be well-suited for space
applications.

As discussed earlier these biomimetic grippers offer grasping capabilities
that are highly specialised. Capable of grasping and manipulating objects that
anthropomimetic grippers couldn’t. This, however, comes with its own issues
regarding design, control and application of these grippers.

### Non-biomimetic Grippers

There are currently only a few examples of grippers that are not based on the
human hand or other biomechanical structures in living organisms. For example,
vacuum grippers used suction cups to create vacuums to adhere to an object,
which are reminiscent of cephalopod sucker’s but were not inspired by them.
Early vacuum grippers used industrial vacuums and cycling airflow to provide
constant suction, but progressed quickly to more energy-efficient equivalents
of vacuum gripping technology. In particular, rather than cycling air for
constant suction, the vacuum gripper presses against an objects surfaces then
has the air in the cup expelled, creating a pressure imbalance for adhesion.

An interesting example of a non-biomimetic gripper is the universal ’jamming’
universal gripper utilising the phenomena for granular materials to ’jam’,
i.e. pack together very tightly when forced together. In one design an elastic
container (like a balloon) is filled with a granular material, pushed against
an object then vacuum suction removes the air from the balloon and jams the
material together, which maintains the same shape but is much stiffer so it
can grasp the object securely.

The end-effectors of surgical robots such as the Da Vinci or Smart Tissue
Autonomous Robot (STAR) are miniaturised surgical tools that can have gripping
functions. For some applications, like surgical pliers, they can be considered
grippers, but in others they are more specialised tools like scalpels.

Grippers in this category are once again specialised even further for specific
applications but lend themselves to being applied and controlled easily.
Vacuum grippers and jamming grippers are incredibly simple and straightforward
but cannot accomplish the more complex tasks that anthropomimetic grippers are
aiming towards.

##  III Grasp Perception

An important capability for robotic grippers is to perceive they interacting
with objects as they come into contact or are holding the object. This could
be comprised of interoceptive sensing inside the hand itself due to pressure,
friction, tension in actuated components, which are analogous to the human
perception of grasping through prioprioceptive and other signals. This
information combined with exteroceptive information such as from vision
creates a feedback loop for interacting with objects and forms the building
blocks of an automated system for a robotic gripper to interact with the
world.

This separation of perception into visual and tactile components is important
because grasping does not entirely concern sensing in the gripper alone:
knowledge of the gripper exclusively is not enough to make intelligent
decisions regarding interacting with objects or completing tasks.

### Proprioception

Proprioception encompasses a suite of senses internal to the body that enables
humans to accurately estimate the position of their own limbs, head and trunk
without being able to see them. These senses originate from muscles, tendons
and joint ligaments to detect changes in skeletal muscle contraction/stretch,
body/limb position and joint capsule stress.

The proprioceptive sense of a robotic gripper depends on the type of gripper.
For example, a two-finger gripper driven by electric motors can sense
proprioceptively by using encoders in the motor, with measurements of how far
a servo has rotated and how much torque is applied being common indications of
effective grasping. A gripper driven pneumatically or hydraulically, however,
can present challenges for integration with proprioceptive sensing. For
example, the previously mentioned Graspar hand had no proprioceptive
capability at all. Simply measuring that the actuator or piston is active
provides more detail, but additional sensors such as barometers are usually
needed for detailed proprioceptive information.

Fully-actuated robotic grippers such as the Shadow Dexterous Hand have
controllable servos for each joint in the fingers. Hence, from the encoder
readings on the servos, an operator or autonomous system can ascertain the
state and position of each finger.

### Exteroception

Exteroception is the sensing of external stimuli and can be seen as a system-
level capability of the entire robot rather than for the gripper alone. By
utilising cameras and depth sensors along with a model of the platform, the
system can localise itself and construct a representation of its environment.

### Tactile Sensing

The human sense of touch is essential for our grasping and dexterous
capabilities, relating specifically to sensations carried through the skin.
Tactile sensing allows humans to evaluatea broad range of physical contact
properties including shape, texture, softness, temperature and noxious stimuli
(pain). It is also used in combination with proprioception to make estimates
of weight and how much force is required to grasp an object. One can view
touch as forming the sensory boundary between proprioception and
exteroception. Therefore, when progressing towards intelligent grippers, the
role of tactile sensing and the link it provides between outward and inward
perception is completely crucial.

Tactile sensors range in size and complexity but their baseline function is
the same; determining whether the gripper has made contact with something.
From simple pressure sensors that enable contact checking to piezoelectric
tactile arrays, to optical tactile sensors such as the TacTip or GelSight
sensors. Optical tactile sensors rely on a camera observing what is usually a
representation of a layer of human skin. The TacTip traces white Papillae on
the inside that deflect and displace in response to surface stimuli. The
GelSight traces shading and dots printed directly under the ‘skin’ to observe
stretch and topography changes at a small scale.

##  IV Levels of Autonomy

The research field of Autonomous Robotics considers Levels of Autonomy (LoA)
that separate into 6 groups, which delineate where the control and
responsibility of an operator lie in relation to the type of autonomous
system.

### Human Control & Teleoperated - LoA 0-1

In any area where a gripper must interact with a human being, it is generally
assumed that most interactions are under human control, whcih can be referred
to as ‘Kineasthetic Guidance’. This may either be through direct control of an
operator or through the system being prompted by a human to act then wait for
further instructions. There must also be sufficient feedback to the human
operator to allow reliable control.

A shared autonomy situation refers to tasks where a robot may operate
autonomously but final control of the system rests with a human. For example,
a prosthetic robot hand could be LoA 1 if the hand is capable of regulating
itself to close around an object but requires human instruction and decision
making to do so.

The Da Vinci surgical robot is directly controlled by a human operator, who
may be in the same room, via teleoperation. Such surgical robots have closed-
loop control systems that offer stable control of surgical tools. This
capability differentiates them from being under direct kineasthetic guidance.
Likewise, solutions for hazardous/dangerous environments are often
teleoperated in a similar manner.

### Shared Autonomy - LoA 2-3

A progression in the level of autonomy would be, for example, a warehouse
scenario where a human inputs an item request for the robot to collect from
some storage bin. The arm manoeuvring to the bin, identifying the item,
determining how to grasp it and retrieving it would be automated. However a
human still controls when the task is undertaken, the details of the task, and
can make a decision to stop or cancel the task. Such operations are at LoA 2.

Giving such systems the capability to initiate tasks autonomously in a self-
determined order to just retrieve and deliver items, would give the robot
sufficient autonomy to reach LoA 3. The human operation is limited to
interventions during emergencies and ceasing operations. In such scenarios a
robot can handle some safety features itself, but is still ultimately
dependent on a human operator. Many driverless cars can be viewed as LoA 3.

### Fully Automated Situations - LoA 4-5

This full LoA is where there is no human involvement at all. Achieving this
LoA does not imply that the system is safe, it just means that the system is
responsible for its own safety measures.

Consider, for example, the automated warehouse described above and imagine
that a section of the warehouse has been closed off for the robot to operate
independently, containing storage bins and containers for certain item types
that the system is capable of handling autonomously. The robot has lists of
tasks that it performs without supervision, making all relevant decisions
regarding the collection of items and the item order. This is a fully
autonomous system that has been limited to operate in a specific scenario that
is LoA 4. This scenario separation may be because of the operational limits of
the system itself; for example, the grippers on the arms may not be able to
handle objects larger than the grippers, so the system is constrained to
prevent it from attempting tasks on which it may fail.

If instead of limiting the item types or section of the warehouse the system
can operate in, it is allowed to operate for all items types in the entire
warehouse then a LoA 5 system has been created. Fully automated shipping yards
are good examples of LoA 5 systems, as they can handle all standard shipping
containers and do so without supervision from a human.

Figure 2: Examples of Levels of Autonomy. LoA 0: A pair of Kitchen tongs, a
gripper with no input or control on the gripper side. LoA 1: A Da Vinci
Surgical robot, teleoperated with feedback control loops to eliminate
instrument shake. LoA 2: An autonomous robot used in a smelting factory, waits
for human input then performs a pre-programmed set of instructions LoA 3: A
factory robot assembling cars. Beginning of operation and emergency stops are
still under human control. LoA 4: A Surface Mounted Device pick and place
system using a pneumatic gripper to assemble devices. The machine operates in
a workspace separate from humans and thus has control over its own safety
measures. LoA 5: The Port of Rotterdam is an almost entirely autonomous
shipping port, automated stacking cranes perform necessary grasping. In this
situation the system can accept tasks, fulfil them, access resources it needs
autonomously and can reasonably grasp any object it will encounter..

##  V Ethical Considerations

### Safety and Harm

The ethical considerations of a robotic gripper being used on or nearby humans
is important but is complicated by the gripper being just one component of an
entire robotic system. In many regards, safety standards that apply to systems
like robotic arms can also be applied to robotic grippers.

In the early development of workplace and factory robots, the simplest way to
ensure human safety was to have a clearance zone that a person should not
enter, or to isolate the robot entirely within a cage. However, separating
humans and robotics is proving to be limiting in modern applications of
robotics.

The development of collaborative industrial robots has brought them into human
workspaces, demanding a much higher degree of safety to allow close proximity
to humans. Safety measures can involve: monitored safety stops, i.e. a
stopping operation when a human enters the workspace; speed and separation
monitoring that causes the robot to slow operations when humans are nearby;
and power limiting. Power and force limiting requires either monitoring of
actuation mechanisms or limiting through inherent design. For example, soft
grippers in collaborative scenarios offer a straightforward and implicit
method of providing operational safety limits. .

Since the primary function of a gripper is to secure the position and
orientation of an object in relation to the robotic platform, a reasonable
safety standard would be to require that a gripper should not change state
upon losing power. A gripper dropping something fragile, heavy or sharp during
an emergency stop or power cut could be harmful and/or costly.

### Impacts on Employment

Developing grippers that are more capable of performing like human hands, or
perhaps are superior to humans for specific situations/tasks, will lead to
development of autonomous platforms that can perform tedious/dangerous tasks
in place of humans. How this affects the job market is a matter of debate, as
the shifting economic growth and recession of the past decade has made it
difficult to evaluate the impact that automating labour has actually had. An
important question is whether increasing automatisation of human physical
labour would simply remove jobs or create more skilled and fulfilling work in
other areas such as the installation and maintenance of those robots?

Whatever the answer, future robotic technologies should be used responsibly
and to improve human society. One clear responsible use in this scenario would
be to target jobs and tasks that are considered dangerous or tedious, so that
the humans doing those jobs can be safer and focus on more productive or
creative work.

##  VI Future Challenges

### Moving further towards Intelligent Grasping

A key problem for future of robotic grasp is how to grasp intelligently.
Modern robotic hands have become highly dexterous and articulated but the
challenge of controlling them remains unsolved.

The use of more sophisticated and human-like sensing in a robotic gripper will
lend itself to enabling intelligence, but also creates a need to process and
interpret more data on top of a potentially already very complex gripping
system. For example, during the development of the iHY hand in the early
2010s, highly articulated dexterous hands were available and had the same
issues that they still face now in regards to uptake and application in
industrial spaces. Simpler grippers are currently a more accessible option,
but have their own issues with integration of greater sensing capacity into
structurally simple hands, often require a complete change in design to be
compatible with a given sensing technology; for example, vision-based tactile
sensors are difficult to integrate into soft grippers.

### Universality vs Specificity

So-called universal grippers offer a cheap and effective way of grasping many
objects, containing a particle material enclosed in fine rubbery membrane for
enclosing around objects.However, they can fail to offer a reliable solutions
for many tasks, such as grasping in clutter or object manipulation. Likewise,
a gripper designed for a specific task, such as 2-fingered grippers for
picking and placing simple objects, may fail to work outside of that task. So
far, the workaround has been to change the tasks you give to certain grippers
or limit their application space. While this separation has enabled progress,
it has led to a huge diversity in gripper types, The development of a gripper
that can be used universally and controlled accurately, which to some extent
the human hand solves, is still ongoing.

### Unstructured Environments

Unknown, unstructured and cluttered environments are problematic for any
robotic system. Finding ways to explore spaces and dealing with clutter is not
only a challenging perception task but also requires intelligent planning. The
system needs to be capable of differentiating between unimportant clutter that
can be ignored or displaced, and dangerous disturbances that must be safely
dealt with. High proprioceptive and tactile sensing capabilities are needed
for gripping systems that can operate in such environments.

In terms of levels of autonomy as we discussed earlier, at present LoA 5
systems exist in very predictable and structured environments such as shipping
yards.

### Safety

While collaborative robots are beginning to make more of an industrial
appearance their uptake remains slow. From a legal and practical standpoint,
it is currently far simpler and safer for company to isolate their robots from
human workers. It remains an important challenge to improve the productivity
of humans working alongside robots while maintaining their safety. As grippers
develop towards more intelligent grasping alongside human works, their
operational safety will remain a key consideration.

##  VII Conclusion

The development of robotic grippers has advanced enormously over the past few
decades, which is exhibited by the diverse range of manipulator designs and
applications. The next steps for the use of robotic grippers needs to address
the fact that highly articulated hands are still very costly, difficult to
control and have not seen as much application as their potential suggests.
Currently, cheaper and less complex grippers are finding more industrial uses.
The developers of dexterous robot hands need to make their grippers easier for
commercial users to utilise, otherwise those users will stick with current
options and use-case scenarios. Moreover, further advancements in the
perceptual and control capabilities of simpler grippers are much-needed
stepping stones to integrating intelligent gripping technologies into fully
autonomous systems.

  * •

Young, B. ”The Bionic-Hand Arms Race: High-Tech Hands are Complicated, Costly,
and Often Impractical.” IEEE Spectrum 59.10: 24-30, 2022.

  * •

Odhner L., Jentoft L., Claffee M., Corson N., Tenzer Y., Ma R., Buehler M.,
Kohout R., Howe R., Dollar a. A compliant, underactuated hand for robust
manipulation. The International Journal of Robotics Research, 33(5):736–752,
2014.

  * •

Dollar A. and Howe R. The highly adaptive SDM hand: Design and performance
evaluation. International Journal of Robotics Research, 29(5):585–597, 2010.

  * •

Ward-Cherrier, B., Pestell N., Cramphorn L., Winstone B., Giannaccini M.,
Rossiter J., and Lepora N. ”The TactTip family: Soft optical tactile sensors
with 3d-printed biomimetic morphologies.” Soft robotics 5, no. 2: 216-227,
2018.

  * •

Ma, R. and Dollar A. ”Yale OpenHand Project: Optimizing Open-Source Hand
Designs for Ease of Fabrication and Adoption” IEEE Robotics ‘I&’ Automation
Magazine (Volume: 24, Issue: 1, March 2017) Pages: 32-40

  * •

Dollar A. and Howe R. ”The SDM Hand as a Prosthetic Terminal Device: A
Feasibility Study”. 2007 IEEE 10th International Conference on Rehabilitation
Robotics, 13-15 June 2007.

  * •

Lepora N., Ford C., Stinchcombe A., Brown A., Lloyd J., Catalano M., Bianchi
M., Ward-Cherrier B. ”Towards integrated tactile sensorimotor control in
anthropomorphic soft robotic hands”. /textit2021 IEEE International Conference
on Robotics and Automation (ICRA). 30 May 2021 - 05 June 2021

  * •

Glick P., Suresh S., Ruffatto D., Cutkosky M., Tolley M., Parness A. ”A Soft
Robotic Gripper With Gecko-Inspired Adhesive”. IEEE Robotics and Automation
Letters ( Volume: 3, Issue: 2, April 2018) Pages:903-910.

  * •

Li M., Su M., Xie R., Zhang Y., Zhu H., Zhang T., Guan Y. ”Development of a
bio-inspired soft gripper with claws”. 2017 IEEE International Conference on
Robotics and Biomimetics (ROBIO), 05-08 December 2017.

  * •

Brown E., Rodenberg N., Amend J., Mozeika A., Steltz E., Zakin M., Lipson H.,
Jaeger H. ”Universal robotic gripper based on the jamming of granular
material”. Proceedings of the National Academy of Sciences 107(44) 2010

  * •

Liang D., Gao Y., Huang H., Li B. ”Design of a Rigid-Flexible Coupling Origami
Gripper”. 2021 IEEE International Conference on Robotics and Biomimetics
(ROBIO), 27-31 December 2021.