database_manager

How to use

To start the database_manager ros node, run the following command on terminal -

> rosrun database_manager run_server

Description

To store and manage the facts generated from Spatial and Temporal Reasoning components, and to add a memory to our system, we created a module based on a SQL Temporal Database. Apart from the conceptual perspective taking (as described in belief_manager), another capacity of the database component is the event based time management. This provides memory to the system. When facts are received, the time of detection is present in one of their variables. When the database manager detects a shift in a property, it updates the belief tables as explained in previous section, but it also records the event. To do so, we add a table filled with each event that occurs, recording the time when the property changes. This is a significant component of TOASTER as it is used for testing and debugging this situation assessment framework.

Implementation details

This module continuously reads facts from PDG, area_manager, agent_monitor and move3d_facts. All these facts are updated in the robot's belief state. Once the robot belief state is updated, it updates the other agent's belief state by the idea of conceptual perspective taking. Figure below explains its implementation :

![] (https://github.com/Greg8978/toaster/blob/master/doc/LatexSource/img/database.jpg)

Inputs

To maintain robot's own belief state, the information produced by perception, geometrical reasoning and inferences are collected by the database management module. Facts computed from area_manager, agent_monitor and move3d_facts are stored in this module.

Outputs

The output of this component is a sql database with fact table and memory table for each agent present in ID table. The fact table stores all the fact true for the agent at that time instant. While, the memory table stores facts that the agent has believed to be true. There is an event table as well to track the occurrence of events like when robot started moving and when it stopped moving. However, during an interaction, many properties that describes an object or an agent may not evolve in time and thus, be considered as static (color, name, age, ownership). To store these static properties, an extra table is present in the database and can be loaded at the start of the interaction, or filled online (if the robot acquire new knowledge on entities). For more details, check https://github.com/Greg8978/toaster/blob/master/database_manager/doc/database%20doc.pdf.

Services

Services of database_manager allows you to add entity, facts and events in respective tables and view all the tables. Its services are described below :

• execute - This service enables users to access the data in tables in various ways by putting different commands.

Shell command:

 rosservice call /database/execute "command: ''
type: ''
facts:
- {property: '', propertyType: '', subProperty: '', subjectId: '', targetId: '', subjectOwnerId: '',
  targetOwnerId: '', valueType: false, factObservability: 0.0, doubleValue: 0.0, stringValue: '',
  confidence: 0.0, time: 0, timeStart: 0, timeEnd: 0, fullTime: false}
agent: ''
order: ''
areaTopic: false
agentTopic: false
move3dTopic: false
pdgTopic: false" 

The different possibilities to call this service are:

• command = ARE_IN_TABLE. It checks given facts are present in agent's fact table. You should also fill facts with the wanted facts to find and agent with the agent name in which table you want to look. The result will be a bool in boolAnswer.
• command = SQL. It execute a sql command. The command should be fill in order and the result will be return in results (+boolAnswer will indicate if there was an error during sql command execution).
• command = EMPTY. If type = ALL, it empties all the database. If type = AGENT, it empties the table of the agent given in agent. If type = PLANNING, it empties the planning table.
• command = PRINT. It prints all the database if type = ALL and only an agent table if type = AGENT (with the agent name's given in agent).
• command = SET_TOPICS. It sets the topic the database should listen to be filled (areaTopic, agentTopic, move3dTopic, pdgTopic variables).
• command = RESET_TABLES. It reset the table with the new id list given in newIDList.

• get_info - This service helps to get data from any given table. The request message looks like this :

Shell command:

rosservice call /database/get_info "type: ''
subType: ''
agentId: ''
reqFact: {property: '', propertyType: '', subProperty: '', subjectId: '', targetId: '',
  subjectOwnerId: '', targetOwnerId: '', valueType: false, factObservability: 0.0,
  doubleValue: 0.0, stringValue: '', confidence: 0.0, time: 0, timeStart: 0, timeEnd: 0}
reqEvent: {property: '', propertyType: '', subProperty: '', subjectId: '', targetId: '',
  subjectOwnerId: '', targetOwnerId: '', valueType: false, factObservability: 0.0,
  doubleValue: 0.0, stringValue: '', confidence: 0.0, time: 0}
id: 0
idString: ''
name: ''
entityClass: ''" 

The different possibilities to fill the service are:

• type = FACT. This return a list of facts in resFactList. You can get all the facts of an agent (current + in memory) (subType = ALL, agent = agent name's). You can get all the current facts of an agent (subType = CURRENT, agent = agent name's). You can get all the facts in the memory of an agent (subType = OLD, agent = agent name's). You can get all the facts in the planning table (subType = PLANNING). And finally you can also get the value of a fact of a fact by giving it without value in reqFact (subType = VALUE, agent = agent name's in which table you want to look).
• type = PROPERTY. This return a list of properties in resProperties. You can get all the properties (subType = ALL) or the value of a property by giving it without value in id (subType = VALUE).
• type = AGENT. This return the list of all agents in resId.
• type = ID. This return a list of ids in resId. You can get all the ids (subType = ALL) or the value of an id by giving its description in idString and name (subType = VALUE).
• type = EVENT. This return a list of events in resEventList. You can get all the events (subType = ALL) or the value of an event by giving it without value in reqEvent (subType = VALUE).
• type = ONTOLOGY. This return a list of ontologies in resOntology. You can get all the ontologies (subType = ALL), all the leaves (subType = LEAVE) or the value of an ontology by giving it without value in entityClass (subType = VALUE).

• plot_facts - This service is developed with the purpose of examining the functioning of TOASTER in real-time environment. It plots the given fact for the given subject and target entity in specified time window. Apart from this, you can also plot the fact from the time ros node started to the current time by setting fullTime parameter as True (you need not to explicity mention startTime and endTime then). This service creates "fact_name.dat" (eg. IsMoving.dat) file in plot_fact folder of database_manager. You can also see the path of file on the database_manager terminal. file in your home directory. To plot the graph install gnuplot and run "gnuplot" command on terminal. In gnuplot terminal, run following commands:

gnuplot> set yrange[-1:2]
gnuplot>  plot "path of plot_fact/fact_name.dat" using 1:2 with lines

And you will see the plot of desired fact with time. Also, multiple facts can be plotted in same graph by using following command in gnuplot.

gnuplot> set yrange[-1:2]
gnuplot> plot "path of plot_fact/fact_name1.dat" using 1:2 with lines, "path of plot_fact/fact_name2.dat" using 1:2 with lines 

Shell command:

rosservice call /database/plot_facts "{subjectID: '', targetID: '', timeStart: '', timeEnd: '', reqFact: ''}"

• set_info -

Shell command:

rosservice call /database/set_info "add: false
infoType: ''
agentId: ''
facts:
- {property: '', propertyType: '', subProperty: '', subjectId: '', targetId: '', subjectOwnerId: '',
  targetOwnerId: '', valueType: false, factObservability: 0.0, doubleValue: 0.0, stringValue: '',
  confidence: 0.0, time: 0, timeStart: 0, timeEnd: 0}
event: {property: '', propertyType: '', subProperty: '', subjectId: '', targetId: '',
  subjectOwnerId: '', targetOwnerId: '', valueType: false, factObservability: 0.0,
  doubleValue: 0.0, stringValue: '', confidence: 0.0, time: 0}
id: ''
name: ''
type: ''
ownerId: ''"

You can:

• infoType = EVENT. Add an event to the database (fill event).
• infoType = RESET_PLANNING. Reset the planning table with a list of facts (in facts)
• infoType = ENTITY. Add an entity to the database (fill id, ownerId, name, type).
• infoType = FACT. Add a list of facts to the database (agentId = PLANNING if in the planning table or the agent name's, the facts should be in facts)

Examples

As an example, if a Mug was on a table and the robot detects that the Mug is now in Bob's hand, it will remove the fact Mug isOn Kitchen_Table from the belief tables of agents able to perceive the change, and add the event _Bob pickUp Mug _in the event table. In memory table, we use as starting time the time when the agent noticed a property, and as ending time the moment when the agent detects a change in it. One of the application can be to understand when a human asks "Where is the mug that was on the table" by detecting in his memory table which mug she/he is talking about and looking in the current fact table where it currently is. In addition, the robot could even tell the related event that created the change: "It is now in the sink, Bob picked it up 5 minutes ago".

Future work and possible improvement

This module is one of the last implementation of TOASTER. More tests should be done to ensure the database is able to answer fast enough to the requests.