Universitšt Bielefeld - Technische Fakultšt - Neuroinformatik
next up previous
Next: References Up: SORMA: Interoperating Distributed Robotics Previous: SORMA Concepts

Experiences with SORMA

 { The first implementation example was a checkers player system, developed with a team of students. Due to the limited space, we must refer any details to the description in [11]. In this hybrid application the distributed object infrastructure was in the foreground. Complying to the international rule of checkers, a robot manipulator (PUMA), equipped with a hydraulic dextrous hand (TUM) and supported by an image processing system, is empowered to play this board game against a human player. The task was split in several service components grouped to six main processes running on two (or 3,4) Unix workstations (see Fig.1). The GUI enhanced symbolic player process interoperates all other hardware components by SO requests, which themselves call other daemons for service (e.g. the token transfer SO carry involves the robot, hand, vision etc.). During operation all daemons can be interactively inspected.

Here the real-time demands were soft (best effort) - and the achieved SORMA interprocess communication times are more than sufficient to meet the desired inter-activeness, including speech generation (between 1.5 and 4.0 tex2html_wrap_inline992 s mean time for request plus reply communication with a daemon; across our computer park).

The real-time capabilities were demonstrated in a 3D robot tracking application, combining vision and force senses and a rapid learning PSOM network [11]. This hard real-time task required strict deadlines with zero time fault tolerance. Thanks to the RCCL/RCI package we conveniently achieve synchronous robot control employing a standard SUN SparcStation [6, 10]. One standard SORMA client-server CO asynchronously connected the vision analysis and the robot host. All other communication used the SORMA time-optimal intraprocess invocation (about tex2html_wrap_inline994 s elapsed call overhead time) and further interprocess communications services via shared memory (about tex2html_wrap_inline996 s).

In contrast to other robot control software frameworks like Chimera [9] or Psyche [7], SORMA does not attempt to be a real-time operating system (OS) itself (e.g. no scheduler). Chimera and Smart [1] focus on multi-processor VME-bus systems which are hosted by a Unix workstation. SORMA offers to interoperate also software components served by high-performance workstations across the network - using the standard interface.

Currently we care about full portability and interoperability across the following operating systems: Aix, Iris4d, Irix5, Irix6, NextStep, OSF1, Linux, Solaris, and SunOS (which gives also the reason to still hesitate about relying on P-threads implementations, which are yet not available on all platforms above).

The central interest is to provide a framework for effective building of components and rapid assembly to distributed solutions. It is interesting to note, that despite the fact that SORMA was independently developed, it shares many ideas formulated in large industrial initiatives to build intelligent distributed object infrastructures, in particular CORBA by OMG [8]. Actually, the ``Common Object Request Broker Architecture'' recently inspired the revised terminology within SORMA. Instead of CORBA's goal of serving many vendors' interests with multiple protocols, we are working with complex robotics hardware, requiring specially adapted solutions. Here SORMA emphasizes in particular interactive, built-in exploration and usage support, robustness, and real-time efficiency.

Furthermore, SORMA supports early resource sharing and re-use of components: providing better services will invite to re-usage, which gives incentive for better services - thus a positive feedback loop can emerge. We believe, this helps to improve the service's economy.

next up previous
Next: References Up: SORMA: Interoperating Distributed Robotics Previous: SORMA Concepts

Joerg Walter