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

Autonomous Weeder for Christmas Trees – Basic Development and Tests

Appendix B: Data processes for the cutter arm control

When active control of the cutter arm position is used (Figure 5.3), the controller needs to know where the trees (obstacles) are, or at least where the tree nearest to the cutter head is, in order to pull in the arm at the right time. Assuming a tree spacing of 1.2 m, and the dimensions and dynamics of the cutter arm and head, at most one tree will be “within scope” at any given time (i.e. the cutter arm controller will only have to consider one tree when positioning the arm – it is fast enough to reposition the arm when the next tree in the row becomes the nearest tree (and this is pretty much implicit by the nature of the desired “path” of the cutter head)).

This appendix describes:

• the ProxTree block which is executing in real-time on the xPC Target (i.e. the On-Board Computer on the ACW) and provides the “nearest tree” to the cutter arm controller,
• and the “prox” program, used “off-line” (on the host computer), to convert the measurements files to C source (providing array of tree positions, sorted for fast look-up), used when preparing the ProxTree block.

The prox_tree function takes a position as input, performs look-up in the database of trees and returns the data on the tree (with center) closest to the input position – provided that the distance is less than 1 m (configurable as DIST_LIM). Figure B1 shows how the block is used in the “ClosestTree” block.

Figure B1 Simulink block diagram showing how the 'ProxTree' block is used by the 'ClosestTree' block. The outputs 'status' and 'tree_id' are discarded.

The 'status' (which tells whether a match was found or not) and the 'tree_id' outputs are currently ignored (the default 'TreeNE' will give large distance to cutter head position and thus not trigger “avoidance” – thus an explicit look-up status or tree-ID is not needed).

1.1 Implementation

The implementation of the ProxTree block is done using an S-Function written in C according to the principles shown in Fig. B2.

Figure B2 Information flow and file relations when configuring the ProxTree block. The hooks are indicating where a file references another file, while an arrow denote processes, for instance converting arbitrary arranged measured data into a sorted list of tree positions).

The database (or array of tree records) is derived from the measurements file, using the utility “prox” (input data on 'stdin', generated C source written to 'stdout').

In order to obtain fast look-up the trees are “sorted” in the database written. The ordering is according to Northing coordinate.

When the application (executing on the xPC Target) requests a look-up the function first locates the range of trees whose Northing coordinates are valid candidates (this can be accomplished in O(log N) time because of the ordering), and then it tests each of the trees in this range to find the one closest to the input position (again, ignoring any trees, which are in a longer distance than DIST_LIM (1 m)).

1.2 The prox utility

As indicated above the prox utility reads a number of tree definitions from 'stdin', stores them in a database, sorts the database, and outputs the sorted database to 'stdout' in a format digestible by a C compiler (i.e. C source). Calling syntax (at Command Prompt): prox <measurements_file.txt >gen_prox_data.c

Figure B3 shows an example of output (the first lines) from the ”prox” program (when fed with full list of all measured trees/poles and viewed in the MS Visual Studio editor).

Figure B3 Sorted list, automatically generated C source. Configuration data (or database) for the ProxTree block.

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

Version 1.0 November 2005, © Danish Environmental Protection Agency