Subscribe via Email

Saturday, April 8, 2017

ARC ROS: Core Component High Level Design

technical: Directed to those in CS. General reader may still keep up.
Previous Post: High Level Design

Previously, the behavior module was demonstrated. This provided the ability for robots to perform various maneuvers in the environment.

With this out of way, I've began designing the core components for ARC. This includes knowledge management, task management, recruitment, and communication handling.

After a few solid week of high level design, I realized something important: It's not possible to fully design something this complicated.  The more elaborate the design, the more uncertainty is introduced into it. There comes a tradeoff with planning and actually developing. My biggest struggle in software development is wonderfully described as Analysis Paralysis. To combat this, I'm taking a new approach to this project.

The approach will involve 3 major iterations of {design + implementation + testing + demo}, each being a theme that establishes a layer of functionality before building on top of it.

This will be the core component for ARC. The rough outline of each component is as follows:
wifi_handler: Picks up incoming signals over ROS. If this is in a simulation, then noise can be added to simulate signal-loss. In a real environment the wifi_handler will be connected to some physical low-level device that is receiving signals.

communication_manager: This node processes incoming signals and decomposes them into individual task requests, announcements, and responses that the robot can work with. Illformated messages will be caught by this node.

Recruitment Manager: This is the core component, the core of the core. It decides how to respond to incoming communication by toggling knowledge it has and tasks it can perform. Everything to do with coordination goes here.

Knowledge Manager: A database storing information the robot knows about it's environment, team mates, and abilities.

task_handler: Receives task requests, handles what can and can't be performed at a given instance. Tasks are servers that toggle different behaviours from the Behaviour Module. Notice that individual tasks can broadcast messages from our robot.

The beauty of this design is that a developer may pick up the framework, and begin working on their Recruitment with ease. They don't have to consider if incoming messages are valid: the communication_manager does this. Some default tasks will be provided that do debris cleaning, and exploration. This means the developer can focus solely on recruitment, and coordination in a small space; while leveraging off a lot of functionality.

Future Iterations

This project will be continued in 4 major iterations, conveniently named after the people who have taken on this project, from its conception to where it is presently.
Iteration 1: ARC_ANDERSON

Main Theme: In this iteration, the goal is to send a message over wifi, and have it propagate through the system to get a robot to do some task. There is no multi-agent focus, or coordination yet. Thus, the robot doesn't respond to anything, it merely acts.

The tasks implemented will include: Explore, UnguidedClearDebris,GuidedClearDebris. The TaskHandler will prevent running 2+ non-background tasks at once.

Ability to send multiple tasks and have them queued up in robot, watching as it does multiple tasks in order of priority and stops one if a higher priority task comes into play.

Iteration 2: ARC_GUNN
Main Theme: Fundamental coordination is provided. A developer could in theory, build their own recruitment Mechanism on this layer.
Robots will no longer immediately do any random task upon request, they instead broadcast a response and let team leader know. They determine if they are suitable to handle the task, and communicate this information. The tasks to do are still simple and don’t require coordination. The only coordination involves giving responses/feedback that they can or can’t do something, as well as feedback when they are done. This theme is based on work by Tyler Gunns thesis.
Iteration 3: ARC_NAGY

Main theme: Demonstrating a functional Recruitment Mechanism developed on the ARC Framework.  A developer should ideally look at this layer, and base their Recruitment/Coordination mechanism off of it. It will outline how to properly implement your own using the ARC Framework.

This will specifically involve extending the Gunn iteration to provide coordination mechanisms outlined in Geoff Nagy's thesis.
Specific features in this theme include:
- Rendezvous manager and tasks
- Fiducial Marker manager
- Implement active recruitment tasks
Iteration 4: ARC_MORRIS

Main Theme: Providing accelerated research opportunity on the ARC Platform, elaborating on tests, and establishing a maintainable Framework that can be used to prototype large scale ideas in Multi-agent coordination and recruitment. This is where I come in.

Support for statistical logging. Local Logger + Global Logger. Managing statistics within communication manager + other nodes as messages come in.
Automate Unit tests, provide more mock objects and easier testing tools for developers using the Framework.

The first 4 iterations are about porting over all of the work done in our lab. Once this is complete, we can take a more community-driven approach. Researchers will experiment with and present their own extensions and ideas for the framework. We do continuous delivery.

I've already been working through the first iteration for a couple of weeks. I look forward to giving a demo of it soon!

-Next Up: ARC_Anderson: Design and Demo

No comments:

Post a Comment

Please feel free to give feedback/criticism, or other suggestions! (be gentle)

Subscribe to Updates via Email