Software Architecture
rapyuta.io recommends a modularized software architecture design. This implies responsibilities are divided across various packages because a modularised software is easy to maintain, share, and scale.
Turtlesim is composed of four packages. They are:
- User Interface
An interactive, web-based user interface for visualizing the state of the Turtles and for passing control commands to the Turtles. - Command Center
A central node for registering Turtles, as well as a router for passing commands and telemetry messages between the User Interface and the Turtles. - Turtle
A package that emulates the behavior of an autonomous ground vehicle with non-holonomic constraints and two distance sensors through the Simulator. There can be multiple instances of this component, each representing a single robot entity. - Simulator
A package that simulates the physical dynamics of 2D robots and their sensors.
The below diagram illustrates how these packages are interconnected. The arrows represent the direction of information flow between the package.
In ROS terminology, each package (apart from the User Interface) is a node. The following diagram illustrates the information that is passed between the nodes.
Each of these nodes (including the User Interface) will be deployed as a package on rapyuta.io. These packages will pass the same information to one another, except that they will do so in the cloud.
Interfaces
Defining interfaces for a package is one of the critical steps during package creation. A package’s interface determines how it may interact with other packages.
You can define component-level interfaces such as endpoints, ROS topics (publisher), ROS services and/or ROS actions. Furthermore, you can define package-level interfaces such as ROS topics (subscriber), ROS services and/or ROS actions.
Package-level inbound interface vs Component-level interface
There may be multiple instances (or deployments) of Turtle. Each Turtle instance publishes the /sim/cmd_vel ROS topic. The Simulator subscribes to the /sim/cmd_vel topic. You’ll define an inbound ROS topic interface for /sim/cmd_vel to help Simulator recognize the different Turtle instances.
In general, if you have a Package-A that expects data from Package-B, and there can be multiple deployments of Package-B, you must list the expected data interfaces as inbound interfaces at the package-level.
Dependent deployment
Package A depends on Package B, that is Package B is a dependent deployment of Package A. The arrow in the diagram represents the dependency relationship. Package B injects configuration parameters and/or network endpoints into Package A as environment variables.
Dependent deployment is a design pattern when you want to loosely couple packages having different instantiated life cycles.
A deployment of User Interface relies on that of Command Center. Hence, Command Center is a dependent deployment of the User Interface. Similarly, a deployment of Command Center depends on that of Simulator, and therefore, Simulator is a dependent deployment of Command Center. However, Simulator is independent of any other deployment.
The table summarises dependency relationships between all of the packages in Turtlesim tutorial.
| Package | Dependent Deployment(s) |
|---|---|
| Simulator | None |
| Command Center | Simulator |
| User Interface | Command Center |
| Turtle | Command Center, Simulator |
The below diagram illustrates the dependencies among packages in Turtlesim tutorial.
You may find it instructive to execute the Turtlesim tutorial locally on your machine. A reference implementation together with execution instructions is found in the GitHub repository and Docker registry.