A Component-Oriented Programming for Embedded Mobile Robot Software

Applying software reuse to many Embedded Real-Time (ERT) systems poses significant challenges to industrial software processes due to the resource-constrained and real-time requirements of the systems. Autonomous Mobile Robot (AMR) system is a class of ERT systems, hence, inherits the challenge of applying software reuse in general ERT systems. Furthermore, software reuse in AMR systems is challenged by the diversities in terms of robot physical size and shape, environmental interaction and implementation platform. Thus, it is envisioned that component-based software engineering will be the suitable way to promote software reuse in AMR systems with consideration to general requirements to be self-contained, platform-independent and real-time predictable. A framework for component-oriented programming for AMR software development using PECOS component model is proposed in this paper. The main features of this framework are: (1) use graphical representation for components definition and composition; (2) target C language for optimal code generation with resource-constrained micro-controller; and (3) minimal requirement for run-time support. Real-time implementation indicates that, the PECOS component model together with the proposed framework is suitable for resource constrained embedded AMR systems software development.


Introduction
An Autonomous Mobile Robot (AMR) is a mechatronics system, which embodies technologies from several engineering disciplines in the domains of mechanical engineering, electronics, automatic control, artificial intelligence, software engineering and computer engineering.Thus, building a complete AMR system requires expertise in those areas.The software aspect of AMR has been recognized as one of the challenging part (Braunl, 2003, Broten et al., 2006) for fully functional and successful AMR.To tackle the difficulty in developing software for AMR, many researchers in robotics research communities proposed the use of Component Based Software Engineering (CBSE) approach (Messina et al., 1999, Blum, 2001, Schlegel, 2006).A component-based solution can help robotic research groups in the following aspects (Oreback, 2000): 1) exchange of software parts or components between robotics laboratories, allowing specialists to focus on their particular field ; 2) comparison of different solutions would be possible from the available components ; 3) startup in robot research can be accelerated using the available components ; and 4) speed up the transfer of research laboratories works in mobile robot to commercial business application.
There have been some efforts on providing CBSE of robotics software in different approaches.Port-Based Object (PBO) component model was proposed to develop a software framework for CBSE for robotics (Stewart et al., 1997).The PBO is supported by an implementation based on domain-specific real-time operating system (RTOS) mechanisms.Blum (2001), proposed a component-based system architecture Operating System for the Control of Autonomous Robots (OSCAR) for exploration of indoor environment with an AMR.OSCAR fully relies on the middle-ware standard CORBA 2.3 specified by the Object Management Group consortium.Since, OSCAR is based on CORBA component model; it is not suitable for implementation on resource limited embedded mobile robot systems.This can be seen from the implementation of OSCAR on MARVIN (Blum, 2001) robot which is equipped with four PCs running Linux operating system.
Orca is an open-source CBSE framework designed for mobile robotics (Brooks et al., 2005).An Orca component is a stand-alone process which interacts with other components over as set of well-defined interfaces.Orca framework provides the means for defining and implementing these interfaces.In Orca framework the processing power and memory requirements are large.Thus, Orca framework is only targeted for off-board processing, i.e.Orca assumes some form of embedded software already present on AMR for communicating with the off-board components.Thus, requirements for selfcontained AMR and predictable real-time performance of AMR systems are not considered in Orca framework.Component-based development of AMR systems has been used in industries.Mobility is a commercially available component-based system produced by Real World Interface Company (iRobot, 2002), to support a certain class of mobile robot platforms which are produced by the company.Most of the works on CBSE in robotics do not address the issues of ERT software for resource-constrained AMR and platform-independent components.As emphasized by Brega et al. (2000) and Pont and Siegwart (2005), realworld AMR must be self-contained and able to meet timing constraints.When on-board or embedded computation is required AMR software development is typically confronted with limited resources such as computing power and memory.With the limited computing power, a precise observation of the timing constraints of the AMR systems is a necessary to make complex robot systems more reliable.Most important, a predictable real-time performance on a robotic system is a necessary condition for guaranteeing a stable behavior of the robot (Buttazzo, 1996).To tackle the above issues an implementation paradigm or framework for component-oriented programming (COP) of AMR software is proposed.The COP framework is a programming framework based the PErvasive COmponent Systems (PECOS) component model (Nierstrasz et al., 2002).The proposed framework enables the idea in PECOS to be implemented optimally without requiring any support tools and proprietary runtime environment from the original PECOS project.The deployment model in the proposed framework is based on C language for portability across platforms and compact code generation which is optimal for resourceconstrained ERT systems.The layout of this paper is as follows.Section 2 describes the PECOS component model for which the framework is based on.In Section 3 the proposed framework is described and its implementation for an AMR software is illustrated.Section 4 presents some implementation results of the framework on a real AMR.Finally, the conclusion is presented in Section 5.

Background
Industrial component technologies currently available such as OMG's CORBA Component Model (CCM), Microsoft's (D)COM/COM+, .NET, SUN Microsystems' JavaBeans and Enterprise JavaBeans, are generally complex, require large resources such as memory and computation power, and are platform dependent (Crnkovic, 2004, Rastofer & Bellosa, 2001).Furthermore, they do not address the non-functional properties such as how much memory it consumes and timing constraints which are important in ERT systems.Consequently, a number of component models such as PBO (Stewart et al., 1997), Koala (Ommering et al., 2000), PECOS (Nierstrasz et al., 2002), and ReFlex (Wall, 2003), have been developed to address requirements of ERT software.Evaluation of these component models against the industrial requirements of heavy vehicle sector shows that PECOS is the most complete component technology with good support for industrial requirements (Möller et al., 2004).PECOS component model was originally developed for field device systems and some supporting tools such as Component Composition (CoCo) description language for specifying components, code generator for generating Java/C++ code skeletons from CoCo and runtime environment (RTE) which interfaces generated code from the real-time operating system used (Wuyts et al., 2005).However, many of these tools are incomplete and information on the RTE is not publicly accessible as it is a proprietary of the ABB Company (Bouyssounouse and Sifakis, 2005).Non-functional verification in PECOS is performed using Rate monotonic analysis (RMA) and schedule verification (Wuyts et al., 2005).The RMA verification is to check whether the entire components involved in the composition meet their deadlines while schedule verification is to check the possibility to fit execution and synchronization behavior sequentially in each task.The original framework for implementation of PECOS components has some limitations with respect to our needs for development of ERT software for AMR systems.Some of these limitations include: 1) the use of CoCo language seems to be difficult for the target audience as CoCo is almost a programming language by itself; 2) targeting for Java or C++ may not be appropriate for small microcontrollers with limited resources, furthermore, Java and C++ supports may not be available for those microcontrollers; and 3) the RTE is difficult to develop and information on the RTE is not publicly accessible.After experimenting with the PECOS component model and implementing it in the AMR applications, it was found that the assembling activities of components at design stage are simple but the implementation of the components is complex without the support from PECOS tools (Jawawi et al., 2006).With the absence of PECOS supporting tools and RTE, there are at least three options in which the PECOS component model can be used effectively in the AMR software development: 1) develop our own supporting tools and RTE; 2) seek alternative from other existing tools such as real-time Unified Modeling Language (UML) tools (Douglass, 2004); or 3) propose an alternative implementation framework for CBSE of AMR embedded software development.Option three has been selected in this work, where a practical Component-Oriented Programming (COP) framework is proposed and has been used to implement PECOS component model for CBSE of embedded AMR software.

The Component-Oriented Programming Framework
This COP framework was originally intended for development of ERT software for AMR.The target audience is the mechatronics and robotics researchers which are not from software engineering background and do not have extensive programming experience.However, experience shows that the COP framework is generally suitable for developing reactive embedded systems which typically use 8-bit or 16-bit microcontrollers with memory constraints and developed with C language.The main features of the COP framework are: (1) use graphical representation for components definition and composition; (2) target the codes in C language for optimal code generation with resource-constrained micro-controller; and (3) depends on minimal requirement for run-time support.Fig. 1 shows the main elements of the proposed COP framework and layers of dependency of each element.The main software elements of the COP framework consists of the component-based software to be developed, the hardware abstraction layer (HAL), and a real-time operating system (RTOS) with its associated abstraction layer (RTOS AL).At the bottom layer is the robot mechanical and electronics hardware with the on-board embedded controller.The COP framework does not assume any particular underlying microcontroller unit and RTOS used in the robot hardware.It is up to the HAL and RTOS AL to abstract the robot hardware and its communication with the robot hardware.The HAL provides decoupling between the components and the underlying hardware, while the RTOS AL provides a thin layer of interface between the components and the actual RTOS used.In this way, the COP framework addressed platform independent issue.The dependency of PECOS model to RTE deployment model thus is replaced by the two abstraction layers.(Jawawi et al., 2006), and a deployment model.In this framework, instead of using the CoCo language, graphical representation of components is used for components definition and composition.Currently, codes have to be written manually from this graphical representation.The framework describes here is based on manual creation of codes guided with the code templates proposed in the COP framework.The COP framework is targeted for C language, since, optimized C compilers are available for most microcontrollers, and C is portable across many platforms.Furthermore, C is a familiar language and has been use extensively by the target audience.In the following sections, the application of the COP framework in the two main engineering activities in the development of component-based software, i.e. component engineering and application engineering are explained.The above three infrastructures proposed here, namely, the graphical model specifications, connection model and the deployment model and their use in component-based development of AMR software are highlighted.

COP in Component Engineering Process
Component engineering process concerned with the analysis of domains and development of generic and domain-specific reusable components.Based on patterns analysis in domain of AMR systems, common components are identified and the specifications of the components are documented in graphical blocks form.As a result of a pattern mining process, currently ten software components were identified in the analysis pattern for typical AMR software.The components identified are: input-output, actuator, sensor, signal processing, motor control, communication, Human-Robot Interface (HRI), Behavior-Based Control (BBC), coordinator and planner.Fig. 2  The code body for an active component consists of three main parts: initialization part, execution part, and synchronization part.In the passive components, the synchronization part is not required.The initialization part is responsible for component initialization, and in the case of active component it calls RTOS through RTOS AL to create the thread or task for the component with the defined Period and Priority.The execution part is the main component behavior while the synchronization part updates the data between inner ports and outer ports as defined by PECOS component execution model.

Fig. 3. MotorControl composite component
Composite components can be built by hierarchically composing a number of subcomponents and stored in the repository for later use.Fig. 3 shows a generic composite component named MotorControl built from three passive subcomponents: Encoder, PID and Motor.The code body for the composite component is still consists of the above three main parts.On top of this, the composite component is responsible for calling the initialization and synchronization parts of its child or sub-components.In this way complex component can be built by hierarchically composing other composite components, and the user is only consent with the top level component interface and synchronization, while the inner components synchronization are handled by the top level component.

COP in Application Engineering Process
Application engineering process is also called component-based software development (CBD), involves developing applications using software components previously developed.A design of an AMR embedded software will be used in this section to illustrate the steps involve in the application engineering using the COP framework.The major steps involve in application engineering of the AMR software are: identification of required components, composition of components, scheduling analysis and assigning the period and priority of components, and codes writing.Based on the requirements and patterns analysis, the required components are identified and composed by connecting the compatible ports.Fig. 4 shows a block diagram composition of the AMR software for MobileRobot1, which consists of eight leaf components and seven composite components shown by blocks with shadow.Sometimes, the concrete components which are application-specific need to be developed from the generic components previously created.For examples in Fig. 4, motorctrl_right and motorctrl_left components are concrete components developed from the MotorControl component.
In this framework, connections of constants to compatible ports are allowed.This is shown in Fig. 4 by the connections of constants to input port (IP01) of motorctrl_right and motorctrl_left components.This gives flexibility for testing and debugging of components and also useful for AMR software to reconfigure components for use with specific hardware or application.Once the composition is completed, the next step is to allocate property bundles value such as period and priority for active components using the WCET and some scheduling theories.The Rate Monotonic Analysis (RMA) (Klien et al., 1993) theory is mainly used to allocate priority in this framework.The MobileRobot1 components of Fig. 4  Response time analysis proposed by Audsley et al. (1993) is then used to determine whether the deadline for each task in Table 1 can be met.The goal of response time schedulability analysis is to show that each task invocation finishes before its deadline.
For each invocation of a task i, worst-case response time Ri is calculated and compare with deadline Di.Equation 1 gives the total calculation for Ri of a task i by adding its own WCET Ci plus the interference on how often higherpriority task j invocation can preempt an invocation of task i.

( )
Since, there are ten tasks derived from the AMR component composition, the analysis were applied for values of i ranging from 1 to 10.For each i worst case response time Ri was calculated and compare with deadline where Di = Ti, the task period of task i.The calculated Ri for all tasks from the design composition in Fig. 4 are listed in Table 1.This indicates all Ri are within their deadlines, hence the design composition of components in Fig. 4 is predicted to be schedulable according to RMA theory.Fig. 5 shows a time line description of how the MobileRobot1's tasks will be scheduled.The schedule is generated using TimesTool simulator from www.timestool.com(Amnell et al., 2003) AMR application is software with about 5000 lines of C codes not including the RTOS source codes.The total binary code size for the resulting application is about 21Kb with RAM usage of about 15Kb.This indicates that, the PECOS component model together with the COP framework can generate application with minimal memories requirements, suitable for other resource constrained ERT systems.Implementing the software by reusing at functions or libraries level will result in reduction of LOC numbers or size of binary codes since the codes to support component interfaces, synchronization and implementa-tion can be eliminated.However, we do not intend to compare the reuse with functions and reuse with components due to the advantages offered by component-based reuse approach.This is one of the trade-off one has to make in using component-based approach.

Measuring Amount of Code Reuse
The main concern in the COP framework is the reuse of the components on different platforms and different physical sizes/shapes of AMR.To quantify the benefit of using the COP framework for software reuse, the amount of reuse metrics were used to measure the reuse improvement effort.A common form of reuse metrics is based on lines of code i.e. the amount of reuse percentage is the percentage of lines of reuse code in the software over the total line of code in the software (Frakes and Terry, 1996).The strategy adopted in measuring amount of reuse was to use two AMR systems with different mechanical and computation platforms and different sizes.The first AMR is called MobileRobot1 and the embedded software is the implementation of components composition shown in Fig. 4. The second AMR is called MobileRobot2 and the software is the implementation of components composition shown in Fig. 7. Table 2 tabulates the specifications of platforms and sizes/shapes of the two AMRs.The task of MobileRobot1 is to find exit passage in an environment surrounded by walls while avoiding obstacles.The mission of MobileRobot2 is to navigate in a room with obstacles trying to locate fire and automatically extinguishes the fire.To perform these different tasks, the two AMR are equipped with sensors and actuators as shown in Table 3.
From Table 3, it can be seen that two hardware components exist in both systems are motor and distance sensor.The type of distance sensor used in both robots is the same but the type of motor used in the two robots is different.Thus, it expected that reuse of distance sensor component will be high, while the reuse of motor component will be low.
In this measurement strategy, the amount of software reuse involves in developing MobileRobot2 software from the MobileRobot1 software is measured.It is assumes that the components from the MobileRobot1 software can be treated as reusable components for developing the MobileRobot2 software.This is true in this case because the software components are: i) generic which were derived from AMR analysis pattern and 2) specified using the modified PECOS component model.
To measure the software reuse rate, line of code (LOC) is used because it is a common metric used in measuring development effort and reuse rate (Rothenberger and Hershauer, 1999).The two ways for amount of reuse analysis were performed on the components assemblies are: 1. Count the LOC by ignoring the hardware dependence modules which include the HAL and some platform specific parts of μC/OS-II RTOS.Thus, only the platform independence components are considered.2. Count the LOC considering all the codes.Without considering the hardware dependent module and RTOS, the amount reuse percentage is calculated as: Equation 2 is also used to calculate the new and changed percentage by changing the Reuse LOC variable.Fig. 8 shows the composition of reuse, change and new software in developing the MobileRobot2 software.Fig. 8 shows that 74% of the software is reused from the MobileRobot1's components, 25% software is new since two new components are required to handle new sensors not previously available on MobileRobot1 software, i.e.LightSensor and TemperatureSensor, a new behavior (BBCSeekFire) is required for the mission in MobileRobot2, and two modules need to be rewritten to configure and integrate the components (pecos_cfg and main function of MobileRobot2).These two components are considered hardware dependence and robot dependence components.
The changes in BatterySensor component is required to accommodate different battery voltage on MobileRobot2.In BBCAvoid component, the changes is required because the size and shape of the MobileRobot2 are different from MobileRobot1 and this requires some code changes in the Avoid behavior.In MobileRobot2 components composition, five of six hardware dependence from MobileRobot1 i.e.Analogin, Motor, LCD, DistanceSensor and Switches can be reused 100% without change.This is possible with the use of HAL as described in Section 3. If the hardware-dependence modules and components are included to calculate the reuse percentage, the reuse percentage will reduce to 67% as shown in Fig. 9.The reason for this reduction is that new modules and components need to be written to support: 1. different processor and hardware requirements, RTOS platform (67% of new LOC consists of pecos_cfg, HAL and porting components of μC/OS-II RTOS) 2. different mission of AMR (34% of new LOC consists of modules or components pecos_cfg, APIBOTmain, BBCSeekFire, LightSensor, and TemperatureSensor).

Conclusion
A practical COP framework for CBSE of autonomous mobile robot embedded software is proposed to better support embedded resource-constrained AMR components integration and composition.To support this COP framework, three infrastructures were developed based on PECOS component model: PECOS component model specifications and components repository in graphical blocks form, PECOS diagrammatical connection model, and a deployment model.The proposed COP framework enables the idea in PECOS to be implemented optimally without requiring any support tools and proprietary run-time environment from the original PECOS project.The deployment model in the proposed framework is based on C language.Templates for components and code skeletons for AMR software are provided in C language.As the C language is the common and familiar language for the target audience, i.e. robotics engineers with little training in software engineering, these strategies will speed up the development of AMR application software.The COP is used to implement embedded software on two real AMR systems with behavior-based intelligence.Results show that, the modified PECOS component model together with the developed COP framework can generate software with minimal memories requirements, suitable for platform-independent resource constrained ERT systems.This is achievable in the COP by removing the dependency on run-time environment with abstraction layers, targeting the codes to standard calls for minimal RTOS, and the use of C language.The amount of reuse measurement showed that up to 74% reuse rate can be achieved in designing a new component-based robot software from existing software components.This indicates that the use of PECOS based component model enable component engineering products to be created directly from other projects.This measurement also prove that the introduction of HAL and RTOS abstraction layers in the proposed COP framework can increase the reuse capability of the design components in the component-based software development.

Fig. 9 .
Fig. 8. MobileRobot2 platform-independence software composition shows a generic component named PID documented in graphical block form.The input ports and output ports, with their associated types and range of values are defined in the block.Each port is numbered accordingly for easy reference.Arrows on the ports indicate the direction or whether they are inports (IP00-IP02) or outports (OP00).Bidirectional ports are not allowed in this framework.The Period and Priority fields are timing specifications for active component, which has its own execution thread in multitasking environment, usually determined in the application engineering stage.Not shown in the block is the specification of worst case execution time (WCET) of the component.Fig.2.A PID component documented in block formThe component specifications are further translated manually to C source codes and stored in repository for use in the application engineering stage.Each component is translated into two parts of C codes: code for interface and code body.For example, the generic interface code implementation for the PID component in Fig.2can be written in C is as follows:

Table 1 .
The mapping results of all components in MobileRobot1 composition are tabulated in Table1.The tasks in the table are ordered from highest to lowest priority.The WCET were measured experimentally in real-time using oscilloscope and a spare bit of output port on the microcontroller, and the tasks periods were obtained from the AMR requirements.The timing results for the MobileRobot1

Table 3 .
The AMR systems sensors and actuators