Let's Make Robots! | RobotShop

Memory Systems

I am curious as to what approaches different people would advocate for giving their robots the capacity to remember.

In order to hopefully stimulate some discussion, I'll mention a few approaches:

1.  Who needs memories?  Make stupid robots that just react but never get smarter.

2.  Use Files To Store Memories in Some Way...like pictures of faces, or data logs for sensors.

3.  Use In Memory Data Structures for Short-Term Memories or frequently used memories.  I personally find dictionaries with key/value pairs (like HybridDictionaries in C#) to be useful for many purposes.  However, what good is this in the long term if not persisted?

4.  Use Databases:   If using a database, how to design it?  Can I have a small set of tables that store many different types of memories, or do I want to model each different type of memory as separate table(s)?

5.  Use Neural Nets?  I haven't tried this, so I can't speak to it.

With any of these, it would seem that "Pattern Recognition", "Searching for Similarity", "Nearest Neighbor", etc. type searches would be necessary.  Any approaches/tools that people like for doing this?

There is also the issue of memories stored over time in sequences, Cause and effect learning, etc.  Anyone doing this?

Memories are fundamental to brain function, so I think the topic deserves discussion.  I am curious how others approach this important function.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

If you talk about Pattern Recognition and data storage, what about an SOM (Self Organizing Map) it's not really a way of storing data itself but a system that classifies input data. It's just a bunch of vectors, you also wouldn't save the data itself but the trained vectors. It's not very difficult but still a little too long to explain here. So what you save is a bunch of vectors and probably which output of the SOM belongs to which pattern/data. One advantage of an SOM is that it never changes the size of the stored vectors. Unlike a database of for example faces where you would store each new face, with an SOM you would change the existing vectors to also classify the new face.

I hope it makes sense what I said for more info on SOM's read the wikipedia page : https://en.wikipedia.org/wiki/Self-organizing_map

One of my main interests with robotics is to try and make them intellegent. What that actually means, I am still working on. But for some basic functions I am researching various methods of computer vision to apply to one of my robots. I have been reading a lot on OpenCv, it has some powerful built in tools to do eiganfaces for face detection and HOG + Linear SVM to do basic object detection.  

In terms of memory storage, I too don't know the best method. However, I am thinking having a large dataset (whether thats a database on the cloud or locally saved files organized by hiearchal folders) that contains thousands of images of different house hold items that are tagged with their name. Then I can use these large data sets to train neural networks so they can recognize and pick up on these objects. The only problem with neural networks, from my initial research, is that its very much a "black box" approach and once its trained for a specific task it can only work for that one task. 

Your point on  "memories stored over time in sequences, Cause and effect learning" is very intersting. I think nerual networks or some form of machine learning might be able to implement this. 

I am currently reading a book, "How to Create a Mind" by Ray Kurzweil. It goes into depth about the different parts of the brain and how researchers are trying to essentialyl model the brain in software. I think you might like it. 

 

The idea that neural nets can be trained to do one job is not strictly true anymore, googles deepmind team have recently published a paper on a new type of neural net called a "differentiable neural computer" - https://deepmind.com/blog/differentiable-neural-computers/

These use an exetenel memory source and learns how to efficiently read/write information and interrupt it correctly. I think this limits the information that needs to be stored for pretty minimal overheads (no need to keep all the training data)

Personally I think neural nets are the way forward, even in the past 5 years they have come on so dramatically, probably brought on by the deep belief boom that kickstarters so much research. By training systems that "learn how to learn" we can craft a single model and teach it new content over time, even having different teams working on teaching the model seperate skills

You're right, a friend of mine told me about this. I don't fully understand the concept yet but I feel like this is the future in terms of AI. What is your experience with neural networks? Have you used tensorflow? I've heard that is a good way to get up and running with neural nets.

 

 

Yeah Tensorflow is awesome, really good for getting up and running with neural nets quickly, I've recently been messing with Keras with a TF backend.

I made a few neural nets at uni using a pretty old language called "CORTEX" and since then made a few for mostly visual tasks (face recognition / tracking / OCR) etc
I've only built one outside of following tutorials with tensorflow which was a deep CNN for character recognition, but I don't think I had quite enough training data to make it work as well as I would like, and got far better results using a KNN classifier and support vector machines.

I made a mouth/jaw tracker a while back using SVM's as well, they are great for visual tasks. Can be seen here if you are interested:

https://www.youtube.com/watch?v=qjgOhO8VmCw

Deep networks are very data hungry, but if you can provide enough they can hit awesome results. If you are interested in playing with one for OCR i'd suggest the following tutorial: http://www.pyimagesearch.com/2016/08/01/lenet-convolutional-neural-network-in-python/

Pyimagesearch is a fantastic resource for both machine learning and computer vision, I can't recommend it enough.

 

 

I am envious of your skills/knowledge/experience.  Makes me feel like an obsolete robot that needs an upgraded processing unit.

Hah, curiously enough that's how I feel every time I see a new update for Ava and Anna!

I use two different types of tables depending on what type of project I am doing.

For the majority of the time I use simple access tables and they seem to work really nice.

I have used SQL tables and they work great but with all the additional software you have to install such as MS-SQL it tend to weigh down the system and decrease the system resources.

With Access tables you dont have to install Access or any other MS office product to make them work and the connection strings are very simple.

I have used the Access tables for storing GPS locations, Images, Text, Number etc... and they have work out well.

My AI project that I have been working on for some time now started with SQL tables but after doing some testing found that the Access tables did just as good a job and didn't weigh the system down and cause the resources to drop. Where as SQL is a service that has to run which pulls the system down some. The teeter totter of resources/memory/Processor is one that I am always playing with and find just the right combination is difficult some of the times. My original AI engine that I made used a text file to store the data in and it was getting out of control and there was no real way to organize it well without using several text files.

I have also experminted with use arrays and variables and while they work well, once you turn the software off or turn the computer off all that was learned is gone.

I find the SOM (Self Organizing Map) VERY interesting.  I have seen papers expressing emotions as vectors.  I think aspects of visual and verbal could be done with vectors.

Most of my memory experience has been with data that is easy to imagine in relational datastores.  Whether Access (as Jeff discussed) or SQL Server, the concept is the same...to model memory structures and then store lots of them with their relationships to other memory structures.  I think this technique has many uses (its how the world stores data), but other techniques are needed in addition to move forward.

Currently, I use a CacheHelper service that sits in between the code and the databases and decides what to hold "in memory" and what to go to the databases for.  It also takes care of building indexes to access by ID, Name, or other factors, for speed.  This works well for frequently accessed data (like words, phrases, and many others) which is constantly being looked up.  It works well too when their are logic questions to deal with like "Can a penguin fly?" where many memory nodes (possibly hierarchical in nature) have to be evaluated to get an answer.

For NLP parses, I also use a special intermediary "cache helper" (keyed by sentence) and "Parse Dictionary" where I cache features about a given parse of a given sentence.  This lets me avoid hitting the NLP parse routines twice for the same sentence in the same session...this lets you ask questions about a recent or distant conversation without having to incur huge delays as each sentence is found, prioritized, and parsed.  Example:  "What color was the bus?" - where recent references to buses need to be recalled, parsed, and colors identified.

For persistence, I used to use a "generic" database structure that could store any memory type.  I then needed "meta memories" - memories about memories - to define and document the structure of each memory type.  This model made it easy to develop a user interface on top of all memories so I culd see what was going on.

Later I decided to support "specific" databases - meaning "non-generic" - where each specific memory type was modeled as a separate table.  In order to build a UI, I still needed the meta-memories - which I derived from the system tables automaticallly.  As a side benefit...This UI has so many business applications...imagine apps that build themselves.  This model has advantages in that additional indexes can be added for specific tables...a necessity now that I am dealing with some tables that have millions of rows.  I would say it is a necessity as anything over 75K rows.

I layered a generic rules engine on top of this...where the rules (pre-conditions (think patterns or stimulus) and post-conditions (think responses) were modelled in a few tables.  Rules could be layered on top of any table in any db...hundreds of them.  Reflexes are one use of a rules engine.  There are many others.

Other than conversation histories, I haven't gotten into storing the detailed histories over time of sensor data...tooo much data.  I feel like some intermediary derived data (features, vectors, etc) might be better and smaller and easier to deal with.

I speculated once on creating what I called "Data Cubes" ...whereby a "Data Cube" object would monitor a given sensor input and store (in memory) the recent history and summary stats on less recent history in various time increments (minute, hourly, daily, etc.).  This cube would handle storing the summary stats asyncronously to a db when it chose to,   The point of this whole idea was to allow a robot to monitor a set of inputs (through multiple cubes) and attempt to derive knowledge or correlations from observation.  Example:  Getting a robot to observe that it tends to get warmer when the sun comes up.  Beyond correlation, since the cubes would store data over time...perhaps they could be programmed to recognize cause and effect...by recognizing a change in one precedes a change in another.   I think it is all possible, but never built the cubes or tried it.   We used to have to derive formulas for raw data in school.  This basically represents coming up with a hypothesis or idea.  Robots could do this too...which would be really cool I think, a robot coming up with ideas from observation.

I haven't mentioned visual here...I think its an area where something like the SOM or some other techniques would be useful...I haven't done anything I would consider useful visually.

What about NoSQL databases such as Mongo or any of a whole cadre of others like it?  I have only played with Mongo a bit, but it is easy to work with and to scale horizontally as your data needs expand.  Microsoft's offerings are a bit more difficult to work with in this regards.  Also, having it in the cloud would allow you to data mine memories etc using standardized big data tools such as 

It sounds like what you have done is to recreate what NoSQL databases give you out of the block although perhaps I am misunderstanding your design.  I know I haven't thought about this as much as you have by any stretch, but it seems off the cuff that a NoSQL database might be a good approach.  These databases were designed to easily search through data that is not necessarily relational (such as data created on Facebook or data off the web) which kind of sounds like memories.  Basically, data is saved as json name value pairs and searches only find data by that name.  So, using your example, the query as to what color the bus is would generate "sql" that asks if there is a bus memory with a color in it, and if there is something there with a color and a bus in it for today, it would give that back to you.  Otherwise, the system can't remember.

I am sure you are way ahead of me on this and looked at them already, but just in case, I thought I would mention it.