-
Notifications
You must be signed in to change notification settings - Fork 16
database_manager
To start the database_manager ros node, run the following command on terminal -
> rosrun database_manager run_server
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.
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 :
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.
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 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 if given facts are present in an agent's fact table. You should fill 'facts' with the wanted facts to find and 'agent' with the agent's name in which table you want to look. The result will be a bool in 'boolAnswer'. If you add 'type=INDIV', the database will return a list of string containing either true or false: it represents if each fact is in the table or not.
- 'command' = SQL. It executes a sql command. The command should be filled 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_infoThis 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's name). You can get all the current facts of an agent ('subType' = CURRENT, 'agent' = agent's name). You can get all the facts in the memory of an agent ('subType' = OLD, 'agent' = agent's name). You can get all the facts in the planning table ('subType' = PLANNING). And finally you can also get the value of a fact by giving it without value in 'reqFact' ('subType' = VALUE, 'agent' = agent's name 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 description of a property by giving itin '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: ''}"
load_save By this service, you can load the existing database (to be mentioned in fileName
parameter) from your file system to toaster's database. This can be helpful if you want to use resulting database of some previous simulations. Also, you can save the current toaster's database using this service by setting toSave
parameter as true. And fileName
takes the name by which you want to save this database along with location.
- Shell command: -
rosservice call /database_manager/load_save "fileName: ''
toSave: false"
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's name, the facts should be in 'facts')
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".
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.