Terex ZZ3 overview

A while back I was looking around for a suitable platform for military work (mine clearing, convoy protection, that sort of thing) and came across a vehicle (then) called Otter (or Gaz 3409 'Bobr' (Beaver in Russian), now Terex ZZ3) from a company called Specialist Vehicle Trading. A few conversations with the owner eventually led to a visit to see a couple that were in the UK.

The vehicles were perfect. Weighing in at around 3-3.5t they are fully amphibious and have phenomenal ground mobility too. The pickup version has a very useful cargo area and load capacity and we figured that a teleoperated version with the upper bodywork removed would have well over a tonne payload.

We set about applying our teleoperation architecture to the new platform. In keeping with the modular approach, our main module and drive module are a standard fit with a platform specific interface module being designed to interface to the Cummins 2.8 ISF and vehicle electrics. This interface module also handles the user interface, as part of our target was to replace the Russian-fit 'stick' steering control with a Western-friendly steering wheel or yoke arrangement.

As a testament to the modularity of the teleoperation architecture, the platform was driving through the new control system at the end of the first day of integration, and entirely remotely midday of the second day (which is when these videos were taken).

http://youtu.be/P4veaEZMr6E

http://youtu.be/9alSIcRmnV8

http://youtu.be/HKLJsdnauuY

By day three we had a quad-camera video link fitted (using two forward-looking cameras) and had successfully driven the vehicle on the road (note: we are still unsure as to the legal technicalities of this so we had two qualified tracked vehicle operators on board for the testing).

At this point the decision was made to transition from prototype modules to full production ones, and to swap our manual gearbox vehicle for an automatic version. While doing this we had a couple of high-profile customer demonstrations and took both vehicles (one remote) to the Emergency Services Show (2012) at Stoneleigh where for both days, despite the rain, we demonstrated the remote control ability to show visitors and exhibitors with a high degree of interest.

Currently both vehicles have been returned to their factory in Russia and we are awaiting their return (complete with automatic gearboxes) in order to fit the latest production modules and to finalise the steering automatic calibration routines.

Several people have asked what the intended use of the remote platform is. The key reasons for remote control are to remove people from potential harm and to increase the platforms capabilities by removing people (e.g. taking the vehicle into a burning building, carrying large loads or using it to rescue stranded people (more people per load so less trips)). We have plans to implement a 'virtual hitch' to create a convoy-style arrangement, a remote control manipulator arm (similar to a HIAB) and to add data links to enable extra functionality such as sensors or UAV applications. Whilst we are concentrating on civilian applications, there are many military applications also, not limited to mine detection and clearing, reconnaissance, recovery, convoying and fire support. Our biggest advantages are unparalleled mobility and low cost.

An “Engineering Guide” to agile project management

Project management has become, in many cases, a self-justifying and overly time consuming occupation, acting as overhead to projects and retarding potential progress. This guide aims to show how this effect can be minimised with additional guidelines or rules that will benefit the project, especially in the early stages between project start before the production phase begins. An over-reliance on processes early on when the project is in an increased state of flux also retards potential progress.

No engineering guide would be complete without a reference to Kelly Johnson’s ’14 Rules of Management’ which were formulated and successfully carried out during his time at Lockheed Martin Skunk Works.

But there should be no hard-and-fast rules. Each project is different, run in a different environment with a different group of people and there are no catch-all solutions that will always give an optimum solution.

The key parameters to keep in mind throughout are:

The project flow is shown as an iterative process, starting with an initial set of specifications (generated from customer requirements) which are updated as the design develops. Here the feared ‘scope creep’ can be harnessed as a powerful positive effect as it is primarily restricted to the early modelling and prototype stages which are rapid. It is expected at this stage that a range of suggestions (resulting from modelling and prototyping) are submitted to the customer in order that the base requirements could be modified (note this is a major deficiency in the present systems engineering philosophy).Her

The usual project flow has been modified to highlight early stages including modelling and prototyping. These are regularly missed in contemporary project phases where the focus is on production. Modelling in this case refers to business models (financial and budgetary), operational models (use cases, functionality) and system models (component, subsystem, algorithms), as well as specialist modelling where appropriate (such as FEA or thermal analysis). This is an incredibly important step as it gives confidence that the product is technically and commercially feasible before any ‘metal is cut’. The models are intended to be kept up to date throughout the project from their creation onwards and validated against prototypes and production output when possible.

Project rules:

Personnel:

• No more than 10-20% of the engineering team should be ‘managers’
• Staff numbers to be kept to a bare minimum
• A multi-disciplinary engineer (or systems engineering team for excessively large or complex projects) should lead project decisions
• Using multi-disciplinary engineers eases resourcing issues and will optimise workloads

Planning:

• Mid and Long Term planning to be minimised except for key dates/deliverables and framework
• Budgetary considerations are to be kept updated weekly – project spend and forecast
• Non-essential documentation to be minimised. Essential documentation to be done to high standard.

Engineering team:

• Teams to be co-located for ease of communication
• Teams will be responsible for allocated tasks
• Designing engineers will be responsible for testing
• ‘Beating deadlines’ will be rewarded

Meetings:

• Restrict attendance to required personnel only but publish minutes
• Meetings shall always have actions
• Meetings should occupy no more than 1 hour per day for engineering personnel

Other:

• The customer shall have open access at all stages of the project
• Decisions will be timely
• The rules are flexible, at the discretion of the lead engineer
• Common sense can replace 90% of processes, especially at the start of the project