jdddog
commented
6 years ago Thanks Linas. We want to explore a more interoperable way to interface OpenCog with other systems (not just ROS), but we are currently finishing a project and are not ready to work on this yet. I would be happy to discuss it in a couple of weeks time.
This is a proposal that describes an "opencog ROS node", as a possible replacement for
ghost_bridge. It is probably low-priority, for now, so not urgent. However, it might (maybe?) resolve certain kinds of performance problems. I'm not convinced that its even a good idea: but it is an interesting idea.First: the "performance bottlenecks" in the current design are these: When the python ROS node receives sensory messages, it must send them to opencog (in some way). It currently sends them by opening a socket to the cogserver (which is running in a different process) and then sending asci//(utf-8) strings to the cogserver - the strings are various scheme commands. There is a fair amount of over-head in this: (a) the operating system must switch between processes (low-cost as they run on different cores) and different memory maps (TLB entries, etc.) (b) socket i/o (c) the guile interpreter needs to run.
One alternative to this is to start and run opencog in ROS, itself (although opencog would need to run in a different thread that ROS). Pros and cons:
cost of (a) (b) might not be that high, so maybe there is not much perfromance efficiency to be had.
cost of (c) is unavoidable, and, if implemented incorrectly, it could increase a lot (viz, guile has a large entry/exit cost; this cost is avoided by using "hot standby" guile interpreters in the cogserver. If the new design doesn't use hot-standbys for scheme evaluation, performance could plummet.)
We've never run opencog-python in its own thread before. This could expose issues/bugs.
The current opencog python bindings are inadquate: (1) no way to start/stop a cogserver from python (2) sharing of common atomspace between python & cogserver is buggy.
Stability. It might crash. We cannot afford to crash opencog, as its the brain of the robot.
There is only one major advantage, win: insertion of atoms, from python, directly into the atomspace, becomes very cheap and easy, because (a), (b) and (c) are all avoided. However, this "big win" is pointless, if ghost-bridge never needs to poke atoms directly into the atomspace, and is instead always triggering scheme scripts.
The above, last bullet, explains why this is an interesting idea, but might not actually be practical for ghost_bridge.
See https://github.com/opencog/benchmark/issues/9#issuecomment-392015975 for initial proposal and additional discussion.