|
While designing mobile robots, we do think that the prototyping phase is really critical. Good and clever choices have to be made. Indeed, we may not easily upgrade such robots, and most of all, when the robot is on its own, any change in both the software and the physical body is going to be very difficult, if not impossible. Thus, a great effort has to be made when prototyping the robot. Furthermore, I think that the kind of programming is very important. If your programming model is not expressive enough, you may experience a great deal of difficulties to add all the features you want, in order to give your robot reactiveness and decision making autonomy. Moreover, designing, and prototyping the on-board software of a reactive robot brings other difficulties. A reactive robot does not include any matter of rapidity. A reactive system is a system able to respond to a huge panel of situations of which it does not have the schedule. In other words, for instance, the robot does not know when a particular situation may occur, and overall, what it would be doing at this time, and what would be its internal state. This kind of robot must be able to take a decision and to act even if they do not have all the contextual information. To do so, we use a computer language named oRis featuring object and active object oriented programming, but also parallel and dynamic code, (the code can be changed during its own execution). This last point has been made possible because oRis is fully interpreted. However oRis may call fully compiled code, but also Prolog and Java code. An oRis program may be distributed on several computers using TCP/IP network connections. The main issue in this paper is to show how active objet oriented programming, as a modern extension of object oriented programming, may help us in designing autonomous mobile robots. Based on a fully parallel software programming, an active object code allows us to give many features to a robot, and to easily solve tasks conflicts. Active object oriented programming is also very useful in matter of software engineering. Indeed, inside the code, the separation between the logical parts is explicit and plain. So it allows the designer to take only the robot's logical software part, regardless of the software testing environment, and to put it on the physical robot. And even among the logical parts of the robot software, the separation is quite huge, which is a good thing in terms of code engineering, upgrading and reusing. This kind of approach is, or should be, imposed by the particular constraints that lie on military robots, and on any kind of autonomous systems acting in hostile environments, if not in really unknown environments. These systems have to lead a mission on which other systems, and even human lives, rely on. That is the reason why we want to have an accurate look on the on-board software which ensures the robot's autonomy of decision.
|
