Philosophy of GIMnet Software Modularity and Reusability through Service Oriented Architecture and Hardware Abstraction
Introduction GIMnet MaCI GIMnet = tcphub + GIMI Enables communication between distributed modules Designed for: 1) to enable remote communication with difficult network topologies 2) to provide minimum-effort API for the users 3) to provide basic tools for service based architecture Machine Control Interface is a library for building robot control software based on modular decomposition of the software into functional pieces. Reusable software components for robotic research Define unified hardware abstraction layer (HAL) Provide implementation guidelines for the developers
GIMnet tcphub GIMI Separate program that all Library and client side API clients connects to Handles and hides all network Clients register with name and specific implementations get internal id Service-based messaging Distributes incoming packets Public interface with service based on name/id ID (provided or accepted) Maintains distributed name Service discovery server ID based incoming Network can consist of message queues multiple hubs
Service Is an application specific, system wide defined data type, that a module provides or accepts GIMI defines the service with an ID. Service discovery reveals all services on all modules Subscribe / send to subscribers allows event based data sending
GIMnet in action The hub network allows optimization of data transfer in network GIMI supports building independent processes with clearly defined input/output messages GIMnet has been used in several robot control related applications and is proven to be well functioning library Open Source release available http://gim.tkk.fi/gimnet
MaCI MaCI is a library for writing robot control software GIMnet based communication (defines application for GIMnet) MaCI is "developer driven" in the sense, that it tries to simplify the architecture so that anyone can write control software for a robot Service based, modular, reusable and of course generic (not yet adaptive nor ubiquitous)
MaCI Structure Library consists of Drivers (MaCI independent, hw-specific), Interfaces and Modules Interface specifies the service and acts as an hardware abstraction layer Interface always has Client (service consumer), Server (provider) and data type definitions. Module is an implementation, that uses some driver and provides some (or many) interfaces
HAL and Interfaces Hardware abstraction hides the differences in hardware and provides a generic interface to it. Task of a MaCI interface is to hide the hardware, that is, from software side of view all the machines are the same Server interface provides the access and client interface consumes it. Communication between client and server is done through GIMnet (encapsulates GIMI) MaCI provides own service discovery methods, which are based on Groups, Interface types and interface instances Client applications remains unchanged if some server instance is changed!
MaCI Example - J2B2
MaCI Example - FSRSim
Client Side Interface definition enables development of generic client components (up to some point) Gimbo framework allows development of GUI components in a similar manner to MACI Most of the interfaces has a client side GUI component implemented Video
Conclusion Module decomposition frees the developer from other software development (do as you please as long as you implement the interface properly) It enables the development of generic client apps, which can be used with various platforms It naturally supports distributed computing Drawbacks: some overhead, no shared memory between modules Challenges: How far can we abstract the machines (with various tools, shapes etc) In future we hopefully see self-organizing-adaptive-worksites that uses MaCI