Difference between revisions of "Robotic Software Development"
From The BABEL Development Site
| Line 1: | Line 1: | ||
| − | As the robotics realm itself, robotic software has continually evolved, running in parallel to the | + | As the robotics realm itself, robotic software has continually evolved, running in parallel to the 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 that received certain effort from the robotics research community. Nevertheless, these stages should |
| − | hardware and software technologies available at the moment. For summarizing the main trends, we | + | be understood as a convenient discretization of a continuous process, thus it is not rare that the works mentioned here can be considered to belong to more than one phase. |
| − | identify here three different stages in time, each of them characterized by a particular software issue | + | |
| − | that received certain effort from the robotics research community. Nevertheless, these stages should | + | #The first stage we can set in the evolution of robotic software, that we could call raw robotic 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). |
| − | be understood as a convenient discretization of a continuous process, thus it is not rare that the | + | |
| − | works mentioned here can be considered to belong to more than one phase. | + | #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]). |
| − | The first stage we can set in the evolution of robotic software, that we could call raw robotic | + | |
| − | programming, covers from the lately sixties until the late eighties of the XX century. In that period | + | #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. |
| − | 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. | ||
Revision as of 10:08, 14 May 2008
As the robotics realm itself, robotic software has continually evolved, running in parallel to the 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 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 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 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.
