On Mon, 22 Nov 2010, Klas Nilsson wrote:

> Hi Herman, isn't the KUKA description related to the special (but in standard
> applications common) case that geometric relations are 'sufficiently' fixed so
> they can be transformed into specific controller actions/states (embedded in
> the control without maintaining the graph), and then maintaining the semantics
> in a higher level scene graph (e.g. RDF knowledge base, or as part of
> engineering tools) that is not real-time capable?

I do not really know, at this moment. Let's await their answer.

> I don't like scene graph either (confusion with graphics needs and with what
> you have in CAD tools when the application is engineered), so what about
> State Graph?

What semantic confusion would that term avoid, and in a better way than
"scene graph"...? There are few words that are more overloaden already than
"state" :-(

And the traditional, graphics "Scene graph" _is_ to a large extent what I
have in mind; I just want to give it some "steroids", so that it can do
more than what it is used for in computer animation.

But I do share your concern for finding a "perfect" name...

Herman

>
> Cheers Klas
> _________________________________________no text inlined below____
>
> Herman Bruyninckx skrev 2010-11-21 16:13:
>> On Thu, 18 Nov 2010, BRICS Office wrote:
>>
>>> Dear Herman,
>>>
>>> Sorry for taking our time, but we have now had some feedback on this from
>>> within KUKA and would like to contribute it to the discussion.
>> Much appreciated!
>>
>>> Overall we really like your move but would like to suggest to not think
>>> just about Scene Graphs, but to think about Scene States. In short if I
>>> tell you I am at (x-4,y=5,z=6) that is not nearly as useful as "I am in
>>> robot 1's gripper at (4,5,6)" etc. The state of a scene tells us much
>>> more about what's going on than the dynamic graph alone.
>>
>> I do not fully understand the meaning of what you call "Scene State"... The
>> fact that you have the knowledge about in what gripper something is at a
>> certain moment is a natural consequence of using the graph: _all_ geometric
>> information is not just provided stand-alone, but linked to the relevant
>> primitives (tools, robots, sensors,...) that are represented in the scene
>> graph. The "arrows" in the scene graph encode these relationships; e.g.,
>> "being grasped by" would be a relevant relationship that a gripper needs to
>> offer in a scene graph.
>>
>>> Use case as you request:
>>> 1) Imagine the object in the gripper of the robot above. Using the scene
>>> state representation we know that the transformation from the gripper to
>>> the object does not change now --> no need to compute this. Could your
>>> "spanning tree" handle this?
>>
>> It should, because it is _generated_ (in this particular use case) from the
>> knowledge that an object has been grasped by the gripper. (Where this
>> knowledge comes from, and how it is applied to generate the spanning tree,
>> that's another issue, and one to be dealt with in the components that _use_
>> the scene graph.
>>
>>> 2) We can imagine that two robots doing something useful together have
>>> completely static scene graphs with respect to each other
>>
>> The _connections_ in the graph would remain the same, but the scene graph
>> itself would not be static: it will reflect the changes in the positions of
>> both robots (at least).
>>
>>> and have no
>>> need for dynamic graph communication with each other
>>
>> I guess they _will_ have such a need, especially when you want the motions
>> of both robots not to hinder each other, or to be coordinated in real time
>> because they have to operate the same object in the world. (Remember our
>> Automatica demo with the two LWRs and the box?)
>>
>>> or any information
>>> about a third performing an independent task in the same workspace during
>>> this particular scene in this particular scene state. In short, keeping
>>> scene state greatly reduces scene graph analysis and computational
>>> complexity.--> again, could your spanning tree handle this?
>>
>> Probably I do not understand fully what you mean with "scene state"...
>>
>>> 3) If you want to grab a box with a two finger gripper, you normally have
>>> 3 grasps (twosides, othertwosides, topbottom). Knowing the state of the
>>> box (on a table, I hold the box, you hold the box) determines which grips
>>> are appropriate in the situation. --> this can be represented more easily
>>> by the scene state than the scene graph, right?
>>
>> Some remark? No idea because of "semantic confusion" about scene state :-)
>>
>>> So, we would like to suggest modifying the great ideas you presented in
>>> the following ways:
>>>
>>> * Scene Graph > Scene state
>>> * Scene Graph object > Scene object
>>> * Scene Graph is an element of Scene State
>>> * Scene State is dynamic as is the scene graph
>>> * Scene state is distributed among "scene state contributors" just as
>>> his Scene Graphs are distributed
>>
>> I see nothing else but suggestions to rename things... That is probably not
>> what you meant :-)
>>
>>> * More attention to the fact that huge portions of the scene are static
>>> (and enumerated in scene state) even in our most dynamic environments!
>>
>> The "spanning trees" for computation exactly have this goal (as one of many
>> more goals): if you know that some part of the world will not change, you
>> should not foresee any computations to "update" that part.
>>
>>> * The entire project is really about "world model" as you said, but
>>> scene graphs are only a part of this. Let's really develop a better world
>>> model sharable in offline programming, simulation, robotics and
>>> manufacturing in general.
>>
>> That's my ambition. There must be some semantic confusion amongst us; which
>> I think is very normal, in this early stage of the ideas.
>>
>>> We hope our comments help and restart this discussion. Please feel free
>>> to expand/criticise/ask for clarification etc...
>>>
>>> Best regards,
>>>
>>> Tim
>>
>> Thanks a lot!
>>
>> Herman
>>
>>
>> _______________________________________________
>> WP2 mailing list
>> WP2 [..] ...
>> http://box448.bluehost.com/mailman/listinfo/wp2_fp7rosetta.org
>
> -------------------------------------------------------------------------
> o--< Klas Nilsson, Dept of Computer Science, Lund University - LTH
> \ Box 118, S-221 00 LUND, Sweden | phone:+46-(0)46-2224304
> O klas [..] ...,klas [..] ..." title="mailto:klas [..] ...,klas [..] ...">mailto:klas [..] ...,klas [..] ... | mobil:+46-(0)705-365015
> +->>[_] http://www.cs.lth.se/~klas | skype:klas_nilsson
> |
> +-------<< Real-time << control << components << PnP << program << users
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>