The rapid evolution in Robotics, Internet-of-Things, Cloud and Software Engineering sciences, has lowered the complexity of developing and delivering interconnected Cyber-Physical systems. It is a fact that traditional robotic applications were monolithic, meaning that they were executed in confined systems (either a single robot or a group of robots in a local area network). This view of robotic systems has changed with the introduction of the IoT paradigm. IoT builds upon the network of physical objects, vehicles, buildings and other items that are enabled with electronics, software, sensors and network connectivity, this way being able to collect and exchange data. One could argue that nowadays robots can be seen as "Things" in the IoT concept, since they essentially are complex devices collecting sensory data from their environment and offering services. The coupling of robotics and IoT could offer additional capabilities, such as interconnectivity between robots, smart devices and sensor modules, or the ability to utilize external web services, such as robotics algorithms executing in high-performance cloud infrastructures. This way, more sophisticated cyber-physical applications may be designed, built and deployed.

This webpage presents a complete application that incorporates Robotic, IoT and CPS concepts, along with Web-based components and Model-driven Engineering principles, so as to implement a modern remake of the famous Pacman game. This application was developed as a competition platform for the ECESCON 11 (Electrical and Computer Engineering Student Conference of Greece) where teams of undergraduate students created strategies for the Pacman and Ghost robots via a graphical language and battled their way into the finals.

In order for a RoboPacman battle between two teams to be performed, two strategies for each team are required, one for Pacman and one for Ghost. Therefore, each game consists of two rounds, during which the roles are swapped. Each battle is performed on a tableau that has the form of a grid, either using real robots or in simulation, which includes a set of randomly interconnected nodes (see figure below). Regarding the motion of the robots, a) they can move from one node to a neighboring one if the robot’s orientation is towards the target node or b) make a stationary rotation of 90, -90 or 180 degrees.

On some of the tableau’s nodes, points and bonuses exist. Specifically, N nodes with cards of variable points exist, which only Pacman can capture by visiting the specific nodes. On the other hand, M bonuses exist, in nodes different than the point cards, which can be gathered by both robots. Bonuses can be used at any time, giving perks to the respected robot, including a) opponent immobilization for a number of moves, b) points multiplication according to the number of bonuses used or c) sudden death (game termination), where Pacman keeps its points and the Ghost gathers 25% of Pacman’s points.

In order for a round to end, one of the following conditions must occur: a) Pacman has gathered all the available point cards, in which case Pacman gains the totality of points and Ghost gets none, b) Ghost captures Pacman when they exist in the same node, in which case Pacman keeps the aggregated points thus far, but the Ghost gains points according to the time elapsed (the quicker the capture, the more the points) and c) when a predefined time limit has been reached, in which case Pacman maintains the aggregated points and Ghost gets none. Winner of the battle is the team with the highest sum of points, gathered from the two rounds.

Looking into the Ghost in the machine

RoboPacman is composed out of several components, namely the Orchestrator, the Simulator, the Message Broker, the Pacman and Ghost robots, the Web Application and the Application Development Environment.

Communication between the aforementioned distinct components is achieved via PubSub and RPC communication patterns. The RabbitMQ Message Broker acts as the communication middleware and implements the AMQP protocol. Pacman and Ghost applications are generated via the App Development Environment, an Eclipse-based DSL implementation. The Orchestrator receives the Pacman and Ghost applications and the game starts!

Furthermore, the Simulator connects to the system only if a simulated execution context is selected. In case of real execution environment is selected, the Simulator component is detached, in order to avoid duplication of resources provided by the real robots. Due to the resource-oriented and device-agnostic design approach, switching between simulated and real-world execution is performed seamlessly.

In order to minimize the required expertise to create new strategies for Ms Pacman and the Robotic Ghost, as well as drastically decrease the overall effort and errors, our framework includes a Graphical User Interface (GUI), which is designed and built according to Model Driven Engineering (MDE) techniques. The following figure illustrates a Ms Pacman Strategy depicted as a model in MDE terms. As evident, several game concepts that comprise the graphical notation to formulate strategies for the game exist. Some of these concepts model robot states (e.g. “Go for bonus", “Multiply Points" etc.), whilst others model transitions from one state to another and are illustrated as arrows that connect the states.

Orchestrator comprises several functionalities that are core to the RoboPacman game. The first concerns the board/tableau generation. In order for the game to be replayable, the Orchestrator node allows for generation of different boards, based on predefined parameters, such as width, height, node density, maximum node neighbors, node’s maximum neighbourhood density and others. Concerning the elements placement in the board, Pacman and Ghost are always placed at the top left and bottom right corners, respectively, and points and bonuses are automatically placed, so as to be symmetrical regarding the two robots.

Since one of the pains in developing robotic applications is the lack of real robots in order to adequately perform tests, a simulator for the RoboPacman was created. Essentially, the simulator replaces the real world environment and the robots, thus it exposes the exact same interfaces (services and pub/sub channels) as the real robots, in order for the applications/strategies to seamlessly operate without having knowledge of whether the robots are real or simulated.

Simulator, was developed using the pygame library and visualizes the robots, their paths, the points and bonuses and handles the virtual robot’s movement. Specifically, when the Orchestrator generates a goal and a path for a robot, it sends only the next motion command, thus the (real or virtual) robots are unaware of their exact position in the tableau. In the virtual robot’s case, the Simulator gets the robot’s motion, executes it and finally informs the Orchestrator that the robot has finished the last motion operation, so as to calculate the next one.

During a game, a Web UI is used from which the battle management and inspection is performed. The User Interface was developed using Web technologies and it is based on a modern Single Page Application architecture using the React library.

The overall architecture was initially designed to meet several requirements, one of which is the flexibility regarding deployment schema. Decomposition of the architecture into discrete interoperable subsystems (Orchestrator, Simulator, Message Broker, Robotic Platforms etc.), allowed for a distributed, container-based, deployment schema.

Due to soft real-time communication constraints of the RoboPacman game, the Orchestrator, Simulator, Web App and Message Broker subsystems were deployed on a Raspberry PI 3 Model B+, in the same LAN with Pacman and Ghost robots and device discovery is achieved via the Multicast DNS (mDNS) protocol.

The RoboPacman Game is distributed in nature. It requires communication between several components, such as the Orchestrator, the Pacman and Ghost robots. For example, motion and immobilization commands are being sent from the Orchestrator via the RabbitMQ message broker. The robot agent for each robot type (Pacman or Ghost) is identical, implemented in ROS and bridges various services and pubsub topics to the message broker. We treat robots as Things in an IoT application, streaming sensor data and effector commands, such as motion. In this chapter we discuss on the hardware architecture and software agent of the robots, as long as on the connectivity with the rest of the system, via a DSL implementation.

The robot’s central computational unit is a Raspberry Pi 3 Model B+. Base motion is achieved via four DC motors, each connected to a wheel of the 4WD mobile platform. Furthermore, motors are driven in pairs (left/right side) via a PWM controlled DC motor controller. For approximate estimation of the robot’s odometry, wheel encoders are integrated on a motor of each side.

In order to perform line following and line and node detection, a line following (LF) sensor is connected to the central unit. The line following sensor is a linear array of IR sensors, which can detect existence of a black line by measuring reflectance of the IR beam. Also, a Neopixel RGB Led Array is used for visual indication of the robot’s states. Power management consists of two LiIon batteries, one for powering the the central unit and its peripherals and one for the DC motor control circuit. This dissociation is being done in order to not have noise interference between the motors and the central unit. For battery voltage regulation a DC-DC converter connects each battery with each unit. The level of each battery is measured via an ADC (Analog-to-Digital Converter) and send to the central unit via an SPI (Serial Peripheral Interface) port.

The motion of the robots is based on following a straight black line, until a black square box (which represents a node) has been reached. From there, the robot can continue straight or make a rotation, left or right. Linear (y axis) and angular (around z axis) velocities (Twist) are defined for the robot and are translated to rpm (revolutions-per-minute) values via a 4-wheel Skid-Steer kinematic model solver. Furthermore, a motion control software component has been developed to meet the necessities of driving the motors, reading the line-following sensor values and controlling the overall kinematic behavior of the robot.

The core component of robot’s software stack is the so-called Robot Agent, which implements all the necessary functionalities of the robot. Such functionalities include communication with peripheral devices, motion control and state management.

Robot Agent is composed out of several components, namely the Motion Controller, the Motion State Agent, the Node Detector, the SkidSteer Controller and the State Indicator. A brief description of each one of the aforementioned components is given below:

• Motion State Agent, which handles the current state and the valid transitions
• Node Detector, which detects robot’s arrival at a node
• State indicator, which is responsible for visualization of robot’s state via an RGB led array
• Skid Steer Controller, which Implements a kinematic solver of 4WD Skid Steer mobile platform, converting input twist velocities to RPM values

The RoboPacman Game is distributed in nature. It requires communication between several components, such as the Orchestrator, the Pacman and Ghost robots. For example, motion and immobilization commands are being sent from the Orchestrator via the RabbitMQ message broker. The robot agent for each robot type (Pacman or Ghost) is identical, implemented in ROS and bridges various services and pubsub topics to the message broker. We treat robots as Things in an IoT application, streaming sensor data and effector commands, such as motion. In this chapter we discuss on the hardware architecture and software agent of the robots, as long as on the connectivity with the rest of the system, via a DSL implementation.