1

AVERT Final Report Section 4.1 Combined

Issue 2 - 28 July 2015

Executive Summary

Terrorism threatens horrific loss of life, extensive disruption to city transport and damage to

commercial real estate. Vehicles provide an ideal delivery mechanism for IEDs (Improvised Explosive

Devices) because they can be meticulously prepared and deployed into the area of operations.

Blocking vehicles can prevent IED Disposal (IEDD) robots from accessing threat vehicles. Current

manual methods of extracting blocking vehicles from restricted access height areas are inadequate

and expose operators to unnecessary hazards.

The Autonomous Vehicle Emergency Recovery Tool (AVERT) project has, over 3 years, researched

and developed a tool for Police, Security Forces and Emergency Services to deploy a unique

capability to remotely remove blocking vehicles from access-denying positions in confined spaces,

tunnels, low bridges and underground car parks. The opportunity is taken to automate the task,

removing operators from the danger area and speeding up the times currently taken to give access.

The AVERT programme has addressed the development of a fully autonomous system which

operates alongside existing and envisaged IEDD/EOD robot technologies to move blocking vehicles

and provide safe, quick access for the disposal robot.

The project team worked throughout with reference to user views from different national IEDD

traditions and approaches. A representative user panel was established to guide the project on how

this new capability should be specified in order to replace manual methods effectively. Interviews

and workshops with the users shaped the Key User Requirements across the domains of Planning,

Situational Awareness, Monitoring, Interoperation, Communications and Information System,

Management, Security, Usability, Deployability and Sustainability. Operational mission tasks were

explored and representative use cases synthesised to provide practical test and verification

scenarios. The tactics, techniques and procedures (TTPs), to successfully deploy and undertake the

mission tasks, were explored using robotic simulations (Webots) to aid a common understanding

during concept development.

The AVERT approach is built on the concept of a swarm of four individual lifting devices being tasked

with moving to a user-identified blocking vehicle, each moving under the car to dock on one of the

four wheels. Then, in unison, they lift the vehicle and transport it to a user designated location which

will then leave an access space to allow the IEDD robot to be brought to the threat vehicle and

undergo its normal disarming or neutralising activities.

The four lifting devices have to run under the car and move sideways to dock from the inside so as to

allow the vehicle to be to be moved without any additional length or width constraints. The solution

2

was to use specially designed low profile mecanum-wheeled bogies which allow omnidirectional

movement even under severe loading. To demonstrate the concept the bogies were mounted on a

specially designed deployment unit (DU) which could be towed to the operating area and, through

mast mounted sensors autonomously prepare a 3D survey to present the scene to the operator who

could designate the vehicle to be moved and its destination. This information allowed the insertion

path for the unloaded bogies to the selected car and the extraction path for the loaded bogie-car

combination to be automatically generated. Once the paths are approved by the operator the bogies

are deployed from the unit and the vehicle is docked onto, lifted and extracted autonomously.

Usability has also been at the forefront of AVERT, providing console tools for environment

visualisation, sensor readings and controls to command fully autonomous or manual controlled

mission tasks.

The AVERT Website (www.avertproject.eu) was established for all interested parties to contact

AVERT partners. The project has had to manage security risks and constraints throughout and so the

website does not detail full operational details.

The Final Demonstration of AVERT followed two Use Cases including a Timed device and Victim

Operated IED. All objectives have been achieved and a successful Final Demonstration was given to

the Users, Exploiters and EU representatives in March 2015 at the Force Ware GmbH premises near

Stuttgart, Germany.

AVERT has delivered an IEDD tool which can be operated either autonomously or under remote

control, removing the need for users to work within the threat area. AVERT has exceeded

expectations on power management and can achieve the validation Use Cases within 30% to 50% of

the time taken by manual methods. The consortium is exceptionally grateful for the enthusiasm and

input from the User community. AVERT has received high praise from them at the User workshops

3

Summary description of context and objectives

Research and Development Objectives

The AVERT project was aimed at addressing a class of problems faced by IEDD teams when tackling

threats where operating access is denied to IEDD robots due to blocking vehicles. These problems

occur when trying to move the blocking vehicle in confined urban spaces such as underground or

multi-story car parks or other urban locations with restricted access which means conventional

remote controlled lifting and handling equipment cannot easily operate.

Currently the main techniques used are based on manual methods such as hook and line where

operators have to enter the danger zone for extended periods to set up the extraction path using

pulleys and strops and physically make attachment to the blocking car. This is time consuming and

unnecessarily risky.

The main objective of AVERT is to provide access for the IEDD robot through remote removal of a

blocking vehicle using an autonomous tool.

The research approach is based on the development of a lifting bogie system which is capable of

travelling under the blocking car either from the end or the side and splitting and docking onto each

of the road wheels so that the can be lifted and the vehicle moved along a safe path (not hitting the

threat vehicle) far enough away to allow the access required, and in a location which does not block

further operations.

The programme was executed in two phases. Period 1 of 18 months covered the research into the

requirement and development of an A-model for proof-of-concept trials at the interim review point.

Period 2, originally of 18 months but extended to 21 months covered the re-design of the A-model

and the development of a demonstrator system capable of being taken forward to exploitation.

It was important to interact with potential users from the very start of the programme in order to

capture the key requirements from different countries and traditions. The objective here was to

ensure that the research delivered a tool that enabled the wide range of IEDD approaches currently

used by different nations in Europe to be accommodated.

The user workshops helped develop and prioritise the user requirements within the broad bands of

Key User Requirements (KUR) priority 1 requirements and priority 2 requirements. These were

developed and verified against a series of illustrative use cases developed by subject matter experts

to be representative.

It was felt in the initial proposal that AVERT as a system should be highly autonomous in each of its

deployed actions. This was in order to reduce manual intervention and also to allow for the user to

conduct parallel activities which may be needed for speeding up the overall time taken to deal with

the threat.

During the research the user panel also placed great emphasis on providing remotely controlled as

well as autonomous capability in order to have an ability for direct intervention as a reversionary

capability.

4

The autonomous strategy for AVERT design was developed between the AVERT consortium partners

to provide an integrated system solution comprising :

1) Command Sub-system (CSS) responsible for operator interface, display and processing of

autonomous survey and mapping and also path planning and overall AVERT management;

2) Deployment Sub-system(DSS) responsible for the autonomous management of the functions

aboard the towed Deployment Unit (DU) , a supporting platform which is used to carry the bogies

from the command point and actively deploy them in the operational area. The DU also provides the

mast mountings for the survey and tracking sensors and the command communications, together

with the housing and power for the processors used by the other subsystems.

3) Bogie Sub-system(BSS) responsible for managing the four split-bogie units both on the path from

the DU to the target vehicle and once the , deployed as two locked pairs from the DU to the form-up

point prior to travelling under the vehicle to split and dock.

The main objective of the CSS is to provide the autonomous control of AVERT under operator

command, requiring development of autonomous sensing and processing of survey and mapping

information, including information from other sub-systems, together with an effective monitoring

and intervention workstation/GUI for effective User MMI.

The approach is based on overall ‘Global’ sensing of the operating environment to the command

sub-system, mapping and path planning. with updates of ‘Local’ obstacles, as discovered by the

bogie sub-system. The bogies operate under a closed loop system, measured and corrected within

the Global coordinate system, to safely rotate and move the vehicle for extraction in any direction,

with synchronised movement of the bogie swarm.

The DSS is used to provide the automatic control of the bogie deployment mechanism on the DU

and provide status and monitoring information for the power system and movement sensors

supporting the processors from the other sub-systems that are mounted on the DU

The four specially designed and mechanically robust lifting bogies are controlled via the BSS with a

coordinating BSS processor managing the overall tracking and swarming and embedded processing

on each bogie to manage the low level control of the drive, energy storage mechanisms and on-

board sensors. It is this configuration which enabled the AVERT to operate within the severe volume

and height constraints imposed by the vehicles they are intended to lift and move

The bogie elements represent the most complex section of the AVERT tool and design and

development was tackled in two Proof of concept was achieved using an full scale A-model early in

the programme. The results from this led to a significant design review of the bogie structure at mid-

project point. After analysis and further modelling appropriate modifications in geometry and

algorithims were applied to the build of the final demonstration bogies.

The system is structured so that a hybrid reversionary mode requested by the user panel can be

used. In this mode the autonomous mapping and planning is by-passed so the bogie sets can be

guided to the car by remote control. Once at the form up point the autonomous wheel detection

and docking/lifting can be activated, and then with the individual bogies still acting as a swarm, the

whole assembly can be moved as a single entity under remote control to the desired location.

5

The specialist mechanical engineering design, load testing and material selection for the mecanum

wheels, resulted in a very high load bearing capacity, given the low profile dimensions. This was a

highly significant achievement on this project and could, in its own right, be exploited.

The rapid survey and mapping capability was also a significant development in its own right. Specific

developments in fusing algorithms and path planning resulted in a very rapid location and mapping

capability which has led to a number of conference and research papers and is also capable of

further exploitation beyond AVERT itself.

The development objectives of AVERT were to deliver an IEDD tool which is effective in providing

access in urban situations, capable of operating with the expected range of vehicles and remains

safe and recoverable when communications are interrupted. Such a system, which provides faster

operation and removes Users further out of harm’s way than with current techniques has resulted

from this programme. AVERT has exceeded expectations on power management and can achieve

the validation Use Cases within 30% to 50% of the time taken by manual methods.

Dissemination and Exploitation Objectives

Dissemination and Exploitation objectives have been addressed throughout the programme. The

team has been active in raising user awareness by presenting AVERT at targeted conferences and

exhibitions throughout. In addition a number of academic papers on the underlying technology and

algorithm development have been prepared and published on peer reviewed open access sites.

The AVERT Website (www.avertproject.eu) was established for all interested parties to contact

AVERT partners. The project has had to manage security risks and constraints throughout and so the

website does not detail full operational details.

In addition the objective of wider dissemination has also been tackled through media outlets such as

Youtube video (300,000+) hits, INTERSEC magazine article and featuring on mainstream technology

shows such as BBC Click.

The dissemination also supports the exploitation objective, which has developed over the life of the

project. Initially potential exploitation partners were embedded in the consortium itself. The

business goals of these partners changed during the life of the project so they were not available to

directly market and exploit. Consequently a new exploitation plan with a revised set of objectives

has been developed.

The consortium has charged the coordinating partner, IDUS with heading up the search for, and

negotiation with, alternative exploiters capable of taking on board the current AVERT demonstrator

and developing it into an exploitable production unit within the next year.

Talks are currently in progress with suitable exploiters and identification of appropriate funding

sources has commenced with good prospects of meeting this objective.

6

Description of main S&T results/foregrounds

Summary

The AVERT project has identified and characterised the need for, and benefit from, developing a tool

to assist in IEDD operations by lifting and moving blocking vehicles so that IEDD robots can gain

access to deal with a discovered IED threat.

The main science and technology achievements commenced with the use of soft sciences, such as

Operational Analysis and Human Factors Research, to generate and consolidate the user and system

requirements across a wide multinational-user base with different cultures and national structures,

including organisation and training expectations.

The project then addressed the hard science areas of physics and maths for modelling and algorithm

assessment, whilst concurrently operating in the technological areas of the engineering sciences;

mechanical, electrical, electronic, computing etc to achieve a practical, demonstrable and trialable

system capable of being taken forward to exploitation.

Results

The results are measured in terms of the development of a system which meets the clear majority of

the KURs and Priority 1 Requirements and is technologically ready for development through to

exploitation (TRL 6 or above).

The verification and validation carried out against the requirements and detailed in the Period 2

periodic report has shown that 98.8% of the KURs were achieved and a total of 80.2% of all

requirements were reached at the demonstration stage.

The technology readiness levels achieved have also been impressive:

Bogie Mechanical Hardware - TRL 9

Electronics &Sensors TRL 6-7

Control & Swarming Software TRL 6-7

Survey & Mapping Software TRL 7-9

System Definition - WP2 Lead IDUS

The primary objective of this WP, planned entirely during Period 1, was to complete the overall

System Definition for the AVERT Tool. The sub-tasks address the overall system concept, the

preparation of Strawman user and system requirements, and the refinement of these with specialist

support to result in agreed user and system requirements. The final sub-task was the preparation of

the overall system design for the demonstration system, based on the requirements.

The WP was led by the IDUS team utilising skills in Operational Research, Systems Analysis,

Mechanical and Manufacturing Engineering, Electrical and Electronic Engineering as well as

Technical Management experience. The programme was arranged so that the requirements work

could be undertaken concurrently to programme research in order overcome project time

constraints.

7

User and system requirements were developed through: User questionnaires and Stakeholder

interviews; derivation of requirements by Systems Analysts; drafting of Strawman documents; and

development of Use Cases for analysis at the first User Workshop to define goals for project

acceptance. Finalisation of key deliverables included the User Requirements Document (URD),

Systems Requirements Document (SRD) and, derived from these, the detailed AVERT System Design

Definition document (SDD).

Five use cases were initially identified for detailed discussion and review at the User Working Group.

From these two (a) Victim Operated IED and (c) Timed Response were eventually confirmed as the

basis for the main operating requirements. In addition a further use case (e) Dirty Bomb in Extremis

was used for the development of stretch requirements. The impact and importance of autonomous

control and removing the user out of harm’s way was fully realised.

System Design Definition (SDD)

The SDD development provided the document describing the system design vision and identifying

the system and sub-system architecture and design concepts. The SDD was used as the design basis

for the A-Model proof of concept bogies (just one pair of experimental split bogies ) and also the

survey and mapping approaches (using fixed tripod mounted laser and camera). Normally the SDD

would have been updated following proof of concept review but, due to portal upload rules, a

separate Demonstrator Design Definition (DDD) had to be produced instead.

For the SDD the system was coordinated by IDUS using inputs from all the consortium partners. In

particular ZHAW, in consultation with BBI and IDUS, undertook mission task and sensor analysis,

which required assessment of local obstacle recognition (for avoidance and navigation), path-

planning and bogie position measurement. DUTH addressed the sensor strategy for mapping and

global path-planning, taking account of possible emission restrictions emerging from the

requirements exercise. The AVERT strategy was developed as follows:

a) The bogies were to be deployed from the DU and instructed to move to a Form Up Point (FUP) in

front or to the side of the vehicle to be moved.

b) The bogies would then go underneath the vehicle, locate the axles, separate and dock with the

vehicle wheels.

c) The bogies, acting as a swarm, would lift and extract the vehicle along a pre-planned path.

Each step of the operation required sensors to detect sub-surface, surface and overhead obstacles,

both locally and globally, for safe navigation when operating as joined bogie pairs, as individual split

bogies and also when working autonomously as a bogie swarm. The obstacles under consideration

were those typical of the scenario and were considered to be static during the mission. The

algorithm was to be capable of being extended to dynamic obstacles if required during exploitation.

The appropriate choice of sensors was essential to meet the User Requirements such that obstacles

could be identified and avoided, the IED threat would not be activated, and also so that AVERT could

be manufactured at a competitive price, within the budget of EOD organisations. For classified

operational reasons the users placed constraints on the use of certain active sensor options.

Consequently the system design was developed in a way that different sensor types could be used

8

on a modular basis. This will assist in tailoring AVERT during exploitation to overcome particular

threats and also allow more cost-effective sensors to be used in certain scenarios.

The extent to which users also wanted full observation, intervention and manual override at all

times was greater than originally expected. It is believed this was due to user's current reliance on

hands-on remote control with existing equipment and has indicated the need to build trust in

autonomous control under user command supervision.

The AVERT research has been predicated on the provision of autonomous capability and this

continued as the prime objective. The architecture was developed so that manual reversion

capability could be incorporated at the exploitation stage but the formal demonstration of the

AVERT research achievements was confined to the autonomous operation itself.

The SDD also explored two design approaches for the deployment unit: towed or powered, self-

propelled remote-controlled. These were reviewed at concept level at the interim review but

selection and build was not required at this stage to support the proof of concept activities.

Both options contained the autonomous bogie deployment system and the review recognised that

the powered, self-propelled remote-controlled DU approach would not demonstrate further

autonomy. Consequently the cheaper and lower risk towed unit was selected for development at

the demonstration. This would not affect the option to provide a powered DU as an alternative for

exploitation.

Demonstrator Design Definition (DDD)

The DDD was refined from the SDD following proof of concept review by EU, the project team and

the users. It included the changes decided after a series of options studies arising from the review,

which were developed in a small, 3 month, extension to the programme timeframe. This resulted in

refinement of the underlying architecture, revision of the bogie design and greater definition of the

DU and the AVERT command console/GUI.

The refined architecture was still based on the three sub-systems (CSS, DSS and BSS) and their

intended interfacing is described in the DDD. Physically the system comprised the following key

hardware components: the detachable AVERT Command Console (ACC); the towed DU; and the 4

split-bogie Units (BU), deployed as two joined bogie pairs.

The requirements, with associated User objectives and acceptance criteria were re-visited, and the

primacy of two of the Use Cases (UC): UC1 “Victim Operated IED (VOIED)” and UC3 “Timed

Response”, with stretch requirements identified by UC5 “Dirty Bomb in Extremis” was confirmed,

with additional operational advice.

Command & Control System WP3 Lead IDUS

Overview

The Command and Control system was designed to service the architectural concept based on the

three functional subsystems, CSS, DSS and BSS and the work package was specifically tasked with the

development of the CSS and DSS by DUTH and IDUS and their linkage to the BSS developed by

ZHAW. Key system architecture components included the communications systems, video relay to

9

the User, onboard processing for each functional subsystem, and command and control of mounted

sensors as well as mobility and actuators.

During development there was continued concern regarding the integration of the sub-systems and

a number of activities were instigated to reduce the inherent risks in this area.

To assist risk mitigation a ‘Command System Distributed Integration Rig’, template was developed

and utilised using laptop emulation at IDUS and DUTH for use as a system integration support tool

and later acted as part of the validation environment for system upgrades. It was originally planned

to network the two elements together over the internet but corporate security policy constraints at

DUTH prevented this, instead files were exchanged and emulators built to represent the missing

elements.

CSS - DUTH/IDUS

The CSS supported mission planning and command decisions by the User, presented status and

monitoring information to the User as well as provision of requested supervision camera and sensor

views. The design philosophy was to enable the user to intervene and facilitate reversionary control

mode and emergency stop commands at any time.

The CSS design was guided by a detailed Concept of Use (CONUSE) presented and developed at the

Second User Workshop in October 2013. This showed how the User would interact with AVERT and

EOD equipment in a range of operations or scenarios In accordance with the CONUSE, the two-

position survey method, developed by DUTH which required the User to pause at an intermediate

point before towing the DU to its final overwatch position was agreed and incorporated.

Robot simulations of Use Cases 1 and 3, developed by DUTH during Period 1 in the Webots tool,

were employed during the Period 2 User Workshops 3 and 4 as well as the Final Demonstration to

help visualise and evaluate how AVERT would be deployed and understand the constraints of the

environment for which it has been designed.

The command and control system itself was researched during period 1in terms of communications

capabilities from a mix of off the shelf and bespoke solutions. This included research into IP

compatible trunk and local communications and antenna solutions specific to under-car operations.

It included the development of a novel narrowband 800MHz safety and reversionary control link

tailored to the swarm.

The communications solution was selected built and integrated during Period 2, initially using a

simulation facility and subsequently being integrated into the full system for final testing. At

exploitation most users would wish to use their own trunk communications system for compatibility

and security purposes so it was ensured that the design used in the demonstration was open

architecture enabling a user's alternative system, e.g. COFDM to be easily substituted.

The CSS was developed to meet the following criteria:

a) responsibility for survey and mapping including control of relevant sensors,

b) responsibility to support mission planning and command decisions by the user,

10

c) obligation to receive obstacle update data for path re-planning from BSS,

c) responsibility to provide path movement and re-planned path movement data to the BSS both for

bogie move to the FUP and swarm extraction of the vehicle to the selected location,

d) responsibility to present status and monitoring information to the user, including data from BSS

and DSS,

e) responsibility to manage the DU mounted survey sensor

f) responsibility to provide requested supervision camera and sensor views to the user

g) responsibility to enable a user to intervene and facilitate reversionary control mode and

emergency stop commands at any time.

CSS Hardware

At the mid-project stage the AVERT Command Console was represented by partially-integrated

console components using discrete screens and laptops. The keypad and joystick were commercial-

off-the-shelf with USB connectivity.

A design scheme was developed for a portable integrated command console in terms of processors,

screens and controls as well as the implementation of the open-source ROS (Robot Operating

System) framework for integration. However it was found in Phase 2 that several of the potential

exploiters involved in preliminary discussions already had suitable console approaches implemented.

It was eventually considered that there was no additional research benefit in developing a more

sophisticated stand-alone console at this stage and so the non-integrated arrangement was carried

forward to the demonstration.

CSS Software

The command system was developed to command autonomous AVERT operations under user

supervision. Separate mechanisms provided video surveillance and emergency stop so that the

command system software did not need to be developed under safety-critical criteria. The CSS had

two processing nodes, one represented by a laptop on the DU managing the sensor processing and

the other, represented by a laptop at the command console managing the GUI.

A command system integration rig, with representative processors, displays and communications

links, was used to provide the basis for trialling elements of the AVERT hardware and software

before they were integrated. It featured the ability to emulate primary operator command and

control inputs and information exchange between CSS/DSS and other system elements.

The command console provided the tools for environment visualisation, sensor readings and User

control input. Multiple parallel processes were required for communication, graphic visualisation of

scanned point cloud data, commands and sensor data processing, as well as User selected solution

processing employing obstacle avoidance algorithms.

The Graphical User Interface (GUI) was developed within ROS utilising the Qt framework, which

enables the User to interact with and examine the ROS environment in a visual manner. The

11

workshops proved helpful in allowing the DUTH team to customise the GUI and widgets contained

within the toolkit to meet the Users’ requests and feedback. From the assessment of the User

Requirements detailed in WP9, the GUI and User Controls exceeded User expectations and have

been a significant achievement under this project.

The GUI activity continued in period 2 in order to simplify the AVERT User experience. The Second

User Workshop provided the forum for discussing User interaction, and provided options for trials.

The User required a relatively simple and graphical diagram interface for selection of bogies, camera

view as well as bogie and DU status information. The bogie release mechanism on the DU itself was

also part of the GUI.

CSS-BSS Integration

CSS-BSS integration was a difficult task throughout the programme as it required assured interfacing

between two software systems each of which was continuously evolving. Initial agreements were

made at integration meetings in June 2013. These were reviewed and challenged during the

subsequent periods in a series of meetings, workshops and teleconferences held between DUTH and

ZHAW and chaired by IDUS. The workshops addressed integration clarification between the three

sub-systems and sought mechanisms to identify a practical way forward. The issue was considered

high risk throughout the programme and continued despite using various risk reduction measures.

Information exchanges considered for communications, sensors and actuators as well as planning

and situational awareness data continued to raise difficulties through the remainder of period 1 and

during period 2 despite several attempts to address it by the universities. One of the problems was

the late availability of BSS software which was a knock-on consequence of the delayed demonstrator

bogie design and subsequent trials. This affected the initial mitigation plan to overcome the

difficulties experienced by DUTH and ZHAW in using the original interface specification given in the

DDD to develop and prove the CSS software (built on a ROS framework) interfacing with the BSS

software (developed from a previous non-ROS application) using the rig.

As a neutral compromise IDUS proposed taking the interfaces as far as they had been developed and

preparing a separate ROS/non-ROS (RnR) transfer application to sit between them and provide two-

way communication between the sub-systems. The RnR application itself was built and pre-tested in

UK on the rig. Then the IDUS team brought it to the demonstrator system integration preparation

and worked directly with the software researchers from DUTH and ZHAW to integrate and test the

application with the latest builds of the CSS and BSS software in the run-up to the demonstration.

This was finally achieved during the last phase of integration and was successfully used at the

demonstration in March 2015 to show the operation of a fully autonomous sequence from initial

survey through to vehicle extraction and placement.

CSS Trunk Communications

The original communications approach was superseded by improvements in off-the-shelf technology

and, following communications trials in period 1 and 2, a modern Multiple-Input:Multiple-Output

(MIMO) based Wi-Fi system was found to provide range and resilience of equal or superior

performance to the original system for trunk linkage at the demonstration stage, and at much lower

12

cost. The COTS Wi-Fi system would be expected to be replaced by a modern COFDM system

compatible with the particular user's other robot controllers in most exploitation circumstances.

The Final Demonstrator also showed integration potential for a dedicated backup communications

system for safety and operator reversionary control, as well as sufficient bandwidth to support laser-

based survey and monitoring functions.

The reversionary communication system was designed to support a simple fail-safe and easily-

evaluated emergency stop system over a separate communication link in case of failure of any of the

primary control elements.

DSS

The DSS was originally considered as the centre of autonomous control, as the major processing

burden was expected to be located on the DU. It would have supported real-world mapping and

mission monitoring as well as processing situational awareness of the AVERT Area of Operations

(AOA) where the bogies are operating.

Following review, these activities were transferred to the CSS and BSS as appropriate, with separate

BSS and CSS processors (located on the DU), each managing the associated mast mounted BSS and

CSS laser sensors respectively.

The DSS was re-purposed to cover the specific DU control & autonomous actions. As a consequence,

a network-connected microcontroller was found to be the most appropriate solution for the DSS

processor. This bespoke unit was designed to manage the CSS commanded autonomous pneumatic

deployment sequencing system, the off-tow parking brake and the on-tow laser sensor guard

(deployed to protect the lower sensor during movement). It was also programmed to monitor and

transmit the DU battery status and odometry sensor readings to the CSS for use across the system.

BSS - ZHAW

The BSS controlled the bogies in joint bogie pair, split-bogie pair and swarm modes in pre-

programmed sequences commanded from the CSS.

a) Joined - For moving to the vehicle in joined mode, the CSS managed the relevant Sick laser based

tracking sensor. When joined the BSS received the planned or re-planned path from the CSS.

b) Split - When the joined bogie split for docking, the bogie on-board sensors operated an

autonomous sequence which detected the wheels to be lifted and split and guided each bogie to the

correct wheel where other onboard sensors managed the lifting.

c) Swarm - Once the vehicle was lifted, the bogie swarm could move a vehicle in any direction. The

actual processing was coordinated at high level by the main CSS processor located on the DU with

embedded pic processors on each bogie, which managed the low-level motor and actuator actions.

The BSS was required to sense local obstacles, in the vicinity of the bogies, such as concrete pillars

and kerb stones, whilst updating these detected obstacles to the CSS so that the path could be re-

planned and re-issued if necessary.

The BSS development is described in the report for WP8.

13

Bogie and Deployment Platform Design WP4 - Lead BBI

Overview

The mechanical design of the A-Model and Demonstrator bogie sets (and also the DU), together with

support for design changes during manufacturing and assembly of all the units, was undertaken by

BBI in this work package.

The bogies, being the key research component, were subjected to an iterative design process with

an initial A-Model design for one pair of bogies as proof of concept being built for mid-project trials.

The results of these were subjected to extended review and a number of alternative design concepts

were developed and debated as a result. Whilst this had significant impact potential on the project

timeline, it did mean that the eventual design for the demonstrator bogies, and especially the high-

load mecanum wheels, was well considered. This opportunity to incorporate the key lessons learned

ensured that the fundamental mechanical design operated effectively during the rest of the project

at a high TRL level, ready for exploitation.

The mechanical load testing, in support of the bogie mecanum wheel redesign, and selection of a

harder rubber material for the ‘tyre’ rollers, was undertaken by FW (this testing had to be

undertaken with Period 2). Design of a bogie system that can lift a large vehicle, such as a 4x4,

including potential overload, using mecanum wheels of such small diameter that could be inserted

underneath any vehicle, was a highly significant achievement on this project and could (in its own

right) be exploited.

A-Model Bogies

The A-Model bogies were designed using 3D CAD and the engineering calculations were carried out

using the CAD package itself, supplemented by load, drive and braking calculations executed in an

Excel-based model. A commercial off the shelf FE package was used for key stress calculations.

Figure 1 - A-model Bogie Design

14

Even at A-Model, the design output was in the form of detailed manufacturing drawings for all the

specialist parts including casings, gears etc. This enabled the purchasing, manufacturing and

assembly procedures to be "dry-run" at the mid-point of the project, in order to reduce logistics risks

for the manufacture and assembly of the demonstrator bogies later on. After the design phase,

design support was provided for impending mechanical design modifications arising from integration

and trials of the A-Model.

From the outset, the design concept for the split bogie incorporated the idea that the half bogies

would rotate and join to form the full bogie. This clever approach means that a single design of half

bogie could be used for all four units in a set, which gave several cost and time advantages during

production. This will be a significant consideration when moving to exploitation.

Demonstrator Bogie Design

The Demonstrator Bogie design commenced with a major consortium-level review. The A-Model

bogies had been successful in proof of concept, but the mechanical layout was questioned in terms

of geometry and steering control in split mode. A comparison and assessment of different Bogie

mechanical design alternatives against System and User Requirements was conducted to optimise

the mechanical system design approach.

User requirements from the first User Workshop for a ‘free-wheel-functionality’ placed an additional

challenge to the bogie design. A redesign was carried out so that, in the event of a severe system

failure, this new capability would allow users to manually push or tow the bogies, with a vehicle

loaded on top, towards a safe area. Furthermore, a more detailed investigation of tyre sizes and

vehicle dimensions showed that the anticipated bogie height had to be reduced to 100mm to cover

the full range of vehicles which may need to be moved if they are built to European ground-

clearance guidelines.

As a result of earlier load testing, a revised mecanum wheel with harder rubber plastic and

redesigned spindles was developed and successfully tested using the A-Model structure but, due to

long lead time for the rollers, this could not occur until the second period. This design, used in the

demonstrator, enabled AVERT to be capable of lifting a large vehicle (such as a 4x4) including

potential overload, using mecanum wheels of such small diameter that they could be inserted

underneath any vehicle.

The final demonstrator design provided for braked-in-line omniwheels to assist the steering in split

mode and utilised the upgraded mecanum wheel components. It also provided a lower-profile cable

management arrangement and revised electronics housing, based on trials of the docking and

forward sensing laser positions using the A-Model. The bogie ground clearance itself was raised from

10mm to 15mm, to overcome potential grounding on some floor types commonly used in parking

areas. This forced the bogie’s overall height also to rise from 100mm to 110mm. This has a knock-on

consequence that some extremely low cars may not have enough clearance to be underridden.

During development for exploitation it is proposed that a trade-off study will be made into the

optimum bogie height for clearance and load-bearing across the population of vehicles likely to be

encountered.

15

Figure 2 - Demonstrator Bogie Design

DU Design

The DU design was not considered as critical as the bogies from a research viewpoint. To reduce

project cost and risk, a simple towed platform was prepared and operated as a proof of concept

model. From an exploitation viewpoint the DU design would be developed to suit the deployment

strategy of the relevant force, whether passive-towed or powered remote-controlled.

Figure 3 - Towed DU Design

16

The basic structure was designed to illustrate deployment within a typical operating constraint,

passing through a narrow doorway. The resulting design was provided with an autonomous

pneumatic lifting and lowering mechanism controlled by the DSS processor. This demonstrated the

proof of principle sufficiently, but would have needed a re-design for greater lifting power during

exploitation, due to the weight increase of the bogie units themselves following modification. The

design also incorporated a dual-mast structure, separating the sensor head from the

communications mast in order to reduce system interaction risks.

As with the bogies the DU framework was developed using Computer Aided Design (CAD) and also,

in line with the bogies, key drawings of the DU were reviewed by the AVERT Consortium Partners to

form the demonstrator manufacturing data-pack. Some detailed elements were omitted, including

some cable runs and type and location of some electronics enclosures. This was due to the

concurrent development approach used for the DU, where enclosures and wiring were being

resolved quite late due to knock-on impact of the delays in the overall programme. Late design

changes were captured in integration documentation and photographs.

Deployment Platform Development & Fabrication WP5 - Lead FW

Overview

The primary objective of this WP was to develop, manufacture, assemble, integrate and test a

representative deployment platform. Originally this would have taken place at the premises of an

experienced platform integrator (MSDG), which was unfortunately not available following its

withdrawal for business reasons earlier in the programme. Consequently the manufacture was

hosted by FW in the same workshop as that where the bogies were fabricated and the integration

was supported with platform and sub-system expertise from IDUS, BBI and DUTH.

Within WP5 the DU was built by FW incorporating sub-system communications and sensor-mast

units developed by IDUS and DUTH respectively. The frame manufacture at FW followed on from the

demonstrator bogie build, and hence occurred slightly later than planned in the original DOW.

The DU was designed with a forward sensor mast and a separate rear communications mast. The

design used readily-available COTS components to minimise procurement and assembly issues, and

the separate mast approach meant that the units could be trialled as sub-assemblies prior to DU

integration in Eningen (Germany).

17

Figure 4 - DU with Forward Sensor Mast Design

In practice the late assembly of the DU due to other programme issues meant that DU integration

and overall demonstrator timeframes overlapped and the pragmatic decision was made to co-locate

the IDUS and DUTH teams with FW for final integration at both the DU and overall system level. The

result was a more tailored DU integration than would have been possible with multi-site working.

However, as there was only one DU there was a need to forgo certain platform details in order to

concentrate on the overall system needs. None of these areas impacted directly on the delivery of a

successful demonstration, but a number of issues were noted which would require further re-design

when going forward to exploitation.

Bogie Module Development & Fabrication WP6 - Lead FW

Overview

Work package 6 covered all manufacturing and development tasks for both the A-Model bogie and

the demonstrator bogie units. Both tasks were undertaken by the same participant in order to

include lessons learnt experience from A-Model manufacturing into manufacturing of the

demonstrator bogie units. In addition, a mechanical performance test to verify the A-Model

capabilities for lifting and displacing a vehicle was performed within WP6, coordinated and

conducted by FW.

18

Figure 5 - Bogie Mechanical Load Test

It was originally planned to build two complete sets of bogie units at FW, one for use by FW and the

other for MSDG during subsequent exploitation activities. With the withdrawal of MSDG, it was

agreed with the EU that just one full set of demonstration bogies and a spare sub-set would be

needed. This resulted in six, rather than eight, split bogies being built. This approach allowed the

diversion of planned resource to support production cost-benefit analysis for exploitation planning.

The manufacturing practices and procedures for AVERT bogies were developed from the normal FW

procedures for equipment and detectors. They had to accommodate a much greater mechanical

complexity and wider range of specialist subcontractors than normal, in order to procure parts for

and built a robotic system of this nature. The approach was trialled with input and re-design

flexibility from BBI in support and the A-Model was successfully constructed.

Following mechanical redesign for the demonstration bogies, these were assembled in the same

manner and with the same suppliers as the A-Model. It was possible to make preliminary estimates

of assembly time and material cost from this exercise, but this has to be heavily caveated when

extrapolating for exploitation, as there were a number of time and cost factors imposed by the

nature of the programme which could be significantly reduced once the design is productionised and

batch sizes are optimised during exploitation.

Two complete sets of Demonstration Bogies were delivered by FW, on 14th November 2014, to

ZHAW for integration and trials. The third set was assembled by FW in time for the Genoa CP Expo

exhibition in December 2014.

19

Figure 6 Demonstration Bogie Set

Simulation & Driving Trajectory Calculation, Synchronised Platform WP7 - Lead DUTH

Overview

The primary objective of this WP was to research and develop strategies and path-planning

algorithms for the safe and fast movement of bogies: a) from the DU to the Form-up Point (FUP: a

User-defined end-point near the blocking vehicle); and b) carrying the lifted blocking vehicle from its

original position along the extraction path to the user-designated final position. These strategies

were simulated in a practical context using the level of point cloud data typically obtained from an

AVERT DU deployment as the basis for navigation.

WP7 was also originally planned to deliver the global navigation for the trajectory, with local

navigation being developed in WP8. Following integration discussions with IDUS and ZHAW towards

the end of Period 1, the local navigation to support obstacle avoidance during transit was not

considered by ZHAW to be covered by WP8. Consequently it was proposed by the consortium, and

accepted by the EU, that there would be an additional sub-task in WP7 during Period 2 covering the

integration of Global and Local trajectory planning to support obstacle avoidance.

The global survey was undertaken using the output from the sensor head on the DU. This head

comprised a vertically scanning SICK LMS500 PRO 2D laser scanner co-located with a Prosilica

GC780C camera mounted on a Schunk PW-70 PTU. To avoid blind spots, at least 2 scans were taken

from different locations and then their point clouds merged using algorithms developed by DUTH

and modified for the AVERT problem by using inferences to rapidly speed up registration time by an

order of magnitude.

The resulting 3D representation of the area was then transformed to a 2 ½D map (2D map with

knowledge of height constraints) for planning the bogie approach and the vehicle extraction. The

20

path-planning algorithm itself was based on improvements made to the D*Lite fast path-

planning/re-planning algorithm for efficiency and speed.

These fast computations provided significant advantage in the time needed to survey and plan

AVERT deployment, resulting in fast-into-action times even in previously un-surveyed locations.

Additionally the underlying speed, and the dynamic re-planning ability, made it possible to bring in

additional obstacle information during transit and re-calculate and re-issue an updated path from

the CSS to the BSS during transit without affecting extraction times.

Planning and re-planning development

DUTH commenced with design and development of the path-planning algorithm itself using discrete

and then Webots simulations prior to the sensor head trials. The path-planning algorithm itself was

selected for development after a literature survey. D*lite was chosen as a fast path-planning/re-

planning algorithm suited to partial or unknown terrain. It was then implemented in a programming

language and parameters modified experimentally to enhance speed of execution. The next step

was to integrate it into the simulation environment.

Figure 7 - Discrete Path Planner Development

Global mapping

The second simulation stage created the global mapping function and used it with the path-planning

in a simulation environment. The approach replicated typical laser scanning from a sensor mast

mounted on a DU equivalent platform. Then the point-cloud-based mapping from this was

converted to a two-dimensional (2D) map, working with the path-planning algorithm in a simulation

of the AVERT situational assessment and planning mode. The point-cloud mapping was undertaken

from two separate static locations to build up the 3D dataset.

21

Figure 8 - AVERT Simulated in Webots

After the simulation, the path-planner was integrated into the overall AVERT system. Mainly this

included the appropriate compilation and definition of the dependencies in the ROS framework

running on the CSS processors located on the DU and with the GUI. The system itself was already

being integrated with the survey functionality from the sensor head.

Figure 9 - Example Sensor Head 3D Capture

Managing local obstacle avoidance

In the additional sub-task for integrating Global and Local trajectory planning to support obstacle

avoidance, advantage was taken of the CSS fast path-planning capability to overcome the issue that

ZHAW considered local obstacle avoidance during transit outside WP8 scope. It was agreed that the

BSS, which would have knowledge of its bogies' own positions in relation to the global map, would

report the position of the obstacles it had seen as it scanned ahead during transit to the CSS. The

CSS, which holds the global map, would then add the obstacle to the map and, if necessary, re-plan

the swarms' transit path and send an update to the BSS. The BSS would receive the update and alter

the trajectory accordingly. This would mean that the bogie swarm elements were still required to

22

operate under closed-loop control in the BSS such that their relative positioning was measured and

corrected within the global coordinate system to follow the overall transit re-plan around the local

obstacle.

A summary of the key achievements of this research includes:

a) The development of the SICK laser as well as the SCHUNK ‘pan and tilt’ software drivers;

b) Interactive software drivers to acquire a 360˚ scan from the SICK and SCHUNK units (completed

within 2 minutes, as demonstrated);

c) Software developed to accurately register successive scans for mapping the environment;

d) Development of the path-planning algorithm (detailed above);

e) Software to merge the mapping and acquired planning data;

f) Path re-planning in transit for local obstacle avoidance.

Bogie Local Control and Obstacle Avoidance Sensor System and Software WP8 - Lead ZHAW

Overview

WP8 covered the design, implementation and commissioning of the electronic hardware as well as

the bogie software controller tasks. This task was led by ZHAW and started in parallel to the detailed

AVERT Concept Design work. The autonomous requirement was for the joined bogies to travel to a

FUP (selected to the front or side of the (blocking) vehicle) using a path provided from the CSS,

detect the exact position of wheels, then insert underneath the vehicle and locate the wheel centres

prior to splitting and docking, i.e. position each split bogie's "jaws" either side of the wheel and

clamp together. Once each bogie was docked, they were each to be activated together to lift the

vehicle and, in a common ‘swarm’ mode, the bogies were required to move it along the planned

extraction path.

Software architecture/framework

The software architecture and framework for the BSS was developed by ZHAW from a previous

internal project using a modular but proprietary approach. This allowed the basic software structure

to be prepared relatively quickly and the specific algorithms for bogie dynamics to be researched

and integrated. The framework also facilitated the internal communication between the bogie

elements and provided a platform for different sensor option experiments. However this decision to

use a closed rather than open system did lead to integration problems with the open-source ROS-

based CSS later in the programme. These were exacerbated by the late development of the BSS

functions due to knock-on delays from bogie design and re-design.

Framework implementation and hardware abstraction

From an early stage the framework was implemented in a Linux laptop computer to simulate the BSS

processor which would be situated on the DU, with the tracking laser, and manage the bogie swarm.

The communications with the bogies were over a dedicated hi-speed Wi-Fi network using the same

type of MIMO communications devices as for the trunk system. On board the bogies themselves, a

23

dedicated PIC-based electronics board with Ethernet and other interfaces was developed to support

on-bogie sensing and control of the joining and lifting systems. The laser sensors and mecanum drive

motors/controllers on board each bogie were also Ethernet connected to the on-board switched

network and through that to the DU over the Wi-Fi.

Early mock-up and A-model

The concept was being developed from scratch so, ahead of the A-model bogies being available, a

heavy-duty bogie mock-up was built to provide test facilities for the servo motors and the bogie

kinematics using a real vehicle. An Opel Vectra station wagon was used as the test vehicle, both for

bogie algorithm development and as a basis for developing the wheel-detection algorithms.

The motors used in the mock-up were relocated to the A-model bogie set when it became available

and the A-model, which also included the lifting system, was then used to demonstrate the proof of

concept for joined bogie movement to the FUP, wheel detection from the FUP, moving under the

car, splitting, docking and lifting. As this was a single bogie set the other wheels were supported by

passive castored dollies (Go-Jacks) during trials.

The findings of the A-model trials resulted in the discussions regarding geometry and algorithms for

reliable movement of the split bogies from their joined position to their docking on individual

wheels. This resulted in the addition of an in-line braked omniwheel being added to each mecanum

wheel pair in the demonstration bogies. The knock-on effect was to delay the availability of the

demonstrator bogies for swarm tests and also to require late modifications to the already developed

bogie kinematics once the bogies were available, which delayed their availability for integration.

Swarming and sensor experiments

Once it was realised that there would be a substantial delay in the availability of the demonstration

bogies, it was decided that a second pair of the heavy-duty mock-up bogies would be constructed by

FW and ZHAW so that the delayed swarming trials could be de-risked. These bogies again used the

motors that would eventually be used in the demonstration bogies and were run using umbilical

Ethernet cables ahead of the wireless network being available. After this was built, it was possible to

prove the swarm concept and tune the software and algorithms using the trial vehicle in the

underground car park at ZHAW.

Figure 10 - Skeleton Bogies Used For Swarm Experiments

24

In addition to swarming, a number of sensor experiments were undertaken using the A-model

bogies to improve tracking, docking and obstacle avoidance for the demonstration bogies in time for

the findings to be fed back to the demonstrator bogie design.

The “Swarm simulation/emulation demonstration” delivered the functionality of bogie subsystem

for local navigation and swarm control. The tests successfully drove a vehicle on a swarm of four

independent bogies, following a trajectory, and demonstrated the complex constraints including the

physical connection of the bogies through the vehicle suspension. These tests were then repeated

with the demonstration bogies themselves, once they became available.

Bogie Tracking

The original approach by ZHAW was based on using a single tracking laser (SICK LMS511) mounted

on the DU to keep track of the bogies and the car wheels. This was amended, following the A-model

experiments, to allow for local tracking and obstacle sensing with a forward-facing upgraded

(version UST) Hokuyo laser sensor. This was mounted on a servo tilt mount to allow horizontal, fixed

angle and variable tilt scanning. The arrangement allowed a scan of the car underbody from the FUP

to detect the risk of impacting low hanging (below 110mm) obstacles before moving off. It also

allowed fixed angle fan scanning to allow detection of obstacles formed of adverse dips or hollows.

Figure 11 - Underbody Scan

For the demonstration, the DU-mounted SICK sensor maintained the tracking of the bogies relative

to the global co-ordinates up to the FUP. For the bogies moving from the FUP under the vehicle to

dock, the forward Hokuyo laser was used for wheel-centre detection and tracking.

A separate laser sensor was fitted to view the wheel area for docking and also to view and track the

partnering bogie in support of autonomous rejoin at the end of the mission.

The upgraded Hokuyo sensors became available during period 2 and gave significantly better

performance in terms of range, resolution and ability to work with the absorbent behaviour of car

tyres than the ones originally used for docking experiments at the project midpoint. This meant that,

25

as well as being used in the FUP to docking segment as described above, the forward sensor could

also be properly tasked with obstacle detection and reporting during the two transit segments.

In later trials it became clear that the rearward-facing laser, with the 16m range of the UST model,

would have the capability to scan for and recognise the DU itself, meaning that the deployment

could be envisaged operating with a simple reflective identifying panel at the DU in place of the SICK

laser. Whilst it was too late in the programme to investigate this in detail, it is considered to be one

of the initial areas to be looked at when preparing for exploitation, due to the lower cost and higher

resilience of such a solution.

BSS Software Integration

The final stage for WP8 was to integrate the demonstrator hardware with the AVERT control

software, ready for commissioning. This encompassed all software changes made, including

algorithm improvements, in preparation for the successful Final Demonstration.

The bogie-tracking algorithm was modified to detect only the bogie edges (as opposed to the full

bogie shape), making it more robust against external movement. The Swarm-tracking algorithm was

also integrated to increase the position accuracy of the swarm. These final improvements were

worked on by the ZHAW team prior to system integration activities in Stuttgart

Integration of Systems Components into Demonstrator WP9 - Lead IDUS

Overview

In WP9 all the technologies developed in the previous work packages were brought together to

integrate and test the AVERT system as a whole. IDUS was responsible for coordinating this task

which was initially rig-based but in its final stages was undertaken with the actual demonstrator sub-

system components as they became available. The primary integration site was at the FW facilities at

Eningen near Stuttgart.

Integration

The demonstration system was assembled and integrated in accordance with the Demonstrator

Design Definition Document developed in WP3. Technical specialists from each of the beneficiaries

prepared each sub-system and then worked together in an integrated team to ensure functional

operation of mechanical, electrical and communications and data interfacing across the system.

Once the functionality was established, including the interfacing with a typical EOD robot kindly lent

by the German user organisation, the team moved to the designated test site provided by FW for

operational integration and performance testing. The site was in a disused workshop with

characteristics similar to those found in a typical parking garage in terms of floor and supporting

pillars. In this area it was possible to set up the vehicle dispositions representative of the two use

cases and to commence operational integration in conjunction with members of the user panel who

provided input and also commanded the legacy EOD robot during the work-up.

26

Verification and Validation

Verification is the (internal) process of evaluating system requirements against the design

specification. Validation is the (external) process of evaluating User Requirements against the

customer or identified stakeholder operational criteria.

The use of the use of the “V diagram” systems engineering process for these tasks was identified by

IDUS at the start of the project and adopted at the first PMB meeting in July 2012.

Figure 12 - V Diagram

(Systems Engineering, coping with complexity”, Stevens, Brook, Jackson and Arnold, ISBN 0-13-095085-8)

The left side of the V defines what must be built in descending order of detail from the User

Requirements to the system requirements to the sub-system requirements. The right hand side of

the V represents the corresponding sub-system, system and user test levels

The electrical, mechanical and software components (built by each consortium partner) were

verified as they were integrated and tested at the component level, sub-systems level and systems

level, and then validated against the Use Cases as described by the Users.

Verification of each sub-system was undertaken within its related WP and only the demonstrator

systems testing and integration work was undertaken in WP9 prior to User validation. A specific

integrated test plan was prepared to cover these WP9 activities.

The level of autonomy was derived from the AVERT URD, to which validation information was

supplemented through feedback from the EOD Users. As part of the test plan document, two Use

Cases were validated by the Users supporting the AVERT Project. The Use Cases were initially

simulated within Webots to present to the Users. This enabled informed discussion of the key issues

regarding how AVERT could be used, with specific reference to the level of autonomy and the needs

and expectations of the Users.

To prepare the test framework the AVERT CONUSE sub-tasks, detailing how AVERT conducts EOD

missions were developed with the users and captured as UML Sequence Diagrams. This formed the

basis, against which a detailed analysis was undertaken for each AVERT sub-system, to map, using a

spreadsheet model, all (unique and individual) User and System Requirements needed to achieve

each and every action, executed through all the sub-tasks. The requirements themselves being

graded into KURs, Priority 1 and Priority 2. This was ratified at the Third User Workshop against the

KUR areas of Planning, SA, Monitoring, Interoperation, CIS Management, Security, Usability,

27

Deployability, and Sustainability. It was also confirmed that only KUR and Priority 1 requirements

would be featured in the demonstration itself.

A demonstration assessment capture document was populated during trials and testing prior to the

Final Demonstration, based on each of the User Requirements grouped against the sequence

diagrams. The outcome of each requirement test was assessed against specific numerical criteria

but, due to the security classification of certain performance data, the published results are rated

only in categories. the four assessment categories used were:

a)significant achievement,

b) passed,

c) failed

d) mission critical failure

Scores and comments were then recorded based on the assessment category and summarised in a

presentation table.

Table 1 - AVERT Verification and Validation Summary

The outcome of the assessment is that 98.8% of the KURs were achieved and a total of 80.2%

(11.1% significant achievement and 69.1% pass) of all requirements were reached at the

demonstration stage.

Additionally of the remaining 19.8% which failed only 1.2 % were KUR , 2.5% were Priority 1 and 16%

were Priority 2 ( desirable).

The 1.2% User Requirements that failed as mission success critical related to Bogie tracking

(demonstrated from the rear of the bogies only) and wireless messaging problems that meant that

the bogie Hokuyo local sensors could not be integrated in time for Final Demonstration. However,

the work to correct these had been delivered by ZHAW under deliverable D8.5 “Bogie Local

Navigation Concept” and can be incorporated during development for exploitation.

Demonstration Assessment of 81 Requirements

Failed and

mission critical

(-5 points)

Failed and

compensated

for or

overcome (0

points)

Pass (1 point) Significant

Achievement (2

points)

Total

Significant

Achievements

that could be

achieved

Key User Requirements (KURs) AVERT Total 1.2% 18.5% 69.1% 11.1% 40.7%

Planning 0.0% 3.7% 8.6% 0.0% 4.9%

Situational Awareness (SA) 1.2% 1.2% 17.3% 0.0% 9.9%

Monitoring 0.0% 4.9% 1.2% 3.7% 4.9%

Interoperation 0.0% 0.0% 3.7% 0.0% 0.0%

Communication and Information System (CIS) Management 0.0% 1.2% 3.7% 0.0% 2.5%

Security 0.0% 1.2% 0.0% 0.0% 1.2%

Usability 0.0% 3.7% 16.0% 6.2% 14.8%

Deployability 0.0% 1.2% 12.3% 1.2% 2.5%

Sustainability 0.0% 1.2% 6.2% 0.0% 0.0%

Demo Priority 1 and KUR (48 requirements) 1.2% 2.5% 45.7% 9.9% 34.6%

Demo Priority 2 (33 requirements) 0.0% 16.0% 23.5% 1.2% 6.2%

28

Key assessment findings

a) AVERT has exceeded the expectations in the KUR areas of Monitoring and Usability:

Embedded watchdog monitoring automatically placed AVERT in a known safe state when normal

communications are interrupted and was backed up by a separate dedicated emergency stop and

reversionary command communications channel, allowing direct user override of the autonomous

system.

The AVERT GUI and User Controls provided mapping, bogie trace and systems monitoring. The

system autonomy allowed the entire survey and deployment sequences to be commanded without

any user intervention, except for the designation of the vehicle to be moved and the place where it

was to be deposited.

b) The goal of fully autonomous operation has been reached:

The AVERT system has demonstrated proven swarm technology to rotate and translate bogies in any

direction, meaning that a vehicle may be extracted from complex and constrained environments.

This has been achieved through a fully-autonomous system, from the point of deployment by the

User to the FUP.

The link between the CSS ( extraction path-planning/ obstacle avoidance re-planning functions) and

the BSS (autonomous bogie docking and bogie swarm control functions) has been established via the

RnR application to achieve integration as an autonomous system.

c) The system is potentially practical in terms of safety, speed, capability and endurance:

AVERT has successfully demonstrated that it can take EOD Users out of harm’s way, whether bogies

are deployed on the DU or deployed by an EOD Operator within near range of the blocking vehicle.

The AVERT capability has been successfully validated against a series of Use Cases and has shown

that they can be achieved faster, with extraction times between 30% to 50% of the time taken by

manual methods.

Further improvements on the demonstrated timeline have been shown to be possible through

further optimisation of the survey and deployment sequence and concurrent rather than

consecutive operation of the bogies during deployment. These can be addressed in the development

for exploitation.

AVERT has exceeded User expectations on power management based on total number of vehicle

extractions per battery charge over short distances. In addition the use of quick change batteries

with spares carried on the DU means that extended operation with multiple extractions is possible

without having to withdraw and recharge the bogie units themselves.

d) The mechanical and survey elements of the system are close to exploitation whilst the electronics

and control software will require further development.

This is illustrated in the TRL assessment table.

29

Table 2 - AVERT Demonstrator TRL Assessment

Dissemination and Exploitation - WP10 - Lead IDUS

Dissemination & Exploitation was undertaken through preparation of academic papers and articles

for trade press (Intersec Magazine) attending international conferences and also a number of

exhibitions, at which printed leaflets were distributed, banners were displayed and short videos

were presented. Towards the end of the project the AVERT website was refurbished and a

professional video made of the final demonstration system. The publicity from the conferences and

the video (which was posted on YouTube in March with 340,850 hits by 22nd July 2015) has shown

considerable interest from the general public. In addition discussions have already been held with a

number of companies interested in exploiting AVERT as a product; however none of these has yet

agreed to go to the next stage.

Figure 13 - AVERT Stand at CPExpo Genoa December 2014

AVERT Element TRL

Bogie Mechanical Hardware 9

Electronics & Sensors 6-7

Control & Swarming Software 6-7

Survey & Mapping Software 7-8

30

Demonstration WP11 – Lead IDUS

Following the integration and validation activities a dedicated international workshop was held to

demonstrate the achievements of the AVERT project to a range of users, potential exploiters and the

EU programme manager and EU technical assessor.

At the workshop a presentation of the programme goals and achievements, including a summary of

the validation assessment was given to provide a context to the demonstration itself. The

demonstration encompassed the whole system but some elements ( in particular the DU

deployment mechanism and the reversionary video mechanism had had integration problems and

were not fully functional. These aspects were accommodated in the demonstration planning and did

not impact on the fundamental demonstration of a fully autonomous system. An additional

presentation summarised future and primary markets for exploitation, AVERT team partnering,

exploitation challenges and presented the assessed Technology Readiness Levels (TRL) of each of the

technologies used within AVERT.

The demonstration that was then held showed, with accompanying commentary from the relevant

technical leads, the full autonomous sequence from the towing in of the loaded DU to the docking,

lifting and extraction of a designated blocking car.

The Final Demonstration of AVERT followed Use Case “Timed” (UC3) and was in a representative

environment. The entrance came through a narrow doorway and then the DU was towed by the

EOD Robot about a concrete column in a turning circle much less than the constraints of a standard

car park of 5m to 6m ‘road’ width.

Figure 14 - Robot Towing Loaded DU

The AVERT CONUSE sub-tasks were demonstrated including (i) Dispatch, initialise and deploy AVERT

(EOD Operator); (ii) Bogie deployment and docking (fully autonomous); (iii) Vehicle lift and

extraction (fully autonomous); and (iv) Lower vehicle; recall bogies and DU (the re-docking of the

split-bogie pair and extraction of the joined bogies was demonstrated).

31

The bogies located the blocking vehicle axles, the bogies split and docked with the tyres in

autonomous mode. The vehicle was lifted and immediately extracted.

Figure 15 - Vehicle Extracted During Demonstration

Following the demonstration an extended question and answer session was held with the users and

exploiters around the equipment to discuss issues to be addressed during development for

exploitation and the exploitation prospects themselves.

The key message that came from the user community in this session was that the autonomy of the

overall system is well in advance of the capability that they would need immediately. For

exploitation most of the users identified that they would be keen to see a lower cost system which

would allow them to remote control the bogies to the FUP and the autonomy would then be

concentrated in the docking and lifting and the station keeping of the swarm as the assembly is

extracted under remote control.

In response to this, at the request of the Exploiters attending, a "bogie only" demonstration was

quickly arranged to prove the principle of the reduced scope approach.

The second demonstration showed that the joined bogie pair could be deployed as an independent

tool which could be either carried by the EOD Robot or deployed on a trolley by an EOD Operator.

The bogies were manually located in front of the vehicle and then autonomously docked. The

extraction and rotation was then conducted by the EOD Operator using a joystick, with ‘semi-

autonomous’ control of the bogie swarm, i.e. the User was controlling the ‘vehicle’ whereas the BSS

controller was processing the direction and speed of the mecanum wheels to resolve the User-

controlled vector direction. This was approved by the User community present as a tactically

acceptable option.

32

Specialist Support to Security and Safety Assessment (WP12) and Consortium Advisory Board

(CAB) & Workshops (WP13) – Lead IDUS

Overview

These two workpackages covered the engagement of specialists and arrangement of user workshops

throughout the programme to ensure that AVERT was being developed as a safe system capable of

meeting user needs and that, during development and especially public dissemination of the results,

security guidelines regarding IEDD operations were adhered to

The CAB was established at the start of the programme with appropriate specialist expertise from a

range of European countries. The initial challenge was to agree the key user requirements and

synthesise the operational use cases in such a way that they were representative of a composite

approach compatible with the very different approaches used across the different countries.

Managing the security level of AVERT has been challenging but has been helped by the active

involvement of the CAB members in reviewing internal requirements documents and external

dissemination documents before publication.

Great care was taken in the compilation of the user requirements from user interviews and

workshops to remove sensitive operational information from the internal documents with redacted

versions being specially prepared before posting on the EU portal. This is also true of the Verification

and Validation results where the actual performance figures have been translated into categories in

the posted documentation.

With the changes in the programme demonstration goals following the exit of MSDG the revised trial

scope did not necessitate the involvement of a separate safety specialist prior to development for

exploitation, sufficient expertise for trials level was available within the development team and the

existing CAB members.

There were four user workshops which were held regularly through the programme with a core

team of user representatives from UK, Germany and Switzerland reviewing the progress made and

giving advice on the interpretation of the requirements and the development of the use cases. The

same personnel sat on the separate security committee with suitable personnel from within the

consortium. The security committee sat formally when each workshop was held and ratified ex-

committee approvals of documents for publication. At the fourth workshop the UK representative

had retired and additional user representatives from Germany were included.

At the final demonstration workshop 23 users from ten separate countries were invited and of

these 12 , representing four countries (Germany, Greece, Austria and Switzerland) were able to

attend. In addition five potential exploiters were invited of which three were able to attend. The EU

Project Officer and Technical Assessor for AVERT were also invited and attended the Final

Demonstration.

33

Figure 16 - Team, Users & Assessors at Final Demonstration

Conclusions of S&T achievements across all Work Packages (WPs)

The AVERT programme has taken a concept and designed and demonstrated a practical autonomous

system capable of being exploited as an IEDD tool:

Within this the key overall conclusions are:

The objective of taking the operator out of harm's way has been achieved;

The goal of fully autonomous operation has been reached;

AVERT has exceeded the expectations in the KUR areas of Monitoring and Usability;

The system has been assessed to be potentially practical in terms of safety, speed, capability

and endurance;

The system is capable of exploitation either as a fully autonomous survey and extraction tool

or as a remotely controlled tool with autonomous docking and swarming to aid vehicle

extraction.

The specific conclusions which have been made across the workpackages are:

WP1 (Project Management) The effort required to monitor, report on and co-ordinate the project,

whilst kept to a minimum, was significantly greater than assumed by EU guidelines. Much of this

stemmed from the large volume of deliverables requiring managing and processing, significantly

greater than comparable projects of this size in other spheres.

WP2 (Overall System Definition) The early use of the CAB panel to develop the system requirements

and their continued involvement during the development and interpretation of the system

requirements was essential to the achievement of a practical system design definition.

The system design encompassed the principle of autonomous operation, providing the operator with

a tool which does not require detailed control but which can be paused or overridden by the user at

34

any point . This approach was designed to give the user confidence in using AVERT in IEDD

operations by reducing, not increasing operator workload.

WP3 (Command and Control System) This workpackage showed that sophisticated and effective

command and control systems can be built using modern off-the-shelf networking and processing

with very little adaptation. In particular the adoption of commercially sourced MIMO wireless

networking provided very robust communications in the less than ideal operating conditions

amongst and under vehicles and in steel framed buildings. Many of the techniques used are similar

to those in the professional COFDM systems used in modern EOD robot control so it is expected that

the transition to exploitation will be straightforward.

The GUI (developed in ROS) played a critical role and was scrutinised by the Users during the

Workshops, providing valuable feedback to meet the Users’ needs. The GUI and User Controls have

exceeded User expectations and have been a significant achievement under this project.

WP4 (AVERT Bogie and Deployment Platform Design) The overall design effort to produce a TRL8

level system with only one iteration was phenomenal in the timeframe, especially the reaction to the

results of the A-model trials and the restructuring of the profile and geometry in under 3 months

extension.

One major design success was the totally new mecanum wheel design and construction capable of

unprecedented load bearing within such a low profile. This is a highly significant achievement on this

project and could (in its own right) be exploited.

Another key design success was the imaginative use of 3D printing to provide rapid solutions to

complex housings and components necessitated by the design constraints, especially the low profile.

The rapid turnround, ease of modification and relatively low batch costs of 3D printing make it an

essential tool in research, development and rapid prototyping.

WP5 (AVERT Deployment Platform Development and Fabrication) The main achievement for WP5

was the ability of the team to rally round and produce a relatively complex platform rapidly, even

with the loss of the experienced platform integration partner. The fabrication task was necessarily

disjointed as the development of the automation sequence required the unit to be temporarily

shipped to the UK whereas ideally all tasks would have been completed in one location.

Nevertheless the prototype platform shown at the demonstration, albeit under-powered

pneumatically, provided all the key functions and showed a potential route to exploitation which

could be refined considerably in the future development phases.

WP6 (AVERT Bogie Module Deployment and Fabrication) The choice to fabricate the A-model to a

high standard was instrumental in understanding and refining the processes for procurement and

assembly ready for application to the Demonstrator bogies in Period 2.

This meant that during the development of the Demonstrator bogies a better understanding of the

critical parts, as well as access to specialist suppliers, helped prioritise purchasing, fabrication and

assembly of the demonstrator bogies and provided valuable information to support future

exploitation.

35

WP7 (Simulation & Driving Trajectory Calculation - Synchronised Platform) The application of

simulation early in the programme not only enabled rapid development of the path planner prior to

equipment availability but also enable the rest of the team to visualise and understand the approach

being taken. This became important during the discussions regarding local and global path planning

held between the leads of WP7 and WP8 which resulted in the local navigation path

planning/replanning and obstacle avoidance for the approaching bogies and the extracted vehicle

being subsumed into the global path planning through an additional task in WP7.

WP8 (AVERT Bogie Local Control & Obstacle Avoidance Sensor) For software development the

operational states of the bogies were determined for each stage in the operation in the sequence: (i)

locating the bogies from the DU to in front of the SICK laser scanners; (ii) controlling the joined bogie

pair along a trajectory to the FUP; (iii) wheel tracking to align the bogies to the axle of the blocking

vehicle; (iv) splitting the bogies and docking against the vehicle tyres; (v) synchronised lifting of the

vehicle; (vi) providing coordinated bogie swarm motion to follow a vehicle trajectory (autonomous

or manual joystick vector); (vii) lowering of the vehicle; and (viii) rejoining the bogie pair.

The development of these states could not be fully simulated in the timescale and hence the actual

bogie hardware was needed to develop and tune the software. This was difficult within the overall

programme due to design and fabrication delays, especially for the full set of demonstration bogies.

The preparation of the skeleton bogie set for swarm software development, and the extended use of

the A-model for docking sensor positioning, were essential to the completion of WP8 in time for the

demonstration. Even so several features which were allowed for in the software framework were

not able to be completed (e.g. side entry ). These are documented in the software code and can be

developed on the road to exploitation.

WP9 (Integration of the System Components into Demonstrator) focussed on the development of

AVERT Sub-Systems integration, at the Systems Requirement verification and User Requirements

acceptance validation levels, moving forward to systems integration as each sub-system became

available. The main conclusion from the verification was that the system is already well integrated at

the demonstration stage and scores highly against the requirements. The remaining capablities

needed for exploitation are readily identifiable.

WP10 (Dissemination & Exploitation) The workpackage has seen significant achievement in

dissemination, with several papers accepted into on-line journals and presented to conferences

during the programme itself, together with the featuring of AVERT at international exhibitions where

printed leaflets were distributed, banners were displayed and short videos were presented. Towards

the end of the project the AVERT website was refurbished and a professional video made of the final

demonstration system. The publicity from the conferences and the video (which was posted on

YouTube in March 340,850 hits by 22nd July 2015) has shown considerable interest from the general

public. In addition discussions have already been held with a number of companies interested in

exploiting AVERT as a product; however none of these has yet agreed to go to the next stage.

WP11 (Demonstration) The high attendance and enthusiasm of the users at the demonstration

reinforced the belief that an AVERT system would make a positive contribution as an IEDD tool. The

option to exploit using partial autonomy was specifically requested and demonstrated as a practical

stepping stone to exploitation of a fully autonomous system.

36

WP12 (Specialist Support to Security & Safety Assessment), WP13 (Specialist Support to CAB &

Workshops) The recruitment of specialist, subject matter expert advice from users has been vital to

the understanding of the AVERT role within the IEDD toolset and the use of the CAB committee

structure has been essential to the management of sensitive issues and the internal and external

documentation release.

The consortium is exceptionally grateful for the enthusiasm and input from the User community and

the high praise that AVERT has received at the workshops and demonstrations.

37

Potential Impact

AVERT provides a tool for Police and Emergency Services; with a unique capability to rapidly deploy,

extract and remove blocking vehicles (without disturbance) from vulnerable positions such as

confined spaces, tunnels, low bridges, as well as under-building and underground car parks. AVERT

operates autonomously alongside existing technologies, enhancing bomb disposal response speed

and safety.

There is a general consensus, amongst the Users approached during the development of AVERT, that

current methods of extracting blocking vehicles from restricted access height areas are inadequate.

This is currently a slow and cumbersome operation that exposes IEDD personnel to unnecessary

hazards. AVERT will improve IEDD operators ability to work out of harm’s way, and has shown the

potential to significantly improve IEDD response and capability to disrupt devices. AVERT is a tool

which extends the accessibility of legacy IEDD robotics to hitherto difficult-to-get-at vehicles and will

be welcomed by the IEDD community. AVERT will operate alongside legacy and future IEDD

equipment, utilising existing incident command vehicles and structures, to introduce the benefits of

autonomous vehicle extraction quickly, thereby providing additional capability to existing Police,

Security Forces and Fire and Rescue Services responsible for IEDD operations in Europe.

Competitive advantage is brought by direct application of AVERT to a known European infrastructure

security problem, within a framework that enables systems scalability to other autonomous control

and surveillance systems.

38

Table of Abbreviations

2D Two-dimensional

3D Three-dimensional

ACC AVERT Command Console

AVERT Autonomous Vehicle Emergency Recovery Tool

BBI Consortium member: BB-Ingenieure Ingenieurbüro, Germany

BSS Bogie Subsystems

BU Bogie Unit

CAB Consortium Advisory Board

CAD Computer Aided Design

CIS Communications and Information System

CONEMP Concept of Employment

CONOPS Concept of Operations

CONUSE Concept of Use

COTS Commercial Off The Shelf

CSS Command Subsystems

DDD Demonstrator Design Definition

DOW Description of Work

DSS Deployment Subsystems

DU Deployment Unit

DUTH Consortium member: Democritus University of Thrace, Greece

EOD Explosive Ordnance Disposal

EU European Union

FE Finite Element

FUP Form-Up Point

FW Consortium member: ForceWare

GUI Graphical User Interface

IED Improvised Explosive Device

IEDD IED Disposal

IEEE Institute of Electrical and Electronics Engineers

KUR Key User Requirements

LER Legacy EOD Robot

MIMO Multiple Input, Multiple Output

MS Microsoft

MSDG Consortium member: Marshall System Design Group Ltd, UK

PMB Project Management Board

RCV Remote Controlled Vehicle

ROS Robot Operating System

SA Situational Awareness

SDD System Design Document

SEIT Systems Engineering Integration Team

SMEs Subject Matter Experts

SMS Safety Management System

SOPs Standard Operational Procedures

SRD Systems Requirements Document

TTPs Tactics, Techniques and Procedures

TRL Technology Readiness Levels

UC Use Case

URD User Requirements Document

UML User Mark-up Language

VBIED Vehicle Borne IED

VOIED Victim Operated IED

Wi-Fi Wireless fidelity. Group of wireless data standards defined by the IEEE 802.11 standard series

WP Work Package

ZHAW Consortium member: Zurcher Hochschule Fur Angewandte Wissenschaften, Switzerland