| Front page | | Contents | | Previous | | Next |

Autonomous weeders for Christmas tree plantations - a feasibility study

Bilag B
Proposed Systems architecture

Simon Blackmore and Spyros Fountas

The Royal Veterinary and Agricultural University, Section for AgroTechnology

To be able to achieve the behaviours noted in appendix A an inherently complex and sophisticated system architecture is needed. It must have redundant systems to achieve fault tolerance and be object oriented to remain manageable. The objects with the SA will follow the same definitions of object-oriented software in terms of encapsulation, inheritance and polymorphism. Encapsulation is of most use to us as it denotes a rigid sub-system boundary that we only need to define the interface and function at this time. Inheritance and polymorphism is a little more difficult to achieve in hardware but processing units that can fulfil the basic functions can be modified to suit particular applications. Communication between objects will only be as text messages that can be understood by people as well to allow easy analysis of the system.

The system architecture presented here has been developed to accommodate the behavioural requirements.

1.1 Background

We consider the definition of both the behaviour and the system architecture to be of paramount importance before constructing the vehicle itself. In general terms, it is a description of how a system is constructed from basics and how the components fit together to form the whole system (Albus, 1995).

Kortenkamp (1998) states that systems architecture is a set of inter-related components organized to achieve certain goals. Every component of the system has to be fully understood and to the interrelationships among the components has to be defined. Arkin (1998) states that behaviors are actually the answer to the question "What should the autonomous vehicle be able to do?" Rzevski (1995) mentions that behavior of a machine is a particular interaction of the machine with its environment over a period of time, defined by a particular set of inputs from and outputs into the environment over that period.

In general terms, at every point in time, the vehicle is faced with a variety of feasible next states to which the machine could move, and it aims to find the transition that is likely to provide the maximum long-term benefit. The maximum benefit may be expressed in a variety of ways- like the minimum risk of failure, the shortest route to a destination and the maximum utilization factor of a given machine (Rzevski, 1995).

The proposed systems architecture has been designed to accommodate the behaviors already defined. As this behavior-based system consists of a number of different behaviors that the vehicle needs to undertake to accomplish the desired tasks each element within the system must contribute to one of them. A short description of the proposed behaviors can be seen in table B.1.

1.2 Systems Architecture design

In order to achieve these behaviours an object-oriented systems architecture design was developed. To construct this design we followed the Arkin (1998) assumption that robotic architecture designs refer to a software architecture, rather than hardware side of the system.

The benefit with the proposed system architecture is that we can divide the system into elements or objects and we can deal with them independently. Rzevski (1995) also supports this concept. He states that the architecture design usually divides the product into large modules that bring together a set of conceptually related concerns, with relatively narrow interfaces between them. A narrow interface minimizes the interaction between the modules it connects to. The advantage of well-defined interfaces is that if a change has to be made in one module during the design process, no change is needed in other modules unless the interfaces are modified. This interface definition also adheres to the object oriented design philosophy.

Table B.1.
Descriptions of behaviour modes.

Each object will only communicate through high level or natural language messages. Each message will have the capability to pass specific parameters that are closely coupled to the particular message. This is the approach taken by a number of other researchers. (Konoglie, 1998 etc) The schematic diagram of the proposed system architecture is shown in Figure B.2.

In the proposed systems architecture design there are two types of objects: processes and databases. Processes execute a coherent set of tasks to achieve an overall goal. This could be pure processing of data, interfaced to sensors or closed loop control. The databases store and retrieve data on demand. Each on-board process could be realized as a processor node, with only messages being passed between them, over a common bus. The current object oriented processes and databases are described here.

Look here!

Figure B.1.
State diagram showing some of the behaviours and their transitions.

The coordinating process will be carried out in the farm office on a PC. (All other processes will be realised on-board the vehicle) It is likely to be a set of optimisation routines that can be instigated by the farm manager. High-level requests can be made, such as monitor the crop in field 10 for 2 days or carry out intra-row weeding in field 5 with implement number 2. The coordinating program can then allocate resources, (e.g. which vehicles to use) prepare an initial route plan based on the GIS and develop a suggested instruction set for the vehicle(s). The manager can then review the proposed itinerary and make adjustments to it before it is then downloaded to the vehicle(s). The coordination process will also be in on-demand communication with the vehicles and show the manager the current location and status of each machine. A real-time video link to steer able on-board cameras would also allow a better understanding of the vehicle’s environment.

Look here!

Figure B.2.
The proposed system architecture.

The supervising process will be hosted on a laptop computer on the vehicle. Firstly, it will relay the appropriate tasks to be executed from the coordinator through a radio modem. Secondly, it will supervise different states of the vehicle and keep a transaction log file of all the messages on the bus. Thirdly, it will present the current status of the vehicle, as a mimic, on the computer’s monitor to allow an operator to interact with it directly.

It is not directly used within the control loop but is one of the redundant systems that can supervise the other processes. It will have an expert system that can decide if any of the processes may be malfunctioning, in which case it can then intervene. The expert system can hold a set of sensible parameter values for comparison with what the processes are sending. It can also send simple requests to each process and check that it gets an expected reply. If it receives an unexpected reply then further checks can be made to identify the situation and take suitable actions like reset the process or shut down the whole vehicle into one of the safety modes.

The mode changer is a process that can assess the current situation from other processes and command each process to switch into a particular mode that can allow an appropriate overall behaviour. It may receive an imperative command from the coordinator, through the supervisor, for the vehicle to go to a particular position. It will check all processes to establish it is safe to switch modes and then issue the appropriate command to each process. An example would be where the manager instructed the vehicle to navigate to a particular Easting and Northing near by. If each process responded that it was nominal, capable of accepting a new mode, and that the implement was secured ready for transport, then each process could be configured to allow the vehicle to navigate to the required position.

Identified messages are: Navigate(Easting, Northing, Time of arrival), Implement task(mode), Refuelling(), Self check(), Explore(), Idle(), Safety(mode), Status(), Reset(), Load program(File Name).

The route plan generator can accept a completed route plan from the route planner in the coordinator or generate its own when asked to navigate to a certain position. It will generate a series of waypoints that the vehicle will follow to arrive at its final destination at the desired time. The waypoints will take into account all the prior knowledge in the GIS, such as gateways, preferred paths and tracks, as well as obstacles such as fences, ditches and public roads. At this stage of the planning it is assumed that the vehicle will travel on the straight line between the waypoints, so careful positioning is crucial if the vehicle is to stay on a narrow curving track. These series of points will be optimised for efficiency of the task in hand (minimum distance would be one criteria), such as to provide the best route to start at a gateway, go down every row in a field and come back to the gateway, avoiding the known obstacles. This route plan is predetermined before the vehicle moves and includes the estimated time of arrival at each waypoint, knowing the start time, end time and distance to be travelled. If the arrival time at the target position computes to unrealistic speeds for the vehicle then a warning will be given to the operator. The control processes will not allow the vehicle to be operated outside predefined limits stored in the vehicle database.

The detailed route plan generator initially calculates a series of detailed waypoints linearly between the waypoints from the RPG at a set distance apart and sends steering and speed messages to the hardware abstraction layer to move towards the next target position. As the vehicle gets to within a certain distance from a detailed waypoint, it switches to the next one in the series. This process will continue until it reaches the next waypoint, unless there is an obstruction in the way.

If an object is sensed within a predefined range and bearing of the vehicle, then the DRPG will stop the vehicle and wait. If the range and bearing of the obstacle changes, then the DRPG will consider it to be a mobile obstacle and wait for it to move outside the safety range and resume its navigation. If the obstacle moves towards the vehicle then it will be seen as a threat and warn the mode changer. If the object appears to be stationary, then its estimated boundary will be entered into the GIS and the vehicle will try to circumnavigate the obstruction.

An obstacle will be deemed an obstruction if it is likely to interfere with the movement of the vehicle or attached implement. If an obstacle is sensed by the obstacle tracking processes to be within the working safety envelope, (derived from the tractor envelope in the tractor database and the implement envelope from the implement database) a new detailed waypoint will be generated to take the vehicle towards the next waypoint but at a safe distance from the obstacle. At this stage, the DRPG does not know the size or the extent of this unforeseen obstacle, so it must rely on the sensors to estimate the distance and plan the next detailed waypoint accordingly and update the GIS for future reference.

1.2.6 Multiple obstacle tracking

This process runs in parallel all the time with the other processes and uses sensors to search the local environment around the vehicle for any obstacles. It can estimate the range and bearing (relative to the vehicle) of a number of obstacles within its sensing range and make a special note of the nearest one and passes this to the DRPG and the safety process. (not shown in the diagram).

The navigation process described so far has assumed a two-dimensional world, i.e. all obstacles are of infinite height, as is the tractor and implement. The object classification process may be needed to deal with three-dimensional objects interacting with the three dimensional vehicle. If there is a small obstacle (e.g. a small stone) in the way, can the vehicle go over it, or should it go round? This complex issue would need a separate model of the tractor and implement.

The hardware abstraction layer object receives the bearing and speed messages from the DRPG and then implements it on the physical platform. It will use an inverse kinematic model to determine the steering angles and wheel speeds before controlling the actuators. Each actuator will also have a transducer to measure the actuator to ensure accuracy. Closed-loop feedback will be used at a number of levels to ensure reliability, but all loops will be within the HAL object (apart from the GPS messages) as the stability of closed loop feedback requires fast responses which cannot be guaranteed over the bus. As the vehicle is encapsulated within the HAL object, no process can get direct access the vehicle control system unless it goes through the HAL.

The self-awareness process also runs parallel and independently all the time. A wide range of sensors on the vehicle supply information about the vehicle and implement hardware components such as position, attitude, engine temperature, fuel capacity and implement logistics. A number of other sensors provide information related to local environment such as altitude, air speed and air temperature from a mobile weather station. All of these data are used to update the GIS database and to send messages to the safety process to decide if there is a need to shut down in adverse weather conditions or unusual situations, like if the vehicle turns over or gets stuck in mud.

The implement task process is highly specialised to the particular activities of the implement. It gets data about the implement from the implement database and has control over the whole vehicle whilst active. Examples of a task could be mechanical weeding, selective harvesting etc.

Contains information about tractor dimensions, wheelbase length and width, ground clearance, minimum turning radius, fuel capacity, maximum temperature, maximum speed, navigation speed as well as any other parameters considering important for the autonomous vehicle.

Contains information about implement dimensions, implement-working dimensions, task working speed as well as any other parameters considering important for the implement task.

1.2.13 GIS database

The geographic information system (GIS) is the main database to store all the spatially related data. Earl, R., Blackmore, S. et al (2000) state that the GIS is essential for generating the field operations maps for autonomous vehicles. GIS database can contain information from an asset survey, provides all the permanent spatial attributes of the field, pertinent to field operations, transient data, provides attributes of a field that change during the growing season, e.g. crop structure and soil nutrient status and field operations maps.

| Front page | | Contents | | Previous | | Next | | Top |