In a couple of my earlier threads, I mentioned the concept of utilizing a representation of “current position” to learn positional information about the features of an object (Learning an ordered sequence out of order and Learning a collection of features where order doesn’t matter). In those threads, I mentioned that this information would be provided by some external system or process. This is one possible method for providing positional information using the concept of “dead reckoning”. This idea may have no basis in reality, but I feel like there could be useful information in exploring the concept.
For those who are not familiar with dead reckoning, the idea is that one vector can be represented as a series of other vectors. This means in the absence of any landmarks, current position can be determined by keeping track of every movement made after some known starting position. For example, if I take 1 step forward and 2 steps back, that is equivalent to taking 1 step back. Rather than performing math (1 - 2) or having an internal GPS sensor, instead I can track all the intermediate steps and arrive at the same result. Obviously this was a simple example – the math can get much more complicated when you consider rotational information and multi-jointed mechanics. By continuously tracking each movement made, I can maintain an accurate current position.
One problem with this system is that errors build up over time. This means of course that I either need to have very accurate (high granularity) inputs, and/or I need to “reset” the system periodically. For example if you are walking around a forest, you may have a good general idea of where you are at, but you are able to “reset” your position by encountering familiar trees or rock formations. I have not yet formulated a good method of doing these “resets”.
That said, this basic concept has a lot of potential uses. It could be applied to features on an object being touched, for example. Perhaps a simpler way to visualize it, though, is if the object as a room, and you are moving through it and encountering features along the way. I will explain the concept initially in terms of 2 dimensions because it is easier to visualize that way, but keep in mind that the concept can easily be extended to 3 dimensions.
For 2 dimensions, the process involves three regions of cells. Two of them are long strips of cells to depict heading and velocity information. The third will be a large sheet of cells for depicting current position and for predicting the next position based on input from the other two regions:
This system relies on the concept of a “starting position”. How and when the starting position is determined are questions that I still need to work out. This will likely be related to the “reset” process I mentioned earlier (getting a strong indication of accurate current position, such as seeing a familiar tree in my forest example, might reset the starting position back to the center of the sheet). For now, let’s assume the starting position is the center of the large sheet, and doesn’t get reset. Of course this means that there is a limited distance I can travel in any given direction, so I’ll need to tackle that problem later.
You will notice that I have reserved multiple cells for each value (4 cells for each for heading + velocity region, and 9 for current position). These numbers are completely arbitrary and could be adjusted. Fewer cells would reduce overall memory usage but be more susceptible to noise and errors. The heading + velocity regions in practice would probably also be much longer, for tracking a finer granularity of velocities. The large sheet for position would also have a lot more cells in it, so that larger distances and finer granularity of position could be tracked.
The heading + velocity regions are used to represent a velocity vector. For example, moving slowly to the right:
Moving faster to the right:
Moving backward and to the left:
One thing you will notice here is that we are only handling translations, not transformations. In other words, we are not depicting rotation anywhere. Rotation is actually important though (for example, I sense direction with my head, which I may turn to the right or left while walking). I have some ideas for handling transformations, but they are not simple enough. I’m hoping to devise something as simple as the way I’m doing translations. I’ll post an update when I figure out some better options for that.
These inputs will cause the cells in the current position sheet to predict the next position. Moving slowly for example:
And moving a bit faster to the left:
As you can see, if I update the current position cells at a constant rate, and keep track of my current heading + velocity, the current position will be a constant representation of where I am in relation to the “starting position”.
This is good for a scenario where there is only one moving part (the whole “1 step forward, 2 steps back” scenario). But what about a system where there are multiple moving parts? For example what if I lean forward while taking a step back? My “current position” (assuming it represents the position of my head) may not have changed in this case. Well, I can use the dead reckoning concept to add up all the smaller movements and arrive at the starting position. That could be done by cycling the values in the heading + velocity strips between the various inputs:
And back to where I started…
Another way is to have additional heading + velocity strips which cascade up through some hierarchical structures which ultimately drive global heading + velocity strips. Since something like this is probably also needed for handling transformations, that is the route I am looking at. I will post an update when I have some ideas for how to do this.
The final piece of this concept is (as you have probably noticed), the next position should be predicted based on the current position and the heading + velocity inputs. This allows each cycle to shift cells to the correct current position. These predictions are done by growing connections between cells in the large sheet and with cells in the two strips, and placing cells into predictive state like in other areas of HTM. Considering the symmetry of the system, the connections could probably be calculated mathematically, but an easier way would be a training phase to teach the cells in the sheet what inputs should result in their becoming active next. There may be some way to have this information learned through experience, but I don’t expect it is too far fetched to assume that systems like this can be pre-programmed (for example, wildebeest infants are able to run within hours of birth – that must require a lot of pre-programming)
Ultimately, the large sheet of cells depicting the current position can be used as an input to a spacial pooler for use in learning positional information about features of an object. See the two threads I mentioned earlier for some possible use cases for positional information. I am working on some apps to explore practical uses for some of these concepts (the first app will be a “robot” that can learn to navigate a 2D maze). I’ll post links to those for reference and discussion when they are complete.
I used this particular range of motion to better explain my next point without having to use a system with three joints. Note that the system works with any number of joints, but for explanation purposes, two joints is simpler to talk about.
-> 
-> 
-> 
-> 
