PSI: System Architecture

In my first post, I presented the requirements and features I hope to include on PSI, my component-based system for robotics. In this post, I will show how I'm organizing the code and files. Here I'll present just an introduction to the architecture of the system and in next posts I'll show all the details of each part.

My first choice in architecture is to keep some global variables working as a registry for parts of the system, this kind of solution for communication among parts is very common in games and other complex systems, see this tutorial to see other perspective over registries. I keep these globals variables as interfaces to theirs respective packages, which are divided into 3 packages:

• core: the core package stores: i) the component manager, which is a kind of list of components; ii) the components definition and properties; iii) other structures such map grids.
• engine: the engine package is the interface to OpenGL, I'll keep all access to the graphic card into it, such the render batches, camera control and display control.
• gui: this package stores the GUI system, with windows, widgets, and dialogs.

These packages are encapsulated into different folders, so that, I have the following directories:

    psi/
        core/
        engine/
        gui/
        resources/
        tools/

The resources folder stores the static resources of the project, such as images and icons, while tools folder is an auxiliary package with utilities for all other packages.

Back to the global variables, I choose to create a class App which will control all the system. The app global variable is the main object of the system is responsible for either control the system execution and acting as an interface among all packages, thus, the cited packages do not call directly each other. The classes Graphics, Manager, and MainWindow are the interface to the engine, core, and gui packages, respectively. I encapsulated these classes in different files and each one in its respectively folders. The current file structure of the project is as follow:

    psi/
        core/
            manager.py
            (...)
        engine/
            graphics.py
            (...)
        gui/
            main_window.py
            (...)

        app.py
        (...)

and the complete list of global variables is:

    app
    graphics
    window
    manager
    log

Notice the addition of log, this variable of class Log, is the interface to the debug, info, error, and warning messages. When the user clicks on the button to run the simulation, the app sends an info message to the log and it directs the message to the status bar, log files and/or any other kind of structure to receive these messages. And finally, the following figure shows the dependence among global variables:

This is the main points on the architecture. The next posts I will describe each package presented here in details.

Diary of my new project, PSI

I started a new project a few day ago and I called it "PSI", a component-based system for my experiments and developments in robotics. I was working on the idea of this system for some time, but only on this vacation from Ph.D I got time to actually do something. My motivation for this project is to create an architecture based on the use of independent, pluggable, and reusable components, in a way that I could create a component (e.g., a grid mapper) and use it in several experiments without the need to copy and paste the code into several different projects or creating a chaotic dependence among projects. I'll use this blog as a development diary of PSI, starting from now. In this first post, I describe the specifications of the system and what I'm planning to do.

Platforms: I've been using both Linux and Windows, at work and home, respectively. Thus, it is mandatory that PSI works, at least, on both platforms.

Language: Python, of course. It is my main language and my natural choice. Moreover, Python provides an extraordinary structure to multiplatform systems, helping me to fulfill the platform requirement. This choice of language brings some interesting performance concerns, that I'm working on since the beginning of the development.

Dependencies: wxPython, PyOpenGL, and NumPy. I choose wxPython to GUI programming due to its support to OpenGL canvas. I considered Qt as a probably alternative, but it was a real pain in the ass for me in previous experiences. I also choose to work directly and purely with PyOpenGL in order to use some complex features of OpenGL in a way that I can control the performance, i.e., I know where PSI have inefficient code. Finally, NumPy is a mandatory library to any scientific program.

Features: I've draw some main features to PSI, but it doesn't mean that this project will be restrict to these ones. I think that a very basic system must comprises the following functionalities:

• Component-based system: the system must provide an interface to creation of components and a mechanism to install new ones. Each component must be independent, reusable and pluggable, being responsible by its own execution, but, at the same time, the system must allows the collaboration between components, e.g., a mapper component depends on the readings of a robot component. PSI must allow this dependence and provide a mechanism to connect both components. The user must be able to add and remove components to the project, and edit their properties.
• Project handling: PSI must be able to create, save and load projects. A project comprises the current configuration of the system, including: all components added to the project; the properties of all components; the state of variables that concerns to the project.
• Simulation environment: PSI must provides a simulation environment, in which the components actually work. It means that, on the default state of the system, components don't really run, they just draw some basic information on the screen; but when use user start the simulation, a robot component can connect to a mobile robot and send and receive information, a mapper component can actually construct a map based on the robot information about the environment, etc. PSI must be able to RUN, PAUSE, RESUME and STOP a simulation.

A component must have a role in PSI. The role of a component will define its priority and gives an idea of what the component do. At first, I'm thinking in provide three roles: ROBOT, MAPPER, and CONTROLLER. A ROBOT component represents some kind of robot, let's say, a mobile robot. Thus we can assume that this component will receive the information of the robot's sensors and send the information about acting the it. A MAPPER component represents some kind of map, e.g., a metric or topological map; a mapper usually uses the information of sensor collected by a ROBOT component and create a map based on it. Finally, a CONTROLLER component is responsible to actually say what a robot must do, e.g., a manual controller receives the keyboard commands and order a ROBOT component to go forward or turn itself. These three roles completes each other, creating and execution cycle:

The execution cycle of components

A component is not limited to a single role, it can implement two to all roles, creating a complex component. A potential field component can be used as an example of a composed component, which can perform the role of MAPPER and CONTROLLER.

Visual: my idea is to provide an interface similar to some 3d editors and game engines, such as 3D max or unity 3D. The following image is a draft of what I'm thinking that the system must looks like. The main panel of PSI is, obviously, an OpenGL canvas showing what matters in the project, this panel draws all visible objects, like robots and maps. In this canvas, the user can move the camera, apply zoom in or zoom out, or yet show a overlay grid. I also want a sidebar with two panels, the top one with a list of all components included on the project and the bottom panel with the properties of the selected component. I also included a status bar and a menu bar.

Draft of the screen

Well, that is it for now, I think it is enough information for an introduction. In this post I presented the features, specifications and requirements I desire to PSI. Next post, I'll present how I am organizing the architecture of PSI, the main classes and how they will communicate to each other.

Unity3D main screen

3D Max main screen