GAMS Primer (C)
C++ Guides: GAMS Primer | Simulation Primer | Generating Code | Creating Algorithms | Creating Platforms | Creating Threads | Creating Transports | Debugging
The Group Autonomy for Mobile Systems (GAMS) project is intended to provide portable algorithms and platforms for AI research into robotic, simulation and software agents. GAMS is provided as middleware for C++ and Java developers to build solutions on top of and is meant to facilitate portable interactions between heterogeneous agents in the most challenging real-world environments (including frequently disconnected environments).
Collaboration amongst agents is facilitated via the MADARA project, which provides portable threading, networking, and knowledge and reasoning services for C++, Java, and Python (we hope to support Python via MADARA once the C++ and Java libraries are solid). MADARA supports Intel and ARM architectures as well as operating systems like Windows, Linux, Android, Mac, etc. For networking, it provides several stock transports like UDP unicast, broadcast and multicast as well as two vendor implementations of the OMG DDS standard (namely PrismTech's and RTTI's implementations).
GAMS Agents are composed of a Controller, one or more high-level algorithms, and a platform driver. High-level algorithms are executed by the Agent in a Monitor, Analyze, Plan, Execute loop, known as the IBM MAPE-K loop. All entities in the GAMS agent interact with each other and with other agents through the MADARA KnowledgeBase.
The BaseController controls the execution of algorithms, platforms, network operations, and knowledge checkpointing. The process of managing algorithms, platforms, network transports, and checkpointing is shown below. Checkpointing can be done as full context saves in individual files based on a monotonic, incrementing counter on send or loop hertz, or it can be the diff of changed knowledge since the last checkpoint.
An algorithm tends to be a high-level operation, e.g., explore a 2D map, that is decoupled from platforms. GAMS includes many high-level algorithms that may be useful while developing your own robotics platforms.
Each platform has a threader that manages its own threads through the MADARA Threader, which provides a handle to the KnowledgeBase and also a deterministic thread hertz. Blasting (e.g, running at infinite hertz) is allowed but discouraged. The design process for GAMS focuses on control, timing, and ultimately verifiability.
Typical platform threads may include a local planner, global planner, camera analyzer, map builder, and state estimator. Each thread communicates with each other over the thread-safe KnowledgeBase.
It is possible to also provide a Threader to a high-level algorithm. This is useful if a high-level algorithm has a long-running task, such as an A* search through a large state space. Such a thread-enabled paradigm for algorithms is depicted in the following.
The Agent model can be extended further with thread-enabled Agent Controllers. This is useful if there is a need to augment the default GAMS controller execution model with a smarter or mission-enabled execution model. Typically, this is done by extending BaseController and overriding the system_analyze function with new logic. By default, the system_analyze function checks for new user requests for high-level algorithms, changes to logging levels, hertz rates, or other flags/statuses in the KnowledgeBase.
The Agent Controller could be further extended with threads to allow for analytics that analyze state over a longer period of time. If this state is platform-specific, then the thread should probably be put in the Platform instead of the Agent Controller. Threads on the Agent Controller should be high-level, controller-specific threads. This will result in cleaner code that other developers can more easily debug and understand.
The Algorithm analyze, plan, and execute and the Platform sense methods should not block the caller for any reason. These functions should be implemented minimally. If anything must run for a long time, then a thread should be created that extends the MADARA BaseThread, and this thread should be attached to an appropriate GAMS Agent entity (e.g., Platform, Algorithm, or Controller).
If you do take too long inside of sense, analyze, plan, execute, or system_analyze, then you will also block the Controller's ability to send knowledge over the network or to save checkpoints. This will result in running the controller at a lower loop_hertz and send_hertz that specified by the user, which is discouraged.
We have worked with the Software Engineering Institute at Carnegie Mellon University to produce a Youtube series on creating distributed artificial intelligence with the GAMS. It walks developers through creating their own high-level algorithms for formations that work in simulations and in the real-world. You will be able to program your own demo at the conclusion.
C++ Guides: GAMS Primer | Simulation Primer | Generating Code | Creating Algorithms | Creating Platforms | Creating Threads | Creating Transports | Debugging