ARC ROS: Road Map

technical: Directed to those in CS/Robotics/etc. General reader may still keep up.

<< previous post <<

The porting project continues. My workterm goal is to migrate an Active Recruitment Framework by previous AALAB graduate, Geoff Nagy, to the ROS (Robot Operating System) platform. In order to fully "port" the arc framework to ROS, it won't be as simple as merely adjusting a few lines in the ros_stage component to support arc. I'm needing to fully port the actual framework itself, and it's functionality.

Porting a large project is a great way to gain exposure to professional development and research techniques while not diving into something I can't handle. It would be too ambitious for me to pursue developing -- from the ground up -- a functional multi agent framework. I'm simply not capable enough to even begin doing such a thing. However, porting Geoff's work will require me to understand each and every component. Furthermore since this is not only a porting of location of software; but rather porting to a whole new architecture/environment, additional design decisions are required on my part to ensure the system semantics are maintained.

Photo of stage simulation of ARC plugin (Nagy, Anderson, 2016)

To properly go about this project, let's outline the BIG goal and the major steps involved in reaching said goal.

ARC ROS Roadmap

1) Understanding the source project

It would take too long to read through every line of code. What I am doing, is spending a few days analyzing the project structure and the interfaces for main components. What pieces are highly coupled? What can run independently? I also contacted Geoff, and other graduate students to get information on how THEY intended the software to be used. The goal here is to identify the main flow of the software, as this will guide how I migrate it.

2) Understanding the Target Environment (ROS)

Porting to a new environment allows for improvements on existing software. It's critical to understand where you are migrating the project to, and what bells and whistles are offered there. Firstly, I explored the key features and design patterns of ROS (Nodes, Topics, Messages, Services..). On top of these, ROS has a massive amount of components that allow developers to save time by leveraging off existing functionality. For example, the ROS Navigation Stack, is a collection of packages that aid in autonomous planning, localization, and navigation through an environment. Ideally, I could eliminate the need to port existing navigation code to ROS, and instead design components such that I can use the Navigation stack instead.

The ROS Navigation Stack. Core functionality is outlined.

Understanding the main goals of ARC, means that I can focus on what the critical parts are (ie what CAN'T be ignored) when migrating to ROS. ARC has it's own navigation code; but that's not the main purpose of the framework. What ARC is all about, is multi-robot task allocation, and recruitment. These components can't be ignored, as they are what MAKE the research.

3) Designing and Implementation

I've never approached software of this size before. My intuitive approach to migrating it, is to do design and implementation in iterations. This assumes I've gathered together an understanding of the structure and flow of the software.

Each layer of design will outline an interface. Each interface acts as a contract, that constrains the more intricate, internal design and allows for easier decision making.

In the upcoming post, I will reveal the first couple of design layers and the reasoning behind my decisions.

>> next post >>