Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers

Andrew McKenzie; Shameka Dawson; Fei Hu; Monica Anderson

doi:10.1155/2011/525724

Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers

McKenzie, Andrew;Dawson, Shameka;Hu, Fei;Anderson, Monica 2011-12-29 00:00:00 Hindawi Publishing Corporation Journal of Robotics Volume 2011, Article ID 525724, 11 pages doi:10.1155/2011/525724 Research Article Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers 1 2 1 2 Andrew McKenzie, Shameka Dawson, Fei Hu, and Monica Anderson Department of Electrical and Computer Engineering, The University of Alabama, Tuscaloosa, AL 35487, USA Department of Computer Science, The University of Alabama, Tuscaloosa, AL 35487, USA Correspondence should be addressed to Andrew McKenzie, awmckenzie@crimson.ua.edu Received 7 May 2011; Revised 16 September 2011; Accepted 16 November 2011 Academic Editor: Yuan Zheng Copyright © 2011 Andrew McKenzie et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Implementing a robot controller that can eﬀectively manage limited resources in a deterministic, real-time manner is challenging. Behavior-based architectures that decompose autonomy into levels of intelligence are popular due to their robustness but do not provide real-time features that enforce timing constraints or support determinism. We propose an architecture and approach for using the real-time features of the Real-Time Speciﬁcation for Java (RTSJ) in a behavior-based mobile robot controller to show that timing constraints aﬀect performance. This is accomplished by extending a real-time aware architecture that explicitly enumerates timing requirements for each behavior. It is not enough to reduce latency. The usefulness of this approach is demonstrated via an implementation on Solaris 10 and the Sun Java Real-Time System (Java RTS). Experimental results are obtained using a K-team Koala robot performing path following with four composite behaviors. Experiments were conducted using several task period sets in three cases: real-time threads with the real-time garbage collector, real-time threads with the non- real-time garbage collector, and non-real-time threads with the non-real-time garbage collector. Results show that even if latency and determinism are improved, the timing of each individual behavior signiﬁcantly aﬀects task performance. 1. Motivation Currently, real-time features and speciﬁc frequency requirements are not included in mobile robot architectures Developing a mobile robot controller can be a complex [6]. Timing constraints, determinism, and low latency are process. Robots must simultaneously perform safety checks important factors to ensure proper operation of the robot (such as obstacle avoidance) while accomplishing high- and can result in better resource utilization. By not having level goals (mapping and path following). Behavior-based an actual real-time controller that explicitly addresses these controllers [1] use prioritized ﬁnite state machines to man- issues, developers may get erratic results causing inconsistent age layers of complexity. Existing robot architectures either and ineﬃcient robot behavior. enable this approach [2, 3] or are purposefully unstructured If the laws of control theory [7]weretobeapplied to to accommodate behaviors [4]. a behavior-based system, the frequency of each individual Although behavior-based paradigms provide robust con- robot behavior would be based on input availability. The def- trollers in the face of complex conditions, real-time issues inition of individual frequency requirements for subsystems are not addressed as part of these architectures. Tasks may within a control system is part of the process for traditional need to be executed and completed within a time constraint real-time system development [8]. Frequencies deﬁne the to prevent undesired results. Since timing and determinism period and the deadline for processing sensor input. If a task matters [5], should robot controllers be programmed using misses its deadline, the system is not responsive to changes real-time control system standards, allowing tasks to execute in input. However, it is not enough to run all behaviors “as in actual real time? fast as possible.” In fact, some resource intensive behaviors 2 Journal of Robotics may take resources and/or preempt more time-sensitive OSaC ˆ s and languages. In Section 2, background and previ- behaviors. Slowing down behaviors that do not receive input ous work is presented. Control theory and its relevance to frequently may free resources for more time-sensitive tasks. our approach is presented in Section 3. Section 4 describes In order to address this timing constraint issue, we ex- Java RTS and its relevance to the interface. Section 5 presents amine adding the Real-Time Speciﬁcation for Java (RTSJ) [9] the implementation of the architecture and the experimental standard to an existing mobile robot architecture [10], using setup. The experimental results and the analysis are pre- Sun’s Java Real-Time System (Java RTS), and running it on a sented in Sections 6 and 7, respectively. Conclusion and real-time operating system (RTOS). Java, a language known future directions are in Section 8. for its portability and safe object-oriented features, has become an option for developers of real-time systems [11]. 2. Background While languages such as C and C++ pose an issue for many real-time developers because of the memory issues associated 2.1. Real-Time in Mobile Robotics. Several robot develop- with them, they are the most common choice because of their ment platforms are available for mobile robots. However, performance and ease of use [12]. As an alternative, Java RTS some of these architectures do not provide real-time fea- is designed to be a system that has deterministic, real-time tures that enforce timing constraints. Of the ones that do features [13] without forcing developers to manage memory provide real-time features, they do not allow developers to usage. This makes Java an appropriate choice for program- provide their own frequency requirements. Buttazzo et al. ming a real-time robot architecture. However, Java is timing [15] conducted research in real-time control of robots where sensitive. Particularly the traditional garbage collector may they designed and implemented a software architecture used cause nondeterministic behavior in a real-time system. The for designing robotic applications with real-time constraints. real-time garbage collector (RTGC) implemented in Java The architecture was a hierarchical programming environ- RTS provides a deterministic approach to dealing with the ment consisting of four parts: an action layer, control layer, garbage collector. communication layer, and a hard real-time kernel (HARTIK) The robot architecture that we propose has several fun- to control the three layers. All of the layers were written in C and encapsulated with a set of library functions. damental purposes. First, real-time issues pertaining to robot They concluded that their architecture provided a ﬂexible controllerswillbemadeexplicit. Secondly, an eﬀective way framework for the development of robotic applications. to use real-time Java within a behavior-based mobile robotics However, they did not provide any experimental results. framework will be demonstrated. By also allowing developers Brega et al. [16] conducted a case study of the XO/2 to declare frequency requirements, tasks can be run only operating system controlling a Pygmalion Robot in real time as fast as needed. Allowing frequencies to be declared can using the Oberon-2 programming language. They discussed ultimately provide the developer with a better understanding the needs and requirements for real-time control of robots in of the frequencies and their relationship to code features. research, education, and real-world use. The XO/2 operating This includes which tasks depend on speciﬁc input devices system was designed by Brega et al. as a real-time operating as well as the dependencies between diﬀerent tasks. system. They concluded that they could not quantify the It is possible that such an architecture will help move need for self-contained autonomy, real-time, and safety embedded systems students up the learning curve faster. In in mobile robots. They also noted that the increasing [14], a real-time systems undergraduate laboratory that was complexity of mobile robots set higher requirements for the created for Java programmers is described. It was found that robots’ hardware, software, and indirectly the operating students taking the real-time software engineering module system. Finally, they noted that “safe composition of soft- performed better and enjoyed it more than other modules. ware modules, type-safety, deadline-driven scheduling and Also, the majority of the students who took this module automatic memory reclamation mechanisms can relieve the found work in the real-time and embedded systems industry. application programmer from many time-consuming im- The results of this work widely impact both current and plementation issues, while raising the safety-bar.” future behavior-based robot development environments. Auerbach et al. [17] implemented a real-time Java ap- Robot architectures need to manage real-time constraints in plication that used Exotasks, a novel Java programming order to eﬀectively behave in a deterministic manner. Exper- construct that achieved deterministic timing, on a real-time imental results show that timing of individual behaviors do virtual machine. They built a helicopter, the JAviator, for aﬀect the robot’s high-level task performance. testing. They showed that their implementation achieved In this paper, we map a behavior-based robot architecture time portability on diﬀerent hardware platforms. However, to Java RTS in order to show that the absence of or incorrect all of their data was processed oﬀ-board and they only timing constraints aﬀect performance. The architecture al- observed one behavior (hovering of the helicopter). lows developers to declare frequency requirements as part of the client interface. Java RTS features are also added to help better manage resources. The main contribution of 2.2. Real-Time in Non-Mobile Robotics. Stewart et al. [18] this paper is to create an oﬀ-the-shelf system that allows real- designed a real-time architecture that is based on port- time control of autonomous robots. To our knowledge our based objects. Port-based objects are fully contained software architecture was the ﬁrst one made for fully autonomous components that contain both state and methods as well mobile robots doing complete tasks, using oﬀ-the-shelf as provide input, output, and resource ports. Input ports Journal of Robotics 3 describe data needed by an object, and output ports describe 3. Control Systems data produced by an object. An input port can only be Control systems are devices or systems that control another connected to exactly one output port. Outputs of the same device or system. Closed loop control systems use the systems type must be merged into one unambiguous output. Each output (feedback) to modify the input to get the desired object is self-contained and has its own frequency. Task output. Today most control systems use computers to make scheduling is determined by the developer and can be all of the controller decisions, called digital control. Since modiﬁed to either increase system stability or reduce com- digital control uses computers, which make decisions every putational resource consumption. clock cycle, the signal is discrete. Bruyninckx et al. [19] implemented a 1 kHz position, On the basic level, autonomous robots use computer-run velocity, and hybrid force control of a KUKA 361 six-DOF algorithms to control its movement, based on input from robot using the hard real-time motion control core of the sensors such as sonar, infrared, GPS, and laser range ﬁnders. OROCOS project (Open Robot Control Software) [20]. They Therefore, an autonomous robot qualiﬁes as a control system bypassed the KUKA legacy controller and controlled it using because it is a device (a computer) that controls other devices only the OROCOS code. The code runs on Linux (without such as motors. So autonomous robots should be treated as real-time performance) and on RTAI (RealTime Application control systems and be required to follow the same rules that Interface for Linux) in hard real time. digital control systems follow. Robertz et al. [21] implemented a motion control system Since digital control is a digital (discrete) time system, for an industrial robot using Java RTS on an RTOS. They problems can occur if input data is not being sampled fast used real-time threads (RTTs) for critical tasks and non-RTTs enough. This happens if the input signal changes between for noncritical tasks. In their approach, the RTTs were run at samplings. For example, if an input has two values A and B, the highest priority and the non-RTTs were run at a lower when value A occurs, the signal will be transmitting data for priority, even lower than the real-time garbage collector. a minimum of 80 ms, and B for 50 ms. The input is sampled Although they discuss time measurements of network delays, at 10 Hz (once every 100 ms). The system samples the input they do not present results showing the eﬀect of these real- signal at times 100 ms, 200 ms, 300 ms, and so on. The input time features on the overall system. signal for A is active from time 0 to 130 ms, changes to B at time 130 ms, then changes back to A at 180 ms. Since the 2.3. Behavior-Based Architectures. Subsumption-based ro- sampling rate occurs every 100 ms, the digital control system botic controllers build autonomy out of layers of behaviors sees A at time step 1 and 2. So it does not see B, which could [22]. Basic layers are complete processing units that take cause problems. The simple ﬁx is to make sure that your input and provide appropriate output. We are particularly sampling time is fast enough. interested in properties that enable temporal decomposi- In control theory, the sampling rate should be at least tions. Aria [2] is a robotic architecture that provides support twice the fastest input signal [7]. In the above system, the for behavioral decompositions. Aria programs are composed fastest input signal B occurs a minimum of 50 ms (20 Hz). of individual behaviors that are each given a priority that is So the system needs to have a minimum sampling rate of applied to the importance of actuator output. Priority does 40 Hz. This problem is easy to ﬁx by making sure that the not aﬀect resource assignment or utilization. Because the system can get an input at a rate of 40 Hz, which can be target hardware architecture only processes commands every done by software or upgrading to hardware that can sample 100 ms, all behaviors are run every 100 ms. Other threads a signal at 40 Hz. This example directly relates to mobile can be added by the developer outside of the framework for robotics. Simply consider any digital sensor, such as a laser processing tasks that have diﬀerent frequency requirements. range ﬁnder, as the source for the input signal. In the case Carmen [23] is an open source modular architecture for of a Hokuyo PBS-03 laser range ﬁnder, which produces laser mobile robot control. It features a three-tier architecture, readings every 180 ms [24], if the system (i.e., controller) where the ﬁrst layer is the hardware interface, the second does not run at least every 90 ms, then laser readings will be layer contains the basic robot tasks, and the ﬁnal layer is the missed. If a reading is missed, it is possible for the system not user-deﬁned application. It uses interprocess communica- to see an object which could produce an incorrect map or, the tion to provide functionality for mobile robots and supports worst case, cause the robot to collide with the missed object. various platforms. According to [7], in order to improve the performance of a The OROCOS project [20]isanopensourcemodular control system, the advanced rules from control theory framework for general-purpose robot and machine control. should be applied. Similarly, a robot controller using only The OROCOS project supports four C++ libraries: the Real- the basic design principles will still work. However, if more Time Toolkit, the Kinematics and Dynamics Library, the advanced control techniques are applied, performance will Bayesian Filtering Library, and the OROCOS Component improve. Library. Although not a behavior-based architecture, Player [4]is an open source robot architecture designed to operate with 4. Java Real-Time System a wide range of hardware components. The Player architec- ture speciﬁcally avoids deﬁning decompositions and there- In order for Java to be considered a programming language fore does not provide a framework for adding frequency for for real-time systems, several criteria are required [11]. First behaviors. of all, it must provide determinism. When programming 4 Journal of Robotics a robot controller in Java, it is essential that the robot using the malloc and free functions. Therefore, the lifetime behaves in a predictable manner and that all tasks meet their of the program is determined by the logic of the program. deadlines. Low latency is another important criteria. Latency However, in Java the developer does not have control over is the diﬀerence between when an event happened and when releasing the memory. This is all done by the garbage it is seen to have happened. In essence, there should be a collector. bounded and known maximum delay between the two to ensure that a task completes before the end of the period in 4.3. Garbage Collector. There is no guarantee within the JVM which it is executed. Also, the timing of the overall system is a that garbage collection will not interfere with the timing of huge factor. Robot behaviors should be executed in a certain code since the garbage collector preempts the execution of timeframeand runonlyasfastasneeded. all threads while it is running. A real-time machine must We extended the Java client to include features available ﬁnd ways to deal with this issue. Java RTS uses an RTGC forJavaRTS.Itprovidesdeveloperswithaplatform where that is based on Henriksson’s garbage collector [26] that they can accurately determine the temporal behavior of their deals with hard real-time scheduling. The garbage collector software in a real-time fashion. This allows programmers runs as an RTT. These threads run at a priority that is to determine how often tasks will execute in their code, lower than all the other RTTs; therefore, their execution is therefore making it possible to schedule tasks so they can be deferred until the critical tasks ﬁnish. This works well as long completed before they miss their deadline. In order to use the as the critical threads do not run out of memory during features of Java RTS, the javax.realtime.RealTimeThread class the threads’ execution. If so, the RTGC will be forced to is used which extends java.lang.thread.JavaRTS enhances run when the program’s memory usage reaches a certain the Java speciﬁcation by adding additional features, which level. This is implemented by increasing the RTGC’s priority include real-time threads, scheduling, memory management, when the level is reached. The priority goes back to the and a real-time garbage collector. Java RTS includes a built-in initial setting when the usage levels go below the deﬁned scheduler, which follows a ﬁxed-priority preemptive policy. threshold. Therefore, the overhead of the RTGC is reduced and determinism of the threads is not aﬀected. 4.1. Real-Time Threads. There are no guarantees for thread scheduling and thread priorities when using the regular 5. Approach Java speciﬁcation. Java RTS provides real-time threads which oﬀer more accurate scheduling than regular Java threads. 5.1. Implementation. In [10], a real-time aware architecture The Java RTS also provides thread priority which is strictly was proposed, tested, and had promising results. The enforced. In a real-time system, if there are higher-priority architecture used Player to interface to the robot hardware tasks that need to be executed, then lower priority tasks will and Java for the control code. It was made real-time aware by be sacriﬁced. Therefore, higher-priority tasks are guaranteed creating a Monitor module that scheduled tasks and reported to execute so they are less likely to miss their deadline. missed deadlines. However, it was not an actual real-time system. In order to be real-time, it would need to be run on 4.2. Memory Management. With the traditional Java virtual an RTOS in a real-time compatible language. Player, which machine (JVM), some tasks may contend with the mem- is written in C, does not support real-time capabilities [6]. ory management costs of other tasks. However, memory Therefore, our robot architecture was rewritten entirely in management is automatic using Java RTS. The NoHeapRe- Java with the addition of Java RTS. The architecture used altimeThread (NHRT) class, a subclass of the RTT class, soft real-time constraints. Soft real-time constraints are time uses scoped and immortal memory so that memory can be constraints that will not necessarily cause the system to allocated and reclaimed in a more predictable manner. It suﬀer a critical failure if the constraints are not met. The does not use the heap memory which the garbage collector architecture applies time constraints to all tasks. The client program was interfaced to various hardware platforms such is responsible for. Immortal memory is the area in memory that is not as the URG laser and the robot via serial connections. The garbage collected. This form of memory is used to avoid drivers for the architecture translated generic commands to dynamic allocation. All the memory is statically allocated speciﬁc hardware interfaces. ahead of time, and it remains in use until the JVM terminates. The structure of the new architecture that we propose is Scoped memory is available to RTTs and NHRTs only. This shown in Figure 1. The framework is implemented as part type of memory has a deﬁned lifetime. Objects allocated of the client program. Behaviors are created by subclassing from scoped memory will stay allocated until the scope Tasks.The Tasks superclass contains functionality needed is no longer active. Through scoped memory, Java RTS for initialization and registration of data store use. Tasks provides developers with an environment that does not suﬀer provides methods for registering production or consump- interference from the garbage collector. tion of data with the DataManager. During execution, In contrast, memory management is done manually in the Tasks superclass method replicates consumed data to C and C++. C and C++ have three kinds of memory: a local store. All data is created by the RobotController static memory, automatic memory, and free store [25]. The when the Khepera and Laser interfaces are created and structure of a program, which is written by the developer, sent to all tasks. All tasks were treated as time-critical tasks determines when memory is allocated and deallocated by because they directly or indirectly controlled the robots Journal of Robotics 5 Robot RobotController Koala Laser Koala Laser 1..n interface interface Tasks DataLaserUpdate DataPosUpdate WaypointPlanner { position} LaserAvoidObstacles PositionData { laser} LaserData OccupancyGridMap MapData { position, laser} DijkstraPlanner PathData { map, position} Data update Multiple outputs Associations Communication Figure 1: Framework for the robot architecture. actuators. The scheduling is done through the Java RTS of the motors when LaserAvoidObstacles does not want control. scheduler using RTTs. All of the tasks run in separate RTTs. Physical experiments employed a K-team Koala robot Timed tasks are executed according to their speciﬁed period. (Figure 3). The robot was equipped with an Acces I/O ETX- The RobotController initializes and starts the threads. Nano computer which has an Intel Core Duo 1.66 GHz Once the RTTs signal that a task has run too long, each processor, 2 GB of RAM, and an 8 GB compact ﬂash card for task’s ranTooLong() method reports deadline misses. A class storage. It is running Sun Solaris 10 RTOS, which requires diagram depicting the central components of the architecture a dual-core processor [29]. Instead of using the onboard IR is shown in Figure 2. proximity sensors, the Koala is augmented with a Hokuyo URG laser range ﬁnder. The Java program handles the inter- 5.2. Experimental Setup. Experiments were performed to face to the robot and its devices via serial connection through measure the usefulness in applying diﬀerent frequency javax.comm (the Java Communication API). All Java code, requirements to behaviors. These frequencies were supplied including the logic and control code, is executed onboard the by the user via the command line. A waypoint navigation robot. Because of the high power requirements of the Acces controller was used to measure the eﬀects of frequency on I/O ETX-Nano, the robot was tethered with a power cord task performance. and an ethernet cat5 cable for remote communication. The The program structure has seven key components, a testing environment was a 9.6 m × 6.2 m room (Figure 4). DataManager and six task threads. The six task threads are Three diﬀerent experiments were conducted: those using summarized in Table 1. Other important modules include RTTs with the RTGC, RTTs with the non-RTGC, and regular the Khepera class. It takes movement requests from Laser- threads with the non-RTGC. In these experiments, all trials AvoidObstacles and WaypointPlanner and determines were given the same four waypoints to reach (shown in what commands are ultimately sent to the robot. Motor Figure 4). From the start position, the robot would travel control is ordered so that safety-related activities, such as to each waypoint until it arrived at the ﬁnish position. The waypoints were chosen such that all tasks needed to be obstacle avoid and stall recovery, get the opportunity to control the motors ﬁrst. If both LaserAvoidObstacles employed to reach the ending position. and WaypointPlanner request control of the motors, Each task was given an interval value that deﬁned both the task’s deadline and period. For comparison, the robot was LaserAvoidObstacles commands are executed since it is a safety-related task. WaypointPlanner only gets control run with diﬀerent interval values for the task threads. Each 6 Journal of Robotics Table 1: Task threads used in the robot architecture. Tasks Description Provides Requires Sends movement commands to the robot and receives updated DataPosUpdate PositionData position information. DataLaserUpdate Gets the laser readings from the URG laser. LaserData PositionData, A high-level behavior that moves the robot through a series of WaypointPlanner LaserData, predeﬁned waypoints using a path created by the DijkstraPlanner. PathData Responds to obstacles sensed by the laser, via DataLaserUpdate,by LaserAvoidObstacles slowing down the robot and turning away from the obstacle, via LaserData DataPosUpdate. Uses the position and laser data reported by MapData LaserData DataPosUpdate and DataLaserUpdate and maintains an OccupancyGridMap [27] occupancy grid map. The map tracks unknown, open, and occupied PositionData space. Takes goal position requests and maintains a path from the current position to the closest goal. Multiple goals may be added and the DijkstraPlanner [28] PathData MapData requester must remove the goal when it is no longer valid (has been reached). RobotController LaserAvoidObstacles Task DataLaserUpdate URG Laser SCTP11 + LaserAvoidObstaclesTask() + AddInterface() + SCIP11() + DataLaserUpdateTask() +URG Laser() + LaserAvoidObstaclesTask() + Task() + doDistanceCommand() + execute() + getLaserData() + execute() + executeSuperTask() +ranTooLong() +ranTooLong() + execute() DijkstraPlanner OccupancyGridMap WaypoinPlanner DataPosUpdate Khepera KheperaSerial + DijkstraPlannerTask() + execute() + Khepera() + KheperaSerial() + OccupancyGridMapTask() + FringSearchTask() + DataPosUpdateTask() +ranTooLong() + Setup() + sendMessage() + execute() + execute() + execute() + Shutdown() + waitForReplay() +ranTooLong() +ranTooLong() +ranTooLong() + SetSpeed() + getReplay() + ResetOdometry() + getIntReplay() + EnableMotors() + DisableMotors() DataManager + noActionNeeded() + DataManager() + ActionNeeded() + registerTaskInterface() + getPosition() Figure 2: Class diagram of the essential parts of the interface. set of experiments had a total of ﬁve runs. The initial period chose to lower this period because of safety issues of both the values were based on the frequency of the URG laser, which robot and environment. The period of DataPosUpdate and is 100 ms [30]. The period for each set thereafter was chosen DataLaserUpdate was set at 75 ms and 100 ms, respectively. based on observation. In three of the ﬁve experiment sets, all It was hypothesized that these experiments would help tasks were given the same period. In the remaining two sets, demonstrate the eﬀect of task frequency and determinism on the period of the LaserAvoidObstacles was varied to see the overall system. Trials were considered complete if they its eﬀect on the overall performance of the experiment. We circled the obstacles approaching and passing each waypoint. Journal of Robotics 7 Table 2: Behavior periods for each experiment set. Behavior periods (ms) Waypoint LaserAvoid Occupancy Dijkstra Set Planner Obstacles GridMap Planner (W) (L) (Oc) (P) 110 10 10 10 2 100 10 100 100 350 50 50 50 4 100 50 100 100 5 100 100 100 100 Figure 3: K-team Koala Robot equipped with an ETX-Nano computer for control and a Hokuyo URG laser ranger. Table 3: Experimental results showing the average number of times the garbage collector executed along with the standard deviation. RTT/RTGC RTT/RegGC RegT/RegGC Set Avg SD Avg SD Avg SD X X 3 2 1 24.6 0.548 1721 24.515 2770 50.710 2 5 0 514.4 9.940 531 12.247 3 6 0 617.8 12.697 536.4 14.082 4 4.2 0.447 430.2 11.256 368.8 13.971 5 4 0 422.6 8.295 376 40.050 X X 4 1 Start/ﬁnish Figures 5 and 6 show the average time that it took the robot to ﬁnish the course. Figures 7 and 8 show the av- Figure 4: The experiment room (9.6 m × 6.2 m) with four erage distance that the robot came to the expected ﬁnish waypoints was equipped with ground truth positioning sensors. position. Figures 9 and 10 give the average time it took The path was chosen such that all behavior tasks could be employed. the robot to travel from waypoint 1 to waypoint 2 (where obstacle avoidance occurred). Figure 11 shows the percent- age of missed deadlines for the four behavior tasks for each experiment set. Figure 11(a) shows an overview of all ﬁve If the robot either got stuck on an obstacle or did not reach sets. Since the ﬁrst set of experiments had such a large all waypoints within six minutes, the trial was considered percentage of missed deadlines as compared to the others, incomplete. Missed deadlines and completeness for each trial that set was removed in Figure 11(b) to show more details of was recorded. the other four sets. 6. Experimental Results 7. Analysis Each of the three trials were run using the diﬀerent behavior 7.1. Real-Time Threads versus Non-Real-Time Threads. The periods (shown in Table 2) to determine the eﬀect of timing results show that experiments using RTTs perform similarly and determinism on the program’s performance. Good or better than experiments that use the regular threads when performance was based on the following categories: run time, measuring time to complete the course (Figures 5 and 6). task completion, and distance to the ending position. These experiments completed the course faster than those Table 3 shows the average number of times the garbage using the regular threads in most cases. collector ran and the standard deviation for each set using RTTs with the RTGC (RTT/RTGC), RTTs with the non- RTGC (RTT/RegGC), and regular threads with the non- 7.2. Comparison of Garbage Collector. We measured the eﬀect RTGC (RegT/RegGC). that the garbage collector had on the performance in order to The experiments were broken into two groups for anal- analyze determinism. The garbage collector ran less often in ysis. Group 1 contains the results from the experiments with the RTT/RTGC experiments (see Table 3). When comparing all behaviors running at the same period. Group 2 contains the trials using only the RTTs, the experiments that utilized the results from the experiments where LaserAvoidObsta- the RTGC completed the course faster than those using the cles was adjusted as well as the set with all tasks running at a regular garbage collector (see Figures 5 and 6). Since the rate of 100 ms. Running LaserAvoidObstacles at a shorter RTGC is deterministic and does not aﬀect the behavior tasks period is suﬃcient since it handles the time consuming safety as they execute, we believe that it may have an eﬀect on the function of moving around the obstacle. average course time. 8 Journal of Robotics Average time to ﬁnish Average distance from ending position 2.5 1.5 W10, L10, W50, L50, W100, L100, W10, W10, L10, L10, W50, W50, L50, L50, W100, W100, L L100, 100, Oc10, P10 Oc100, P100 Oc10, Oc10, P10 P10 Oc100, Oc100, P100 P100 Oc50, P50 Oc50, Oc50, P50 P50 Experiment Set Exper Experiment iment Set Set RTT/RTGC R RT TT/R T/RT TG GC C RTT/RegGC RT RTT T/ /RegGC RegT/RegGC RegT/RegGC Figure 5: The average time it took the robot to complete the course Figure 7: The average distance the robot came to the ending for group 1. position for group 1. Average distance from ending position Average time to ﬁnish 2.5 1.5 W100, W100, L10 L10, , W100, W100, L L50 0, , W100, W100, L100, L100, W100, W100, L10 L10, , W100, W100, L L50 0, , W100, W100, L100, L100, Oc100, Oc100, P100 P100 Oc100, Oc100, P P100 100 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 Oc100, Oc100, P P100 100 Exper Experiment iment Set Set Exper Experiment iment Set Set R RT TT/R T/RT TG GC C RT RTT T/ /RT RTG GC C RT RTT T/ /RegGC RT RTT T/ /RegGC RegT/RegGC RegT/RegGC Figure 8: The average distance the robot came to the ending Figure 6: The average time it took the robot to complete the course position for group 2. for group 2. Also, to measure the eﬀect that an individual task has on performance, we observed how obstacle avoidance aﬀected 7.3. Eﬀect of Behavior Frequency. There were statistical diﬀer- the time it took the robot to travel from waypoint 1 to ences with the behavior periods when comparing the average waypoint 2 (see Figures 9 and 10). In all but one case the distance when the robot came to the ending position for the RTT/RTGC experiments reached waypoint 2 faster than the RTT/RTGC experiments. For instance, in group 1 (Figure 7), RTT/RegGC experiments. running the behaviors at a frequency of 10 ms is statistically diﬀerent from running at 50 ms. Also, running at a frequency of 100 ms is statistically diﬀerent from running at 50 ms. 7.4. Eﬀect of Latency. One indicator of latency is missed In group 2 (Figure 8), running LaserAvoidObstacles at deadlines. The system reports when tasks do not complete a period of 50 ms and all other behaviors at 100 ms is within their speciﬁed period; however, the tasks are not killed statistically diﬀerent from running at a period of 100 ms. when using the RTTs. Therefore, tasks that take too long These results show that even changes to the frequency of to complete may cause other tasks not to have enough re- a single behavior can aﬀect performance. This also shows sources. that, if tasks are permitted to run too fast or too slow, it We hypothesized that latency would not be an issue can adversely aﬀect overall performance in form of task with the lower frequencies because they provide more time completion and accuracy. foreachbehaviortocomplete. From Figure 11(a),itis Time (sec) Time (sec) Distance (m) Distance (m) Journal of Robotics 9 Averagetime to getfromwaypoint1to2 Total missed deadlines 0.9 0.8 0.7 0.6 0.5 0.4 70 0.3 0.2 W10, W10, L10, L10, W50, W50, L50, L50, W100, W100, L100, L100, 0.1 Oc10, Oc10, P10 P10 Oc100, Oc100, P P100 100 Oc50, Oc50, P50 P50 Exper Experiment iment Set Set RT RTT T/ /RT RTG GC C RT RTT T/ /RegGC RegT/RegGC Exper Experi iment ment Set Set R RT TT/R T/RT TG GC C Figure 9: The average time it took the robot to travel from waypoint 1 to waypoint 2 for group 1. RT RTT T/ /RegGC RegT/RegGC Averagetime to getfromwaypoint1to2 (a) Total missed deadlines 0.018 0.016 0.014 0.012 0.01 0.008 0.006 W100, W100, L10 L10, , W100, W100, L L50 0, , W100, W100, L100, L100, 0.004 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 0.002 Exper Experiment iment Set Set R RT TT/R T/RT TG GC C RegGC RT RTT T/ / RegT/RegGC Figure 10: The average time it took the robot to travel from Exper Experiment iment Set Set waypoint 1 to waypoint 2 for group 2. R RT TT/R T/RT TG GC C RT RTT T/ /RegGC RegT/RegGC shown that the set with all behaviors running at a period of 10 ms resulted in more missed deadlines. The experiments (b) in this set utilizing RTTs had more missed deadlines than Figure 11: Percentage of missed deadlines (a) for all ﬁve experiment those using regular threads. However, this is not the case sets and (b) for the four experiment sets with a lower missed when running the behaviors at a period of 100 ms (see deadline percentage (rescaled to show more details). Figure 11(b)). In this case, the RTT/RTGC experiments had no missed deadlines. However, (with the exception of experiment set 3) the RTT/RegGC experiments have a higher percentage of missed are improved in the RTT/RTGC experiments, there is still a deadlines than the RegT/RegGC experiments. Since the diﬀerence in how each experiment set performs at diﬀerent regular garbage collector is less deterministic, it is diﬃcult frequencies. Therefore, the frequency of each behavior to determine the eﬀect that it has on the task threads. should be based on input availability. Results also show that faster cycle times are not a good 7.5. Overall Analysis. Results show that proper timing is approach. However, the prevailing approach is to run behav- important to resource utilization even in an unconstrained iors as fast as possible, which is not ideal. Slower cycle times (resource rich) system. Although latency and determinism would give behaviors more time to ﬁnish, but too slow may Time (sec) Time (sec) Missed deadlines (%) Missed deadlines (%) W10, L10, W100, L10, Oc10, P10 Oc100, P100 W100, L10, Oc100, P100 W50, L50, Oc50, P50 W50, L50, Oc50, P50 W100, L50, Oc100, P100 W100, L50, Oc100, P100 W100, L100, W100, L100, Oc100, P100 Oc100, P100 10 Journal of Robotics also cause system instability, which is consistent with control [2] K. Konolige, “Saphira robot control architecture,” Technical Report, SRI International, Menlo Park, Calif, USA, 2002. theory. The key is to ﬁnd the optimal window at which [3] D. S. Touretzky and E. J. Tira-Thompson, “Tekkotsu: a frame- tasks do not run too short (depleting system resources) or work for AIBO cognitive robotics,” in Proceedings of the Na- too long (causing slow response). Therefore, the laws of tional Conference on Artiﬁcial Intelligence, vol. 4, pp. 1741– control theory should be applied to robotics requiring all 1742, AAAI Press, MIT Press, Pittsburgh, Pa, USA, 2005. behaviors and their dependencies to be analyzed. This would [4] B. P. Gerkey, R. T. Vaughan, K. Støy, A. Howard, G. S. give developers the chance to deﬁne their own frequency Sukhatme, and M. J. Mataric, ´ “Most valuable player: a robot requirements that is appropriate for the system that they are device server for distributed control,” in Proceedings of the using. IEEE International Conference on Intelligent Robots and Systems (IROS ’01), vol. 3, pp. 1226–1231, 2001. [5] G. Beccari, S. Caselli, M. Reggiani, and F. Zanichelli, “Real- 8. Conclusion time library for the design of hybrid robot control architec- tures,” in Proceedings of the IEEE/RSJ International Conference Many robot architectures view correct frequency as a func- on Intelligent Robots and Systems, pp. 1145–1150, October tion of resource availability. By not properly addressing timing concerns, mobile robot systems may not eﬃciently [6] J. Kramer and M. Scheutz, “Development environments for utilize system resources. Furthermore, ignorance of timing autonomous mobile robots: a survey,” Autonomous Robots, vol. details can lead a developer to produce unstable systems. 22, no. 2, pp. 101–132, 2007. This is partially because our intuition is that only the [7] J. Dorsey, Continuous and Discrete Control Systems, McGraw- critical tasks of a robot control program need to run fast, Hill College, New York, NY, USA, 2001. which is incorrect. One must apply the laws of Control [8] S. Bennett, Real-Time Computer Control: An Introduction, Theory to robotics, requiring all behaviors and their input Prentice Hall International, New York, NY, USA, 1994. dependencies to be analyzed instead of just the critical [9] G. Bollella and J. Gosling, “The real-time speciﬁcation for tasks. These laws should be applied because, consistent with Java,” Computer, vol. 33, no. 6, pp. 47–54, 2000. [10] A. McKenzie, S. Dawson, Q. Alexander, and M. Anderson, control theory, periods that are too short may cause system “Using real-time awareness to manage performance of java instability. clients on mobile robots,” in Proceedings of the IEEE/RSJ We developed a robot software platform to incorporate International Conference on Intelligent Robots and Systems temporal awareness. The system, written completely in Java (IROS ’09), pp. 3422–3428, December 2009. using Java RTS, allows individual program components to be [11] A. Nilsson, T. Ekman, and K. Nilsson, “Real Java for real assigned an execution frequency. It also utilizes RTTs, non- time—gain and pain,” in Proceedings of the International Con- RTTs, the RTGC, and the traditional garbage collector. We ference on Compilers, Architecture, and Synthesis for Embedded presented the details of the system and its implementation. Systems (CASES ’02), pp. 304–311, October 2002. Experiments demonstrated how manipulating the timing of [12] D. Arora, A. Raghunathan, S. Ravi, and N. K. Jha, “Archi- subtasks and using RTTs with the RTGC aﬀect overall task tectural support for safe software execution on embedded performance as measured by time to complete the path and processors,” in Proceedings of the 4th International Conference on Hardware Software Codesign and System Synthesis, pp. 106– the error associated with the ending position. The results 111, October 2006. of testing validate the hypothesis and show how important [13] G. Bollella, T. Canham, V. Carson et al., “Programming with proper timing is to resource utilization in mobile robot non-heap memory in the real time speciﬁcation for Java,” in systems. Proceedings of the Conference on Object-Oriented Programming In future work, the architecture will be written in a more Systems, Languages, and Applications (OOPSLA ’03), pp. 361– common real-time language such as C++ using the ORO- 369, 2003. COS Real-Time Toolkit [19]. It will then be compared to [14] S. Smith, S. W. Lawson, and A. Lawson, “Can real-time soft- the Java RTS version. This will be a good measure of Java ware engineering be taught to Java programmers?” in Proceed- RTS’s performance. Human studies that evaluate program- ings of the 17th Conference on Software Engineering Education mer proﬁciency on both Java RTS and C++ may shed light and Training, vol. 17, pp. 124–129, 2004. on features of the architecture that are useful in teaching [15] G. Buttazzo, F. Conticelli, G. Lamastra, and G. Lipari, “Robot control in hard real-time environment,” in Proceedings of the embedded programming techniques. 4th International Workshop on Real-Time Computing Systems and Applications (RTCSA ’97), pp. 152–159, October 1997. Acknowledgments [16] R. Brega, N. Tomatis, and K. O. Arras, “The need for au- tonomy and real-time in mobile robotics: a case study of The authors gratefully acknowledge the following NSF XO/2 and Pygmalion,” in Proceedings of the IEEE International Grants: IIS-0846976 and CCF-0829827 for supporting this Conference on Intelligent Robots and Systems, vol. 2, pp. 1422– work. They would also like to thank Nicholas A. Kraft for his 1427, 2000. knowledge of Solaris. [17] J. Auerbach,D.F.Bacon,D.T.Iercanetal., “Javatakes ﬂight: time-portable real-time programming with exotasks,” in Proceedings of the ACM SIGPLAN Conference on Languages, References Compilers, and Tools for Embedded Systems (LCTES ’07),pp. [1] R. A. Brooks, “A robust layered control system for a mobile 51–62, June 2007. [18] D. B. Stewart, D. E. Schmitz, and P. K. Khosla, “Chimera robot,” IEEE Journal of Robotics and Automation,vol. 2, no.1, pp. 14–23, 1986. II real-time operating system for advanced sensor-based Journal of Robotics 11 control applications,” IEEE Transactions on Systems, Man and Cybernetics, vol. 22, no. 6, pp. 1282–1295, 1992. [19] H. Bruyninckx, P. Soetens, and B. Koninckx, “The real-time motion control core of the OROCOS project,” in Proceedings of the IEEE International Conference on Robotics and Automation, vol. 2, pp. 2766–2771, September 2003. [20] H. Bruyninckx, “Open robot control software: the OROCOS project,” in Proceedings of the IEEE International Conference on Robotics and Automation, vol. 3, pp. 2523–2528, May 2001. [21] S. G. Robertz, R. Henriksson, K. Nilsson, A. Blomdell, and I. Tarasov, “Using real-time Java for industrial robot control,” in Proceedings of the 5th International Workshop on Java Technologies for Real-Time and Embedded Systems (JTRES ’07), pp. 104–110, 2007. [22] R. A. Brooks, “Intelligence without representation,” Artiﬁcial Intelligence, vol. 47, no. 1–3, pp. 139–159, 1991. [23] M. Montemerlo, N. Roy, and S. Thrun, “Perspectives on standardization in mobile robot programming: the carnegie mellon navigation (CARMEN) toolkit,” in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 2436–2441, October 2003. [24] Measuring Distance Type Obstacle Detection Sensor PBS-03JN Series Instruction Manual, Hokuyo Automatic, 2002. [25] B. Stroustrup, The C++ Programming Language, Addison- Wesley, Reading, Mass, USA, 1986. [26] R. Henriksson, Scheduling garbage collection in embedded systems, Ph.D. dissertation, Lund University, 1998. [27] A. Elfes, “Using occupancy grids for mobile robot perception and navigation,” Computer, vol. 22, no. 6, pp. 46–57, 1989. [28] E. W. Dijkstra, “A note on two problems in connexion with graphs,” Numerische Mathematik, vol. 1, no. 1, pp. 269–271, [29] Sun Java Real-Time System Precision Control for the Financial Services Market, Sun Microsystems, 2008. [30] Range-Finder Type Laser Scanner URG 04LX Speciﬁcations, Hokuyo Automatic, 2005. International Journal of Rotating Machinery International Journal of Journal of The Scientific Journal of Distributed Engineering World Journal Sensors Sensor Networks Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 Volume 2014 Journal of Control Science and Engineering Advances in Civil Engineering Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 Submit your manuscripts at http://www.hindawi.com Journal of Journal of Electrical and Computer Robotics Engineering Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 VLSI Design Advances in OptoElectronics International Journal of Modelling & Aerospace International Journal of Simulation Navigation and in Engineering Engineering Observation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2010 Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com http://www.hindawi.com Volume 2014 International Journal of Active and Passive International Journal of Antennas and Advances in Chemical Engineering Propagation Electronic Components Shock and Vibration Acoustics and Vibration Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png Journal of Robotics Hindawi Publishing Corporation http://www.deepdyve.com/lp/hindawi-publishing-corporation/using-sun-s-java-real-time-system-to-manage-behavior-based-mobile-1L0SuxuudC

Loading next page...

References

References for this paper are not available at this time. We will be adding them shortly, thank you for your patience.

Publisher: Hindawi Publishing Corporation
Copyright: Copyright © 2011 Andrew McKenzie et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
ISSN: 1687-9600
eISSN: 1687-9619
DOI: 10.1155/2011/525724
Publisher site: See Article on Publisher Site

Abstract

Hindawi Publishing Corporation Journal of Robotics Volume 2011, Article ID 525724, 11 pages doi:10.1155/2011/525724 Research Article Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers 1 2 1 2 Andrew McKenzie, Shameka Dawson, Fei Hu, and Monica Anderson Department of Electrical and Computer Engineering, The University of Alabama, Tuscaloosa, AL 35487, USA Department of Computer Science, The University of Alabama, Tuscaloosa, AL 35487, USA Correspondence should be addressed to Andrew McKenzie, awmckenzie@crimson.ua.edu Received 7 May 2011; Revised 16 September 2011; Accepted 16 November 2011 Academic Editor: Yuan Zheng Copyright © 2011 Andrew McKenzie et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Implementing a robot controller that can eﬀectively manage limited resources in a deterministic, real-time manner is challenging. Behavior-based architectures that decompose autonomy into levels of intelligence are popular due to their robustness but do not provide real-time features that enforce timing constraints or support determinism. We propose an architecture and approach for using the real-time features of the Real-Time Speciﬁcation for Java (RTSJ) in a behavior-based mobile robot controller to show that timing constraints aﬀect performance. This is accomplished by extending a real-time aware architecture that explicitly enumerates timing requirements for each behavior. It is not enough to reduce latency. The usefulness of this approach is demonstrated via an implementation on Solaris 10 and the Sun Java Real-Time System (Java RTS). Experimental results are obtained using a K-team Koala robot performing path following with four composite behaviors. Experiments were conducted using several task period sets in three cases: real-time threads with the real-time garbage collector, real-time threads with the non- real-time garbage collector, and non-real-time threads with the non-real-time garbage collector. Results show that even if latency and determinism are improved, the timing of each individual behavior signiﬁcantly aﬀects task performance. 1. Motivation Currently, real-time features and speciﬁc frequency requirements are not included in mobile robot architectures Developing a mobile robot controller can be a complex [6]. Timing constraints, determinism, and low latency are process. Robots must simultaneously perform safety checks important factors to ensure proper operation of the robot (such as obstacle avoidance) while accomplishing high- and can result in better resource utilization. By not having level goals (mapping and path following). Behavior-based an actual real-time controller that explicitly addresses these controllers [1] use prioritized ﬁnite state machines to man- issues, developers may get erratic results causing inconsistent age layers of complexity. Existing robot architectures either and ineﬃcient robot behavior. enable this approach [2, 3] or are purposefully unstructured If the laws of control theory [7]weretobeapplied to to accommodate behaviors [4]. a behavior-based system, the frequency of each individual Although behavior-based paradigms provide robust con- robot behavior would be based on input availability. The def- trollers in the face of complex conditions, real-time issues inition of individual frequency requirements for subsystems are not addressed as part of these architectures. Tasks may within a control system is part of the process for traditional need to be executed and completed within a time constraint real-time system development [8]. Frequencies deﬁne the to prevent undesired results. Since timing and determinism period and the deadline for processing sensor input. If a task matters [5], should robot controllers be programmed using misses its deadline, the system is not responsive to changes real-time control system standards, allowing tasks to execute in input. However, it is not enough to run all behaviors “as in actual real time? fast as possible.” In fact, some resource intensive behaviors 2 Journal of Robotics may take resources and/or preempt more time-sensitive OSaC ˆ s and languages. In Section 2, background and previ- behaviors. Slowing down behaviors that do not receive input ous work is presented. Control theory and its relevance to frequently may free resources for more time-sensitive tasks. our approach is presented in Section 3. Section 4 describes In order to address this timing constraint issue, we ex- Java RTS and its relevance to the interface. Section 5 presents amine adding the Real-Time Speciﬁcation for Java (RTSJ) [9] the implementation of the architecture and the experimental standard to an existing mobile robot architecture [10], using setup. The experimental results and the analysis are pre- Sun’s Java Real-Time System (Java RTS), and running it on a sented in Sections 6 and 7, respectively. Conclusion and real-time operating system (RTOS). Java, a language known future directions are in Section 8. for its portability and safe object-oriented features, has become an option for developers of real-time systems [11]. 2. Background While languages such as C and C++ pose an issue for many real-time developers because of the memory issues associated 2.1. Real-Time in Mobile Robotics. Several robot develop- with them, they are the most common choice because of their ment platforms are available for mobile robots. However, performance and ease of use [12]. As an alternative, Java RTS some of these architectures do not provide real-time fea- is designed to be a system that has deterministic, real-time tures that enforce timing constraints. Of the ones that do features [13] without forcing developers to manage memory provide real-time features, they do not allow developers to usage. This makes Java an appropriate choice for program- provide their own frequency requirements. Buttazzo et al. ming a real-time robot architecture. However, Java is timing [15] conducted research in real-time control of robots where sensitive. Particularly the traditional garbage collector may they designed and implemented a software architecture used cause nondeterministic behavior in a real-time system. The for designing robotic applications with real-time constraints. real-time garbage collector (RTGC) implemented in Java The architecture was a hierarchical programming environ- RTS provides a deterministic approach to dealing with the ment consisting of four parts: an action layer, control layer, garbage collector. communication layer, and a hard real-time kernel (HARTIK) The robot architecture that we propose has several fun- to control the three layers. All of the layers were written in C and encapsulated with a set of library functions. damental purposes. First, real-time issues pertaining to robot They concluded that their architecture provided a ﬂexible controllerswillbemadeexplicit. Secondly, an eﬀective way framework for the development of robotic applications. to use real-time Java within a behavior-based mobile robotics However, they did not provide any experimental results. framework will be demonstrated. By also allowing developers Brega et al. [16] conducted a case study of the XO/2 to declare frequency requirements, tasks can be run only operating system controlling a Pygmalion Robot in real time as fast as needed. Allowing frequencies to be declared can using the Oberon-2 programming language. They discussed ultimately provide the developer with a better understanding the needs and requirements for real-time control of robots in of the frequencies and their relationship to code features. research, education, and real-world use. The XO/2 operating This includes which tasks depend on speciﬁc input devices system was designed by Brega et al. as a real-time operating as well as the dependencies between diﬀerent tasks. system. They concluded that they could not quantify the It is possible that such an architecture will help move need for self-contained autonomy, real-time, and safety embedded systems students up the learning curve faster. In in mobile robots. They also noted that the increasing [14], a real-time systems undergraduate laboratory that was complexity of mobile robots set higher requirements for the created for Java programmers is described. It was found that robots’ hardware, software, and indirectly the operating students taking the real-time software engineering module system. Finally, they noted that “safe composition of soft- performed better and enjoyed it more than other modules. ware modules, type-safety, deadline-driven scheduling and Also, the majority of the students who took this module automatic memory reclamation mechanisms can relieve the found work in the real-time and embedded systems industry. application programmer from many time-consuming im- The results of this work widely impact both current and plementation issues, while raising the safety-bar.” future behavior-based robot development environments. Auerbach et al. [17] implemented a real-time Java ap- Robot architectures need to manage real-time constraints in plication that used Exotasks, a novel Java programming order to eﬀectively behave in a deterministic manner. Exper- construct that achieved deterministic timing, on a real-time imental results show that timing of individual behaviors do virtual machine. They built a helicopter, the JAviator, for aﬀect the robot’s high-level task performance. testing. They showed that their implementation achieved In this paper, we map a behavior-based robot architecture time portability on diﬀerent hardware platforms. However, to Java RTS in order to show that the absence of or incorrect all of their data was processed oﬀ-board and they only timing constraints aﬀect performance. The architecture al- observed one behavior (hovering of the helicopter). lows developers to declare frequency requirements as part of the client interface. Java RTS features are also added to help better manage resources. The main contribution of 2.2. Real-Time in Non-Mobile Robotics. Stewart et al. [18] this paper is to create an oﬀ-the-shelf system that allows real- designed a real-time architecture that is based on port- time control of autonomous robots. To our knowledge our based objects. Port-based objects are fully contained software architecture was the ﬁrst one made for fully autonomous components that contain both state and methods as well mobile robots doing complete tasks, using oﬀ-the-shelf as provide input, output, and resource ports. Input ports Journal of Robotics 3 describe data needed by an object, and output ports describe 3. Control Systems data produced by an object. An input port can only be Control systems are devices or systems that control another connected to exactly one output port. Outputs of the same device or system. Closed loop control systems use the systems type must be merged into one unambiguous output. Each output (feedback) to modify the input to get the desired object is self-contained and has its own frequency. Task output. Today most control systems use computers to make scheduling is determined by the developer and can be all of the controller decisions, called digital control. Since modiﬁed to either increase system stability or reduce com- digital control uses computers, which make decisions every putational resource consumption. clock cycle, the signal is discrete. Bruyninckx et al. [19] implemented a 1 kHz position, On the basic level, autonomous robots use computer-run velocity, and hybrid force control of a KUKA 361 six-DOF algorithms to control its movement, based on input from robot using the hard real-time motion control core of the sensors such as sonar, infrared, GPS, and laser range ﬁnders. OROCOS project (Open Robot Control Software) [20]. They Therefore, an autonomous robot qualiﬁes as a control system bypassed the KUKA legacy controller and controlled it using because it is a device (a computer) that controls other devices only the OROCOS code. The code runs on Linux (without such as motors. So autonomous robots should be treated as real-time performance) and on RTAI (RealTime Application control systems and be required to follow the same rules that Interface for Linux) in hard real time. digital control systems follow. Robertz et al. [21] implemented a motion control system Since digital control is a digital (discrete) time system, for an industrial robot using Java RTS on an RTOS. They problems can occur if input data is not being sampled fast used real-time threads (RTTs) for critical tasks and non-RTTs enough. This happens if the input signal changes between for noncritical tasks. In their approach, the RTTs were run at samplings. For example, if an input has two values A and B, the highest priority and the non-RTTs were run at a lower when value A occurs, the signal will be transmitting data for priority, even lower than the real-time garbage collector. a minimum of 80 ms, and B for 50 ms. The input is sampled Although they discuss time measurements of network delays, at 10 Hz (once every 100 ms). The system samples the input they do not present results showing the eﬀect of these real- signal at times 100 ms, 200 ms, 300 ms, and so on. The input time features on the overall system. signal for A is active from time 0 to 130 ms, changes to B at time 130 ms, then changes back to A at 180 ms. Since the 2.3. Behavior-Based Architectures. Subsumption-based ro- sampling rate occurs every 100 ms, the digital control system botic controllers build autonomy out of layers of behaviors sees A at time step 1 and 2. So it does not see B, which could [22]. Basic layers are complete processing units that take cause problems. The simple ﬁx is to make sure that your input and provide appropriate output. We are particularly sampling time is fast enough. interested in properties that enable temporal decomposi- In control theory, the sampling rate should be at least tions. Aria [2] is a robotic architecture that provides support twice the fastest input signal [7]. In the above system, the for behavioral decompositions. Aria programs are composed fastest input signal B occurs a minimum of 50 ms (20 Hz). of individual behaviors that are each given a priority that is So the system needs to have a minimum sampling rate of applied to the importance of actuator output. Priority does 40 Hz. This problem is easy to ﬁx by making sure that the not aﬀect resource assignment or utilization. Because the system can get an input at a rate of 40 Hz, which can be target hardware architecture only processes commands every done by software or upgrading to hardware that can sample 100 ms, all behaviors are run every 100 ms. Other threads a signal at 40 Hz. This example directly relates to mobile can be added by the developer outside of the framework for robotics. Simply consider any digital sensor, such as a laser processing tasks that have diﬀerent frequency requirements. range ﬁnder, as the source for the input signal. In the case Carmen [23] is an open source modular architecture for of a Hokuyo PBS-03 laser range ﬁnder, which produces laser mobile robot control. It features a three-tier architecture, readings every 180 ms [24], if the system (i.e., controller) where the ﬁrst layer is the hardware interface, the second does not run at least every 90 ms, then laser readings will be layer contains the basic robot tasks, and the ﬁnal layer is the missed. If a reading is missed, it is possible for the system not user-deﬁned application. It uses interprocess communica- to see an object which could produce an incorrect map or, the tion to provide functionality for mobile robots and supports worst case, cause the robot to collide with the missed object. various platforms. According to [7], in order to improve the performance of a The OROCOS project [20]isanopensourcemodular control system, the advanced rules from control theory framework for general-purpose robot and machine control. should be applied. Similarly, a robot controller using only The OROCOS project supports four C++ libraries: the Real- the basic design principles will still work. However, if more Time Toolkit, the Kinematics and Dynamics Library, the advanced control techniques are applied, performance will Bayesian Filtering Library, and the OROCOS Component improve. Library. Although not a behavior-based architecture, Player [4]is an open source robot architecture designed to operate with 4. Java Real-Time System a wide range of hardware components. The Player architec- ture speciﬁcally avoids deﬁning decompositions and there- In order for Java to be considered a programming language fore does not provide a framework for adding frequency for for real-time systems, several criteria are required [11]. First behaviors. of all, it must provide determinism. When programming 4 Journal of Robotics a robot controller in Java, it is essential that the robot using the malloc and free functions. Therefore, the lifetime behaves in a predictable manner and that all tasks meet their of the program is determined by the logic of the program. deadlines. Low latency is another important criteria. Latency However, in Java the developer does not have control over is the diﬀerence between when an event happened and when releasing the memory. This is all done by the garbage it is seen to have happened. In essence, there should be a collector. bounded and known maximum delay between the two to ensure that a task completes before the end of the period in 4.3. Garbage Collector. There is no guarantee within the JVM which it is executed. Also, the timing of the overall system is a that garbage collection will not interfere with the timing of huge factor. Robot behaviors should be executed in a certain code since the garbage collector preempts the execution of timeframeand runonlyasfastasneeded. all threads while it is running. A real-time machine must We extended the Java client to include features available ﬁnd ways to deal with this issue. Java RTS uses an RTGC forJavaRTS.Itprovidesdeveloperswithaplatform where that is based on Henriksson’s garbage collector [26] that they can accurately determine the temporal behavior of their deals with hard real-time scheduling. The garbage collector software in a real-time fashion. This allows programmers runs as an RTT. These threads run at a priority that is to determine how often tasks will execute in their code, lower than all the other RTTs; therefore, their execution is therefore making it possible to schedule tasks so they can be deferred until the critical tasks ﬁnish. This works well as long completed before they miss their deadline. In order to use the as the critical threads do not run out of memory during features of Java RTS, the javax.realtime.RealTimeThread class the threads’ execution. If so, the RTGC will be forced to is used which extends java.lang.thread.JavaRTS enhances run when the program’s memory usage reaches a certain the Java speciﬁcation by adding additional features, which level. This is implemented by increasing the RTGC’s priority include real-time threads, scheduling, memory management, when the level is reached. The priority goes back to the and a real-time garbage collector. Java RTS includes a built-in initial setting when the usage levels go below the deﬁned scheduler, which follows a ﬁxed-priority preemptive policy. threshold. Therefore, the overhead of the RTGC is reduced and determinism of the threads is not aﬀected. 4.1. Real-Time Threads. There are no guarantees for thread scheduling and thread priorities when using the regular 5. Approach Java speciﬁcation. Java RTS provides real-time threads which oﬀer more accurate scheduling than regular Java threads. 5.1. Implementation. In [10], a real-time aware architecture The Java RTS also provides thread priority which is strictly was proposed, tested, and had promising results. The enforced. In a real-time system, if there are higher-priority architecture used Player to interface to the robot hardware tasks that need to be executed, then lower priority tasks will and Java for the control code. It was made real-time aware by be sacriﬁced. Therefore, higher-priority tasks are guaranteed creating a Monitor module that scheduled tasks and reported to execute so they are less likely to miss their deadline. missed deadlines. However, it was not an actual real-time system. In order to be real-time, it would need to be run on 4.2. Memory Management. With the traditional Java virtual an RTOS in a real-time compatible language. Player, which machine (JVM), some tasks may contend with the mem- is written in C, does not support real-time capabilities [6]. ory management costs of other tasks. However, memory Therefore, our robot architecture was rewritten entirely in management is automatic using Java RTS. The NoHeapRe- Java with the addition of Java RTS. The architecture used altimeThread (NHRT) class, a subclass of the RTT class, soft real-time constraints. Soft real-time constraints are time uses scoped and immortal memory so that memory can be constraints that will not necessarily cause the system to allocated and reclaimed in a more predictable manner. It suﬀer a critical failure if the constraints are not met. The does not use the heap memory which the garbage collector architecture applies time constraints to all tasks. The client program was interfaced to various hardware platforms such is responsible for. Immortal memory is the area in memory that is not as the URG laser and the robot via serial connections. The garbage collected. This form of memory is used to avoid drivers for the architecture translated generic commands to dynamic allocation. All the memory is statically allocated speciﬁc hardware interfaces. ahead of time, and it remains in use until the JVM terminates. The structure of the new architecture that we propose is Scoped memory is available to RTTs and NHRTs only. This shown in Figure 1. The framework is implemented as part type of memory has a deﬁned lifetime. Objects allocated of the client program. Behaviors are created by subclassing from scoped memory will stay allocated until the scope Tasks.The Tasks superclass contains functionality needed is no longer active. Through scoped memory, Java RTS for initialization and registration of data store use. Tasks provides developers with an environment that does not suﬀer provides methods for registering production or consump- interference from the garbage collector. tion of data with the DataManager. During execution, In contrast, memory management is done manually in the Tasks superclass method replicates consumed data to C and C++. C and C++ have three kinds of memory: a local store. All data is created by the RobotController static memory, automatic memory, and free store [25]. The when the Khepera and Laser interfaces are created and structure of a program, which is written by the developer, sent to all tasks. All tasks were treated as time-critical tasks determines when memory is allocated and deallocated by because they directly or indirectly controlled the robots Journal of Robotics 5 Robot RobotController Koala Laser Koala Laser 1..n interface interface Tasks DataLaserUpdate DataPosUpdate WaypointPlanner { position} LaserAvoidObstacles PositionData { laser} LaserData OccupancyGridMap MapData { position, laser} DijkstraPlanner PathData { map, position} Data update Multiple outputs Associations Communication Figure 1: Framework for the robot architecture. actuators. The scheduling is done through the Java RTS of the motors when LaserAvoidObstacles does not want control. scheduler using RTTs. All of the tasks run in separate RTTs. Physical experiments employed a K-team Koala robot Timed tasks are executed according to their speciﬁed period. (Figure 3). The robot was equipped with an Acces I/O ETX- The RobotController initializes and starts the threads. Nano computer which has an Intel Core Duo 1.66 GHz Once the RTTs signal that a task has run too long, each processor, 2 GB of RAM, and an 8 GB compact ﬂash card for task’s ranTooLong() method reports deadline misses. A class storage. It is running Sun Solaris 10 RTOS, which requires diagram depicting the central components of the architecture a dual-core processor [29]. Instead of using the onboard IR is shown in Figure 2. proximity sensors, the Koala is augmented with a Hokuyo URG laser range ﬁnder. The Java program handles the inter- 5.2. Experimental Setup. Experiments were performed to face to the robot and its devices via serial connection through measure the usefulness in applying diﬀerent frequency javax.comm (the Java Communication API). All Java code, requirements to behaviors. These frequencies were supplied including the logic and control code, is executed onboard the by the user via the command line. A waypoint navigation robot. Because of the high power requirements of the Acces controller was used to measure the eﬀects of frequency on I/O ETX-Nano, the robot was tethered with a power cord task performance. and an ethernet cat5 cable for remote communication. The The program structure has seven key components, a testing environment was a 9.6 m × 6.2 m room (Figure 4). DataManager and six task threads. The six task threads are Three diﬀerent experiments were conducted: those using summarized in Table 1. Other important modules include RTTs with the RTGC, RTTs with the non-RTGC, and regular the Khepera class. It takes movement requests from Laser- threads with the non-RTGC. In these experiments, all trials AvoidObstacles and WaypointPlanner and determines were given the same four waypoints to reach (shown in what commands are ultimately sent to the robot. Motor Figure 4). From the start position, the robot would travel control is ordered so that safety-related activities, such as to each waypoint until it arrived at the ﬁnish position. The waypoints were chosen such that all tasks needed to be obstacle avoid and stall recovery, get the opportunity to control the motors ﬁrst. If both LaserAvoidObstacles employed to reach the ending position. and WaypointPlanner request control of the motors, Each task was given an interval value that deﬁned both the task’s deadline and period. For comparison, the robot was LaserAvoidObstacles commands are executed since it is a safety-related task. WaypointPlanner only gets control run with diﬀerent interval values for the task threads. Each 6 Journal of Robotics Table 1: Task threads used in the robot architecture. Tasks Description Provides Requires Sends movement commands to the robot and receives updated DataPosUpdate PositionData position information. DataLaserUpdate Gets the laser readings from the URG laser. LaserData PositionData, A high-level behavior that moves the robot through a series of WaypointPlanner LaserData, predeﬁned waypoints using a path created by the DijkstraPlanner. PathData Responds to obstacles sensed by the laser, via DataLaserUpdate,by LaserAvoidObstacles slowing down the robot and turning away from the obstacle, via LaserData DataPosUpdate. Uses the position and laser data reported by MapData LaserData DataPosUpdate and DataLaserUpdate and maintains an OccupancyGridMap [27] occupancy grid map. The map tracks unknown, open, and occupied PositionData space. Takes goal position requests and maintains a path from the current position to the closest goal. Multiple goals may be added and the DijkstraPlanner [28] PathData MapData requester must remove the goal when it is no longer valid (has been reached). RobotController LaserAvoidObstacles Task DataLaserUpdate URG Laser SCTP11 + LaserAvoidObstaclesTask() + AddInterface() + SCIP11() + DataLaserUpdateTask() +URG Laser() + LaserAvoidObstaclesTask() + Task() + doDistanceCommand() + execute() + getLaserData() + execute() + executeSuperTask() +ranTooLong() +ranTooLong() + execute() DijkstraPlanner OccupancyGridMap WaypoinPlanner DataPosUpdate Khepera KheperaSerial + DijkstraPlannerTask() + execute() + Khepera() + KheperaSerial() + OccupancyGridMapTask() + FringSearchTask() + DataPosUpdateTask() +ranTooLong() + Setup() + sendMessage() + execute() + execute() + execute() + Shutdown() + waitForReplay() +ranTooLong() +ranTooLong() +ranTooLong() + SetSpeed() + getReplay() + ResetOdometry() + getIntReplay() + EnableMotors() + DisableMotors() DataManager + noActionNeeded() + DataManager() + ActionNeeded() + registerTaskInterface() + getPosition() Figure 2: Class diagram of the essential parts of the interface. set of experiments had a total of ﬁve runs. The initial period chose to lower this period because of safety issues of both the values were based on the frequency of the URG laser, which robot and environment. The period of DataPosUpdate and is 100 ms [30]. The period for each set thereafter was chosen DataLaserUpdate was set at 75 ms and 100 ms, respectively. based on observation. In three of the ﬁve experiment sets, all It was hypothesized that these experiments would help tasks were given the same period. In the remaining two sets, demonstrate the eﬀect of task frequency and determinism on the period of the LaserAvoidObstacles was varied to see the overall system. Trials were considered complete if they its eﬀect on the overall performance of the experiment. We circled the obstacles approaching and passing each waypoint. Journal of Robotics 7 Table 2: Behavior periods for each experiment set. Behavior periods (ms) Waypoint LaserAvoid Occupancy Dijkstra Set Planner Obstacles GridMap Planner (W) (L) (Oc) (P) 110 10 10 10 2 100 10 100 100 350 50 50 50 4 100 50 100 100 5 100 100 100 100 Figure 3: K-team Koala Robot equipped with an ETX-Nano computer for control and a Hokuyo URG laser ranger. Table 3: Experimental results showing the average number of times the garbage collector executed along with the standard deviation. RTT/RTGC RTT/RegGC RegT/RegGC Set Avg SD Avg SD Avg SD X X 3 2 1 24.6 0.548 1721 24.515 2770 50.710 2 5 0 514.4 9.940 531 12.247 3 6 0 617.8 12.697 536.4 14.082 4 4.2 0.447 430.2 11.256 368.8 13.971 5 4 0 422.6 8.295 376 40.050 X X 4 1 Start/ﬁnish Figures 5 and 6 show the average time that it took the robot to ﬁnish the course. Figures 7 and 8 show the av- Figure 4: The experiment room (9.6 m × 6.2 m) with four erage distance that the robot came to the expected ﬁnish waypoints was equipped with ground truth positioning sensors. position. Figures 9 and 10 give the average time it took The path was chosen such that all behavior tasks could be employed. the robot to travel from waypoint 1 to waypoint 2 (where obstacle avoidance occurred). Figure 11 shows the percent- age of missed deadlines for the four behavior tasks for each experiment set. Figure 11(a) shows an overview of all ﬁve If the robot either got stuck on an obstacle or did not reach sets. Since the ﬁrst set of experiments had such a large all waypoints within six minutes, the trial was considered percentage of missed deadlines as compared to the others, incomplete. Missed deadlines and completeness for each trial that set was removed in Figure 11(b) to show more details of was recorded. the other four sets. 6. Experimental Results 7. Analysis Each of the three trials were run using the diﬀerent behavior 7.1. Real-Time Threads versus Non-Real-Time Threads. The periods (shown in Table 2) to determine the eﬀect of timing results show that experiments using RTTs perform similarly and determinism on the program’s performance. Good or better than experiments that use the regular threads when performance was based on the following categories: run time, measuring time to complete the course (Figures 5 and 6). task completion, and distance to the ending position. These experiments completed the course faster than those Table 3 shows the average number of times the garbage using the regular threads in most cases. collector ran and the standard deviation for each set using RTTs with the RTGC (RTT/RTGC), RTTs with the non- RTGC (RTT/RegGC), and regular threads with the non- 7.2. Comparison of Garbage Collector. We measured the eﬀect RTGC (RegT/RegGC). that the garbage collector had on the performance in order to The experiments were broken into two groups for anal- analyze determinism. The garbage collector ran less often in ysis. Group 1 contains the results from the experiments with the RTT/RTGC experiments (see Table 3). When comparing all behaviors running at the same period. Group 2 contains the trials using only the RTTs, the experiments that utilized the results from the experiments where LaserAvoidObsta- the RTGC completed the course faster than those using the cles was adjusted as well as the set with all tasks running at a regular garbage collector (see Figures 5 and 6). Since the rate of 100 ms. Running LaserAvoidObstacles at a shorter RTGC is deterministic and does not aﬀect the behavior tasks period is suﬃcient since it handles the time consuming safety as they execute, we believe that it may have an eﬀect on the function of moving around the obstacle. average course time. 8 Journal of Robotics Average time to ﬁnish Average distance from ending position 2.5 1.5 W10, L10, W50, L50, W100, L100, W10, W10, L10, L10, W50, W50, L50, L50, W100, W100, L L100, 100, Oc10, P10 Oc100, P100 Oc10, Oc10, P10 P10 Oc100, Oc100, P100 P100 Oc50, P50 Oc50, Oc50, P50 P50 Experiment Set Exper Experiment iment Set Set RTT/RTGC R RT TT/R T/RT TG GC C RTT/RegGC RT RTT T/ /RegGC RegT/RegGC RegT/RegGC Figure 5: The average time it took the robot to complete the course Figure 7: The average distance the robot came to the ending for group 1. position for group 1. Average distance from ending position Average time to ﬁnish 2.5 1.5 W100, W100, L10 L10, , W100, W100, L L50 0, , W100, W100, L100, L100, W100, W100, L10 L10, , W100, W100, L L50 0, , W100, W100, L100, L100, Oc100, Oc100, P100 P100 Oc100, Oc100, P P100 100 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 Oc100, Oc100, P P100 100 Exper Experiment iment Set Set Exper Experiment iment Set Set R RT TT/R T/RT TG GC C RT RTT T/ /RT RTG GC C RT RTT T/ /RegGC RT RTT T/ /RegGC RegT/RegGC RegT/RegGC Figure 8: The average distance the robot came to the ending Figure 6: The average time it took the robot to complete the course position for group 2. for group 2. Also, to measure the eﬀect that an individual task has on performance, we observed how obstacle avoidance aﬀected 7.3. Eﬀect of Behavior Frequency. There were statistical diﬀer- the time it took the robot to travel from waypoint 1 to ences with the behavior periods when comparing the average waypoint 2 (see Figures 9 and 10). In all but one case the distance when the robot came to the ending position for the RTT/RTGC experiments reached waypoint 2 faster than the RTT/RTGC experiments. For instance, in group 1 (Figure 7), RTT/RegGC experiments. running the behaviors at a frequency of 10 ms is statistically diﬀerent from running at 50 ms. Also, running at a frequency of 100 ms is statistically diﬀerent from running at 50 ms. 7.4. Eﬀect of Latency. One indicator of latency is missed In group 2 (Figure 8), running LaserAvoidObstacles at deadlines. The system reports when tasks do not complete a period of 50 ms and all other behaviors at 100 ms is within their speciﬁed period; however, the tasks are not killed statistically diﬀerent from running at a period of 100 ms. when using the RTTs. Therefore, tasks that take too long These results show that even changes to the frequency of to complete may cause other tasks not to have enough re- a single behavior can aﬀect performance. This also shows sources. that, if tasks are permitted to run too fast or too slow, it We hypothesized that latency would not be an issue can adversely aﬀect overall performance in form of task with the lower frequencies because they provide more time completion and accuracy. foreachbehaviortocomplete. From Figure 11(a),itis Time (sec) Time (sec) Distance (m) Distance (m) Journal of Robotics 9 Averagetime to getfromwaypoint1to2 Total missed deadlines 0.9 0.8 0.7 0.6 0.5 0.4 70 0.3 0.2 W10, W10, L10, L10, W50, W50, L50, L50, W100, W100, L100, L100, 0.1 Oc10, Oc10, P10 P10 Oc100, Oc100, P P100 100 Oc50, Oc50, P50 P50 Exper Experiment iment Set Set RT RTT T/ /RT RTG GC C RT RTT T/ /RegGC RegT/RegGC Exper Experi iment ment Set Set R RT TT/R T/RT TG GC C Figure 9: The average time it took the robot to travel from waypoint 1 to waypoint 2 for group 1. RT RTT T/ /RegGC RegT/RegGC Averagetime to getfromwaypoint1to2 (a) Total missed deadlines 0.018 0.016 0.014 0.012 0.01 0.008 0.006 W100, W100, L10 L10, , W100, W100, L L50 0, , W100, W100, L100, L100, 0.004 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 Oc100, Oc100, P100 P100 0.002 Exper Experiment iment Set Set R RT TT/R T/RT TG GC C RegGC RT RTT T/ / RegT/RegGC Figure 10: The average time it took the robot to travel from Exper Experiment iment Set Set waypoint 1 to waypoint 2 for group 2. R RT TT/R T/RT TG GC C RT RTT T/ /RegGC RegT/RegGC shown that the set with all behaviors running at a period of 10 ms resulted in more missed deadlines. The experiments (b) in this set utilizing RTTs had more missed deadlines than Figure 11: Percentage of missed deadlines (a) for all ﬁve experiment those using regular threads. However, this is not the case sets and (b) for the four experiment sets with a lower missed when running the behaviors at a period of 100 ms (see deadline percentage (rescaled to show more details). Figure 11(b)). In this case, the RTT/RTGC experiments had no missed deadlines. However, (with the exception of experiment set 3) the RTT/RegGC experiments have a higher percentage of missed are improved in the RTT/RTGC experiments, there is still a deadlines than the RegT/RegGC experiments. Since the diﬀerence in how each experiment set performs at diﬀerent regular garbage collector is less deterministic, it is diﬃcult frequencies. Therefore, the frequency of each behavior to determine the eﬀect that it has on the task threads. should be based on input availability. Results also show that faster cycle times are not a good 7.5. Overall Analysis. Results show that proper timing is approach. However, the prevailing approach is to run behav- important to resource utilization even in an unconstrained iors as fast as possible, which is not ideal. Slower cycle times (resource rich) system. Although latency and determinism would give behaviors more time to ﬁnish, but too slow may Time (sec) Time (sec) Missed deadlines (%) Missed deadlines (%) W10, L10, W100, L10, Oc10, P10 Oc100, P100 W100, L10, Oc100, P100 W50, L50, Oc50, P50 W50, L50, Oc50, P50 W100, L50, Oc100, P100 W100, L50, Oc100, P100 W100, L100, W100, L100, Oc100, P100 Oc100, P100 10 Journal of Robotics also cause system instability, which is consistent with control [2] K. Konolige, “Saphira robot control architecture,” Technical Report, SRI International, Menlo Park, Calif, USA, 2002. theory. The key is to ﬁnd the optimal window at which [3] D. S. Touretzky and E. J. Tira-Thompson, “Tekkotsu: a frame- tasks do not run too short (depleting system resources) or work for AIBO cognitive robotics,” in Proceedings of the Na- too long (causing slow response). Therefore, the laws of tional Conference on Artiﬁcial Intelligence, vol. 4, pp. 1741– control theory should be applied to robotics requiring all 1742, AAAI Press, MIT Press, Pittsburgh, Pa, USA, 2005. behaviors and their dependencies to be analyzed. This would [4] B. P. Gerkey, R. T. Vaughan, K. Støy, A. Howard, G. S. give developers the chance to deﬁne their own frequency Sukhatme, and M. J. Mataric, ´ “Most valuable player: a robot requirements that is appropriate for the system that they are device server for distributed control,” in Proceedings of the using. IEEE International Conference on Intelligent Robots and Systems (IROS ’01), vol. 3, pp. 1226–1231, 2001. [5] G. Beccari, S. Caselli, M. Reggiani, and F. Zanichelli, “Real- 8. Conclusion time library for the design of hybrid robot control architec- tures,” in Proceedings of the IEEE/RSJ International Conference Many robot architectures view correct frequency as a func- on Intelligent Robots and Systems, pp. 1145–1150, October tion of resource availability. By not properly addressing timing concerns, mobile robot systems may not eﬃciently [6] J. Kramer and M. Scheutz, “Development environments for utilize system resources. Furthermore, ignorance of timing autonomous mobile robots: a survey,” Autonomous Robots, vol. details can lead a developer to produce unstable systems. 22, no. 2, pp. 101–132, 2007. This is partially because our intuition is that only the [7] J. Dorsey, Continuous and Discrete Control Systems, McGraw- critical tasks of a robot control program need to run fast, Hill College, New York, NY, USA, 2001. which is incorrect. One must apply the laws of Control [8] S. Bennett, Real-Time Computer Control: An Introduction, Theory to robotics, requiring all behaviors and their input Prentice Hall International, New York, NY, USA, 1994. dependencies to be analyzed instead of just the critical [9] G. Bollella and J. Gosling, “The real-time speciﬁcation for tasks. These laws should be applied because, consistent with Java,” Computer, vol. 33, no. 6, pp. 47–54, 2000. [10] A. McKenzie, S. Dawson, Q. Alexander, and M. Anderson, control theory, periods that are too short may cause system “Using real-time awareness to manage performance of java instability. clients on mobile robots,” in Proceedings of the IEEE/RSJ We developed a robot software platform to incorporate International Conference on Intelligent Robots and Systems temporal awareness. The system, written completely in Java (IROS ’09), pp. 3422–3428, December 2009. using Java RTS, allows individual program components to be [11] A. Nilsson, T. Ekman, and K. Nilsson, “Real Java for real assigned an execution frequency. It also utilizes RTTs, non- time—gain and pain,” in Proceedings of the International Con- RTTs, the RTGC, and the traditional garbage collector. We ference on Compilers, Architecture, and Synthesis for Embedded presented the details of the system and its implementation. Systems (CASES ’02), pp. 304–311, October 2002. Experiments demonstrated how manipulating the timing of [12] D. Arora, A. Raghunathan, S. Ravi, and N. K. Jha, “Archi- subtasks and using RTTs with the RTGC aﬀect overall task tectural support for safe software execution on embedded performance as measured by time to complete the path and processors,” in Proceedings of the 4th International Conference on Hardware Software Codesign and System Synthesis, pp. 106– the error associated with the ending position. The results 111, October 2006. of testing validate the hypothesis and show how important [13] G. Bollella, T. Canham, V. Carson et al., “Programming with proper timing is to resource utilization in mobile robot non-heap memory in the real time speciﬁcation for Java,” in systems. Proceedings of the Conference on Object-Oriented Programming In future work, the architecture will be written in a more Systems, Languages, and Applications (OOPSLA ’03), pp. 361– common real-time language such as C++ using the ORO- 369, 2003. COS Real-Time Toolkit [19]. It will then be compared to [14] S. Smith, S. W. Lawson, and A. Lawson, “Can real-time soft- the Java RTS version. This will be a good measure of Java ware engineering be taught to Java programmers?” in Proceed- RTS’s performance. Human studies that evaluate program- ings of the 17th Conference on Software Engineering Education mer proﬁciency on both Java RTS and C++ may shed light and Training, vol. 17, pp. 124–129, 2004. on features of the architecture that are useful in teaching [15] G. Buttazzo, F. Conticelli, G. Lamastra, and G. Lipari, “Robot control in hard real-time environment,” in Proceedings of the embedded programming techniques. 4th International Workshop on Real-Time Computing Systems and Applications (RTCSA ’97), pp. 152–159, October 1997. Acknowledgments [16] R. Brega, N. Tomatis, and K. O. Arras, “The need for au- tonomy and real-time in mobile robotics: a case study of The authors gratefully acknowledge the following NSF XO/2 and Pygmalion,” in Proceedings of the IEEE International Grants: IIS-0846976 and CCF-0829827 for supporting this Conference on Intelligent Robots and Systems, vol. 2, pp. 1422– work. They would also like to thank Nicholas A. Kraft for his 1427, 2000. knowledge of Solaris. [17] J. Auerbach,D.F.Bacon,D.T.Iercanetal., “Javatakes ﬂight: time-portable real-time programming with exotasks,” in Proceedings of the ACM SIGPLAN Conference on Languages, References Compilers, and Tools for Embedded Systems (LCTES ’07),pp. [1] R. A. Brooks, “A robust layered control system for a mobile 51–62, June 2007. [18] D. B. Stewart, D. E. Schmitz, and P. K. Khosla, “Chimera robot,” IEEE Journal of Robotics and Automation,vol. 2, no.1, pp. 14–23, 1986. II real-time operating system for advanced sensor-based Journal of Robotics 11 control applications,” IEEE Transactions on Systems, Man and Cybernetics, vol. 22, no. 6, pp. 1282–1295, 1992. [19] H. Bruyninckx, P. Soetens, and B. Koninckx, “The real-time motion control core of the OROCOS project,” in Proceedings of the IEEE International Conference on Robotics and Automation, vol. 2, pp. 2766–2771, September 2003. [20] H. Bruyninckx, “Open robot control software: the OROCOS project,” in Proceedings of the IEEE International Conference on Robotics and Automation, vol. 3, pp. 2523–2528, May 2001. [21] S. G. Robertz, R. Henriksson, K. Nilsson, A. Blomdell, and I. Tarasov, “Using real-time Java for industrial robot control,” in Proceedings of the 5th International Workshop on Java Technologies for Real-Time and Embedded Systems (JTRES ’07), pp. 104–110, 2007. [22] R. A. Brooks, “Intelligence without representation,” Artiﬁcial Intelligence, vol. 47, no. 1–3, pp. 139–159, 1991. [23] M. Montemerlo, N. Roy, and S. Thrun, “Perspectives on standardization in mobile robot programming: the carnegie mellon navigation (CARMEN) toolkit,” in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 2436–2441, October 2003. [24] Measuring Distance Type Obstacle Detection Sensor PBS-03JN Series Instruction Manual, Hokuyo Automatic, 2002. [25] B. Stroustrup, The C++ Programming Language, Addison- Wesley, Reading, Mass, USA, 1986. [26] R. Henriksson, Scheduling garbage collection in embedded systems, Ph.D. dissertation, Lund University, 1998. [27] A. Elfes, “Using occupancy grids for mobile robot perception and navigation,” Computer, vol. 22, no. 6, pp. 46–57, 1989. [28] E. W. Dijkstra, “A note on two problems in connexion with graphs,” Numerische Mathematik, vol. 1, no. 1, pp. 269–271, [29] Sun Java Real-Time System Precision Control for the Financial Services Market, Sun Microsystems, 2008. [30] Range-Finder Type Laser Scanner URG 04LX Speciﬁcations, Hokuyo Automatic, 2005. International Journal of Rotating Machinery International Journal of Journal of The Scientific Journal of Distributed Engineering World Journal Sensors Sensor Networks Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 Volume 2014 Journal of Control Science and Engineering Advances in Civil Engineering Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 Submit your manuscripts at http://www.hindawi.com Journal of Journal of Electrical and Computer Robotics Engineering Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 VLSI Design Advances in OptoElectronics International Journal of Modelling & Aerospace International Journal of Simulation Navigation and in Engineering Engineering Observation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2010 Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com http://www.hindawi.com Volume 2014 International Journal of Active and Passive International Journal of Antennas and Advances in Chemical Engineering Propagation Electronic Components Shock and Vibration Acoustics and Vibration Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014 http://www.hindawi.com Volume 2014

Journal

Journal of Robotics – Hindawi Publishing Corporation

Published: Dec 29, 2011

References

A robust layered control system for a mobile robot,

R. A. Brooks
Saphira robot control architecture,

K. Konolige
Tekkotsu: a framework for AIBO cognitive robotics,

D. S. Touretzky and E. J. Tira-Thompson
Most valuable player: a robot device server for distributed control,

B. P. Gerkey, R. T. Vaughan, K. Støy, A. Howard, G. S. Sukhatme, and M. J. Matarić
Real-time library for the design of hybrid robot control architectures,

G. Beccari, S. Caselli, M. Reggiani, and F. Zanichelli
Development environments for autonomous mobile robots: a survey,

J. Kramer and M. Scheutz
The real-time specification for Java,

G. Bollella and J. Gosling
Using real-time awareness to manage performance of java clients on mobile robots,

A. McKenzie, S. Dawson, Q. Alexander, and M. Anderson
Real Java for real time—gain and pain,

A. Nilsson, T. Ekman, and K. Nilsson
Architectural support for safe software execution on embedded processors,

D. Arora, A. Raghunathan, S. Ravi, and N. K. Jha
Programming with non-heap memory in the real time specification for Java,

G. Bollella, T. Canham, V. Carson et al.
Can real-time software engineering be taught to Java programmers?

S. Smith, S. W. Lawson, and A. Lawson
Robot control in hard real-time environment,

G. Buttazzo, F. Conticelli, G. Lamastra, and G. Lipari
The need for autonomy and real-time in mobile robotics: a case study of XO/2 and Pygmalion,

R. Brega, N. Tomatis, and K. O. Arras
Java takes flight: time-portable real-time programming with exotasks,

J. Auerbach, D. F. Bacon, D. T. Iercan et al.
Chimera II real-time operating system for advanced sensor-based control applications,

D. B. Stewart, D. E. Schmitz, and P. K. Khosla
The real-time motion control core of the OROCOS project,

H. Bruyninckx, P. Soetens, and B. Koninckx
Open robot control software: the OROCOS project,

H. Bruyninckx
Using real-time Java for industrial robot control,

S. G. Robertz, R. Henriksson, K. Nilsson, A. Blomdell, and I. Tarasov
Intelligence without representation,

R. A. Brooks
Perspectives on standardization in mobile robot programming: the carnegie mellon navigation (CARMEN) toolkit,

M. Montemerlo, N. Roy, and S. Thrun
Using occupancy grids for mobile robot perception and navigation,

A. Elfes
A note on two problems in connexion with graphs,

E. W. Dijkstra

Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 14-Day Trial for You or Your Team.

Learn More →

Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers

Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers

Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 14-Day Trial for You or Your Team.

Learn More →

Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers

Using Sun’s Java Real-Time System to Manage Behavior-Based Mobile Robot Controllers

References

Abstract

Journal

Recommended Articles

References

Our policy towards the use of cookies