Getting on with the job

Citation

Loughlin, C. (1999), "Getting on with the job", Industrial Robot, Vol. 26 No. 3. https://doi.org/10.1108/ir.1999.04926caa.001

Getting on with the job

Getting on with the job

Our theme is "Teleoperation" and while gathering material for this issue I have been surprised that most of those working in this field hold very similar views regarding the man-machine interface and the distribution of tasks between the person and the computer that controls the robot.

A fully autonomous robot is generally not regarded as being either possible (today) or desirable. However the considerable benefits which can arise from having a certain task performed automatically, such as tool changing and stow and deploy operations, are widely acknowledged. I agree with this view, but rather than expand it still further I will attempt to highlight the issues from the user's perspective.

Teleoperator driven robots are very different from their industrial relations. Very occasionally a standard industrial robot will be used for a teleoperator task but this will usually only be the case if budgets, project time constraints, or lack of availability of a suitable teleoperator manipulator, preclude the development of a more purpose designed teleoperator system.

Whereas industrial robots are characterised by phrases such as "teach and repeat" and "cycle times" and "operation of the same pre-programmed moves over and over again", it is quite likely that a teleoperator manipulator will never perform the same action twice. Also, whereas a single industrial robot may be used in many different applications and sold in reasonable quantities (> 100), teleoperator manipulators are often designed for a very specific task and environment and will consequently only be produced in small quantities (<10).

The most important element in the teleoperator system is the human operator and I consider it most important that the actual operators (and not just their supervisors) are involved in the system design process. It is all too easy for the whizz kids designing the control system to be blinkered by their own enthusiasm and well intentioned beliefs regarding "useful features". The result can soon end up being a technological marvel and a practical nightmare.

To illustrate this point I will paint a picture of a typical teleoperation scenario:

You are on a small ship perhaps 50m in length, about 300km and a day's sailing out of Aberdeen in the middle of Scotland's North Sea. The ship and crew cost £50,000 a day to run. The task in hand is to turn a manual control valve on the sea bed to isolate a section of oil pipeline. The manipulator is mounted on an unmanned submersible vehicle (ROV). A storm is approaching and sea state is force six and rising and you cannot operate above force seven. As an extra bonus the valve has not been operated for sometime and may be stiff, also if too much force is exerted the valve stem can break and resultant costs of repair are in excess of £500,000 excluding incidental costs from pipeline "down time".

You are the manipulator operator ­ so what are your priorities?

• •

  Reliability of the manipulator.

• •

  Ease of use.

• •

  Minimise risk of damage to control valve, the manipulator and the ROV.

• •

  Getting home before the weather gets too rough.

Under such circumstances you will be seriously unimpressed if the manipulator ceases to work AT ALL because the vdu monitor cannot display the particular shade of pink specified for the valve in the valve characteristics database, because of a bug in the current screen driver software for the super enhanced simulation mode you had no intention of using in the first place.

Technical developments are all very well but they should ideally happen in the background without any need for operator action, and they must never ever unnecessarily jeopardise the safe and efficient operation of the system as a whole. The goal is simply to get the job done.

Clive Loughlin