## Abstract

Cooperative small harvesting robots, mimicking a group of human pickers, have the potential to significantly reduce labor dependence in strawberry production. A tri-layered algorithm is investigated to effectively assign rows to robots with each robot incentivized to maximize its total number of picked strawberries within the fleet’s harvesting time. The proposed algorithm consists of a decentralized local auction and negotiation strategy as the primary phase with a centralized fallback algorithm that guarantees an assignment. The salient features of the algorithm are reduced communication time, scalability, constant time complexity in the decentralized phase, and ease of implementation. The proposed algorithm is evaluated in a Monte Carlo simulation and the superior performance (e.g., significantly reduced computational time) is observed when compared with a centralized approach. It is expected that this row negotiation algorithm can address an important gap in strawberry harvesting via cooperative, small harvesting robots.

## 1 Introduction

High production costs, increasing populations, and labor shortages have driven the demand for automation in the agricultural industry [1–3]. Many operations in agricultural fields, such as weed control [4] and harvesting [5], have been or are being automated. Specialty crops, such as strawberries, are a research and engineering focal point of automation [6]. However, it is challenging to use robotics in some strawberry field operations which require more control and dexterity, such as harvesting, than grains or field crops [7]. To date, most strawberries are manually harvested, accounting for over 25% of the total production costs [7,8]. In Florida, many strawberry growers reported labor shortages while crops are in season [8], resulting in some of the yield being abandoned. Although autonomous harvesting has shown promising results in greenhouse conditions [9–11], advancements in field settings are quite limited. To increase the harvesting efficiency, industry players such as Agrobot^{2} and Harvest Croo^{3} developed robotic platforms with multiple independent harvesters that span the width of several strawberry rows. However, these approaches have foreseen inadequacies in the long run such as transportation difficulty, prone to single-point-of-failure, significant downtime impact, low platform flexibility, and low adaptation to field variations. It becomes natural to utilize cooperative, small robotic platforms in strawberry harvesting, analogous to a group of human pickers. Nevertheless, multirobot systems must address additional technique challenges, one of which is effectively scheduling a robot to a row in real-time.

So far, all research in scheduling can be broadly categorized as centralized or decentralized. To the best of our knowledge, centralized approaches are popular in solving robotic platform scheduling problems in agricultural fields, mainly due to the possibility that not many robots, if multiple robots are present, would work in one field at the same time [12–18]. For example, an automatic system for vineyards [12] utilizes a central computer to assign paths for robots to irrigate high-priority vines. Restricted by the layout of vineyards, robots can only change rows at row headlines [12,16]. In the case of an herbicide-spraying robot, task sets are assigned from a central computer that generates random solutions, improving at each iteration and converging on a set of assignments [13]. Using a cost matrix to assign tasks in a centralized approach can account for external factors like crop rotation, weather constraints, and urgency to harvest [14]. Agricultural surveillance drones can have flight paths calculated and assigned via a centralized computer [18], sometimes assisted by negotiations among agents [17].

Decentralized approaches such as bundle algorithms, greedy algorithms, and auction algorithms are widely seen in other application domains [19–21]. Choi et al. [20] proposed a two-layer decentralized algorithm to optimally assign multiple tasks to each agent with applications in office cleaning and building emergency surveying [19]. In those studies [19,20], each agent generates a bundle list via an auction algorithm in Phase 1, and conflicts are resolved via a consensus approach in Phase 2. Auction algorithms involve a bidding process where tasks are assigned based on the associated values [21], and the process is overseen by a centralized computer to reduce communication time and achieve consensus.

In this paper, a tri-layered negotiation algorithm is proposed for real-time scheduling consisting of a decentralized bidding process between neighboring robots (layer 1 and layer 2) and, if needed, a centralized algorithm afterward (layer 3). In layer 1, robots determine if they are able to continue harvesting. Layer 2 contains two algorithms: one for robots bidding to help neighbors and another for robots overseeing the bidding process initiated by its neighbors. If a solution cannot be obtained in the decentralized layer, the Hungarian Algorithm [22] is utilized in layer 3 to assign tasks to each robot requesting a new assignment. Robots are incentivized to cooperate like human pickers to harvest the field in minimal time while collecting as many strawberries as they can. However the robots are subjected to motion limitations due to row size and their own capabilities.

The work in this paper proposes a row allocation negotiation algorithm to address an important gap in strawberry harvesting via cooperative, small harvesting robots. The technical contributions of the study are summarized here. (i) The decentralized part of the algorithm is scalable. The complexity of the centralized part is *O*(*N*^{3}), but the probability of using it is low. (ii) The computational time is significantly reduced as compared to centralized approaches. (iii) The algorithm is easy to implement.

The remainder of the paper is organized as follows. In Sec. 2, the row allocation problem for robots in a strawberry field is defined with a list of assumptions. The algorithm is discussed in Sec. 3, and its communication, convergence, and computational complexity analyses are given in Sec. 4. The proposed approach is validated in a Monte Carlo simulation and its performance is discussed in Sec. 5. Conclusions are given in Sec. 6.

## 2 Problem Definition and Assumptions

There are a total of *N*_{s} rows in a strawberry field. For a typical field, two lines of trees are planted in every row, with mostly uniform distances between trees. There are *N*_{hr} harvesting robots in the fleet, each with identical functionalities and physical characteristics.

Figure 1 depicts a potential configuration of robots in a field, in which robots, their velocities, and the rows they occupy are shown along with descriptive information about the dimensions of the rows and the sets they belong to.

*The N _{s} rows are grouped into three sets: set Ω_{n} includes unharvested rows, set Ω_{u} includes rows currently under harvesting, and set Ω_{h} includes rows that have already been harvested.*

*r ^{+} and r^{−} denote the rows that are the right and left neighbors of row r in the same set, respectively.*

*The row that robot i is currently in is denoted as row(i), and the number of robots in row r is defined as num(r).*

The following assumptions and constraints are considered in the scheduling algorithm development.

*Similar to a human picker, the total number of strawberries robot i harvested n _{i,st} is proportional to the overbed length traveled L_{i,h} as n_{i,st} ∝ L_{i,h}, i = 1, …, N_{hr}. Therefore, each robot will try to maximize this length within the total harvesting time. This assumption incentivizes a robot to help harvest a neighboring robot’s row instead of going to a new, unharvested row that is far away from its current position.*

*Robot i, i = 1, …, N _{hr}, has constant but distinct nonharvesting and harvesting speeds v_{i,nh} and v_{i,h} (v_{i,nh} ≥ v_{i,h}), respectively.*

*Robot i, i = 1, …, N _{hr}, will continue to harvest for as long as they can, e.g., they still have sufficient battery life and rows are available for harvesting (*$\Omega n\u2260\u2205$

*or*$\Omega u\u2260\u2205$

*).*

*Robot i has a finite basket capacity C _{i}, i = 1, …, N_{hr} (i.e., the maximum number of strawberries) and can monitor the current number of strawberries in the basket n_{i,b}. The robot delivers the basket to the collection truck when the basket is full:*$\u03c2i=ni,b/Ci=1$.

*Basket delivery times are calculated by dividing the distance between a robot and the collection truck by its delivery speed.*

*A robot always delivers its basket to the collection truck after completing a row and returns to the current row before requesting a new assignment.*

*Robot i can calculate the distance to the end of row(j), meaning*$di,j,\u2200j\u2208\Omega n\u222a\Omega u$. *The distance to each row is the known width of each row multiplied by the number of rows between the robot and the row of interest. The turning distance is relatively small, thus omitted here.*

*All robots in the fleet spend the same amount of time T in the farm. In reality, all robots in a fleet will be transported at the same time between a field and a storage facility. This implies that no robot should be idle if the overall objective is to minimize the harvesting time.*

*There are collection trucks at both ends of the rows, allowing a robot to harvest up or down a row and deliver its basket to the truck on the closer end, assuring no motion conflict between two robots in the same row.*

*No more than two robots are allowed per row (harvesting in opposite directions), meaning num(r) ≤ 2. A robot will deliver the basket to the collection truck on its side after finishing a row, according to Assumption 8.*

*There are many nonharvesting events, such as moving toward a collection truck, repairing the powertrain, and replacing the onboard battery. Only the nonharvesting related traveling is modeled, and all the other nonharvesting operations will be neglected.*

*T*}. Based on Assumption 7,

*T*

_{i}=

*T*=

*T*

_{i,h}+

*T*

_{i,nh},

*i*= 1, …,

*N*

_{hr}, denotes the time robot

*i*spent on the farm including the times spent in harvesting operations

*T*

_{i,h}and nonharvesting operations

*T*

_{i,nh}. Following Assumptions 1 and 2,

*T*

_{i}=

*L*

_{i,h}/

*v*

_{i,h}+

*L*

_{i,nh}/

*v*

_{i,nh}, in which

*L*

_{i,nh}is the total distance robot

*i*travels in nonharvesting operations. To minimize

*T*

_{i}, we seek to minimize the time when robot

*i*is in nonharvesting operations. This can be done by reducing the distance traveled with constant speeds (Assumptions 2 and 10), reinforcing the incentive for robots to help nearby neighbors instead of traveling to a new row further away from its current row. Therefore, the performance index for the allocation algorithm to minimize is

The optimization is subject to the constraints implied in the aforementioned assumptions. The nearest-neighbor topology is chosen for the communication considering typical commercial strawberry farm size, off-the-shelf wireless communication range, and number of harvesting robots in a fleet. Robot *i*, *i* = 1, …, *N*_{hr}, can only communicate with its neighboring robots in *row*(*i*^{+}) and *row*(*i*^{−}), as well as the truck when necessary. The maximum number of bid iterations *n*_{req} among neighboring robots is set to two, but can be adjusted by users.

## 3 A Decentralized, Auction-Based Row Allocation Algorithm

The algorithm is divided into three decision layers comprised four algorithms. The first layer’s algorithm executes every time a robot finishes harvesting a distance equal to its body length *l*_{i}. If robot *i* receives a request from its neighbor in *row*(*j*) ∈ [*row*(*i*)^{+}, *row*(*i*)^{−}], it will not process the request until it finishes its current harvesting distance (e.g., *l*_{i} = 1*m*).

### 3.1 Algorithm 1 in Layer 1.

The algorithm begins in layer 1 (the pseudo code in Table 1), which is triggered when robot *i* harvests a distance *l*_{i} and reads in information from its file to decide if it should continue harvesting, etc. (line 1 of Table 1). Data in the file, updated by robot *i* itself, its neighboring robots, and/or the collection trucks, contain information about the farm, the progress, and condition of the robot fleet, and the inquiries sent by its neighboring robots. A robot will check for conditions that render it unable to harvest (lines 2 and 3 of Table 1). If robot *i* is at the end of its row, i.e., $\lambda i=100%$ (line 4 of Table 1), it delivers its basket to the collection truck and returns to its row (Assumption 5). Robot *i* will determine which row to harvest next (lines 6–8 of Table 1) by either going to a new nearby row or entering Algorithm 2 to offer help to neighboring robots. Line 9 of Table 1 comes directly from the basket capacity definition in Assumption 4. If a robot receives an offer for a neighboring robot to come help (line 11 of Table 1), it enters Algorithm 3 to determine if this offer will be accepted. Otherwise, robot *i* will continue harvesting (line 14 of Table 1, Assumption 3).

1 | Read in information from an onboard file |

2 | if “no battery”, “repairs are needed”, etc. |

3 | Stop harvesting, wait for maintenance |

4 | else if $\lambda i=100%$ |

5 | Deliver strawberries to a truck |

6 | If $\u2203$ rows in $[row(i)\u2212,row(i)]\u222a[row(i),row(i)+]$, and these rows ∈ Ω_{n} |

7 | go to the nearest row which belongs to Ω_{n}; break; end |

8 | Enter Algorithm 2 in Decision Layer 2 |

9 | else if ζ_{i} = 1 |

10 | Deliver strawberries to a truck, go back to the current position of row(i) Continue harvesting |

11 | else if “any neighboring robot sent an offer” |

12 | Enter Algorithm 3 in Decision Layer 2 |

13 | else |

14 | Continue harvesting |

15 | end |

1 | Read in information from an onboard file |

2 | if “no battery”, “repairs are needed”, etc. |

3 | Stop harvesting, wait for maintenance |

4 | else if $\lambda i=100%$ |

5 | Deliver strawberries to a truck |

6 | If $\u2203$ rows in $[row(i)\u2212,row(i)]\u222a[row(i),row(i)+]$, and these rows ∈ Ω_{n} |

7 | go to the nearest row which belongs to Ω_{n}; break; end |

8 | Enter Algorithm 2 in Decision Layer 2 |

9 | else if ζ_{i} = 1 |

10 | Deliver strawberries to a truck, go back to the current position of row(i) Continue harvesting |

11 | else if “any neighboring robot sent an offer” |

12 | Enter Algorithm 3 in Decision Layer 2 |

13 | else |

14 | Continue harvesting |

15 | end |

### 3.2 Algorithm 2 in layer 2.

In Algorithm 2, robot *i* initiates the bidding process by sending time incentives to its neighboring robots. Time incentives are used as currency in an auction process, where smaller time incentives are more valuable. The neighboring robots that receive time incentives will oversee the auction and determine the appropriate outcomes. We define *n*_{req} as the number of times robot *i* offers to help its neighbor. Robot *i* offers to help one of its neighboring robots in *row*(*j*) ∈ [*row*(*i*)^{+}, *row*(*i*)^{−}] and waits long enough for robot *j* to respond (e.g., *t*_{c} ranging between 1 and 3 s) (line 5 of Table 2). The time incentive used in Algorithm 2 is calculated as follows. Per Assumption 5, a robot has an empty basket when calculating time incentives, therefore it does not need to factor in basket delivery times. The remaining fraction of row(*j*) that has not been harvested yet is defined as *L*_{j} (1 − *λ*_{j}), where *L*_{j} is the length of *row*(*j*) and *λ*_{j} is the percentage of the overbed length harvested. The distance robot *i* covers in transit is the distance between robot *i* and the end of row(*j*), *d*_{i,j} (Assumption 6), plus *L*_{j}(1 − *λ*_{j})/2. Furthermore, the time needed for both robot *i* and robot *j* to finish harvesting the row where robot *j* is in is counted in the time incentive. This yields the time incentive for robot *i* to help robot *j*, $tij=[di,j+Lj(1\u2212\lambda j)/2]/vi,nh+Lj(1\u2212\lambda j)/(vi,h+vj,h)$, consistent with Assumption 9. If robot *i* receives positive responses (indicating it has won the bid) from both neighbors, the neighbor corresponding to the smaller $tij$ will receive help from robot *i*, based on Eq. (1), and it will update Ω_{n}, Ω_{h}, and Ω_{u}. If neither neighbor sends a positive response initially, robot *i* will offer to help a second time (*n*_{req} = 2). If it has not won a bid in the second iteration, it will enter the next decision layer. The bid offering process is shown in lines 5–16 of Table 2.

1 | If there is a row k ∈ Ω_{n} between row(i) and row(j), j = [i^{+}, i^{−}] |

2 | go to row k; break; end |

3 | Set n_{req} = 1 |

4 | while n_{req} ≤ 2 |

5 | Calculate and send $tij$ to robot j, j = [i^{+}, i^{−}], and wait for t_{c} seconds |

6 | if a positive response is received from both robots j = i^{+} and j = i^{−} |

7 | Select the smaller one of [$tii+$,$tii\u2212$] |

8 | Inform robot j it will receive help, and the other robot will not |

9 | Update Ω_{n}, Ω_{h}, and Ω_{u} |

10 | Go to row(j); break |

11 | else if only one neighboring robot in row(j) sends a positive response |

12 | Inform robot j it will receive help |

13 | Update Ω_{n}, Ω_{h}, and Ω_{u} |

14 | Go to row(j); break; end |

15 | else if n_{req} = 2 |

16 | Enter Algorithm 4 in Decision Layer 3; break |

17 | end |

18 | n_{req} = n_{req} + 1 |

19 | end |

1 | If there is a row k ∈ Ω_{n} between row(i) and row(j), j = [i^{+}, i^{−}] |

2 | go to row k; break; end |

3 | Set n_{req} = 1 |

4 | while n_{req} ≤ 2 |

5 | Calculate and send $tij$ to robot j, j = [i^{+}, i^{−}], and wait for t_{c} seconds |

6 | if a positive response is received from both robots j = i^{+} and j = i^{−} |

7 | Select the smaller one of [$tii+$,$tii\u2212$] |

8 | Inform robot j it will receive help, and the other robot will not |

9 | Update Ω_{n}, Ω_{h}, and Ω_{u} |

10 | Go to row(j); break |

11 | else if only one neighboring robot in row(j) sends a positive response |

12 | Inform robot j it will receive help |

13 | Update Ω_{n}, Ω_{h}, and Ω_{u} |

14 | Go to row(j); break; end |

15 | else if n_{req} = 2 |

16 | Enter Algorithm 4 in Decision Layer 3; break |

17 | end |

18 | n_{req} = n_{req} + 1 |

19 | end |

### 3.3 Algorithm 3 in layer 2.

In Algorithm 3 (Table 3), robot *i* has finished harvesting a section of length *l*_{i} and checks to see if a neighboring robot in *row*(*j*) ∈ [*row*(*i*)^{+}, *row*(*i*)^{−}] has offered to help (line 9 of Algorithm 1). Since the time incentives sent by the robot(s) on the far side of a row will be larger than that of the one(s) just on the near side and its motion is constrained by the field layout, it will decline the help offer immediately, and only focus on selecting between those that are closest to itself. Robot *i* compares the time incentive $tji$ to the time it would spend harvesting the remainder of the row by itself $tie$ and informs robot *j* if it won or not. If more than one time incentive was received from robots in different rows and robot *j* declines to come help after winning a bid, robot *i* will select the other time incentive $tji$ accordingly. If the second neighboring robot also declines to help, robot *i* will not be helped. A robot offering help will repeat the offer a second time if it fails to win a bid in the first iteration, therefore it is necessary for robot *i* to check for a second offer before resuming Algorithm 1. In this algorithm, the time incentive value for robot *i* to harvest its current row by itself is computed as $tie=Li(1\u2212\lambda i)/vi,h$. It is noting that the harvesting time is included in the time incentive calculated in Algorithm 2 so to compare with robot *i* itself in Algorithm 3.

1 | Set n_{req} = 1 |

2 | while n_{req} ≤ 2 |

3 | Read in the time incentives $tji$ |

4 | if there are two robots in either row(j) that send $tji$ |

5 | Inform the robot(s) on the far end of row(j) that it has lost the bid |

6 | for remaining $tji$ received, starting with the smaller $tji,j=[i+,i\u2212]$ |

7 | if $tji<tie$ |

8 | Inform robot j it won the bid |

9 | Wait for t_{c} seconds |

10 | if robot j confirms it will help |

11 | Inform the other robot that it losts the bid; break; end |

12 | end |

13 | else |

14 | Inform robots j they lost the bid; break |

15 | end |

16 | end |

17 | n_{req} = n_{req} + 1 |

18 | end |

1 | Set n_{req} = 1 |

2 | while n_{req} ≤ 2 |

3 | Read in the time incentives $tji$ |

4 | if there are two robots in either row(j) that send $tji$ |

5 | Inform the robot(s) on the far end of row(j) that it has lost the bid |

6 | for remaining $tji$ received, starting with the smaller $tji,j=[i+,i\u2212]$ |

7 | if $tji<tie$ |

8 | Inform robot j it won the bid |

9 | Wait for t_{c} seconds |

10 | if robot j confirms it will help |

11 | Inform the other robot that it losts the bid; break; end |

12 | end |

13 | else |

14 | Inform robots j they lost the bid; break |

15 | end |

16 | end |

17 | n_{req} = n_{req} + 1 |

18 | end |

Figure 2 is shown with two example scenarios of a robot selecting rows affiliated with the lowest travel time as an unharvested row (left), and a partially harvested row occupied by a neighbor (right).

### 3.4 Algorithm 4 in layer 3.

Algorithm 4 begins when a robot fails to receive an assignment from its neighbors and requests an assignment from the collection truck. The truck’s computer will wait *t*_{w} (e.g., between 1 and 3) seconds after receiving the first inquiry to allow other robots to submit requests before sending out the list of rows in Ω_{n} and Ω_{u} (line 3 of Table 4). The computer will then wait for *t*_{c} seconds for the robots to calculate and send time incentives. The time incentives are used to determine the row assignments via the Munkres Assignment Algorithm [22] in line 5 of Table 4. The collection truck computer will then update sets Ω_{n}, Ω_{h}, and Ω_{u}, shown in line 7. As mentioned before, Algorithm 4 is centralized; however, this algorithm has a low chance of being used. If the candidate row *j* belongs to Ω_{n}, the time incentive for robot *i* to move from its current row end to that row is $tij=\gamma |j\u2212row(i)|di,j/vi,nh$. Mimicking a human picker (Assumption 1), the discount factor *γ* > 1 is used to show the hesitation of a robot to go to a remote row. If the candidate row *j* belongs to Ω_{u}, the time incentive for robot *i* to move from its current row end to the remaining middle of row *j* is $tij=\gamma |j\u2212row(i)|di,j/vi,nh+Lj(1\u2212\lambda j)/2/vi,nh$.

1 | Receive a row request from a robot |

2 | Wait for t_{w} seconds for more robots to send requests |

3 | Send out Set Ω_{n} to robots that requested a new row |

4 | Wait t_{c} to receive $tij,j\u2208\Omega n$ from robots requesting a new row |

5 | Optimal assignment using the Munkres Assignment Algorithm [22] |

6 | Send the row assignments to all robots that requested a new row |

7 | Update Sets Ω_{n}, Ω_{h}, and Ω_{u} |

1 | Receive a row request from a robot |

2 | Wait for t_{w} seconds for more robots to send requests |

3 | Send out Set Ω_{n} to robots that requested a new row |

4 | Wait t_{c} to receive $tij,j\u2208\Omega n$ from robots requesting a new row |

5 | Optimal assignment using the Munkres Assignment Algorithm [22] |

6 | Send the row assignments to all robots that requested a new row |

7 | Update Sets Ω_{n}, Ω_{h}, and Ω_{u} |

Here, the tri-layered, decentralized auction-based row allocation algorithm is abbreviated as DARA, and the decision process is shown in Fig. 3.

## 4 Algorithm Analyses

### 4.1 Communication Complexity.

Information will be exchanged among robots and/or trucks periodically. A robot will not update its global information such as the row sets until it reaches a truck. In the communication complexity analysis (the worst case scenario), we assume that any information regardless of its type (e.g., Booleans, integers, or floating point numbers) is stored as one unit.

In Algorithm 1 (Table 5), robot *i* will read information from its onboard file, which is updated by the collection trucks and its neighbors. The only information that will be transmitted from robot *i* to a truck is the robot index (one unit) and a Boolean (one unit) indicating if repairs, a battery replacement, etc., are needed.

Layer# | To neighbors | From neighbors | Received by a truck | Sent by a truck |
---|---|---|---|---|

1 | 0 | 0 | 2 | 0 |

2 | 16 | 8 | 3 | 0 |

3 | 0 | 0 | N_{r} + 3 | N_{r} + 3 |

Layer# | To neighbors | From neighbors | Received by a truck | Sent by a truck |
---|---|---|---|---|

1 | 0 | 0 | 2 | 0 |

2 | 16 | 8 | 3 | 0 |

3 | 0 | 0 | N_{r} + 3 | N_{r} + 3 |

In Algorithm 2, robot *i* sends an array of three units (a time incentive, its corresponding row, and the robot index) to a maximum of two available neighbors. The neighboring robots respond by each sending two units of information (a Boolean and its index). If no bid is won, robot *i* resends the offers as three units of information and receives two units of information from each neighbor. Robot *i* then responds to each of its neighbors with two units of information and informs the truck of the row status changes by sending three units of information (the row that has been completed, the row it is moving to, and its index).

In Algorithm 3, robot *i* evaluates up to four time incentives sent by neighbors. It will immediately respond to two neighbors with a Boolean and an index (two units) to remove them from the bidding process and will send an additional two-unit response to the robot with the smallest time incentive. Robot *i* then receives a Boolean response and index (two units). Two units will be sent to its other neighbor if the initial response declines the offer, prompting it to send a two-unit response.

In Algorithm 4, as shown in Fig. 4, the collection truck receives a robot index and an integer prompting the algorithm to execute (two units) from a maximum of *N*_{hr} robots. Then the truck will send *N*_{r} integers indicating which rows are unharvested (*N*_{r} is the number of rows in Ω_{n}) and the truck index to each of the *N*_{hr} robots. It will then receive the robot index and *N*_{r} time incentives corresponding to the unharvested rows from the *N*_{hr} robots and will send back two units of information to each robot containing the robot index and an integer representing the new row assignment.

### 4.2 Convergence Analysis.

Consider a general instance where *n*_{1} robots, 1 ≤ *n*_{1} ≤ *N*_{hr}, finished their rows and requested new assignments at around the same time. According to DARA, a robot requesting a new row will always receive an assignment if $\Omega n\u2260\u2205$ or $\Omega u\u2260\u2205$. If $\Omega n=\u2205$ and $\Omega u=\u2205$, the robot will wait in the farm until all robots finished their current rows.

The maximum time for the algorithm to converge is defined as the time needed for all the related robots (*n*_{1} robots, their neighbors, and the trucks) to execute the algorithms including communication time, code execution time, and waiting time. Two cases are considered here. In case 1, a robot is seeking an assignment; in case 2, a robot receives a message from its neighbor offering help. The time needed for a truck to run its algorithm is included in these two cases.

*Case 1*: The robot enters Algorithm 2 to offer help to its neighbors and will enter Algorithm 4 if it does not win a bid. The Munkres Assignment Algorithm [22] in layer 4 guarantees an assignment for each robot requesting a new row if one is available. Thus, the robot will have a fixed number of instances of communication to obtain an assignment. The waiting time and the code execution time in all three layers are fixed and upper bounded. Therefore, the maximum time for a robot to obtain a new assignment is finite.

*Case 2*: The robot enters Algorithm 3 overseeing two iterations of the bidding process for up to four neighbors. In each iteration, a robot completes a fixed number of instances of communication for each neighbor. Combining the initial reception of help messages and the instances of rejecting robots on the far sides, there are also a fixed total instances of communication. The process finishes after the second iteration regardless of the results of the bidding process. Therefore, a robot receiving a help offer will oversee the bidding process in finite time.

Combining these two cases, the algorithm will converge in finite time.

### 4.3 Computational Complexity.

The computational complexities of the two cases mentioned in Sec. 4.2 are analyzed here.

*Case 1*: The CPU time used in calculating the time incentives is constant since only addition and multiplication operations are used. Communicating information about new rows is of constant complexity. Calculating time incentives corresponding to these rows is of *O*(*n*_{2}) complexity, where *n*_{2} is the number of rows related to *n*_{1} robots and is bounded by the size of the strawberry field. The complexity of the centralized process, the Munkres Assignment Algorithm, has a $O(n33)$ time complexity [22], where *n*_{3} is the larger of the number of rows in Ω_{n} and Ω_{u} and the number of robots requesting a new assignment. Therefore, the upper bound of time complexity for case 1 is $O(n33)$.

*Case 2*: The robot receives a help inquiry and oversees the bidding process, which is upper bound by the complexity of Algorithm 3 process. Reading in the time incentives, comparing these values, and communicating the results, each have constant time complexities. The process is limited to two iterations, resulting in an overall constant time complexity.

Combining both cases, the complexity of the centralized part in DARA is $O(n33)$, while that of the decentralized part is *O*(*n*_{1}). The chances of using the centralized part are low.

## 5 Simulation Results and Discussions

### 5.1 Simulation Setup.

The Monte Carlo simulation aims to evaluate the ability of DARA to produce a new row assignment within the constraints. Table 6 lists the constant settings related to a simulated farm and harvesting robot fleet.

Values | |
---|---|

# of stops per row | 100 |

Width of each row (m) | 2 |

Distance between the truck and the nearest row (m) | 2 |

Basket capacity (# of strawberries) | 500 |

Delivery speed (m/s) | 2.5 |

Harvesting speed (m/s) | 0.1 |

Values | |
---|---|

# of stops per row | 100 |

Width of each row (m) | 2 |

Distance between the truck and the nearest row (m) | 2 |

Basket capacity (# of strawberries) | 500 |

Delivery speed (m/s) | 2.5 |

Harvesting speed (m/s) | 0.1 |

Different scheduling scenarios are mimicked by different combinations of the independent variables shown in Table 7. For example, a “repair” event is triggered when the Boolean representing a mechanical failure, *h*, is set to 1 or the battery life *η* (between 0% and 100%) is below a threshold. The determination of *h* is biased in favor of 0, as robots are not expected to fail frequently. Variables such as *ζ*, *λ*, and *η* are assigned with a normal distribution centered at 50%. When the variable indicating the percent fullness of a robot’s basket, *ζ*, is at 100%, it will trigger the robot to deliver the basket to a nearby collection truck. The number of robots in the fleet is proportionate to the size of the farm ranging between 30 and 480 rows.

Values | |
---|---|

h (boolean) | {0,1} |

η (%) (floating) | [0,100] |

ζ (%) (integers) | [0,100] |

row(i) (integers) | [0,30] |

λ of each robot (%) (integers) | [0,100] |

# of harvesting robots | [5,80] |

# of rows | [30,480] |

γ | 2 |

Values | |
---|---|

h (boolean) | {0,1} |

η (%) (floating) | [0,100] |

ζ (%) (integers) | [0,100] |

row(i) (integers) | [0,30] |

λ of each robot (%) (integers) | [0,100] |

# of harvesting robots | [5,80] |

# of rows | [30,480] |

γ | 2 |

Each simulated robot is assigned to a randomly selected row; however, no more than two robots will be assigned to the same row. To reliably trigger a row assignment event, we let robot *i* always be at the end of its row, with other robots in the fleet given a random overbed position *λ* ranging between 0% and 100% of the row length. Since robots are likely to progress through the field near the rest of the fleet, robot *i* in *row*(*i*) has two available neighbors, with other robots being randomly assigned to nearby rows.

### 5.2 Results and Discussions.

The Monte Carlo simulation of DARA is executed for 100,000 trials and compared to a benchmark central process (Benchmark). Benchmark utilizes only the centralized Munkres Assignment Algorithm [22] to award assignments from a set of available rows and is evaluated under the same conditions as DARA. The actual row assignment for each simulation run is not shown which is not crucial in demonstrating the advantages of the algorithm against the benchmark algorithm.

In Table 8, Benchmark and DARA assignments and execution times are observed for varying farm and fleet sizes. DARA assignments are globally optimal when they match the Benchmark assignments, which occurs a majority of the time. Discrepancies are caused by DARA assigning rows within the scope of its neighbors and Benchmark assigning unharvested rows outside of this range (e.g., the number of robots in the fleet) in cases where the overbed distance to travel to the starting point of an partially harvested row is significant. In these cases, DARA assignments are locally optimal. The results of the simulation indicate that, at minimum, the locally optimal assignment is obtained using DARA when compared to Benchmark with 100% of trials resulting in successful row assignments. Figure 5 shows the average execution times from Table 8 as the numbers of rows and robots increase, with DARA outperforming Benchmark and displaying much better scalability. It is worth noting that the waiting times are not included in the execution times.

Average execution time (ms) | Match (%) – high quality | Nonmatch (%)–Low Quality | ||||
---|---|---|---|---|---|---|

# of Rows | # of Robots | DARA | Benchmark | Both assign neighboring row (%) | Both assign new rows (%) | Nonmatch (%)–Low Quality DARA to neighbor Benchmark to new row (%) |

30 | 5 | 0.061 | 0.169 | 72.3 | 7.80 | 19.9 |

60 | 10 | 0.081 | 0.548 | 80.7 | 5.10 | 14.2 |

120 | 20 | 0.164 | 1.564 | 80.1 | 7.10 | 12.8 |

240 | 40 | 0.590 | 6.456 | 78.9 | 8.80 | 12.3 |

480 | 80 | 2.449 | 24.066 | 78.1 | 10.0 | 11.9 |

Average execution time (ms) | Match (%) – high quality | Nonmatch (%)–Low Quality | ||||
---|---|---|---|---|---|---|

# of Rows | # of Robots | DARA | Benchmark | Both assign neighboring row (%) | Both assign new rows (%) | Nonmatch (%)–Low Quality DARA to neighbor Benchmark to new row (%) |

30 | 5 | 0.061 | 0.169 | 72.3 | 7.80 | 19.9 |

60 | 10 | 0.081 | 0.548 | 80.7 | 5.10 | 14.2 |

120 | 20 | 0.164 | 1.564 | 80.1 | 7.10 | 12.8 |

240 | 40 | 0.590 | 6.456 | 78.9 | 8.80 | 12.3 |

480 | 80 | 2.449 | 24.066 | 78.1 | 10.0 | 11.9 |

The percentage of mismatches between DARA and Benchmark assignments reduces as *γ* increases since the increase of *γ* encourages Benchmark assignments to be within the neighboring range. This effect is shown in Table 9. In this case, there are 120 rows in the field, with the row width and length to be 2.5 m and 50 m, respectively. By increasing the discount factor, the cases where the DARA results differ from the Benchmark results can be reduced to less than 2% of total cases.

Match | Nonmatch | ||
---|---|---|---|

Gamma | Both assign neighboring row (%) | Both assign new row (%) | DARA to neighbor, benchmark new row (%) |

1.1 | 66.9 | 7.35 | 25.7 |

1.5 | 80.9 | 7.12 | 12.0 |

2 | 86.6 | 7.14 | 6.25 |

2.5 | 90.9 | 7.33 | 1.78 |

3 | 91.1 | 7.19 | 1.77 |

Match | Nonmatch | ||
---|---|---|---|

Gamma | Both assign neighboring row (%) | Both assign new row (%) | DARA to neighbor, benchmark new row (%) |

1.1 | 66.9 | 7.35 | 25.7 |

1.5 | 80.9 | 7.12 | 12.0 |

2 | 86.6 | 7.14 | 6.25 |

2.5 | 90.9 | 7.33 | 1.78 |

3 | 91.1 | 7.19 | 1.77 |

Increasing the width of each row reduces the percentage of mismatches between DARA and Benchmark assignments. Larger traveling distances between rows results in Benchmark preferring to assign rows within the neighboring range.

DARA and Benchmark assign rows outside of the neighboring range more often for smaller fleet sizes since the decreased span of the neighboring range reduces the traveling distance to get to new rows.

The DARA algorithm is designed based on the nearest-neighbor topology. If communication devices with wider ranges are adopted in the harvesting robot fleet, all-to-all communication topology and thus centralized algorithms can be used to achieve a better optimality with some latency. One of the future tasks is the detailed calculation of latency and bandwidth when using different communication topologies.

The applicability of algorithm is mainly constrained by the assumptions listed in Sec. 2. As one example, if Assumption 1 is invalid, meaning the total number of strawberries harvested is not proportional to the length a robot covered, the result achieved via this algorithm may only be a feasible solution. In this case, a stochastic optimization algorithm will need to be considered, which is beyond the scope of this study. Additionally, if collection trucks are only present on one side of the field (against Assumption 8), the distance calculation will be different. In this case, the algorithm is still applicable, but the results will be different.

## 6 Conclusions

The row assignment problem for a fleet of cooperative, small harvesting robots in strawberry fields is studied including local negotiations and a centralized fallback algorithm. The algorithm allocates a new row to a robot based on the time the robot predicts it will take to complete the row. The algorithm is validated in a Monte Carlo simulation and compared to a benchmark centralized algorithm. The results show that the algorithm finds local optimal solutions and has a lesser computational cost with superior scalability.

## Footnotes

## Acknowledgment

This work was supported by the National Science Foundation (Grant No. 1924622).

## Conflict of Interest

There are no conflicts of interest.