# Technology Enhanced Learning Using Humanoid Robots
## 4 The Proposed Architectural Design
### Server-Side-Support Component (SSSC)  
The second part a new module might consist of is the server-side program, developed with any back-end technology, containing the support software (e.g., heavy computation, or storage capabilities), and exposing the REST APIs. The back-end is hosted either in the cloud or in a dedicated server. The Python program of the CC needs to know the IP address of the cloud system or the server where the back-end of the program resides to be able to call its REST APIs and exploit its capabilities. The reader notices that this component is not essential as a new module may consist of just the CC when there are not heavy computations to be executed. As an example, a simple Bingo game may be developed as Python code as a CC only and uploaded into the robot. In such a case, there would not be an external program in charge of any specific computation.  
To note, each newly created module can run independently from each other and it is possible to include as many modules as desired. Moreover, when different CCs of multiple modules are loaded into the robot, a priority for each module must be assigned so that when the user speaks to the robot, one module at a time may be activated. The four modules presented in this paper and that are shown in Figure 1 have the following priority importance: Semantic Sentiment Analysis Module, Object Detection, Action Command Ontology Module, and Conversational Agent Module. This means that when the robot gets some text from the user, it checks in that order if one of those modules can be triggered. Section 4.7 will illustrate how the modules' priorities are set. Only one module can be triggered for the underlying text.  
This scheme is scalable and flexible as:  
* The Python programs directly loaded into the robot from Choregraphe are usually very light, and we can upload a very high number of them before the physical space of the robot ends;
* There are no limits to the number of SSSCs we can host/call into/from the cloud or a given server;
* The same SSSC can be uploaded in several robots and in such a case the robots may either lie within the same local area network or on a different network while still being able to share the same program running on a server or cloud system. As an example, in Figure 1 there is another robot connected to the same LAN, with the Object Detection CC loaded and whose Object Detection SSSC is shared with the existing one.  
The robotic platform is only responsible for interaction with humans. Such an interaction evolves according to the underlying module that is being triggered and by what each SSSC returns depending on the user's action. Basically, the robot itself is a mere interface that interacts with humans through its sensors. The cognitive skills, learning skills, and any other smart capabilities are provided by the SSSC where NLP, Semantic Web, Computer Vision, AI, and other innovative research applications may be executed providing a more and more effective human-computer interaction.  
Noticeably, the robot does not perform any action if there are no loaded modules. As soon as one module is loaded, the robot starts performing some action accordingly. When the robot is shut down and boots again, the loaded modules are still available in the robot. The programmer has to explicitly disable them (at least the related CC using the Choregraphe framework) to unload them from the robot.