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