Problem – the challenge of a change

This post is part of the SATF work.

In my previous work, I also developed a mobile robot control system. It was inherently evolutionary, thus it was bound to face the problem of continuous change. But the extent to which the problem was pronounced impressed me much and made me think.

This control system was a variation of behavior based system (like Brook’s Subsumption or Arkin’s AURA). In such systems, many of relatively simple and independent behaviours cooperate simultaneously to produce some target behaviour. Each of them is a small Sense-Plan-Act system and there does not exist a global SPA cycle. In theory, such behaviours could be developed independently and incrementally. Although being self-sufficient from the code point of view, the behaviours are not truly independent. They could interact via physical environment (and this is even sought by designers striving to get the so called emergent behaviour); or they could directly suppress other behaviours; or they could produce commands for a single shared actuator. In that case some arbitration is needed, one possible way of which is fusing – an attempt to produce a reasonable average from a set of given commands.

Introduction of a new behavior into the system, then, could (and often did) change the behavior of the whole system in an unexpected way (as is mentioned in the Subsumption critique). This caused the need to reproduce the tests for all correlated implemented behaviors. It was a very time consuming and laborious task: you had to setup the environment of a test, configure the software, issue the commands and check the results of execution as the test case reads, then repeat for every test case. Even putting aside the problem of continuously changing system’s behaviour, simple verification of freshly implemented functionality correctness demanded a significant effort. As a sheer volume of implemented functionality and number of test cases grew, this required more and more time and, eventually, became a real problem.

Admittedly, the control system to be developed this time was not going to be behaviour based. But the problem of continuous change still remained, as it does in any software development problem, only aggravated by the other problem of general unwieldiness of robotic testing procedures.

Previous Next

Leave a Reply

Your email address will not be published. Required fields are marked *