Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
doc:reasoning:overview [2015/04/07 17:53] – gkazhoyadoc:reasoning:overview [2015/05/29 13:18] – gkazhoya
Line 18: Line 18:
 Equipped with the above-mentioned reasoning capabilities, the robot can infer parametrizations of under-specified actions, e.g., if the robot is required to bring a plate from the counter to the dining table, it can infer where is the counter positioned, where should it stand in order to be able to see objects on the counter, when it finds a plate on the counter where should it stand in order to grasp it, where should it stand to be able to put down the object in a location on the dining table etc. This information can then be used at run-time when actually performing the action on the real robot, or used in a simulation in order to find the best parametrization based on a number of trials. Which parametrization is the "best" is then decided based on a certain cost function, which can, for example, be a distance the robot would be driving throughout the action execution. Equipped with the above-mentioned reasoning capabilities, the robot can infer parametrizations of under-specified actions, e.g., if the robot is required to bring a plate from the counter to the dining table, it can infer where is the counter positioned, where should it stand in order to be able to see objects on the counter, when it finds a plate on the counter where should it stand in order to grasp it, where should it stand to be able to put down the object in a location on the dining table etc. This information can then be used at run-time when actually performing the action on the real robot, or used in a simulation in order to find the best parametrization based on a number of trials. Which parametrization is the "best" is then decided based on a certain cost function, which can, for example, be a distance the robot would be driving throughout the action execution.
  
-<html><div style="float:right; margin-left:10px;"><iframe width="560" height="315" src="https://www.youtube.com/embed/TDdWJ5Xu20w" frameborder="0" allowfullscreen></iframe>+<html><div style="float:right; margin-left:10px;"><iframe width="560" height="315" src="https://www.youtube.com/embed/CDeMtnl2v60" frameborder="0" allowfullscreen></iframe>
 </div></html> </div></html>
  
 In order to be able to use the results of the simulation while executing the action in the real world, the simulation has to be extremely fast, so that the robot wouldn't spend too much time "thinking" before actually starting to execute the action. Therefore, the simulation environment used in CRAM is designed to be very lightweight. As a result, all the low-level specifics of executing actions are neglected, e.g., manipulation trajectories are actually not executed in a continuous manner, but the robot's arm is teleported from one key configuration to another, i.e. when grasping an object, at one moment the robot's arm is in the initial configuration, then it is in the pre-grasp position if one is given, and, finally, it is in the grasp configuration. The actual execution of the trajectory should then be handled by the motion planning library and the low-level controllers. In order to be able to use the results of the simulation while executing the action in the real world, the simulation has to be extremely fast, so that the robot wouldn't spend too much time "thinking" before actually starting to execute the action. Therefore, the simulation environment used in CRAM is designed to be very lightweight. As a result, all the low-level specifics of executing actions are neglected, e.g., manipulation trajectories are actually not executed in a continuous manner, but the robot's arm is teleported from one key configuration to another, i.e. when grasping an object, at one moment the robot's arm is in the initial configuration, then it is in the pre-grasp position if one is given, and, finally, it is in the grasp configuration. The actual execution of the trajectory should then be handled by the motion planning library and the low-level controllers.
  
-The video demonstrates execution of a table setting task for pancake making in the lightweight simulation that we call plan projection. The video is edited, it is not realtime, so for the time being the efficiency of the projection is not yet satisfactory for our needs. However, the fact that it doesn't have to calculate and render every timestamp of the continuous world state, as traditional simulator software does, gives it an advantage for efficient lightweight reasoning.+The video demonstrates execution of a pancake making task including table setting / preparation in the lightweight simulation that we call plan projection. The video is edited, it is not realtime, so for the time being the efficiency of the projection is not yet satisfactory for our needs. However, the fact that it doesn't have to calculate and render every timestamp of the continuous world state, as traditional simulator software does, gives it an advantage for efficient lightweight reasoning.
  
 For more information, take a look at the related [[/publications|publications]]. For more information, take a look at the related [[/publications|publications]].