Hi Linas, The intended design is that there is a well-known Value that is attached to > red-cube. That Value is knows how to obtain the correct 3D location from > the SpaceServer (or some other server, e.g. your server). That Value ONLY > fetches the location when it is asked for it, and ONLY THEN. This is the > code that Misgana wrote. Twice. You should NEVER directly shove 3D > positions into the atomspace!! >
Am I right that implementation of this design is still not merged? In current atomspace/opencog code I can find OctoMapValue only which inherits FloatValue (and keeps vector of doubles in it) + has update() method which updates the value using OctoMapNode. So value should be updated before using it. > That way, we can have a common, uniform API for all visual-processing and > 3D spatial reasoning systems. (for example, some 3D spatial reasoning > might be done on imaginary, pretend objects. The sizes, colors, locations > of those objects will not come from your vision server; they will come in > through some other subsystem. However, the API will be the same. > > I should be able to tell the robot "Imagine that there is a six-foot red > cube directly in front of Joel. Would Joel still be visible?" and get the > right answer to that. When the robot imagines this, it would not use the > space-server, or your server, or the ROS-SLAM code for that imagination. > However, since the access style/access API is effectively the same, it can > still perform that spatial reasoning and get correct answers. > Yes, I think I see your point. We could wrap NN by value and return its results on demand to be analyzed by generic predicates. Such approach allows getting results from visual features on demand. But back propagation seems to not work with this approach. For example if generic predicate uses value to verify whether object is "red", then what it expects from value is pair of doubles (mean, confidence). If our value returns such pair of doubles it forgets all computation graph which led to this result. It means that we are not able to propagate an error back through the calculation graph and improve next result. As far as I see such unification is not possible without changing predicate logic or introducing outer system to calculate predicates and keep computation graph. -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/3f8d3cf0-b92a-4ac3-9230-3d547334ad42%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
