ROS API support - Githubissues

numenta / nupic-legacy

Numenta Platform for Intelligent Computing is an implementation of Hierarchical Temporal Memory (HTM), a theory of intelligence based strictly on the neuroscience of the neocortex.

http://numenta.org/

GNU Affero General Public License v3.0

6.34k stars 1.56k forks source link

ROS API support #1076

Open rhyolight opened 10 years ago

rhyolight commented 10 years ago

From: https://issues.numenta.org/browse/NPC-269

Add support for ROS (Robotic OS) APIs, this will give us a huge variety of :

simulation environments
other AI algorithms
periphetals and sensors

Make NuPIC act as a ROS node.

utensil commented 10 years ago

:+1:

rcrowder commented 10 years ago

Possibly tie this in with Rapyuta http://rapyuta.org/ (A Cloud Robotics Platform).

Conveniently it has a public AMI to use (EU-West/Ireland). Custom AMIs can also be built (http://rapyuta.org/maintainer_resources).

breznak commented 10 years ago

Wow, that looks real cool @rcrowder Thanks for sharing! ..oh, now I see I never got it upstream. I have an implementation of "ROSencoder" that somewhat simulates the Publisher/Lister ROS nodes; but I plan a rewrite soon to ROSRegions which would be much better solution.

rhyolight commented 8 years ago

Is anyone still interested in this?

rhyolight commented 8 years ago

@iandanforth This was your idea, right?

breznak commented 8 years ago

I think I came with this idea back then.. I wonder if I have some functional code laying around.

There's one question to decide: "make NuPIC a ROS node":

make a ROSRegion wrapper, so each region can be made into a lego-piece separately
make "HTM applications" (prediction, AD,..) and wrap that as a functional Node?

I'd prefer the first for flexibility, although some most-common usecases "apps" can be made available also.

rhyolight commented 8 years ago

Whatever it ends up being, it should not be a part of the nupic codebase. This should be maintained as an adaptor in a separate repository.

breznak commented 8 years ago

vThis should be maintained as an adaptor in a separate repository.

nupic.ros then? btw, what is nupic/bindings (swig) for? Apart for "our" use of nupic-nupic.core? I was of the idea that bindings to another languages would go there (ie. part for nupic.core)

rhyolight commented 8 years ago

nupic.ros then?

Fine by me, but some people don't like that naming.convention.

btw, what is nupic/bindings (swig) for? Apart for "our" use of nupic-nupic.core? I was of the idea that bindings to another languages would go there (ie. part for nupic.core)

Yes, that is the idea. There could eventually be bindings at bindings/ruby or bindings/java or whatever. Also this allows any other Python projects to bind to nupic.core if someone wants to create their own OPF-style library, which would be cool.