Heuristic cooperative coverage path planning for multiple autonomous agricultural field machines performing sequentially dependent tasks of different working widths and turn characteristics

Coverage path planning is a central task in agricultural field operations such as tillage, planting, cultivation, and harvesting. In future visions, manual operation will be replaced by fleets of autonomous agricultural vehicles that perform the tasks autonomously. A step towards this transition is to enable simultaneous and safe cooperation of autonomous vehicles on the field. In this article a novel approach is presented for coverage path planning (CPP) for two autonomous tractors that perform sequentially dependent tasks simultaneously on the same area. The approach is based on the idea of computing the coverage solutions for each task by dividing them into short paths that consist of a swath and a turn. The approach ensures collision avoidance by examining that the simultaneous short paths, operated by different tractors, do not collide geometrically, and then schedules them to be operated simultaneously in real-time. The approach was demonstrated successfully in a real-world test environment with two autonomous tractors. The tractor that performed the first task was equipped with a disc cultivator and the second tractor was equipped with a seed drill. A test area of 0.8 ha was used for the demonstration drive, during which the tractors drove 22 swaths simultaneously. Both tractors completed their respective tasks.


Introduction
In the visions of future farming, autonomous vehicles carry out field work in open fields.As many agricultural fields are not fenced in broad acre farming, safety must be considered in order to enable autonomous systems.In most cultivating operations, the work requires power and material to be moved back and forth -especially in sowing, planting, and harvesting operations, but also during crop growth.Hence, as the work cannot be carried out only with miniature vehicles, the safety must be handled with large machinery either by technological means or by keeping a human in the loop.
A proposed intermediate step on the way to fully autonomous operations is to have one human required in the field.The human operator is sitting on-board one of the autonomous vehicles and the fleet of autonomous vehicles are working in the same field.While the human operator is able to monitor all vehicles in the area, for safety reasons, the operator may also assist with manual operations if required, e.g. to refill tanks or to rescue a vehicle in trouble.In the foreseeable near future, human operators are also needed to transport the vehicle fleet from one field plot to another.
In this article, the aforementioned scenario is studied with multiple tractors working in the same field, with an additional requirement that the tractors work on different tasks simultaneously.For instance, harrowing and sowing typically follow each other, and in haymaking, raking and baling operations may be done simultaneously in the same field by multiple vehicles.Harrowing is considered as one task, and sowing with a seed drill as another task, but they are spatially dependent on each other locally.
Any region in the field must be first handled with harrow before it can be handled with seed drill.Both operations per field are considered simultaneous, as the fleet will arrive and leave the field at the same time; but the second task, being dependent on the first task, may start as soon as a large enough area has been handled.
Similar procedures of simultaneous and sequentially dependent operations are applied currently in broad acre farming with no automation.The strategy may be based on dividing a large field into subplots and operating these one by one; vehicles moving from one subplot to another in a pipeline manner.Another strategy in human driven systems may be based on swaths where the field is divided in straight guidance lines that are shared by multiple vehicles and the work progress is lane-by-lane.The Controlled Traffic Farming (CTF) methodology is a permanent way to divide the field into lanes, which allows a simultaneous work by multiple vehicles.
In this article, the problem described above is studied without dividing the field into subplots, but by letting the tractors find their way on-the-go, i.e. as the work is progressed.This would allow a flexible approach, where online optimisation takes place throughout the operation.A centralised Mission Planner takes care of the optimisation and defines waypoints for each tractor in the fleet, piece by piece.The centralised Mission Planner also takes care of collision avoidance and path generation for turning.
The objective of coverage path planning is to determine a collision free path that passes over every point of an area (or volume) of interest, which is a central task in agricultural field operations.The application of coverage path planning in agriculture has been researched in various studies, and many studies also consider cooperative scenarios where multiple vehicles operate simultaneously on the same field.
In several studies, reducing field completion times has been considered by distributing one task among a fleet of multiple vehicles.Burger et al. (2013) formulated the problem of complete field coverage as a multiple Vehicle Routing Problem (VRP).The workload among the vehicles can be balanced when travel distance along the swaths is taken into account.Another coverage path planning approach for multiple agricultural vehicles was shown by Conesa-Muñoz et al. (2015), where the swaths were divided and assigned among available vehicles.A cost function with multiple optimisation criteria was used to determine the optimal track sequence including refilling for a fleet of heterogeneous vehicles.The solution itself eliminates the possibility of collisions in the mainland.Seyyedhasani and Dvorak (2017) also used a VRP formulation to reduce field completion times with a fleet of vehicles.Increasing the number of vehicles resulted in notable reductions in the field completion times with a meta-heuristic algorithm.A centralised planning and control system for a fleet of small agricultural vehicles performing a seeding task was presented by Blender et al., 2016, where planning, task assignment, optimisation and supervision were all handled by the central unit.As the vehicles are identical, the workload was distributed as evenly as possible to guarantee maximum efficiency.The swaths were assigned to the vehicles so that collisions in the main part of the field are not possible.However, to prevent collisions in the headlands/turning areas, the central unit must supervise and coordinate the vehicles.Some studies also considered cooperation of multiple vehicles with different tasks.Bochtis and Sørensen (2009) considered single and multiple primary units in neutral, input and output material flow operations.Several types of agricultural field operations involving multiple vehicles were formalised as different variations of the VRP or the Travelling Salesman Problem (TSP).The work was continued to consider also single or multiple support units in the operations (Bochtis and Sørensen, 2010).Another approach for path planning for supporting transport units was presented by Jensen et al. (2012), where the support unit cooperates with a primary unit, such as a combine harvester.However, in these studies, the support units do not perform a coverage task in parallel with the primary unit.
Some approaches to enable cooperation of multiple vehicles by local coordination have been shown as well.Zhang et al. (2009) presented a method of developing a platooning system for autonomous agricultural vehicles.The system enables an autonomous tractor to follow a leading tractor at an offset.During turning in the headlands, the following vehicle is halted while the leading vehicle turns.Vougioukas (2012) addressed the issue of avoiding collisions in multiple vehicle operations with a collective tracking controller based on model predictive control.The purpose of the tracking controller is to solve local conflicts that may have been disregarded or were not possible to anticipate in the global plan.The problem of path planning was not considered: a global plan needs to be provided by a higher-level planner.
Only a small number of studies exist that touch on the challenge of coverage path planning with sequentially dependent tasks.The concept of sequential in-field operations was discussed by Zhou et al. (2015), but for the purpose of supporting field operational decision-making at a management level.Wu et al. (2020) developed a method to update the available workspace for multiple sequential operations.However, the method is not a solution to the sequentially dependent robotic problem.The main result of the work by Wu et al. (2020) was an algorithm to update the available areas to be worked on that can aid the tractor operator to choose the next track to work on.
To summarise, the relevant cooperation scenarios can be roughly divided into the following three cases: 1) A primary unit is collaborating with a support unit.Both units are needed to complete a common task.The primary unit cannot continue its work until the support unit has performed its task.For example, harvesting and unloading.2) A task is divided among several independent primary units.Several units provide redundancy: all units are not necessarily needed to complete the overall task.Field completion times can be reduced compared to using a single vehicle.3) Several primary units are performing sequentially dependent tasks.
Having two units performing two tasks, the second unit is not needed to complete the first task.The second unit can only work on areas that the first unit has already processed.
Many studies have considered different types of cooperative scenarios where multiple vehicles operate simultaneously on the same field.However, a thorough search of the relevant literature yielded no related work where two (or more) vehicles perform sequentially dependent individual coverage operations simultaneously on the same field, fully autonomously, while sharing the same workspace.In the light of these findings, the challenge of cooperative coverage path planning for sequentially dependent operations is still an open problem.
The contribution in this paper is threefold.First, a novel algorithm is presented to route two tractors carrying out two sequentially dependent coverage tasks.Second, the real-time capability of the algorithm is ensured by 'slicing' the implementation so that return values are provided within the control loop cycle time, independent of if the computations are completed.Finally, the solution is tested in a real-world experimental test environment with real tractors and implements.In the demonstration setup, a disc cultivator is connected to an autonomous tractor with a cab (where the operator is sitting) and a seed drill is connected to a cabless autonomous tractor.

Problem formulation
The general problem of CPP with sequentially dependent tasks can involve any number of autonomous vehicles.For the purpose of this study, the problem is simplified to the two-vehicle case.In addition, while this solution to the problem is task agnostic, in the example harrowing and sowing are used as the consecutive tasks.In this case, the mission can be defined as the following: 1) Two different operations (tasks) are to be performed on an agricultural field • Harrow the field area (1st task) • Sow the field area (2nd task) 2) The tasks require two tractor cooperation • One autonomous tractor with human operator • One driverless autonomous tractor 3) The tractors are operating on the field simultaneously 4) The tasks are pre-allocated • The autonomous tractor with human operator performs the 1st task (harrowing) • The driverless autonomous tractor performs the 2nd task (sowing) 5) The tasks are strictly sequential • The 1st task is independent (can be performed on any unprocessed area) • The 2nd task is dependent (can only be performed on areas where the 1st task has already been performed) 6) The tractors are equipped with hitch-mounted implements • The tractor that performs the 1st task is equipped with a disk cultivator • The tractor that performs the 2nd task is equipped with a seed drill

Basic idea of the algorithm
A solution is developed to the problem of sequentially dependent coverage path planning that makes use of one turn and a swath as the smallest planning unit.In other words, the coverage path for each tractor is planned one turn and a swath at a time.To complete the entire coverage task, this computation is repeated online until both tractors have finished work on all of their swaths.
The first part of the solution is computed once at the beginning of the algorithm: the field is divided into a headland and a mainland for both tractors based on the dimensions of their implements, and the centrelines for all headland and mainland swaths are computed.For both tractors, compute the following steps: 1) Determine the headland swath centrelines based on the desired amount of headland swaths and the implement width 2) Determine the mainland swath centrelines based on the remaining area and the implement width These swath centrelines, when accurately traversed by the tractors with their implements, provide a geometrical solution to the complete coverage of the field.The rest of the solution, i.e. traversing these centrelines, is computed iteratively online by repeating the following steps: 3) Revise the available swaths for the 2nd tractor after each iteration 4) For both tractors, optimise the next swath based on time efficiency 5) For both tractors, choose the best swath 6) For the 1st tractor, calculate the turn to the beginning of the chosen swath 7) For the 2nd tractor, exclude from the turn area the collision zone of the 1st tractor's path 8) Check that the swath for the 2nd tractor does not collide with the path of the 1st tractor • in case of collision, choose the next best swath for the 2nd tractor and repeat step 8) • in case of no collision, use the current choice of swath for both tractors 9) For the 2nd tractor, calculate the turn to the beginning of the chosen swath 10) Check that the final paths do not collide • in case of collision, cancel routing for the 2nd tractor • in case of no collision, route both tractors according to the current solution Fig. 1 illustrates the basic idea of the algorithm following the 10 steps that are presented above.Step 10) finishes one iteration of the algorithm.If a collision is detected in step 10), it means that none of the remaining swaths for the second tractor was collision-free with the path of the first tractor.In this case, the routing for the second tractor is cancelled, and it will wait until the first tractor has finished its next turn and swath.This and other details of the computations in each step are described in the following sections.
In addition, on each status update from the tractors their coverage area maps are updated.This is especially important for updating the available swaths for the 2nd tractor.Fig. 1(c) illustrates the computation of the continuous status update of the coverage map of the tasks.Note that the illustration is simplified so that the implements of the tractors have the same width.

Initialisation and parameters
The algorithm is initialised with two different maps that describe the geometry of the field, and several parameters that describe the tractors and allow the modification of the algorithm behaviour.Two different maps are used so that different regions can be defined for the work area and the turn area on the field.However, the work area must be either equal to the turn area or completely contained inside the turn area.In addition to the field geometry, several parameters are needed to initialise the task.Most of the parameters are used to define the tractor characteristics and to modify their individual behaviour during the task.For example, the swaths are generated based on the implement width and an overlap parameter that are defined separately for both tractors.

Headland and mainland swaths
The swath centrelines for both headlands and the main part of the field are precomputed for both tractors.A polygon representation of the field boundary is required as input for computing the swath centrelines.The location of the centrelines inside the field boundary depends on the implement dimensions and the amount of headland swaths, and therefore the centrelines can be different for different tractors.Fig. 2 shows an example of the precomputed swath centrelines for a convex area.
A headland is created everywhere around the field area.In many cases it is not necessary, but it does provide some flexibility for turning and for determining the operational swaths afterwards.This approach also guarantees that the corners of the field can be operated when the turning area is limited to the field.
In the algorithm, the headland width is determined based on the width of the implement and the number of headland passes, which is decided by the user.Therefore, the algorithm does not compute a headland based on the turning radius of the tractors.The headland is created for a proof-of-concept, and in the final application the headland creation should consider the turning characteristics of the tractors, if the turns are to be limited to the headland.
A polygon offsetting algorithm is used to generate the outlines of the headland swaths.The field boundary is inset by a distance derived from the implement width.To obtain four nested rounds of swaths in the headland, the insetting is performed four times.The resulting polygons are later referred to as headland swath polygons.An open source freeware library called Clipper (Johnson, 2010) was used for the offsetting.The offsetting also determines the inner headland boundary, which is equal to the main field boundary.The outer headland boundary is equal to the whole field boundary, and the inner boundary is determined by the number of headland swath polygons and the implement width.
The final headland swaths are determined from the headland swath polygons.For an arbitrarily shaped polygonal field, some vertices of the headland swath polygons can be too sharp to drive along the edge without lifting the implement and making a turn at the vertex.Such a vertex is referred to as a critical vertex.The criticality of a vertex is determined based on the directional change between a previous and a following line segment (Oksanen, 2007).All critical vertices in the headland polygons need to be converted into two new vertices, and between these vertices a turn has to be made.A separate turn path algorithm is used to generate the actual turning path between the vertices and, in the end, the turn can also be made to another swath (for example to a main field swath) rather than to the next headland swath.
The two new vertices for each critical vertex are determined by extending and cutting the headland swath polygon edges that meet at a critical vertex.All critical vertices of all headland swath polygons are processed.If the angle at a critical vertex is convex, for each headland polygon, in the processing order of the vertices, the previous edge of the polygon is extended to intersect the outer headland boundary.The new swath endpoint is at the intersection.The following edge of the polygon is cut based on a line that is extrapolated from the inner headland boundary.The new swath endpoint is at the intersection and the line segment between the original critical vertex and the new swath endpoint vertex is removed.If the angle at a critical vertex is concave, the roles of the inner and the outer headland boundary are simply switched.
With this approach, the headland swaths are generated so that the headland can be processed even when the tractors need to always stay inside the field boundaries.This also requires that the headland swaths can only be driven in one direction beginning from the endpoint that is located on the outer or inner boundary of the headland.
After the headland swaths have been generated, the main field swaths are generated to cover the main field area.The inner headland  boundary is equal to the main field boundary.For the purposes of this study, it was considered sufficient to consider only simple convex polygons.Therefore, the main field swaths are simply generated as being parallel to the longest edge of the mainland boundary.The spacing between the swaths depends on the implement width and an optional overlap.
While the general purpose of the headland is to provide a turning area for the tractors, in the experimental test in this study the headland was created for a proof-of-concept.The focus of this study is on the sequentially dependent and parallel work, and the turns between successive swaths have not been limited to the headland area.

Start position and first swath
Both tractors can begin their tasks from an arbitrary position inside the whole field boundary.Choosing the first swath is optimised in the same way as choosing the next swath at each decision point.This feature is helpful for testing purposes but for the purpose of comparing different algorithms it should be noted that the start position does affect the overall order of the swaths.This will affect the overall optimality of the solution and also the possibility that at some point both tractors cannot be routed simultaneously.

Swath order optimisation
The driving order of the swaths for both tractors is decided swath by swath during the task.At each decision point, only the next turn and swath are determined and then calculated.The next swath should be chosen for both tractors before the tractors reach the end of the current swath.The optimisation of the swath order is done individually for both tractors and in the end, the optimality of the combined solution is not guaranteed.
The 1st tractor is allowed to drive any of its swaths from the beginning of the task.For the 2nd tractor, a swath is available only if it covers an area that has already been processed by the 1st tractor.An individual list of the remaining available swaths is maintained for both tractors.After computing the efficiency of all available swaths, they are ordered accordingly.When deciding the next swath, the ordered list is used to choose the best possible option.When a tractor has completed a swath, the swath is removed from its list of available swaths.In addition, the mainland swaths can be driven in either direction.The efficiency is obviously different for each direction since the duration of the turn is different at each end of the main field swath.Therefore, each main field swath is considered twice in the list of available swaths and both instances are also removed once the swath is completed.
The swath order optimisation for each tractor is based on time efficiency according to Equation (1).All possible options for the next swath are compared, one step into the future.An additional constant c is included in the equation to allow a prioritising of the headland swaths if necessary.For the first tractor the value of the constant was set to 0.1 to prioritise the headland swaths in the test drive.Time efficiency of a swath including the turn to the beginning of that swath is defined as: It should be noted that optimality of the overall route for each tractor cannot be guaranteed for two reasons.First, only the next swath is considered in the optimisation.To ensure a more optimal overall solution the optimisation of the next swath should be extended further in the optimisation horizon to include several decision points (Oksanen, 2007).Second, even if the available swaths were ordered optimally, it cannot be guaranteed that the most optimal swath can eventually be chosen for both tractors, if the paths to process those swaths are in conflict.

Turn path calculation
A turn path calculation algorithm is required to compute paths between two successive swaths.The algorithm that was developed for the turn path calculation takes start and end positions and orientations as inputs in addition to allowed turn areas.Based on these inputs, it can generate feasible turn paths that consider tractor dynamics, such as minimum turning radius and the angular velocity of the wheels of the vehicle.Additionally, it can consider obstacles and generate turn paths even if the successive swaths would be on the other side of the field (Väyrynen, 2019).
The turn path calculation algorithm consists of two phases: path generation and smoothing.The path generation combines analytical Reeds-Shepp paths (Reeds and Shepp, 1990) with the numerical A* algorithm (Hart et al., 1968) -a combination that is called Hybrid A* (Montemerlo et al., 2009).This hybrid approach is computationally more efficient and accurate than purely numerical methods, while being able to avoid obstacles and field borders unlike analytical methods.However, the paths produced with this approach have a discontinuous curvature derivative, which means that the tractor would have to occasionally stop to reorient its wheels to follow such a path accurately.The numerical gradient descent-based smoothing solves this problem by relocating path points to minimise curvature and maximise path linearity (Väyrynen, 2019).
In practice, the turns that are generated by this grid-based turn path algorithm before smoothing consist of Reeds-Shepp curves, which are either straight lines or circular arcs.Both reversing and driving forward are possible.To arrive from the start location to the end location, the possible combinations of these curves are searched over a grid, resulting in a path where the start and end are connected by a sequence of these curves.Finally, a smoothing algorithm is applied to the generated turn path.This algorithm is capable of also generating long turn paths that consist of long straight sections combined with Reeds-Shepp-like curves to arrive at the precise start and endpoint of the turn.For example, a fishtail-type turn is possible.In addition, the algorithm can estimate the time it takes to drive the turn.

Conflict detection
A means to detect possible collisions is necessary when the path for each tractor is planned individually.For safety reasons, a final validation is performed on every solution before forwarding new waypoints to the tractors.A simple method for conflict detection was implemented with polyline buffering and a Boolean operation on polygon overlap.
To determine whether two paths are in conflict, the path of each tractor is buffered with a collision zone based on the tractor dimensions and a safety margin parameter.The tractor dimensions and the safety margin parameter define the buffer distance.Given the path and the buffer distance, the buffer polygon is computed by moving a circle of radius equal to the buffer distance along the line segments defined by the path.If the resulting polygons overlap, the paths are considered to collide.
An example of a conflict of two paths is shown in Fig. 3.The original paths are shown with red and blue polylines.The corresponding collision zone polygons are shown in red and blue.The overlap is determined by a polygon overlap function readily available in Matlab.

Updating the coverage map
A map of the unprocessed area is maintained for both tractors.The area is represented by a polygon consisting of several vertices, one polygon for each tractor.The status updates of both vehicles are received at approximately even time intervals.The area that was processed between two consecutive status updates is calculated based on the implement working position, Global Navigation Satellite System (GNSS) data and the dimensions of the vehicle and the implement.At each status update, this calculation is done for both tractors.The processed area of the first tractor is used to update the available swaths for the second tractor.
To track the unprocessed area, the method begins with a polygon that equals the boundary of the whole field.The polygon is modified at each status update by subtracting the area that was processed between the newest and the previous status update.The implement position between the two status updates is determined from the hitch level values.A polygon is only calculated for the processed area if the implement was lowered.This polygon is always a trapezoid approximation of the area that was actually processed between the two status updates.The tradeoff between a long and a short time interval between two consecutive status updates is between the mitigating the impact of GNSS noise on the resulting unprocessed area boundary and increasing the accuracy of the calculation.
The GNSS coordinates and heading define the position and orientation of the tractor.The endpoints of the implement are calculated based on the placement of the GNSS receiver on the tractor and the dimensions of the tractor and the implement.The distance between the two positions in two consecutive status updates depends on the time interval and the velocity and acceleration of the tractor during that time.The updated unprocessed area is obtained by subtracting the resulting trapezoid from the unprocessed area polygon.

Updating the available swaths for the second tractor
The second tractor is allowed to drive only those swaths that cover an area that the first tractor has already processed.Continuous update of the progress of the first task is needed to update the available swaths for the second tractor.Instead of tracking the area that has been processed, the area that is unprocessed is monitored.Then the available swaths for the second tractor are the ones that do not overlap the unprocessed area of the first tractor.The polygonal coverage area for each swath is determined from the previously calculated swath centrelines.If the coverage area of a swath does not overlap the unprocessed area of the first tractor, the swath is marked as an available option for the next optimisation.
When the swaths for both tractors are placed in the same orientation it is most likely that new swaths for the second tractor will only be available when the first tractor has completed a swath, not while the first tractor is still processing the swath.Therefore, the available swaths for the second tractor are revised only when the tractors have reached the end of the previous swath.

Practical constraints of tractors and navigation
In real-life there are various error sources and non-ideal circumstances concerning modelling and measurement.For example, the tool cannot be lowered or lifted instantly, all the dimensions or the minimum turning radius of the tractor cannot be measured exactly, a good driving speed may depend on the field conditions, etc … Therefore, several tuning parameters and additional processing routines were included in the algorithms.
To ensure that the tool is lowered correctly at the beginning of a swath and lifted correctly at the end of a swath, two additional entry waypoints and two additional exit waypoints are generated for each swath.Each swath then begins with two entry waypoints, followed by the waypoints of the main part of the swath, and ends with two exit waypoints.The main part of the swath can consist of several waypoints, especially if the swath is curved.
A lower speed set-point (0.5 m s − 1 ) for all entry and exit waypoints is used for precision purposes, instead of the working speed set-point.The tool is lowered during the second entry waypoint and lifted during the second exit waypoint.Therefore, the tool is safely lifted during lower driving speed and only after and before a turn between successive swaths.
The length of the entry and exit waypoints can be adjusted as well.The length can be adjusted for example to accommodate different speeds and acceleration limits of the tractors.This is also useful for tools that process the soil in two phases.For example, the disk cultivator used in the tests of this study has two rows of disks to process the soil.Therefore, the tool may need to be lowered earlier and lifted later at the beginning and the end of a swath.
By adjusting the parameters involved in the computation of the swath centrelines it is also possible to adjust the overlap between adjacent swaths.These parameters can be used to ensure that there is no gap left between adjacent swaths despite GNSS noise or other possible error sources.

Software tools and framework
A Matlab class called Mission Planner was developed in Matlab (The MathWorks, Inc., Natick, Massachusetts, USA) and the cooperative coverage path planning algorithm was implemented as a class method of the Mission Planner class.The Mission Planner class implementation can be used from Matlab, but it can also be assembled into a Dynamic Link Library (DLL) to be used from a C# program.A set of interface functions and a function call proxy were written to be assembled into the DLL.To be able to use the Mission Planner class via the DLL, the call proxy holds a persistent instance of the Mission Planner class.The purpose of all the interface functions is to forward the function call they receive to the call proxy, which in turn calls the corresponding class methods of the persistent instance of the Mission Planner class with the given input values.

Simultaneous paths
The first part of implementing the cooperation is to compute two non-colliding paths, a turn and a swath, for each tractor.Once the paths are solved, they are scheduled in real-time.An algorithm that is based on a state machine was developed to solve the two paths.The algorithm was implemented as a class method of the Mission Planner Matlab class.The method call always returns three values ready, waypointVehicle1 and waypointVehicle2.
The algorithm is sliced so that one method call will return in less than 100 ms in normal operation.During one method call, the algorithm will advance not more than to the next state of the state machine.If the computation during a state takes more than 100 ms, the method will return nevertheless, and continue from where it left once the method is called again.The method always returns between state transitions.Therefore, one function call to the algorithm equals one state of the state machine at most.If there are no new waypoints for either of the tractors, the last waypoint is returned again in waypointVehicle1 and/or way-pointVehicle2 in each method call.
One turn and swath solve cycle of the algorithm state machine yields the next action for both tractors.The return value ready is assigned true when one cycle of the algorithm is complete.If both tractors can be routed, the actions for both tractors consist of waypoints for a turn and a swath.If there was a conflict that could not be solved, the second tractor will not receive any new waypoints.During the execution of the next action the second tractor will wait where it is currently located.

Real-time scheduling
The second part of implementing the cooperation is to schedule the two paths in real-time.The Mission Planner solves simultaneous nonoverlapping paths for the tractors but does not schedule them.For the real-world field test, the Mission Planner Matlab code was assembled into a DLL that can be used from a C# program.
In the real-world field test, the Mission Planner class method that corresponds to the cooperative path planning algorithm is called in a 100 ms cycle in the C# program that is responsible for the real-time scheduling.An input value called restartOptimisation is used to control the progress of the algorithm, and each method call always returns three outputs ready, waypointVehicle1 and waypointVehicle2.
The value for output ready is true only if the algorithm has reached the end of the algorithm cycle and the next action for the tractors is ready.Then the algorithm remains in the last state of the state machine until the method receives a restart command from the C# program.To proceed to the next algorithm cycle, the input value restartOptimisation is set to true for one method call and then set to false again.The time it takes for the Mission Planner to compute the next action is indeterminate.When the next action has been computed successfully, the new waypoints are returned one by one in the output values waypointVehicle1 and waypointVehicle2.
The output values waypointVehicle1 and waypointVehicle2 always contain one waypoint for each tractor.If there are no new waypoints the last waypoint is output again.If the new waypoint that was received from the Mission Planner is the same as the previous one, then the last batch of waypoints (turn and swath) were received and new waypoints are not expected before the algorithm is requested to solve the next turn and swath.
When the waypoints for the next action have been received in the C# program, they are scheduled for execution by sending them to the tractors at the right time.To safely schedule the new waypoints for the tractors, the C# program verifies that the tractors have completed all the previously sent waypoints.The waypoints are sent one by one for both tractors, ensuring that a positive acknowledgement is received for each waypoint before sending the next one.
If the paths are not scheduled in this way, a collision could happen between the previous and the current action because the Mission Planner only validates that the two simultaneous paths that it computes do not overlap.Because the Mission Planner only computes paths, not trajectories with time synchronisation, it is impossible for the Mission Planner alone to fully verify that the tractors cannot collide.
The tractor status feedback is updated to the Mission Planner with the same 100 ms interval as the C# program calls the Mission Planner path planning algorithm.The status feedback is used to update the coverage map of both tasks.The coverage map of the first tractor defines the available swaths for the second tractor.

Communication
User Datagram Protocol (UDP) is a connectionless transport layer communication protocol in the Internet Protocol (IP) suite.Three different types of UDP messages are used for communication between the C# program and the tractors.One message type is used to send new waypoints from the C# program to the tractors.Individual messages that contain one new waypoint are sent for both tractors.Because UDP gives no guarantee of either delivery or order of arrival, an acknowledgement is expected from the tractors for each waypoint message.In addition, both tractors send their status messages (including current position and hitch data) to the C# program every 100 ms.The UDP messages are sent over Ethernet.

System architecture
The system architecture and hardware of the experimental test setup is illustrated in Fig. 4.Both tractors have a navigation computer that is connected to the tractor bus.The navigation computers communicate over a radio link.The mission planner computer is physically located in the 1st tractor, and it is connected to the navigation computer of the 1st tractor.Fig. 4 also highlights the differences of the tractor dimensions and other parameters.

Tractors
The cooperative real-world test scenario involved two tasks and two tractors.The first task was to perform secondary tillage on the field with a disc cultivator and the second task was to sow the field with a seed drill.The first task was assigned to an autonomous tractor with a human operator.The second task was dependent on the first task and it was assigned to an autonomous driverless tractor.
The tractor that performs the first task (secondary tillage) was a Valtra prototype.A human operator is always needed in the tractor.The tractor is able to follow a given path on its own but to change gear from forward to reverse, or vice versa, a lever needs to be operated manually.The navigation system requests the driver to change gear when necessary.The tractor was equipped with a hitch-mounted Multiva Disc-Master 300 offset disk cultivator (Dometal Oy, Loimaa, Finland).An image of the tractor with the disc cultivator is shown in Fig. 5.The disc cultivator has a roller and two rows of cultivation discs.The cultivation depth can be controlled by adjusting the position of the roller.The disc cultivator weighs approximately 2000 kg and has a working width of 3.0 m.
The tractor that performed the second task (seeding) was originally built by Modulaire Oy, Finland, but the control system was later reconditioned completely.The wheelbase is 2.7 m and the tractor weighs 5900 kg.Each wheel of the four-wheel steered tractor steers a maximum 22 • .The steering rate is limited to 8-12 • s − 1 , and therefore the operating speed of the tractor in accurate navigation is limited to 2.0 m s − 1 (Oksanen, 2015).The tractor is driverless and does not have a cabin.The tractor was equipped with a hitch-mounted Tume KL-2500 combined seed drill (Tume-Agri Oy, Turenki, Finland).An image of the tractor with the seed drill is shown in Fig. 6.The seed drill weighs approximately 1000 kg and its working width is 2.5 m.

Hardware and communication
The communication between the tractors and the mission planning computer was implemented over Ethernet and UDP.Both tractors had a navigation system computer on board and they sent and received messages over UDP.The messages to and from the second tractor were sent over a radio link.The radios that were used in the experimental setup are RFD868x-EU Modem by RFDesign (Brisbane, Australia).The manufacturer reports 20 km range or more for these modems.No communication timeouts were observed in the tests.Both tractors were equipped with Real-Time Kinematic (RTK) GNSS receivers.The computer that runs the cooperative path planning algorithm during the test drive was a Dell Latitude E5470 laptop with an Intel Core i5-6300U CPU rated at 2.4-2.5 GHz using 8 GB of RAM.The operating system was Windows 10 Pro.During the test drive the mission planning computer was in the 1st tractor with the disc cultivator that performs the first task.

Test field
The test field that was used for the real-world field tests is in Vihti, Finland.A rectangular area of 0.8 ha (80 m × 100 m) was used for the test drive that is presented in this paper.An aerial image of the test field area is shown in Fig. 7.The boundary of the test field is shown with a black rectangle.There are minor differences in altitude across the field.

Demonstration
The total duration of the test drive was approximately 1 h and 42 min.For both tractors it took around 55 s to drive one swath.An aerial image of the test drive is shown in Fig. 8, where the first tractor is in the beginning of its third to last swath.The second tractor is working on an area that has already been harrowed by the first tractor.

Mission progress
Step-by-step progress of the experimental test drive is visualised in Fig. 9, based on GNSS data from both tractors.The steps are in chronological order from left to right, top to bottom so that the first step is shown in the top left (step (1)).Each sub-figure shows one step, i.e. one turn and swath for both tractors.The blue trace is for the first tractor and the red trace is for the second tractor.Bright colours indicate that an action that was being done during the current step, and pale colours indicate past actions.A thin line signifies a turn, i.e. when the implement was not in the working position.The painted area indicates the area that was operated on, i.e. when the implement was in the working position.The asterisks show where the tractors were at the beginning of each step.If only the asterisk is shown for either tractor, it implies that the tractor   For example, during steps 1-7, the first tractor is working on the headland, while the second tractor has to wait.The second tractor starts its task at step 8, making a long turn to the opposite side of the test field.A mistake in the processing of the headland for the first tractor is amended manually after step 39, while the algorithm continues routing the second tractor automatically.Both tasks are completed after step 59, and no actions are done in the final step (step 60).However, the second tractor did not achieve 100% coverage at this point, and the causes of this are discussed later.

Amount of simultaneous work
All the algorithm steps during the test drive are shown in Fig. 9. Due to the sequential nature of the tasks, the second tractor must always wait at the beginning of the mission while the first tractor has not yet completed any swaths.The first tractor is idle at the end of the mission while the second tractor completes its last swaths.If the implements of the tractors are of different width, then the number of swaths is different as well.
During the test drive, the algorithm produced 57 steps where at least one of the tractors was working.Of these 57 steps, the tractors were working simultaneously during 22 steps (38.6 %).The second tractor had to wait during 15 steps (26.3 %) and the first tractor was idle during 20 steps (35.1 %).The solution for the tractors to complete their own tasks consisted of 37 swaths for the first tractor and 42 swaths for the second tractor (the disc cultivator is wider than the seed drill and therefore the first tractor had less swaths).Therefore, the second tractor had five more swaths to work on than the first tractor.During 59.5 % (22/37) of the swaths for the first tractor, the second tractor was also working, whereas during 52.4 % (22/42) of the swaths for the second tractor the first tractor was also working.

Task completion
The completion of the tasks at the end of the test drive is shown in Figs. 10 and 11.Again the blue colour is for the first tractor and red colour is for the second tractor.The colour intensity indicates the temporal order of processing the swaths, i.e. the order in which the tractors drove the swaths.The most recent swaths are more intense (darker) in colour.Black colour indicates an area that was left uncovered.
Both tractors drove all the swaths in the test drive.The task completion percentage (processed area of total area) at the end of the test drive was computed from the work area polygonal map and the polygonal coverage maps that were constructed during the test drive.The first tractor completed 100.00% of its task and the second tractor completed 96.25% of its task.The area that remained unprocessed for the second tractor was always located at the beginning or at the end of a swath.Therefore, a higher task completion percentage for the second tractor could be obtained by tuning its parameters in more detail.

Computation time
The computation times for each step of the algorithm are shown in Fig. 12.One step equals the solution for one turn and one swath for at least one of the tractors.During the test drive, the minimum time to solve one step was 1.92 s, the maximum time to solve one step was 28.86 s, the average time to solve one step was 4.68 s and the median time to solve one step was 4.05 s.
As the number of optional swaths decrease towards the end of the task, the computation time for the algorithm to solve the next step decreases as well.The need to reroute in case of a conflict increases the computation time.The total time to solve all the steps for the test drive was 280.76 s.Notice that the steps are solved during the course of the mission, not instantly one after the other.The full solution for the mission is therefore available only at the end of the mission.

Discussion
With the algorithms presented in this article it is possible to perform two sequentially dependent agricultural coverage tasks simultaneously on the same area.It was proven by tests in a real-world environment with two tractors that were equipped with a disc cultivator and a seed drill.
When measured as a percentage of total work area, the first tractor completed 100.00 % of its task and the second tractor completed 96.25 % of its task.The solution that was produced during the test drive had 57 steps during which at least one of the tractors was working on a swath, and the two tractors were working simultaneously during 22 of these steps (38.6 %).
While the tractors were working simultaneously for almost 40% of the operation, there is certainly room for improvement.One reason the algorithm did not perform as well as it could have during the test drive was that the implement of the first tractor was not lowered in time during the first headland swath.Therefore, the corresponding swath for the second tractor was not considered available until the end of the task  when the driver of the first tractor manually corrected the incomplete swath.This resulted in some steps where the second tractor needed to wait, when it otherwise wouldn't have.In addition, there will always be some amount of non-simultaneous work, since the second tractor can begin only once the first tractor has completed some swaths.In addition, the total amount of swaths has an impact on the relative amount of simultaneous work.For this proof-of-concept, a small area of 0.8 ha was used, which meant that the relative amount of simultaneous work was smaller compared to larger fields, which are more typical in practice.
In this test drive the parameters for the first tractor were adjusted so that the headland swaths were prioritised.Even if it is not necessary with GNSS guided tractors, it is common to follow this practice in tillage and sowing operations.A value of 0.1 was set for parameter c in the efficiency calculation (Eqn.( 1)) for the first tractor.Therefore, it is typical for the algorithm to begin the first task in a headland.This will likely result in the second tractor beginning its task in a headland too.The option for an arbitrary start position for the tractors could affect which headland swath they drive first.Since the tasks were strictly sequential, at the beginning of the mission it was obvious that the second tractor had to wait before beginning its task.The test drive indicated that the second tractor also had to wait when the first tractor completed the headland swaths.The turn from one main field swath to another intersected some of the headland swaths and therefore these headland swaths were not an option for the second tractor while the first tractor was working in the main field.These headland swaths are likely to be the last ones that the second tractor completes during the task.It is expected that the field size and shape will contribute to the results.With the approach that was presented in this article, the number of swaths depended on the field geometry, and obviously the number of swaths has an impact on the possibilities for proficient cooperation.For example, the safety margins for collision detection would (and should) prevent the tractors form working on adjacent swaths.It is also intuitive that a small area is generally more demanding for cooperation.
The number of swaths for both tractors was dependent on the implement widths.It was expected that the algorithm could produce a solution independent of the implement widths, given that they were sensible for the size of the work area.Due to the way that the headland swaths were placed in the algorithm, it could be beneficial that the implement for the second tractor is not wider than the implement for the first tractor.Otherwise, a situation could arise where the second tractor cannot complete the innermost headland swaths before the field is completely finished by the first tractor.However, this situation could be solved by improving the algorithm to consider this constraint during the headland creation.
Several aspects in real-world circumstances could affect the completion of the coverage tasks.One crucial requirement for the cooperation is that the first tractor can complete its task consistently.Otherwise, the coverage map that is used to update the available swaths for the second tractor is incomplete and the second tractor will not be able to complete all its swaths.For example, navigation error or GNSS noise can result in small gaps in the computation of the coverage map.If the GNSS accuracy is temporarily too low, for example the RTK correction signal is lost, the navigation stops.However, even if the navigation stops, a small gap may result in the coverage map when the task is continued.It should be noted that the completion percent of each task was also estimated based on calculations using the GNSS data and geometry.This means that there could be minor disparities between reality and the computed coverage map.However, at the end of the test drive, no major gaps were observed in the field that would not be recognisable in the coverage maps presented in the results.
Also, an inconsistent delay in lowering or lifting the implement can result in an incomplete swath.Several parameters were used to adjust this behaviour at the beginning and at the end of the swath.For example, the speed set-point for the lowering and lifting stages of the implement can be adjusted.Despite adjustment and tuning, all inaccuracy in the test drive results could not be eliminated, which is visible in the results presented in Section 5.4.The parameters for the first tractor were adjusted several times to ensure that the swaths were fully completed.The parameters for the second tractor were not adjusted in as much detail and therefore some gaps remained at the end of each swath.These gaps are visible in Fig. 11.The completion percentages for the second tractor would be higher if its parameters were tuned in more detail.
For the first tractor, the parameter for swath overlap was also set so  that there was a small overlap between adjacent swaths.This was to ensure that no gap remained between adjacent swaths, which would prevent the second tractor from completing its task.For the second tractor, no overlap was set in the parameters, but as can be seen in Fig. 11, no gaps were left between adjacent swaths of the second tractor either.
To better enable cooperation and full completion of the second task, small errors (gaps) in the coverage map of the first task could be overlooked when finding available swaths for the second tractor.Currently, only the swaths whose footprint is fully inside the area that is already processed by the first tractor are considered available for the second tractor.For example, a threshold could be defined so that when the availability of the swaths for the second tractor is updated, a gap that is smaller than the value of the threshold is ignored.
The computation times presented in the results indicated that all the available processing time was not fully utilised and that there was room for more intensive online calculation (such as optimising the swath order) during the completion of the tasks.For example, for the test area used in this study, the time it takes for the tractors to complete one main field swath was around 55 s.For most of the algorithm steps this would leave almost 50 s of time before new waypoints needed to be sent to the tractors.However, the maximum time to solve one step in the experimental test was approximately 30 s, which should be considered in a real-time application.This would leave approximately 25 s of additional processing time before the end of the swath on this specific test area.These numbers should be considered estimates, but they give a general idea of the time constraints and the available processing time.Furthermore, this was a small field and in most real-world situations the length of swaths, and the time to traverse a swath, would be considerably greater.This would increase the potential processing time per swath that could be used for optimisation and planning.
The surplus computation time could also be used to increase the adaptability of the algorithm.Computing new swath centrelines online based on the updated coverage map would increase the options for cooperation, especially for the second tractor as instead of finding the available swaths from a set of predetermined swaths, the swaths could be placed inside the area that has already been processed by the first tractor.In addition, an error in the coverage of a swath could be corrected by the algorithm later, because all the uncovered area would be considered when computing the new swaths.This would, however, increase computation requirements online.
While the algorithm was applied successfully, it has its limitations.The main point of improvement is to investigate the overall optimality of the solution.Currently, only the next swath for each tractor is considered in the optimisation, and a conflict could render it unfeasible to pick the best route for both.In future work, it is planned to increase the time horizon in the optimisation to anticipate the impact of the current actions on the overall optimality.Additionally, plans to explicitly include the overall duration of the mission, or a similar measure, in the optimisation criteria are previewed.Furthermore, it is important to develop the right metrics to assess the methods of solving this novel problem of sequentially dependent coverage tasks.Finally, support for combinations of different agricultural operations could be added by implementing decision-making for changes in the permitted area for nonworking travel.
To the best of the authors' knowledge, no other algorithm has been shown in the literature that solves this problem for two autonomous tractors performing sequentially dependent tasks.Therefore, the results are presented and discussed as is, and comparing the efficiency of simultaneous work remains for future work.It is hoped to see more studies that investigate this problem in the future.

Conclusions
In this article, an algorithm for cooperative coverage path planning for multiple agricultural field machines performing sequentially dependent tasks is presented and demonstrated.It was shown in a realworld field test that the algorithm is able to perform two sequentially dependent agricultural coverage tasks simultaneously on the same area, in real-time.
In the field test, a rectangular area of 0.8 ha was processed by two tractors.The first tractor was equipped with a disk cultivator and the second tractor was equipped with a seed drill.Both tractors were able to complete all the swaths for their tasks in the demonstration.When measured as a percentage of total work area, the first tractor completed 100.00 % of its task and the second tractor completed 96.25 % of its task.Of the 57 steps during which at least one of the tractors was working on a swath, the two tractors were working simultaneously during 22 steps (38.6 % of the time).

Declaration of competing interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
Fig. 1 illustrates the basic idea of the algorithm following the 10 steps that are presented above.Fig. 1(a) and (b) show steps 1) and 2), Fig. 1(c) and (d) show step 3), Fig. 1(e) shows step 4), Fig. 1(f) shows step 5), Fig. 1(g) shows step 6), Fig. 1(h) shows step 7), Fig. 1(i) and (j) show step 8), Fig. 1(k) shows step 9), and Fig. 1(l) shows step 10).Step 10) finishes one iteration of the algorithm.If a collision is detected in step 10), it means that none of the remaining swaths for the second tractor was collision-free with the path of the first tractor.In this case, the routing for the second tractor is cancelled, and it will wait until the first tractor has finished its next turn and swath.This and other details of the computations in each step are described in the following sections.In addition, on each status update from the tractors their coverage area maps are updated.This is especially important for updating the available swaths for the 2nd tractor.Fig.1(c) illustrates the computation of the continuous status update of the coverage map of the tasks.Note that the illustration is simplified so that the implements of the tractors have the same width.

Fig. 1 .
Fig. 1.Basic idea of the algorithm: calculate the headland swaths (a) and mainland swaths (b), update the covered area (c), update the available swaths for the 2nd tractor (d), optimise the next swaths (e), choose the best swaths (f), calculate the final turn path for the 1st tractor (g), exclude the path of the 1st tractor from the turn area of the 2nd tractor (h), check for collisions (i and j), calculate the final turn path for the 2nd tractor (k), and perform final collision check and routing (l).

Fig. 2 .
Fig. 2.An example of the precomputed swath centrelines for a field with a convex area.

Fig. 3 .
Fig. 3.An example of collision detection on two conflicting paths.

Fig. 4 .
Fig. 4. A schematic of the two-tractor experimental system architecture and hardware.

Fig. 5 .
Fig. 5.The autosteer tractor that performs the first task, equipped with a disk cultivator.

Fig. 6 .
Fig.6.The autonomous tractor that performs the second task, equipped with a seed drill.

Fig. 7 .
Fig. 7.A 0.8 ha test area for the test drive.

Fig. 8 .
Fig. 8.An aerial image of the demonstration in progress.The image was taken during step (35) shown in Fig. 9.The first tractor is the one closer to the top right corner of the rectangular test area.

Fig. 9 .
Fig. 9. Step-by-step progress of the experimental test solved by the algorithm, based on GPS data from both tractors.Blue and red colour indicate the tractors with the 1st and the 2nd task, respectively.Bright colour indicates an action that was done during the current step, and pale colour indicates past actions.A thin line signifies a turn, i.e. when the implement was not in the working position.Painted area indicates the area that was operated on, i.e. when the implement was in the working position.(For interpretation of the references to colour in this figure legend, the reader is referred to the Web version of this article.)

Fig. 10 .
Fig. 10.Area completion of the first task (harrowing) at the end of the test drive.

Fig. 11 .Fig. 12 .
Fig. 11.Area completion of the second task (seeding) at the end of the test drive.