Philosophy of GIMnet

Transcription

1 Philosophy of GIMnet Software Modularity and Reusability through Service Oriented Architecture and Hardware Abstraction

2 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

3 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

4 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

5 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

6 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)

7 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

8 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!

9 MaCI Example - J2B2

10 MaCI Example - FSRSim

11 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

12 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