I have just drafted a rather high-level overview (v2) of the system as I see it and wanted to share it with you. If we agree that this makes sense, I will be able to formalize the specification and requirements.
Don't worry if it does not make sense, it is just a draft and I will try to explain it during the meeting on Wednesday.
System Design
Even though software design might not seem as a very important aspect at this stage of the development, we believe it is vital for the success of our robot. Having a clear idea about the specifications, requirements and assumptions about the project will guarantee that every member knows how their work fits in into the bigger picture, not to mention it encourages us to think about the integration phase from the very beginning.
One of the challenges that we had to face during the early days was the separation of the system into small and independent components; each of which could be then managed and developed by a different team. Fortunately, we didn't have any problems with that as the natural division, according to different responsibilities, was not only the first to cross our minds but also the most sensible one. Hence the system will comprise following subsystems.
- vision - processing the video stream and extracting the data about the state of the world
- planning - processing the data received from the vision component and creating a winning strategy
- simulation - simulating the real world and robots
- visualization - the "dashboard" of our system, which will display data received from vision and planning
- robotcontroller - the communication and low level interface with the robot
Communication between components
One of the obvious drawbacks of having a multi-component system is the necessity of their integration and communication among them. We have considered various methods of doing that and the findings are presented below.
Internet Communication Engine
Encouraged by the success of last year group with the Internet Communication Engine, or Ice, this was the first approach we looked at. Ice is a 3rd party library facilitating an inter-process communication with the purpose of simplifying development of distributed applications. It allows processes to publish data to a channel, or topic, and then the data is distributed by the Ice framework to all the receivers. In other words, Ice provides the functionality of the Observer pattern but on a much wider, inter-process, scale. One of the advantages of this method is the system that is modular and all the systems are independent of each other. Additionally, because the Ice enforces programmer to precisely specify the format of the data that will be published to the topic, it also enforces the "design by contract" methodology resulting in a loosely coupled system. This means that we could implement various components in different programming languages or deploy each of them to a different machine. However, because Ice adds also an unnecessary complexity to our system we agreed that although it might be a good idea to have a modular system, we can achieve it using different methods.
Monolithic System
The other approach that was briefly considered by our team was a system that would be completely monolithic, i.e. the whole system would be part of one process running on one machine. The first benefit that comes to mind is the lack of any sophisticated communication; the components could just pass messages to each other. Tempting as it is, we decided not to proceed with this design, with our rationale being that the vision system will need as much CPU time as it is only possible and the other parts cannot interfere.
Socket based communication
The last approach that combines the ideas of the previous two is a system that will follow the basic server-client architecture. Since we decided the vision cannot be obstructed by any other component, it will be running on a separate computer and the remaining functionality will be provided by a separate process running on a different computer. This way we can get the best of the two worlds: the resources of a whole machine just for the processing of the camera feed and the lack of any needless complexity.
Conclusion
Even though all 3 methods have their pros and cons, we have chosen the Socket based communication because it meets our requirements and does not introduce any problems. However, should we find out that the Socket based communication is insufficient for our needs or it introduces performance issues, we will be able to quite easily change it to any other form of communication.
