|
|
| (14 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | As the robotics realm itself, robotic software has continually evolved, running in parallel to the
| + | == On Robotic Software Development == |
| − | hardware and software technologies available at the moment. For summarizing the main trends, we
| + | |
| − | identify here three different stages in time, each of them characterized by a particular software issue
| + | * [[Introduction]] |
| − | that received certain effort from the robotics research community. Nevertheless, these stages should
| + | |
| − | be understood as a convenient discretization of a continuous process, thus it is not rare that the
| + | * [[Historic Evolution]] |
| − | works mentioned here can be considered to belong to more than one phase.
| + | |
| − | The first stage we can set in the evolution of robotic software, that we could call raw robotic
| + | * [[Robotics Software Development Systems Review]] |
| − | programming, covers from the lately sixties until the late eighties of the XX century. In that period
| |
| − | robotics programming was limited to solutions based on direct hardware implementation of
| |
| − | algorithms [4] or ad-hoc programming of concrete hardware platforms [23], [32]. Most of the
| |
| − | development of programming languages for robots was focused during that period on industrial
| |
| − | manipulators [25], although those languages were of a very low level (close to assembler).
| |
| − | In a second stage, that we could call middleware robotic programming and extends around the
| |
| − | early nineties, the goal for the robotic software developers shifted to provide pre-defined software
| |
| − | platforms to control the physical devices of the robot (namely, actuators and sensors); in spite of
| |
| − | this software being tightly coupled to specific hardware, it alleviated the, until the moment, heavy
| |
| − | task of programming robots. In this period, some robotic software was in fact real-time operative
| |
| − | systems, like ALBATROSS [36], Harmony [20], or Chimera II [33]. But this stage do not stopped
| |
| − | there: these platforms led to the ability of a more complex processing, and, accordingly, the notion
| |
| − | of robotic control architecture (a set of software elements or modules that worked together in order
| |
| − | to achieve a robotic task) also received attention by the robotics community2. So, the first years of
| |
| − | the 90's decade also offered interesting architectures like TCA [29] or NASREM [1]. Since then,
| |
| − | architecture solutions were continuously released to the robotics arena: e.g., new robotics fields (for
| |
| − | example, multirobots) demand their own architectural approaches ([24]).
| |
| − | Finally, we can distinguish a last stage of robotics software that embraces from the mid nineties
| |
| − | to present, and can be called robotics software engineering. The key point at this stage is that some
| |
| − | SE aspects are considered when programming robots, mainly due to the complexity of robotic
| |
| − | applications. Now, the goal is not to produce a closed or static architecture, but a framework that
| |
| − | allows the developer to produce the architectural solution he/she may need in his/her particular
| |
| − | situation3. Examples of free, commercial, and/or academical frameworks are ORCCADD [30],
| |
| − | Cimetrix's CODE [7], RTI's ControlShell [28], GeNoM [16], NEXUS [9] (a previous instance of our
| |
| − | current BABEL development system), OSACA [31], OROCOS [35], Player/Stage [26], CARMEN
| |
| − | [37], MARIE [38], RobotFlow [25], CLARAty [13], or Microsoft Robotics Studio [22]. Different
| |
| − | SE paradigms -like object-oriented programming, software lifecycle, software validation,
| |
| − | reusability, CASE tools, or automatic code generation- are being progressively included into these
| |
| − | frameworks. However, not all of these focus on SE in the same manner or intensity. In particular, it
| |
| − | is very common that they are not able to deal with heterogeneity in a desirable way, which is our
| |
| − | aim with BABEL.
| |
