01577044

DECEMBER 2005 IEEE Robotics & Automation Magazine 751070-9932/05/$20.002005 IEEE

The idea of robotic mechanisms hasfascinated humans since the firstmachines were built. Before the firstrobot was even constructed, thepopular view of robotics consisted of

humanlike machines that could walk, talk, andperform as well as their human counterparts[4]. Despite this popular view of humanoidrobots, industrial robotics has been the most dominant areaof research and growth in the years that followed. Eventoday, sophisticated humanoid-type robots are still far awayfrom realization, and their industrial-type counterparts,which are far from the popular view, still constitute the

largest percentage of robotics sales andresearch [39], [24].

Our need for robotics will continue to growas we become more immersed in technologyand as prices for robotic manipulators decrease.The International Federation of Robotics(IFR), a leading authority in the robotics indus-try, estimated that worldwide robotics sales were

up 15% in 2000 [39]. Although the majority of robotics saleswill continue to be generated by manufacturing industriessuch as automotive companies, we are beginning to see roboticsspread into other areas including military applications and aidsfor home and work use [39]. Some recent examples of this

BY GEORGIOS A. DEMETRIOU AND ALLAN H. LAMBERT

An Extensible

Object-OrientedPlatform

EYEWIRE

IEEE Robotics & Automation Magazine DECEMBER 200576

growth of industrial robotics into other areas include therecent use of robotics in packaging the new European currencyand the development of a robotic system that debones porkloin [33], [17].

All of the various sectors of growth point to an increase inthe need for robotics technicians in the near future. To keepup with this demand, institutions of higher learning will haveto adapt and develop diversified programs for robotics educa-tion, while overcoming spatial, temporal, and budget limita-tions. This article discusses impediments that face researchersand academic institutions that try to implement such trainingprograms and explains the ability of virtual modeling and sim-ulation (VM&S) systems to mitigate such problems, and asolution system, Virtual Robots (VROBO), is developed todemonstrate the effectiveness of the approach.

Existing Robotic Applications

Military RoboticsMilitary use promises to be a strong source of growth for therobotics community. Since its formation in 1990, the federallyfunded Joint Robotics Program (JRP) has received substantialfunding averaging around US$12 million per year. The mainpurpose of the program is to develop autonomous andremotely operated robots for surveillance and reconnaissance.Robotics can provide the military the benefit of the surveil-lance of hostile areas using remotely operated vehicles and ofthe remote disarmament of explosives [11].

Robotics in the WorkplaceRobotic developers are beginning to move their focus intonew areas such as robots that enable us to perform our person-al daily tasks better. The first area where robots are making ourtasks easier is the workplace. One work area with promisinggrowth is in the aid to medical technicians. Various robots areundergoing trials or are currently being utilized in general sur-gical applications such as diagnostic procedures, therapy, teach-ing and training, and telesurgery [12]. A specialized surgicalrobot in the labs of the Fraunhofer Institute for ManufacturingEngineering and Automation has recently been developed foruse in delicate spinal surgery. Since the robot is accurate towithin submillimeter range, it greatly reduces the chances oftrauma to the spinal chord or the surrounding tissue [27].

Robots in the HomeRobots are being developed that can perform various house-hold tasks. Household robotics was introduced to the publicaround 1983, but due to the publics overestimated views ofwhat robots could do, the process soon lost its momentum[15]. Recently, various Japanese companies have begun devel-oping home help robots that perform various tasks. One pro-ject is being conducted at NECs Central ResearchLaboratory. In 2001, the project introduced a 15 in 10 inrobot called PaPeRo. It can recognize up to ten people viamounted cameras, recognize up to 650 phrases via one of thefour mounted microphones, and even change the television

channel with its built-in infrared. Another project being con-ducted by Matsushita Electr ical Industr ial involves anautonomous vacuum cleaner. It is currently being evaluated intrial runs in many Japanese homes. One innovative idearecently came from Evolutions Robotics and their ER1 Per-sonal Robot system. It is a build-it-yourself kit that allows youto plug in your laptop to be used as the controller [46].

Physical Robot ProblemsToday, only a few universities offer specializations in roboticseducation, while most universities do not even offer a singlerobotics course [37]. This could be due to a lack of interest,operational costs, technological complexity, or a number ofother factors. According to one survey, instructors noted thattheir students thought of the robotics course as a fun thing,but had no plans of pursuing it as a career [26]. Traditionalcomputer science and engineering curriculums will have tofind ways to incorporate robotics training to meet the futuredemands of industry.

There are many physical robotics systems that are currentlybeing utilized in academia. Some of the more popular solu-tions include the LEGO Mindstorms sets, the Basic Stamps,OOPIC (object-oriented programmable integrated circuit),and articulated arm systems such as the Rhino arms [28]. Allof these systems are useful in an academic setting, but theyalso pose problems for the students and researchers usingthem. These barriers include factors such as various opera-tional costs, availability of equipment, technical complexity,flexibility of work environment, and time constraints.

CostPrices for robotics equipment can range from a few hundredto several hundred thousand dollars, depending largely on thefunctionality needed. Even the lower-priced equipment canbecome expensive when it must be bought for multiple stu-dents or researchers. And to perform additional research andexperiments, it is usually necessary to purchase more acces-sories and equipment [37], [22].

Maintenance and RepairRepair and maintenance is another substantial variable thatmust be factored into the overall cost of robotics programs[37]. Robotic manipulators, actuators, and sensors wear andbreak like all electromechanical equipment. Belts for pulleysystems break, circuit components burn out, screws pop off ofend effectors, and just about anything else that can happendoes [22]. Routine maintenance, such as oils to lubricatejoints and replacement fluids for hydraulic actuators, also playsa part in the overall cost. All of these factors lead to the needfor skilled personnel and extra parts to perform repairs [10].

Labor costs can vary depending on the task that must beperformed. If students and researchers are skilled in the areasof mechanical and electrical systems, it is possible that somerepairs can be performed in house [23]. However, these skillsare lacking in many departments; in these cases, it would bewise to allow a skilled professional to perform the work.

DECEMBER 2005 IEEE Robotics & Automation Magazine 77

Availability of EquipmentIn addition to those discussed above, another problem thatarises in robotics is the availability of the equipment. Thisproblem takes shape in a number of different ways; all cankeep the researchers and students from getting work done in atimely manner. These factors include such things as equip-ment downtime, limited resources, hours of availability, andstudent or researcher geographic location.

Technical ComplexityAnother serious problem that arises with the introductionof robotics into educational programs is the interdiscipli-nary nature of robotics. A firm understanding of roboticsincludes knowledge from areas such as computer sciencefor programming robotics, electronics for building andrepairing robots, and physics for understanding the dynam-ics and kinematics associated with robotic actuators andmanipulators. In addition to these base fields is the needfor the student or researcher to be knowledgeable in thedomain the robotic system is addressing. For instance, if arobotic manipulator is being developed to remotely per-form delicate surgery, the student or researcher must befamiliar with the medical procedures needed to performsuch an operation. Fur thermore, i f the student orresearcher is responsible for developing the protocols forcommunicating with remotely operated robotic manipula-tors, a thorough understanding of networking architectureis required. This inherent array of skills needed to set upand maintain a robotics lab can deter many departmentsfrom establishing a program [23].

Robots and Work Cell FlexibilityThe ability to rapidly reconfigure and reprogram physicalsystems and their accompanying work cells is limited. Somesystems allow various reconfigurations, such as the roboticskits discussed earlier, but most systems, especially roboticarms, are designed with static structures that only allowmodest flexibilities. Additionally, the students andresearchers are limited to what is available, and they cannotwork with the conceptualized mechanisms that are not yetavailable as off-the-shelf components.

There is also the problem of work cell flexibility. Therobot operator is limited to the physical layout and spaceavailable at hand. If the operator needs a new work cellarrangement they will have to manually reconfigure all of theobjects in the workspace and acquire extra structures that arenot already available. Frequently, robotic arms are semi-permanently bolted to their work cells, limiting their flexi-bility. In addition, physical structures such as mazes, tables,and other objects are put together in a monolithic fashion,further hindering the ability to rapidly configure the environ-ment [37]. Another problem is the ability of the system toaccept different programming languages and controllers. Mostpurchased robotics systems are limited to the proprietary pro-gramming languages and controllers sold by the same compa-ny that manufactures the robot.

Time ConstraintsThe final problem associated with the physical application ofrobotics training and research is that it takes a lot of time toreconfigure, maintain and repair, and program physical robot-ics equipment. As mentioned earlier, robotic manipulatorsand their accompanying work cells take time to constructand reconfigure. For instance, if a new robot is to be con-structed, it must be designed and then put together piece bypiece, ensuring that all the mechanical and electrical parts areworking in sync [13], [37]. In addition to the lost time thatresults from maintenance and repair, there also can be a sub-stantial amount of time associated with repairing the roboticequipment if the researcher or student is responsible for itsupkeep [10]. Some equipment also suffers from the need toprogram the robot over slow connections. For example,some robotics equipment requires that the entire program bewritten and downloaded before it can be tested, which doesnot facilitate interactive debugging [13]. Finally, cumbersomemethodssuch as programming with a teach pendantcantake a lot of time by walking the robotic manipulatorthrough numerous steps to obtain the desired behavior.

The problems presented in this section will continue toslow the adoption of robotics education in academia andresearch arenas in the future; therefore, something must bedone to combat these problems. The next section proposesthe use of virtual environments for dealing with the numerousproblems in this section. Although virtual environments cannever mimic situations as perfectly as their real-world coun-terparts can, they have come a lot closer in recent years withrapid increases in hardware and software technologies.

Virtual Modeling and SimulationVirtual modeling and simulation is a diverse field of researchthat embodies two main areas: virtual reality (VR) and com-puter-aided design (CAD). VR and CAD developed inde-pendently, but they were later combined after the benefits thatVR brought to static CAD drawings were understood. Theoriginal CAD systems were static two-dimensional (2-D)drawing platforms that ran on large expensive mainframecomputers. Soon after, 3-D capabilities were introduced, giv-ing the drawings a more aesthetic appearance. In addition, the3-D capabilities conveyed the objects characteristics andattributes more accurately than the static 2-D drawings.

Virtual reality has come a long way since the first simula-tions of flight cockpits in the early 1980s. Today, most peoplestill attribute large bodysuits and cumbersome headsets withVR. Despite this perception, VR can normally be brokendown into three separate categories. The first is the mostimmersive and constitutes the popular view. Headsets areworn by the user; the headsets project 3-D images to theuser. The direction of gaze can be input to the system viamotion sensors attached to the headsets. In addition, gloves,bodysuits, and other peripherals with various pressure sensorscan be used to provide input data for manipulating surround-ings and to provide sensory feedback to the user. The secondcategory of VR involves the projection of an image onto a


curved surface. The surface is usually large enough to coverthe users entire field of vision, giving them the sense ofimmersion. The final category employs common PCs and flatscreens to convey flat 3-D perspective projections of virtualworlds. Even though this category is the least immersive, ithas been the fastest growing category due to its cost-benefitratio. Furthermore, this cost-benefit ratio makes this theselected option for our development of VM&S platform.

These VM&S systems allowed the static 3-D data to beloaded into the virtual environments. In turn, the interactivenature and easy manipulation of objects provided by VRextended to the static 3-D description of CAD drawingswhen loaded into the environment. This gave rise to a pow-erful tool for rapidly modeling and simulating virtual proto-types and their accompanying environments, yieldingsignificant benefits to the user [2].

Overcoming Physical Implementation ProblemsVirtual prototyping and simulation, with its highly customiz-able and interactive nature, can be used to overcome most ofthe problems discussed in the Physical Robot Problems sec-tion of this article. This depends on picking a VM&S systemwhose constituent parts effectively provide solutions in thevarious areas, because not all systems will provide completesolutions. However, if the right functionalities are included inthe VM&S system, then there can be lowered costs of owner-ship, increased equipment availability, reduced complexity dueto information hiding, and increased system flexibility, allresulting in the reduction of wasted time.

Cost was the first major factor impeding the developmentof robotics programs across academic and research programs.The way in which VM&S overcomes financial barriers can bebroken down into its two constituent parts. These two partsare hardware and software.

On the software side, open-source technologies can greatlyreduce the financial overhead of the lab [30]. There are a num-ber of freely available prototyping tools out there, including theVRML language and Java3D. There have been many elaboratestudies confirming the successful use of both tools for applica-tions ranging from the modeling of online virtual communitiesto the modeling of complex autonomous agent behavior incomplex environments. In addition, both tools have been scru-tinized by the user community, which has resulted in stable andwell-tested software tools. There are also many books andonline references available that document each of theseapproaches. An additional benefit offered by these two tools isthat both are platform independent, so the implementation ofthe robot can be written once and then distributed across mul-tiple operating environments. Finally, they both can be distrib-uted via the World Wide Web, allowing online collaboration ofstudents and researchers. In the case of Java3D, we can makeuse of its distributive capabilities to spread the computationalworkload across multiple machines [38].

The other major component is the use of standard hard-ware architectures for running the VM&S environment.Rapid developments in the information technology (IT)

industry have made it feasible for common PCs to comecloser to mimicking the computationally intensive kinemat-ics and dynamics of the real world. The current hardwaremight not be able to perfectly mimic real-world counter-parts, but for research and student development, it can stillbe effective in robot design and research experiments [5].Furthermore, the virtual environment can be used to emu-late environments that are not accessible to the student orresearcher. For example, the virtual environment can beconstructed to resemble the surface of a distant planet orthe bottom of the ocean [5].

VM&S eliminates all costs associated with maintenanceand repair needed by our real-world mechanical systems.Software is not affected by the same daily stress that a real-world robot will endure. Once a software system is construct-ed and fully tested, it will not slowly erode due to physicalfactorssuch as intense use of the systemas a real-worldsystem will.

Availability of EquipmentIf the equipment is not available for use, it does not efficientlymeet the needs of the students or researchers in their develop-ment efforts. Today, VM&S tools are highly capable systemsthat can be delivered to the end user in multiple different for-mats and with varying technologies. This flexible nature ofVM&S allows for reduced downtime due to mechanical fail-ures, reduces the need for multiple sets of equipment, makesthe system available around the clock, and tears down thegeographic barriers between the user and the equipment.

VM&S eliminates the need to buy multiple pieces ofequipment, which results in higher availability to its users.Robotic software systems can be duplicated for as many sys-tems as are needed. This allows each student or researcher tohave their own system; they dont have to wait for other indi-viduals to finish using the equipment [2]. The hours of avail-ability is not a problem any longer due to the easy replicationof VM&S environments. Since the user does not have to usethe system at specific times, he is able to perform experimentsand assignments at more convenient times for his schedule.

Finally, the use of a VM&S system will remove the geo-graphic barriers that were discussed previously. As long assoftware can be executed on standard hardware, such as adesktop personal computer, then the user can take the soft-ware anywhere with access to a computer [16]. In the caseof the previously mentioned VRML and Java3D environ-ments, both can run on any machine that possesses theneeded interpreter for understanding the VRML andJava3D formats. They can also be used in a client and serverscenario where the software is physically located on aremote server and is accessed by the user through the net-work and displayed on their system. This is especially usefulin applications where immense computational capabilitiesare required. Since Java3D can leverage the distributivecapabilities of the Java language, it is possible to have multi-ple computers, each performing some part of the calculationand the client receiving the result [14].

Technical ComplexityAs mentioned above, robotics is by nature a cross-discipli-nary area of research and can require the user to acquireknowledge in areas of engineering, physics, and computerscience. Most individuals do not have such knowledge andwould require years of training if all of the fields were need-ed to understand the operation of the system. Regardingthe engineering side, the user would need training in thesystems mechanical aspects to understand theoperation of the actuators and manipulatorsand would require training in electrical engi-neering to understand the underlying circuit-ry. Computational abilities, such as thoselearned in physics, would be needed for cal-culating the dynamical movement of the sys-tem including velocities and accelerations ofjoint and angles and their accompanyingmanipulators and end effectors. Finally, computer sciencetraining would be needed to understand the software andhardware aspects of the real-world system. Some of thetechnical complexities of the system can be hidden fromthe user, but they still are not flexible enough to hideunderlying implementation details [23].

Finally, the controls and interface software used across thedifferent physical robotics platforms are usually proprietarystandards; therefore, users will have to learn a different inter-face for every physical system they intend to use. Adding tothis complexity, each individual physical systems controls andinterfaces normally cannot be customized to show only therelevant features required at the time, forcing the user towade through a vast array of functions to find the few rele-vant functions they need.

The ability to hide the complexity of the robotic system is amajor benefit of using VM&S systems. Using object-orientedapproaches, the user of the system can be exposed to only theareas of the system they are trying to experiment on orresearch. If the user is only interested in learning how to pro-gram the robot or in researching obstacle avoidance algo-rithms, he does not have to worry about the dynamic aspectssuch as acceleration and velocity [32].

Robot and Work Cell FlexibilityFlexibility of the VM&S can be provided in various formats,allowing the user to easily add or reconfigure components ofthe system. Several options that allow a virtual system to pro-vide this flexibility exist, and each one requires different userskills [13]. The various ways that this is provided can begrouped into two large categories: those that are provided bygraphical user interface (GUI) and those that are provided bythe object-oriented (OO) capabilities of the system.

The most flexible part of a system is the ability to extendand modify the underlying system. If object-oriented pro-gramming features are provided in the underlying language,then generalized objects can be provided that allow the userto extend them and provide more specific functionality. Thekey would be to specify a minimal implementation so that

the new component could work with the current system.These types of features would provide unlimited options forreconfiguring the environment and its controls [38].

Additional BenefitsIn addition to solving our physical constraints, the VM&S alsooffers many additional benefits to the user. Some of thesebenefits are directly related to physical constraints and others

are more general; nonetheless, each requires additional com-ment. Two of the most important benefits of the systeminclude user safety and remote control applications when therobot is not locally available.

Safety is probably the most important benefit to the user ofthe system [10]. Students or researchers using a VM&S systemare completely safe from the mechanical mishaps that can occurwith real-world equipment. This allows the user to quickly tryout new programs and configurations without having to put allof the safety mechanisms in place. Also, initially viewing theoperation of real-world equipment through virtual interfaces isa good way to familiarize students and researchers with thephysical equipment. By training them in this manner, they areless likely to cause harm to themselves or others when using thephysical equipment.

Teleoperation of robots is currently an intense area ofresearch and development. To control a remote robot, it isnecessary to have some visual feedback showing the currentstate of the robots joints and sensor arrays. In some instances,this can be provided via a local slave robot or simply by a list-ing of current values and a video feed. The problem withusing a slave arm is that an additional replica of the masterrobot must be constructed or purchased. To avoid this extracost, VM&S systems are being used more often in applicationswhere it is not cost beneficial to have two identical robots.Furthermore, if the environment is not readily available, itmight be more appropriate to test and develop in a virtualworld. Examples can include interplanetary space missions,deep ocean exploration, and other nonhuman friendly envi-ronments [5].

Shortcomings of VM&SThe most notable problem that VM&S faces is the virtual sys-tems lack of ability to fully and completely emulate its real-world counterpart. Physical systems are subject to such com-plex and numerous mechanical factors that even the fastestsupercomputers cannot perfectly emulate them. However, aslong as the virtual system can provide enough realism for theuser to investigate a new algorithm, test a program, and teach

Virtual prototyping and simulation, with its highly customizable and interactive

nature, can be used to overcome mostphysical robot problems.



robotics concepts to students or for the researcher to moreeasily communicate his design, then it does not matter thatevery physical aspect of the original system is not present [5].

Another problem is that students having only virtualtraining end up with no experience working with real sys-tems. Experience with real systems is necessary to help stu-dents understand the complexities and mechanicallimitations of robotic systems. For example, a certain algo-rithm might work in the virtual environment but may notbe feasible due to some physical constraint that was notmodeled in the virtual world.

State-Of-The-Art Virtual Modeling and SimulationCurrently there are numerous solutions for implementingrobotics labs for students and researchers. These systems rangefrom pricey commercial software suites to academia-basedsolutions [8]. In both cases, there must be a specific set of cri-teria that allows users to overcome the obstacles that impederobotics research and development. If these criteria are notselected carefully, it is possible for the benefits of the VM&Ssystem to be reduced significantly. When we discussed thebenefits of using VM&S, we identified most of the criteria thatwould bring cost-effective robotics to students and researchers.These criteria included desirable goals such as reduction of

cost, VM&S system flexibility, reduction in technical com-plexity, operating system and hardware platform independence,and the application of current network technologies [5].

Reviewed SimulatorsThere are many systems currently available, but three ofthem will be discussed here. Selection of the systems wasbased on each systems adherence to the criteria that we setforth. In addition, there needed to be some evidence thatthey had already been used in either teaching or research.The three systems that have been reviewed are Simderella,Khepera Simulator, and RoboWorks. These systems differgreatly in the key assumptions that were made during theirdevelopment. Further challenges arise because each systemwas developed for different purposes. For these reasons, wegenerally refrain from comparing their performance. Fur-thermore, we have not tested all of these systems extensively;therefore, most of the specifications given in this article arederived from the literature.

SimderellaSimderella came out of the work done by Patrick van derSmagt while attending the University of Amsterdam. Theprogram was developed over several years to aid in his neuralnetwork research. Its main purpose was to speed up thedevelopment of controller interfaces for robots by allowingformulation and immediate testing of new controller algo-rithms. In addition, the program is modular in that it is sep-arated into three modules. All three modules run inseparate processes and communicate via a socket interface.Since the system performs message passing over a socketinterface, it is possible to place each process on separatecomputers resulting in a distributed VM&S system. Therelationship between the individual modules is pictured inFigure 1 [42].

Figure 2. A screen shot of the Khepera Simulator.

Figure 1. The Simderella environment.

Connel SimmelBemmel


The first of the three parts is connel, which is the con-troller part of the system. The initial system comes with adefault controller that provides the reverse and forwardkinematics for a Philips OSCAR-6 anthropomorphic arm.This is the module where most of the customization takesplace. Functions are provided in C/C++ code that mustbe implemented by the user of the system. The result is anew controller that can be used to send control messagesto the rest of the system. In addition to sending controlmessages, connel receives information from simmelincluding things such as current joint values and cameraposition [42], [43].

The simulation part of the system is the module that tiesthe other two modules together. Simmel is capable of com-puting forward and inverse kinematics when a file is loadedthat contains the Denavit-Hartenberg (DH) parameters forthe robot. After computing DH-matrices, they are sent tobemmel for display to the user [42], [43].

Khepera SimulatorThe Khepera Simulator (Figure 2) is similar in functionalityto the Simderella VM&S system. Oliver Michel, a doctoralstudent at the University of Nice-Sophia Anipolis, France,developed it during his preparation for a Ph.D. dissertation.Much like the Simderella system, it allows writing of con-trollers to control the motions of a mobile robot using eitherC or C++. The GUI of the system is a 2-D image of the

robot and its work cell; it requires an X11 server for thegraphics to be displayed. On the right of Figure 2 are thesensors and controls that are used to provide feedback andinput into the virtual world [29].

RoboWorks RoboWorks (Figure 3) is a commercial application thatallows the user to construct articulated objects from simple3-D primitives. The system uses a scene graph approach toconstruct and describe the objects in the tree called nodes[35]. Nodes consist not only of geometric primitives, but alsocan include transformation nodes for the articulated move-ment of the objects and material nodes to indicate the mater-ial properties of objects for light model rendering [1].

The system supports automation via keyboard, ASCIItext files consisting of joint values, and programming inter-faces for C/C++, VB, and MATLAB [35]. Robotalk is thepart of the system that allows for easy integration into vari-ous languages to obtain the ability to control the robot.Robotalk does not provide a controller on its own, Instead,it gives commands for specifying joint angles. The interfaceis implemented as a Win32 dynamic link library, so itsexported functions can be called from any programminglanguage that supports them. In addition, RoboWorks usesstandard TCP/IP protocols for communications. Therefore,it is possible to have the controller on one machine controlthe model that is located on another [34].

Figure 3. A screen shot of RoboWorks with loaded geometry.


Evaluation of Reviewed SystemsNow that we have elaborated on the systems under consider-ation, we can discuss how they do or do not meet our goals.None of these systems were intended for pure educationaland research purposes. Most of them are worthy candidatesfor use in teaching and research but still lack one or more ofthe qualities that we defined.

Cost ReductionIf we are to reduce the price of our system, then we mustchoose a cost-effective solution. The Simderella system is verycost effective because it is freely downloadable from the WorldWide Web. It can be used in all research and academic envi-ronments; however, use of the system for commercial softwareis not allowed [42], [43].

The Khepera Simulator is also freely available via theInternet. There is a commercial version based on thiswork called Webot, which has additional features includ-ing a 3-D interface. The free 2-D program is available forteaching and research purposes [29].

The last system, RoboWorks, is the most expensive of thereviewed systems.

Flexibility of SystemWhen discussing flexibility, we must break it down into twoseparate parts. The first is flexibility via the user interface, forexample, allowing the user to configure robots and theirwork cells via menu commands and toolbars. In addition, itcan also provide the ability to change modes of controllingthe robot, such as an off-line programming interface. Thesecond deals with the flexibility provided by the program-ming interface, which includes source code modifications,application programming interfaces (APIs), and inheritancecapabilities provided through object-oriented languages.

The Simderella system provided only moderate flexibility.Only one robot is provided for controlling via the singleincluded keyboard interface controller, and the keyboard inter-face is very limited. However, the system does provide theability to extend or implement new C functions that allow theuser to create new controllers or additional commands. Thesystem does not provide a means for reconfiguring the robotor work cell through the GUI. The only way to modify thefunctionality is through source code modification [42].

Since the Khepera system shares basic design principleswith the Simderella system, it also offers similar flexibility.The Khepera system is programmed through modification ofsource code files. One of the improvements that the Khepera

system has made is that it comes with a few prewritten con-trollers, including a neural network controller. The maininterface consists of three C structures located in a file namedrobot.h and a series of C functions that let you overridethe command buttons viewable on the GUI interface.Another improvement of this system over the Simderella sys-tem is the ability to reconfigure work cells and save them.The objects that can be placed in the system include 2-Dblocks and lights for interaction with the simulated Kheperassensor array. Finally, the system offers a set of functions fordrawing. For example, the user could generate graphicaldepictions of the robots sensors in relation to each otherusing this provided set of graphics functions. However, justlike the Simderella system, it does not provide off-line pro-gramming of the robot or the ability to replace the Khepera

robot with another robot. In addition, the multiplecontrollers can only be used one at a time and require arecompile to switch to a new one [29].

The most flexible of the systems was the RoboWorkssystem. The attribute that makes this system highly flexi-ble is the ability to change the work cell and robot viathe GUI interface. Menus and toolbars are provided tomodify the scene graph that is rendered into the Win32windowing interface. This allows multiple robots and

work cells to be constructed and saved via a menu commandto the hard drive for later use. This requires no source codemodification. In addition, the system provides three ways ofinterfacing with the constructed system. All three methodsrequire the user to attach tag names to the transformations inthe scene graph. This tag name provides an identifier formodifying the value of the transforms parameter. The first ofthe three methods controls the transformation through key-board keys. This method requires the user to specify a key-board key in addition to specifying a tag so that the key canbe pressed to articulate the joint. To move in the other direc-tion, the user only has to hold down the shift key in additionto the specified key. The second approach is accomplished viaa tag file. The tag file, a simple ASCII text file, consists of arow of tag names in the first row with transform parametervalues specified on the additional rows. The file is loaded intoRoboWorks and when executed assigns the parameters oneline at a time to the indicated tags until the end of the file isreached [35]. The last method uses the RoboTalk program-ming interface. This dynamic link library exports functionsthat allow the user to programmatically change the transformparameters using the tags [34]. The user can use any languagethat supports the ability to understand dynamic link libraries,such as Visual Basic, C/C++, and MATLAB. The systemsonly problem is that it does not come with predefined con-trollers; however, it does come with preconstructed robotsand associated tag files [35].

Reduced Technical ComplexityModerate complexity was a problem with most all of the sys-tems under consideration. The Simderella system came with abasic keyboard controller, but nonintuitive key assignments

By the selection of tools, the system was able to realize significant progress for the cost, portability, and networking criteria.


made this interface very cumbersome. Secondly, theSimderella system requires the user to perform source codemodifications to produce additional functionality. Finally, theSimderella system requires building the system before you caneven run it. This problem is compounded by having to con-figure a number of the scripts and other files if the construct-ed system does not perform as expected. This seemed to bethe case when running the system on Red Hat Linux 8.0[42], [43]. The Khepera system was not as complicated to useas the Simderella system; the GUI was easily understood andintuitive. However, the Khepera system still required sourcecode modifications for additional functionality and for build-ing the provided source files before the first use of the system[29]. The scene graph architecture of the RoboWorks systemcould be complex for an inexperienced user. It requiresknowledge of graphical object hierarchies and their renderingorder. Consequently, the feature that gave RoboWorks itsflexibility also contributed to its increased complexity. On theother hand, through the keyboard and tag files, the systemprovided easy control of the articulate figures, and there wasonly moderate complexity associated with using RoboTalk toprovide increased capabilities [35].

Portability of SystemThe three systems scored the lowest on portability issues.Both the Simderella and Khepera simulators were onlyavailable on Unix or Unix-variant platforms. The main rea-son for this dependency was that they both relied on theX11 windowing interface to provide graphics. The otherplatform dependency problems involved the use of UNIXscripts in the build and configuration processes [29], [42].The RoboWorks system suffered from a similar windowingenvironment problem. In this case, Roboworks relies heavilyon the Win32 windowing subsystem, which is provided by aseries of dynamic link libraries (dlls). The use of dlls was alsoa problem when dealing with the programming interfacethat is included, RoboTalk. RoboTalk is itself a Win32dynamic link library. Due to these dependencies,Roboworks can only be executed on Windows 9x/ME andWindows NT, 2000, and XP platforms [34]. The most sig-nificant problem for all three systems was their reliance onplatform-dependent windowing environments. If not forthis, most of the systems could have been modified with lit-tle change to the underlying code and recompiled to workon other platforms.

Networking CapabilitiesThe networking capabilities allow for increased distributionand computational abilities [5]. For example, since theSimderella system is composed of three separate modules run-ning in different processes, it is possible to distribute each toseparate machines. This could consist of machines specificallydesigned to handle the modules functionality [42].RoboWorks also provides distribution of itself and the Rob-oTalk dynamic link library to separate physical computers.This could be useful for applications that require a controllerwith computationally complex algorithms to be placed on acomputer capable of intense number crunching. Since thegraphical RoboWorks interface does not need to performthese intense calculations, it could be placed on a typical homecomputer with minimal graphics capabilities [34]. The finalsystem, Khepera, does not provide any networking capabilitiesand was completely instantiated in a single running process.

Overall EvaluationIt is apparent in Table 1 that none of the currently availableVM&S systems satisfy all of our criteria. However, it mightnot be necessary for all of the criteria to be met if the adop-tion of the program is not hindered. For instance, if the stu-dent or researcher does not have a need for the teleoperationof remote cells or online collaboration, then the networkingcriteria does not necessarily have to be met [5]. HoweverVROBO (Virtual Robots) allows for the quick and easy inte-gration of a robotics program or class into an existing academ-ic and research institution. VROBO meets all of the criteriaset forth, and it can rapidly adapt to newly established pro-grams as well as existing ones.

VROBO Architecture Overview and EvaluationBefore the implementation of VROBO, certain criteria wereestablished as guidelines during the design and evaluation phas-es. The following criteria are the same as the criteria used toevaluate virtual modeling and simulation (see previous section):

reduced cost flexibility complexity portability network/Internet capabilities.VROBOs architecture is shown in the block diagram in

Figure 4. The systems functionality is outlined below.1) The user selects a specific robot to program.

Khepera RoboSystem Simderella Simulator Works

Cost Free Free US$4,999.95Flexibility Moderate Moderate HighComplexity Moderate Moderate ModeratePortability Moderate Low LowNetwork Enabled Moderate Low Moderate

Table 1. Comparison of currently available VM&S systems.

Figure 4. A block diagram of VROBO.

GUI ComputerSystemRobotic

Controller


Figure 5. A screen capture of VROBO.

2) The programming is performed with a generic pro-gramming language that was developed specifically forthis system and is based on existing robotic program-ming languages.

3) The program is simulated on the robot that is displayedon the GUI.

4) The program can be modified and tried again until theuser is satisfied with the results.

5) Once the program is complete, the user can downloadthe program to the controller of the actual robot beingsimulated.

6) During the download phase, a translation is done fromthe VROBO programming language to the specificlanguage of the actual robot.

7) Finally the program can be executed on the real system.The GUI, shown in Figure 5 was built using current Java

technologies. The interface consists of four main areas: thecontroller selection list box (CSLB), the controller panel(CP), the robot selection list box (RSLB), and the robotpanel (RP). When the application is first executed, neitherthe controller nor the robot is initially selected. To indicateto the user that selections must be made, a select a con-troller option is initially selected in the CSLB of the con-troller panel, and a select a robot option is initially selectedin the RSLB. Once a controller and robot are selected, the

controller can articulate the robot. This is the basic interfaceto the entire application.

Despite the simplicity of the interface, the overall successof the system at meeting the criteria depends on severalchoices. The choices fall into two main categories: decidingwhich tools to employ in the design and the decisions thatmust be made during the design itself.

Tool Selection and Meeting Cost,Portability and Networking Criteria In selecting technologies to implement the system, it wasnecessary to pick tools that would maximize the realizationof the goals at hand. Some of the choices may actually meetan entire goal, while others just encouraged the success of acompliant system. Nevertheless, by the selection of tools,the system was able to realize significant progress for thecost, portability, and networking criteria.

Since the system is based on freely available Java tech-nologies, it was possible to reduce the costs of the developerand the user of the system. The Java components consistedof both core Java technologies and the use of add-onlibraries. The core Java technologies used were available viathe Sun Microsystems Web site (http://java.sun.com). Thecore development tools employed in the development of thesystem were the Java 2 Platform, Standard Edition (J2SE)


Software Development Kit (SDK) 1.4 and the Java RuntimeEnvironment (JRE). The difference between the two is thatthe SDK contains the tools and code to create new contentfor the Java platform, while the JRE only contains a minimalset of features for running prewritten content. In reality, theJRE is distributed as part of the SDK and is installed whenthe SDK is installed. These two configurationsallow individuals who only need the user inter-face functionality of the VROBO applicationto only download the JRE, which has a smallerdownload size compared to the SDK. If theperson needs to add extra functionality to theVROBO system by extending interfaces orclasses or with direct code modifications, theycan download the freely available JDK [45].The add-on libraries used were part of theJava3D API, which is also maintained by SunMicrosystems. These libraries consist of four Java jar files thatare copied into the Java directory structure during the instal-lation process of Java3D. The Java3D API provides the abilityto build customized scene graphs that can be rendered intoJava-based interfaces using native OpenGL calls on UNIX-based and Windows-based systems. In addition to theOpenGL binding, support for native DirectX use is availablefor Windows users [45].

High levels of portability were achieved through the selec-tion of Java technologies. This was possible due to the avail-ability of JREs and Java3D implementations for both UNIXplatforms and Microsoft Windows. The Java code maintainscode portability by not converting source-level code intomachine instructions. Instead, it takes the source code and

compiles it into an intermediate form called bytecodes. Byconverting the code to an intermediate format, the systemcan be distributed to any machine that has a JRE installed,and the JRE will take care of the translation of the bytecodesinto machine code for that particular platform [9]. Further-more, since OpenGL implementations are provided on mostplatforms, it is possible for the OpenGL Java3D binding to beused on either UNIX or Windows platforms [1].

Figure 6. A partial class diagram for the VROBO system.

RoboJointConstraints

RoboMessagePad

RoboOrbiterViewer

RoboRobotLoader

RoboMCP

RoboController

RoboRobo

RoboWorkCell

RoboRobot

RoboJointActuator RoboCommandInterpreter

RoboCobra600

RoboArticulatedLines2D

RoboArticulatedCylinders3D

Robotics is by nature a cross-disciplinary area of research

and can require the user to acquireknowledge in areas of engineering, physics,

and computer science.


Figure 9. A screen capture of VROBO using the CommandIn-terpreter controller to maneuver the Cobra 600 robot.

Figure 10. A screen capture of VROBO using the Joint Actua-tor controller to articulate the ArticulatedCylinder3D.

The final criterion that benefits from the selection ofdevelopment tools and environment is that of networkingcapabilities. Java itself was developed to take advantage ofnetworking from the beginning. Java also makes it easier touse networks, and it supplies different layers to suit differ-ent needs. For example, it provides high-level APIs to theuser for HTTP and FTP protocols while still giving accessto lower-level programming interfaces such as sockets [14].Not only does the Java environment provide mechanismsfor protocol communications, it also provides ways ofdownloading remote code to be executed either in thebrowser or through the use of Java Web Start technologies.

System Design and ImplementationIn the previous section, three of the criteria were discussed.The entire criterion for portability was realized; however, thecriteria of cost and networking were only partly fulfilled bychoosing Java-based tools. In the case of cost, the only addi-tional action that must be performed is the release of the soft-ware as open source. The open-source paradigm would allowindividuals to freely use and modify the code without payinglicensing fees or having other types of costs incurred [30].However, that still leaves the criterion of networking to con-

sider in the design and implementation of the system. Thiscriterion, accompanied by the criteria not directly affected bythe tool selection, results in making careful design decisionsthat will increase the overall flexibility, decrease the technicalcomplexity, and take advantage of the networking capabilitiesthat the Java API offers.

FlexibilityThe criterion for flexibility presents itself in many areasthroughout the design and implementation of the system.Some of them are implemented through programmatic abili-ties while others are realized through the GUI. The majorprovisions for flexibility and those that are most apparentinclude the use of multiple controllers and interfaces, the abil-ity to add new controllers and robots to the system, the capa-bilities of some of the controllers to dynamically reconfigurethemselves based on the selected robot, and the ability todirectly modify the underlying source code (Figure 6).

The system provides a number of controllers and articu-lated figures via the GUI. These controllers and articulatedfigures can be mixed and matched as needed, which in itselfprovides a great deal of flexibility. The CSLB currently pro-vides the user with three different controllers. The manual

Figure 7. A screen capture of VROBO using the MCP con-troller to maneuver the Cobra 600 robot.

Figure 8. A screen capture of VROBO using the Joint Actuatorcontroller to articulate the ArticulatedLine2D.


control pendant (MCP) controller (see Figure 7) is the leastflexible of all of the available controllers. The only robotthat the MCP works with is the Cobra 600. The secondcontroller that is provided is the JointActuator (Figure 8),which can be used with all of the articulated figures. Thelast of the controllers is a programmatic interface (Figure 9)for specifying a sequence of commands for the robot to per-form, and it can be used with any of the articulated figures.Each of these controllers can be selected at anytime duringthe duration of the program.

On the right side of the VROBO interface is the RSLB,and it provides three articulated objects that can be controlledby the controllers. The first robot is the ArticulatedLines2Drobot, which is pictured on the right-hand side of Figure 8. Asimple multisegment line with joints assigned at each linesstarting point is drawn using Java2D APIs to implement theArticulatedLines2D robot.

The second robot, the wired figure in Figure 10, is theArticulatedCylinders3D. It is implemented using a series ofprimitive cylinder objects provided by the Java3D API. Simi-lar to the ArticulatedLines2D, the ArticulatedCylinders3Dobject places rotational joints at the starting point of each ofthe cylinders that make up the articulated robot. Finally, themost specialized of the articulated objects is the Cobra 600(right-hand side of Figures 7 and 9), a robot whose individuallinks are loaded from Alias Wavefront object files. This robotdemonstrates the ability of the Java3D API to load CAD datato be displayed within its scene graph architecture. For articu-lation, selected points are used to assign rotational and pris-matic joints based on the individual linkages operation on thereal-world robot [40]. The ability to select among these vari-ous controllers and articulated objects represents one way thatthe VROBO system provides flexibility to the user.

The ability to add additional controllers and articulatedobjects to the system using object-oriented programming(OOP) features is the second flexibility offered by the system.In this case, the system allows a user two Java interfaces fordefining new controllers and robots. In the case of con-trollers, the interface that is provided is the Controller inter-face (the Controller in Figure 11). The relationship betweenthe defined controllers and the Controller interface is pic-tured in Figure 11.

To define an additional controller for the system, the usermust create a new class that implements the controller. Byimplementing the Controller interface, the user is forced bythe Java API to implement each method in the interface,which then allows it to work within the framework of thesystem. It is up to the user to define what the result of theindividual interface calls will generate in their own imple-mentation [9]. The Controller interface currently only forcesimplementation of one method that is used to communicateto the controller when the robot is changing its state. Thisinterface would also be where the sensory communicationfrom the robots could be enforced when implemented. Figure12 depicts the Robot interface that allows the user of the sys-tem to define additional robots for the VROBO system. The

Figure 11. A class diagram showing the relationship betweenthe defined controllers and the Controller interface.

RoboController

RoboMCP

RoboJointActuator

+ robotChangedMessage ( ) : void

RoboCommandInterpreter

RoboRobot

+ getJointConstraints (int m_intJoint) : JointConstraints+ getJointValue (int m_intJoint) : float+ getNumberOfJoints ( ) : int+ getRobot ( ) : BranchGroup+ setJointValue (float p_dbtJointValue, int m_intJoint) : void

Robo

ArticulatedLines2D

Robo

Cobra600

Robo

ArticulatedCylinders3D

Figure 12. A class diagram showing the relationship betweenthe defined robots and the Robot interface.

figure also shows the relationship of the predefined robots totheir implemented interface. Similar to the Controller inter-face, the Robot interface is implemented by each robot thatis added to the system. As before, the user must implementeach method that is defined in the interface in their class def-inition for the class to work within the VROBO system. TheRobot interface provides several methods for communicatingits current state and constraints. The various functions of theRobot interface are discussed in more detail later in this sec-tion. In addition to implementing the required interfaces, theonly remaining task to be completed is adding the newly

implemented robots and controllers to the RSLB and CSLB,respectively.

The third aspect of the system that displays its flexibility isthe ability of two of the supplied controllers to dynamicallyconfigure and reconfigure themselves based on the robot thatis currently being controlled. This ability is possible due to theuse of interfaces for communications between robot and controller. The JointActuator is the first of two controllersthat provides this type of flexibility. The process that the JointActuator uses to configure itself consists of three methodcalls to the current robot.

The first method is the getNumberOfJoints method ofthe current robot. This lets the controller know the numberof joints that needs to be accommodated. It accomplishesthis by constructing sets of controls for each joint, so thevalue can be changed.

Next, the JointActuator calls the getJointConstraintsmethod for each joint to obtain a JointConstraints object foreach joint of the robot. The JointConstraints contains theminimum and maximum allowable joint values for the joint.In addition, it contains information for the preferred namingfor the joint. If the returned joint constraints are exceeded,the user will receive an error message.

The third and final method call that is executed is thegetJointValue for each of the joints, which returns the currentjoint value for that particular joint. This is used to initialize thecontroller with the current joint values. As a result, the robotprovides the driving configuration, and the controller assumesthe configuration of whichever robot is loaded. The results ofthis configuration procedure can be seen in Figures 8, 10, and13. The second controller, which will dynamically configureitself, is the CommandInterpreter controller. This allows theuser to write commands whose interpretation depends on therobot that is selected. For example, the HOME commandworks by querying the robot for the number of joints availableand then moves each of the corresponding joints to their zeropositions using a separate animation thread. Another commandis the SETSPEED command, which takes one argument tospecify the speed at which the animation thread updates theuser interface. Another example, the MOVE command sup-plies the ability to set each joint of the articulated figure. If theMOVE command is specified with less than the appropriateamount of joints the command will start at the beginning ofthe kinematic chain and assign joint values until there is nomore. In other words, if fewer joints are specified than areavailable to articulate, there is no error generated. However,the same is not true when the MOVE command exceeds thenumber of joints that are available. In this case, the systemCommandInterpreter generates an error message indicatingthat execution will not resume until the error is fixed. Query-ing the robots joint constraints before it is articulated to thedesired location performs one other syntax check. If the speci-fied value exceeds the maximum or minimum values, an errordialog box is displayed. Finally, in the case where a commandis specified that is not available, or an error in parsing a lineoccurs, an error dialog box is displayed.


Figure 14. A class diagram depicting the relationshipbetween the VROBO class and the applet class.

Figure 13. A screen capture of VROBO using the Joint Actua-tor controller to articulate the Cobra 600 robot.


The fourth and final flexible aspect of the system dealswith direct programmatic modifications to the underlyingsource code. This allows the user to not only add additionalrobots and controllers to the system but also enables modifica-tion of the GUI or underlying architecture. For example, theuser can add new menu commands to the system, add theability to control multiple robots, or add mouse control fea-tures to the articulated object. This final attribute may requirethe most effort from the user, but it also provides the greatestrange of flexibility.

ComplexitySystem complexity is one of the more difficult of the criteriato meet. In making a system more flexible and adding morenetworking support, the system itself becomes more complex.The method that was used to resolve the problem with com-plexity was a layered one. The different layers that were pro-vided were the Abstract Windowing Toolkit-based(AWT-based) GUI controllers, the off-line programminginterface, the extension of the Controller and Robot inter-faces, and the direct code modifications.

The first and least complex method for controlling thearticulated figures is the AWT-based controllers. The two thatare initially provided for use with the VROBO system are theMCP and the JointActuator. The MCP is specific for control-ling the Cobra 600 robot, but the JointActuator can be usedto control all of the articulated figures. In the case of both,different windowing components are used to display andarticulate the robots. The JointActuator, for instance, uses oneLabel class, two TextField classes, and two Button classes asthe interface for controlling each of the available joints. TheLabel is constructed by obtaining the preferred name of thejoint from its associated JointConstraints object. The twoTextField objects are constructed with the current joint valueof the articulated joint and the initial joint speed, respectively.Finally, the two Button objects are used to cycle through therange of values that the joint can assume. As the up and downbuttons are specified, the TextField that indicates the jointsnew value is displayed.

The off-line programming interface, the CommandInter-preter pictured in Figure 9, provides the next level of com-plexity. It does not require low-level programming interfaces,but instead supplies a high-level robot programming languagefor off-line programming of the articulated figure. The com-mand interpreter is implemented using a simple interpreterengine that indicates when an error in the specified code isfound. This layer still shields the user from the underlyingdetails of system implementation and keeps them in the con-straints of the supplied GUI.

The third layer of complexity requires the user to moveout of the structured GUI and add new controllers andarticulated objects programmatically. This layer requires theuser to be familiar with basic OO design and implementa-tion techniques. Even though this layer of the systemrequires knowledge of such things as interfaces, classes, andinheritance, it still makes the process of implementing new

controllers and articulated objects fairly easier. This is adirect result of using interfaces to impose constraints on theuser when developing the new extensions to the system.Since the main member variables of the VROBO class thatpoint to the current controller and robot are of type Con-troller and Robot respectively, classes must implement oneor the other to be used in the system. In addition, bydeclaring the newly defined class to implement one of theinterfaces, the Java environment will enforce strict author-ing of the methods contained in the interface [9].

Finally, the system provides the most complexity by allow-ing direct source code modification to all of the suppliedclasses. This requires the most technical abilities of the user.While the OO techniques discussed previously for specifyingnew controllers and robots follows a methodical procedure,the direct modification of other parts of the system requiremore indepth knowledge of OO methodologies and the coreJava and extension APIs. This layer offers the most technicalcomplexity needed by the user while at the same time provid-ing the greatest flexibility.

By layering the complexity of the system, it was possible toreduce technical complexity for individual users of the system.For instance, an inexperienced user can begin by using theAWT-based controllers, while a more advanced user couldbegin with the off-line programming interface. Furthermore,if advanced functionality is needed, the user can use the OOextension mechanisms to integrate new robots or controllersinto the system. The most advanced users can then move onto direct source code modifications if needed. This layeredapproach succeeds in reducing technical complexity by mak-ing the system complexity relative to the user and the type ofinterface that they start out with.

NetworkingThe final criterion is the ability of the system to take advantageof current networking capabilities. By implementing network-ing into the system, it allows the system to be more easily dis-tributed and readily available. The underlying Java API providesnetworking capabilities that can be exploited to provide teleop-eration of robots or the distributed computation of computa-tionally complex control algorithms, or provide downloadablerobotics environments that can be run in the users browser[14]. The current networking capability of the VROBO systemis provided by the use of the applet class by the Java API. Figure14 depicts the relationship between the VROBO classes andthe applet class, which shows, by way of inheritance, the exten-sion of the applet class by the VROBO class. Applets allow thecode for the system to be located on a remote machine andaccessed from a local machine using the HTTP protocol. Byembedding the applet in a Web page, the page can be down-loaded to any machine that contains a browser and a JRE plug-in [9]. Once it is downloaded and initialized, the code can beused just as easily as if it were directly executed on the remotecomputer. One last capability of the VROBO system is that ittakes advantage of Sun utility classes to support executions ofthe system that do not have to run in a browser [19].


Evaluation of VROBOVROBO meets most of the criteria considered under thenew system development. Because of freely available Javaapplication programming interfaces, it was possible to keepthe cost of system development to zero. In addition, thesystem provides the ability to use preconstructed controllersand articulated figures, create additional controllers andarticulated figures via extension of Java interfaces, and theability to do off-line programming of the robot with thebuilt-in language. These features of the system demonstratethe flexibility of the system. Furthermore, the complexityof the system is provided in a layered approach, with theuser only needing to manipulate the articulated figuresthrough the supplied controllers. The next layer of com-plexity is the use of the off-line programming capabilities ofthe system. The user who needs more functionality thanthese two provide can extend the system to create newcontrollers, robots, and work cells. The reliance on JavaAPIs provides the platform-independent capabilities of thesystem. This is possible because of the multiple platformsthat provide JREs, which the software system that wasdeveloped is capable of utilizing. Finally, increased net-working support is demonstrated through the use of appletsand from the possibilities allowed by the networking pack-ages available in the Java API. Since the system that wasdeveloped significantly reduces the barriers that impede thedevelopment of robotics programs, it is more likely forthese programs to be implemented and utilized to meet thecurrent and future needs of the robotics industry.

Future WorkThe first step towards the evaluation and improvement ofthis system is to introduce VROBO to a classroom envi-ronment. Several class projects have been designed specifi-cally for VROBO. These projects will be assigned tostudents as class homework/projects. Student feedback aswell as monitoring the performance of VROBO underrealistic constraints will help the improvement and fine-tuning of VROBO.

Several improvements are planned for the basic VROBOsystem. Three are discussed briefly here: incorporation of for-ward and inverse kinematics, interactions between articulatefigures and work cells, and manipulation of scene graph viagraphical user interface.

The calculation of the DH representations would be use-ful in improving the flexibility and usefulness of the system.The DH representation of articulate objects is useful in twoways. The first, which is referred to as forward kinematics, isthe ability to calculate the orientation and position of therobots end effector given the joint parameters of all thejoints. The second, called inverse kinematics, is the ability tospecify a position for the end effector in Cartesian coordi-nates and let the equations calculate the joint values. Specialsolutions can be derived for individual articulated objects, butthe DH representation has the benefit of application to arbi-trary configurations [31].

For the system to prove useful in simulations that aremore realistic, there must be a mechanism to allow interac-tions between the articulated figure and its surroundings.For example, a robot with a clamplike end effector shouldbe able to pick up and position a block or some otherobject to a different location within the scene. The Java3DAPI provides mechanisms for incorporating this functional-ity into programs, so it is not necessary for the developersto create their own collision-detection mechanisms. Byusing Java3Ds built-in collision detection it is possible toprovide a more realistic interaction of objects in the virtualenvironment [38].

Finally, the ability to create articulated figures via theGUI would make the system more flexible and keep theuser from having to get into the complexity associated withimplementing new articulated figures programmatically. Inaddition to being able to add geometric primitives, the sys-tem would also be able to add arbitrary geometry to thescene graph as well as imported CAD data, such as theCobra 600 that was used. Since the Java3D platform usesthe scene graph as its underlying model, it should ease thedevelopment of a GUI-based interface for manipulation [3].

KeywordsComputer-aided design, open source, work cell, simulation,modeling, object-oriented design, robotics, education, virtu-al environments.

References[1] E. Angel, Interactive Computer Graphics: A Top Down Approach with

OpenGL. Reading, PA: Addison Wesley Longman, 2000.[2] The availability of low-cost prototyping, Prime Faraday Technology

Watch, Nov. 2001 [Online]. Available: http://www.primetechnology-watch.org.uk/documents/low-cost-prototyping.pdf

[3] J.D. Bouvier, Getting Started with the Java API. Sun Microsystems, Inc.,Monterey, CA, 2001.

[4] R. Brooks, Humanoid robots, Commun. ACM, vol. 45, no. 3, pp.5963, Mar. 2002.

[5] D.P. Brutzman, A virtual world for an autonomous underwater vehicle,Ph.D. dissertation, Naval Post Graduate School, Dec. 1994 [Online]. Avail-able: http://www.stl.nps.navy.mil/~brutzman/dissertation/

[6] D.P. Brutzman,Teaching 3D modeling and simulation: Virtual kelp for-est case study, Ph.D. dissertation, Naval Postgraduate School, Monterey,CA, 2002 [Online]. Available: http://web.nps.navy.mil/ ~brutzman/kelp

[7] Chairmans report, Robotics Newsletter, no. 44, Dec. 2001/Jan. 2002.[Online]. Available: http://www.ifr.org/newsletter//news/news44.htm

[8] K. Dowling, What kinds of robotics simulators are there? RoboticsFrequently Asked Questions List, 23 Oct. 19962 Jul. 2002 [Online].Available: http://www.frc.ri.cmu.edu/robotics-faq/13.html

[9] D. Flanagan, Java in a Nutshell. Cambridge, MA: OReilly and Associ-ates, 1997.

[10] J.L. Fuller, Robotics: Introduction, Programming, and Projects. New Jersey:Prentice-Hall, 1999.

[11] Funding for U.S. Joint Robotics Program expected to rise, AerotechNews Review, 14 Jan. 200223 May 2002 [Online]. Available:http://www.aerotechnews.com/starc/2002/011402/robotics.html

[12] A.L. Gaspari and N. Lorenzo, State of the art of robotics in generalsurgery in Business Briefing: Global Healthcare, Univ. Rome, Italy,2002 [Online]. Available: http://www.wmrc.com/businessbriefing/pdf/healthcare2002/reference/18.pdf

[13] L. Greenwald, Tools for effective low-cost robotics, Drexel Univ.,


2001 [Online]. Available: http://plan.mcs.drexel.edu/papers/itcsl_springsymp01.pdf

[14] E.R. Harold, Java Network Programming. Cambridge, MA: OReilly andAssociates, 1997.

[15] A History of Educational Robotics, General Robotics Cooperation, May 28,2002 [Online]. Available: http://www.edurobot.com/stories/overview.html

[16] I. Horvath and Z. Rusak, Collaborative shape conceptualization invirtual design environments, Commun. ACM, vol. 44, no. 12, pp.5963, Dec. 2001.

[17] IPA delivers automated system to debone pork loin, Robotics Newslet-ter, no. 44. Dec. 2001/Jan. 2002 [Online]. Available: http://www.ifr.org/newsletter//news/news44.htm

[18] The Java 3D API collateral: Technical white paper, Sun Microsys-tems [Online]. Available: http://java.sun.com/products/java-media/3D/collateral/j3d_api/ j3d_api_3.html

[19] Java 3D API documentation, Sun Microsystems [Online]. Available:http://www.isi.edu/~amarshal/Java3DUtils/com/sun/j3d/utils/applet/MainFrame.html

[20] O. Khatib, O. Brock, K-S Chang, F.s Conti, D. Ruspini, and L. Sentis,Robotics and interactive simulation, Commun. ACM. vol. 45, no. 3,pp. 4651, Mar. 2002.

[21] C. Kitts, An aggressive robotics devlopment program for integrativeundergraduate education, Santa Clara Univ., 2002 [Online]. Available:http://rsl.engr.scu.edu/NewWeb/Publications/2002/02-An_Aggres-sive_Robotics.pdf

[22] J. Kopena and L. Greenwald, On achieving educational and researchgoals with small, low-cost robot platforms, Drexel Univ. [Online].Available: http://plan.mcs.drexel.edu/papers/itcsl_robotedu_ieeera02. pdf

[23] K.W. Lau, H.K. Tan, and B.T. Erwin, Creative learning in schoolwith LEGO programmable robotics products, 1999 [Online]. Avail-able: http://www.idi.ntnu.no/~petrovic/lego/creative.html

[24] Learn more: History, Robotics Res. Group, Univ. Texas at Austin,Austin, TX. May 2002 [Online]. Available: http://www.robotics.utexas.edu/rrg/ learn_more/history/

[25] J. Lentz, R.A. Maulucci, and R.H. Eckhouse. Real-time devices atpractical prices: Low cost laboratory projects, 2003 [Online]. Available:http://www.cs.umb.edu/~eckhouse/RTpaper.pdf

[26] T. Lough and C. Fett, Robotics education: Teacher observations ofthe effect on student attitudes and learning, Ties Mag., June 2002[Online]. Available: http://www.tiesmagazine.org/archives/jun_2002/pdf/jun_2002_RoboticsEd.pdf

[27] Medical: hexapod assistant in surgery, Robotics Newsletter, no. 41,Mar. 2001 [Online]. Available: http://www.ifr. org/newsletter//news/news41.htm

[28] C. Merriam, Comp.robotics FAQ, Dec. 2002 [Online]. Available:http://www.truegift.com/robots/

[29] O. Michel, Khepera Simulator version 2.0 User Manual, Univ. Nice,France, Jan. 2003.

[30] M. Minansi, Linux for Windows NT/2000 Administrators. San Francisco,CA: SYBEX, 2000.

[31] S.B. Niku Introduction to Robotics: Analysis, Systems, Applications. Engle-wood Cliffs, NJ: Prentice Hall, 2001.

[32] R.S. Pressman, Software Engineering: A Practioners Approach. New York:McGraw-Hill, 1997.

[33] Robots play a role as Europe changes to euro, Robotics Newsletter, no.44, Dec. 2001/Jan. 2002 [Online]. Available: http://www.ifr.org/newsletter//news/news44.htm

[34] RoboWorks frequently asked questions, Newtonium, Oct. 2002[Online]. Available: http://www.newtonium.com/public_html/Products/RoboWorks/RoboWorks_faq.htm

[35] RoboWorks support, Newtonium, Sept. 2002 [Online]. Available:http://www.newtonium.com/public_html/Products/RoboWorks/RoboWorks_support.htm

[36] E. Roos, A. Behrens, and S. Anton, RDSRealistic dynamic simula-tion of robots, Jan. 22 2003 [Online]. Available: http://ourworld.compuserve.com/homepages/stefan_anton/rds2.htm

[37] M. Rosenblatt and H. Choset, Designing and implementing hands-

on robotics labs, IEEE Intell.Syst., vol. 15, no. 6, pp. 3239,Nov.Dec. 2000.

[38] N. Smith, C. Egert, E. Cuddihy, and D. Walters, Implementing virtu-al robots in Java3D using a subsumption architecture, SUNY atBuffalo, New York, Nov. 1999 [Online]. Available: http://www.cs.buf-falo. edu/~egert/papers/webnet99ns.pdf

[39] Solid growth for robotics in the year 2000, Robotics Newsletter,no. 41, Mar. 2001 [Online]. Available: http://www. ifr.org/newsletter//news/news41.htm

[40] H.A. Sowizral and M.F. Deering, The Java 3D API and virtual reality,IEEE Comput. Graph. Appl., vol. 19, no. 3, pp. 1215, MayJune 1999.

[41] U.N.: Robots could lghten load of household chores, Yahoo! News,Oct. 3, 2002 [Online]. Available: http://abcnews.go.com/wire/SciTech/reuters20021003_63.html

[42] P. van der Smagt, Simderella: A robot simulator for neuro-controllerdesign, Dept. of Comput. Syst., University of Amsterdam, Amsterdam,The Netherlands, Jan. 1994 [Online]. Available:http://www.robotic.dlr.de/Smagt/papers/ Sma94b.ps.gz

[43] Simderella 2.1 [Online]. Available: http://www.robotic.dlr.de/Smagt/software/simderella/software/simderella.2.1.tar.gz

[44] M.M. Veloso, Entertainment robotics, Commun. ACM, vol. 45, no.3, pp. 5963, Mar. 2002.

[45] What can Java technology do? in The Java Tutorial, Sun Microsystems,2003, Feb. 2, 2003 [Online]. Available:http://java.sun.com/docs/books/tutorial/getStarted/intro/cando.html

[46] M. Williams, Robots are cute, but can you put them to work? IDGNews Service, Jul. 58 2002 [Online]. Available: http://www.pcworld.com/news/article/0,aid,102429,00.asp

Georgios A. Demetriou received his Ph.D. in computer sci-ence and his M.S. in computer engineering from the Centerfor Advanced Computer Studies at the University of Louisianaat Lafayette in 1994 and 1998, respectively. Since August2004, he has been with the Computer Engineering Depart-ment of Purdue University, Fort Wayne, Indiana. Before that,he was with the Computer Science Department of the Uni-versity of Southern Mississippi-Gulf Coast, Long Beach,where he served as the director of the Robotics and GraphicsLaboratory and the coordinator for the computer science grad-uate and undergraduate programs. His research interests includemobile robotics systems, intelligent systems, computer graphics,visualization, and virtual reality.

Allan H. Lambert is a Ph.D. student at the University ofSouthern Mississippi. He received his M.S. and B.S. in com-puter science from the Computer Science Department ofthe University of Mississippi, Long Beach in 2003 and 1998,respectively. Since 1998, he has been working with theNaval Oceanographic Office, Stennis Space Center as acomputer scientist and software engineer. His research inter-ests include computer graphics, robotics, operating systems,programming languages, image processing, networkingtechnologies, systems hardware and software, and scientificvisualization.

Address for Correspondence: Georgios Demetriou, 5429 RiverRun Trail, Fort Wayne, IN 46825 USA. Phone +1 260 4823182. E-mail: [email protected].

Date post:	01-Oct-2015
Category:	Documents
Upload:	sfaizullahbasha
View:	220 times
Download:	2 times

01577044

Documents