FeatureRequests

Features we would like to see

Highlevel

Tools

• Introspective thread graph visualiser. E.g, a visual graph which shows what threads are reading what variables and writing what variables to the KB. Perhaps show things as well like loop time. A similar tool is one from ROS, called rosgraph.
• Replay capabilities. Useful for experiments, testing, and debugging.
• Tools which when pointed at a ROS node C++ code, able to provide a rough idea of what would be read(), write(), and compute(). This requires code introspection. Alternative is a guide on how to identify this (for ROS code, and for general code for users not familiar).

Policies:

• Enforcing RCW from the KB's side so programmers cannot potentially break it. Throwing exceptions/warnings when it is violated.

Community & Code Sharing:

• Thread objects which are built for sharing. Tutorials & Design docs on how to make a thread that can be ported to another GAMS project.
• A base thread class which defines a requires() and provides() which tells the system what other thread names and KB variable names/KB objects it requires to run and what it provides to the system. This also helps with creation of a graph as above and for sharing efforts.
• Tutorials on how to package & share the code generated and written.
• I see a thread as being analogous to a node

Core components:

• Generic threads/drivers which are apart of GAMS which work for standard HW components (e.g LaserDriver, CameraDriver, ImuDriver)
• Standardized container types for most used sensor data
• Generic controllers and control loops which help set up a base system. In ROS it was determined that the only unique part is the hardware interface (or fake hw interface), and so the rest can be given freely to speed up prototyping and development.

Handling feature requests for ROS service implementation:

• To make them non-blocking the 'function' implemented as the service would have to avoid the KB so as to not block anything using it.
• It may be possible to spawn a separate process where all services are handled. In doing so, two KBs on the system would be maintained so as to not block the main robot's KB.
• Services are still useful, we just need to find a way to implement them. Sometimes, a robot shouldn't be constantly polling a variable (e.g is the motor on agent 0 enabled yet?) and is best handled by an interrupt.

Threads:

• A base class which has a name field so as to identify it

System bringup:

• Examples on how to launch and setup a complex system with a madara file

Knowledgebase:

• Ability to make variables const or static so users do not accidentally modify or other systems cannot modify (I believe this can be done with local params, but not global)
• Locations which clearly separate what is an argument, what is a parameter, what is data
• Parameters/variables being set on the KnowledgeBase should have a requirement to pass in the name/thread ID of the thread and/or class that is setting the parameter. Useful for debugging and reliability

Command line:

• Commands to print contents of KB (e.g get value of agent.0.location once or also cyclic, determine hz rate, etc. similar to rostopic http://wiki.ros.org/rostopic)
• print outputs/inputs of a thread (e.g like rostopic echo)
• print all modifiable parameters on a system

Reference Frames:

• Generating the reference frame tree from a human readable xml file. (E.g URDF, XML, SRDF).
• Easier to read than having an entire robots tree spread across multiple source files in c++
• Loads once in the knowledge base, making a central point of access for what the TF tree of a robot is.

Lowlevel

NativeDoubleVector

• Built-in methods to convert the NativeDoubleVector to common used types like std::vector<double> and similar