A Reconfiguration Framework for ROS (Robot Operating System) running on TurtleBot
A reconfiguration framework that allows users (ROS application developers) to swap navigation and control algorithms and parameters being used in the robot at runtime. Also, practiced Spiral and Scrum software development process and quality assurance in the software development life cycle.
Where the project come from ?
The idea of this project stems from the development of CoBot robots, by some faculty and students in the CMU Robotics department. These robots have been used to pursue academic research in effective real-time mobile robot localization and navigation algorithms, symbiotic human-robot interaction, and multi-task multi-robot dynamic task planning. These robots are highly stable and have recorded over 1000 km of travel distance, but are not easily maintainable and modifiable, especially in terms of runtime reconfigurability.
What features the framework provide ?
- Be responsible for managing the interactions between multiple nodes on a bot when configuring/reconfiguring (adding, removing, switching on, switching off nodes) happens.
- Ensures the stability of the bot (and the state of the nodes) during and after the respective configuration/reconfiguration activity.
- Fault management mechanism is provided to detect and mitigate faults or issues that occur during the reconfiguration scenarios.
What I have done ?
- Acted as the team’s architect leader, and designed software architecture of the reconfiguration framework.
- Designed the protocol that covers node dependency storage and calculation, fault management mechanism.
- Established general properties and then created the model of the designed protocol.
- Implemented PROMELA (Process or Protocol Meta Language) code to verity the designed protocol.
- Implemented all core features (reconﬁgure framework, node dependency) individually and performed peer reviews.
Figure 1. Framework in the Self-adaption System Figure 1 shows the functional breakdown of the self-adaption system that’s developed by CMU staff and students. The self-adaption system’s objective is to provide dynamic reconfiguration feature for ROS. Suppose when the turtlebot’s kinnect camera faces some hardware or software issues, users want to switch to another navigation. So, they’ll swap camera based navigation algorithm with bump sensor based navigation algorithm.
There’re two major roles in the system:
- Decision Making
This module will identify the change to be made in the system and send the command to the system configuration framework.
- System Configuration Framework
This is the framework we design that will apply the change to the system.
The responsibility can be concluded as follows:
- Identify dependencies between applications
- Perform reconfiguration when directed by the Decision Making Node
- Pause communication between dependent applications when reconfiguring
- Restore communication after the reconfiguration is done
Figure 2. Physical View of the framework Figure 2 shows the overview of the reconfiguration framework the team designed for ROS (Indingo). As you can seen, the framework is located between the lower ROS master (Message Bus) and those higher ROS applications.
Figure 3. Architecture design of the reconfigure framework Figures 3 shows the architecture design of the reconfiguration framework. Two main parts in the architecture:
- System Configuration Node
- Stores dependencies between nodes operating in the system
- Interacts with Decision Making Node
- Performs reconfiguration on both, a running system (Moving Robot) and a stopped system
- System Configuration Node Library
- Provides API’s that wrap inter process (ROS node) communication API’s provided by ROS framework
- Communicates with the System Configuration Node
- Registers Nodes to the framework
- Registers a series of callbacks (save state, load state etc.) that are called at the time of reconfiguration
The following 3 figures show the model we created to verify whether the protocol we designed is valid. Figure 4. Model of Client Subscriber
Figure 5. Model of Server Publisher
Figure 6. Model of System Control Node