Final Report Summary - AVERT (The Autonomous Vehicle Emergency Recovery Tool (AVERT) provides a capability rapidly to deploy, extract and remove both blocking and suspect vehicles from vulnerable positions and confined spaces.)
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 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
Project 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.
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.
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.
Project Results:
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.
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 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 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,
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 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 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.
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.
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.
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.
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).
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.
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.
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 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 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.
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.
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.
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 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 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.
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.
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, 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.
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.
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, 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.
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.3 % 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.
Key assessment findings
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.
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.
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.
Dissemination and Exploitation - WP10 - Lead IDUS
WP10 (Dissemination & Exploitation) involved attending international exhibitions, at which printed leaflets were distributed, banners were displayed and short videos were presented. An AVERT website was set up and populated. A video of the Final Demonstration was posted on YouTube, where it had received 1,124 hits by 22nd July 2015. Some companies approached IDUS, wanting to show AVERT on television and these queries are being followed up. Several companies were approached, with a view to exploiting AVERT as a product; discussion are still ongoing.
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.
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).
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.
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.
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.
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 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.
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) 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.
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.
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.
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.
List of Websites:
www.avertproject.eu
www.youtube.com/watch?v=7Oo4AGviyJo
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 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
Project 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.
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.
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.
Project Results:
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.
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 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 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,
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 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 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.
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.
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.
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.
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).
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.
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.
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 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 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.
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.
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.
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 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 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.
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.
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, 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.
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.
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, 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.
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.3 % 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.
Key assessment findings
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.
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.
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.
Dissemination and Exploitation - WP10 - Lead IDUS
WP10 (Dissemination & Exploitation) involved attending international exhibitions, at which printed leaflets were distributed, banners were displayed and short videos were presented. An AVERT website was set up and populated. A video of the Final Demonstration was posted on YouTube, where it had received 1,124 hits by 22nd July 2015. Some companies approached IDUS, wanting to show AVERT on television and these queries are being followed up. Several companies were approached, with a view to exploiting AVERT as a product; discussion are still ongoing.
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.
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).
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.
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.
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.
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 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.
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) 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.
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.
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.
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.
List of Websites:
www.avertproject.eu
www.youtube.com/watch?v=7Oo4AGviyJo
