Sensors and Actuators
GAMS and its sister project MADARA have been developed to provide developers and researchers with the tools and techniques they'll need to deploy large scale, multi-agent and even swarm-scale artificial intelligence within distributed systems. Historically, GAMS has approached the problem set from a top-down point-of-view (e.g., agent controllers, decentralized algorithm primitives, high-level platform interfaces, etc.), and MADARA has approached solutions from the bottom-up (e.g., knowledge sharing, threading, portable OS primitives, networking, etc.) In the past five years of development, this has left application developers and researchers with a questionable area of the architecture--the place where the platform driver ends and the knowledge base begins. Specifically, there hasn't really been an official API or interface for sensors and actuators.
In this wiki page, we'll present a new Sensor and Actuator architecture for implementing and exposing devices like optical cameras, thermal cameras, robotic arms, etc. Over time, we will implement a standard toolkit and integration with gpc.pl to help with generating interfaces to useful libraries of sensor/actuator implementations that will reside in the gams::sensors namespace.
Platforms own sensors and actuators and have a map of sensor/actuator names mapped to instances of Sensors. We plan to augment the gpc.pl to generate everything developers need to implement their own sensor interfaces that can then be shared, referenced, and used by algorithms and accent algorithms, wherever this makes sense.
The main features that should be implemented by any Sensor developer are the two sense methods. The first method sense(void) returns all sensor values. The second method sense(string) returns the results of only one sensor entry. Note that the result of this method is actually a KnowledgeMap too (a STL map of string to KnowledgeRecord). Consequently, a sensor can return many named values. Keep in mind that Sensors may be implemented with Capnproto types, if the primitive MADARA types (integers, doubles, arrays, strings, character blobs, etc.) are inadequate.
Help is recommended and for standard Sensors should absolutely be implemented verbosely for maximum portability. Params has a getter and setter for retrieving or setting configuration information for sensors.
The primary feature that should be implemented for any actuator is the act(KnowledgeMap) method, which returns a KnowledgeMap of return values for each action specified in the function parameters. Actions returns a list of actions that are acceptable given the current state of the actuator. Help is recommended and for standard actuators should be implemented verbosely for maximum portability.