SLAM!

OctoMY™ has a huge ambition when it comes to the way the agent will localize itself and map environment.

OctoMY™ SLAM (Simultaneous Localization And Mapping)

When a robot is looking at it's environment through it's sensors, it will get a pattern of data. It then has to process this pattern to identify it's location in the environment, and also accumulate meaningful information about the structure of this environment for future use (creating a map).

The data could be as simple as the readings of an ultrasonic range finder or as complex as the video streams from a stereoscopic pair of cameras. And the algorithms an heuristics that are used to derive meaningful localization and mapping data is loosely fit under the term SLAM (Simultaneous Localization And Mapping).

Stereo Camera Sensor

And there are about as many approaches to SLAM as there are implementations out there. This is a really hard set of problems with no "best" solutions. Many of the implementations are crafted for specific sets of performance, constraints and trade-offs such as

• Available processing power ("must run in real-time on smartphone").
• Indoor only or outdoor as well.
• 2D or 3D mapping
• Sparsity/size of map data
• Accuracy of localization
• Loop detection (detection and resolution of circular pathways in environment).
• Scalability with size of environment
• Must be GPU/FPGA/DSP accelerable.
• etc.

So now that you have a grasp on what SLAM is, it's time to move on to how this is planned for OctoMY™.

Since we are basically building a platform on top of which we hope you will add all the cool plugins and features, there really arn't any limitations to what kind of SLAM methods can become part of OctoMY™. But since SLAM is such an essential concept, we will have to provide a pretty darn good default implementation from the get-go that you can get started with right away.

Nothing is set in stone yet, but here are some of the thoughts about SLAM in OctoMY™:

• Should be unsupervised as far as possible
• Automatic camera lens/other sensor calibration
• Automatic environment scale detection
• Automatic tweaking of parameters to get the best result in general
• Should generate detailed and accurate 3D map of high accuracy.
• Should support huge maps
• Should support distributed data model that allows  sharing of data between agents all over the world.
• Should support input from whatever sensors are available, and make the most of it.
• Should adapt to the processing hardware available:
• Make use of hardware acceleration through OpenCL when available.
• Use less resources on lower-end platforms such as old smart phones.
• Should use less hand-crafted and more "learned" methods.

In conclusion, yes ambitions are sky high for the central problem of localization and mapping of environment. In later articles we will surely explore parts of this problem in more detail.

Short introduction to HTM

Jeff Hawkins is an engineer, business man, neuroscientist and inventor who spent his life in the pursuit of a grand unified theory about how our brain works. He has a noteworthy list of accomplishments behind him, and is very successful in his quest.

I first heard about him when I watched his ted talk, and from there my curiosity took over, and I started looking more into the research he is conducting with his company numenta. I will try to summarize the basics of his theories in this post.

If you want to learn more, a good place to start is to read his book "On intelligence".

So what is HTM? HTM is an acronym for Hierarchical Temporal Memory and basically it is a list of 3 important aspects of the algorithm in the theory. The most prominent contributor to intelligence in our brain is the "neocortex".

In contrast to the rest of the brain which has evolved longer and therefore is much more specialized, the relatively new neocortex has a homogenous structure that is re-used throughout.

This structure is basically that the cortex is a 2mm sheet of neurons about the size of a large napkin, crumpled to fit inside our cranium. The sheet is divided into 6 layers of neurons that are connected in a particular way.

Small patches of the cortex represent stages in a hierarchy, and the connections between the neurons is what dictate the boundaries of each patch. Signals pass from lower stages up to higher stages and back down.

The lowest stages are connected to our senses such as eyes, ears and skin via mechanisms of the old brain. The signals passed from here consists of patterns of impulses that make their way up the stages, and it is temporal sequences of these patterns that are learned in each stage.

And perhaps the most important part of the theory is the following; Each stage will try to remember signals coming from lower stages and later predict those signals once they have been remembered. Only the signals that have not been predicted or "learned" will pass to the next stage unchanged, so by every stage the impulses have been refined and condensed into more abstract and high-level information.

 When a stage is seeing a new signal that it cannot predict, it will be sent up to the next stage until one stage recognizes it. If no stage recognize the input, it is forwarded to the hippo-campus which sits at the logical top of the hierarchy. The hippo-campus will keep the unknown information around for a some time until it is no longer useful. Hopefully, the stages below will now have managed to learn it, and if they have not, it will simply be discarded.

Beyond this introductory description of HTM, there are many important details that really describe well how this relatively simple algorithm actually explains our intelligence and sense of being completely.

I can warmly recommend to read the book "On intelligence".

The operation was successful, the patient died.

Extensive refactoring has been made to the build system for OctoMY™, however as it stands now, there are in fact no improvements to be experienced. In fact the build time has increased so much that TravisCI aborts the build thinking it has gone stale!

So why did we bother?

The new build architecture gives us the following benefits:

• We can now select to build each part as a separate library or simply include the sources. Both has its pros and cons, and now we get to choose using a very simple syntax.
• We no longer have to specify build parameters for each library, they are inferred automatically and you only supply them if you need to override the defaults.
• All the include paths have been cleaned up so now all  #include "../libs/libX/subfolder/SomeClass.hpp" are converted to #include "subfolder/SomeClass.hpp"

At this stage it builds fine but more work will have to be put in before we can leverage this new system to get shorter build times and other benefits as promised.

Refactor in progress.

We are working on a large refactoring of the OctoMY™ code base at the moment.

The reason we decided to start this was that the existing project structure was becoming increasingly difficult to work with. Now with the refactor we plan to improve on the following:

• Shorter build times
• More modular design
• Fewer inter-dependencies
• More organized and predictable structure
• Smaller modules

It has taken more effort than anticipated. Hopefully it will resolve itself in a short time.

Achievement unlocked: OctoMY™Travis build passes for the first time!

We finally managed to have OctoMY built using TravisCI.

It took a few days of googling around to get the perfect combination of yaml settings and the result was completely worth it.

We now have a shiny green "passing" button: