rlm@425: #+title: =CORTEX= rlm@425: #+author: Robert McIntyre rlm@425: #+email: rlm@mit.edu rlm@425: #+description: Using embodied AI to facilitate Artificial Imagination. rlm@425: #+keywords: AI, clojure, embodiment rlm@451: #+LaTeX_CLASS_OPTIONS: [nofloat] rlm@422: rlm@465: * COMMENT templates rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+name: name rlm@470: #+begin_listing clojure rlm@479: #+BEGIN_SRC clojure rlm@479: #+END_SRC rlm@470: #+end_listing rlm@465: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+name: name rlm@470: #+ATTR_LaTeX: :width 10cm rlm@470: [[./images/aurellem-gray.png]] rlm@470: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+name: name rlm@470: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@475: #+END_SRC rlm@470: #+end_listing rlm@470: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+caption: rlm@470: #+name: name rlm@470: #+ATTR_LaTeX: :width 10cm rlm@470: [[./images/aurellem-gray.png]] rlm@470: rlm@465: rlm@541: * Empathy \& Embodiment: problem solving strategies rlm@516: rlm@551: By the time you have read this thesis, you will understand a novel rlm@551: approach to representing and recognizing physical actions using rlm@551: embodiment and empathy. You will also see one way to efficiently rlm@551: implement physical empathy for embodied creatures. Finally, you will rlm@551: become familiar with =CORTEX=, a system for designing and simulating rlm@551: creatures with rich senses, which I have designed as a library that rlm@551: you can use in your own research. Note that I /do not/ process video rlm@551: directly --- I start with knowledge of the positions of a creature's rlm@551: body parts and work from there. rlm@437: rlm@516: This is the core vision of my thesis: That one of the important ways rlm@516: in which we understand others is by imagining ourselves in their rlm@516: position and emphatically feeling experiences relative to our own rlm@516: bodies. By understanding events in terms of our own previous rlm@516: corporeal experience, we greatly constrain the possibilities of what rlm@516: would otherwise be an unwieldy exponential search. This extra rlm@516: constraint can be the difference between easily understanding what rlm@516: is happening in a video and being completely lost in a sea of rlm@516: incomprehensible color and movement. rlm@516: rlm@525: ** The problem: recognizing actions is hard! rlm@511: rlm@551: Examine figure \ref{cat-drink}. What is happening? As you, and rlm@551: indeed very young children, can easily determine, this is an image rlm@551: of drinking. rlm@516: rlm@441: #+caption: A cat drinking some water. Identifying this action is rlm@511: #+caption: beyond the capabilities of existing computer vision systems. rlm@551: #+name: cat-drink rlm@441: #+ATTR_LaTeX: :width 7cm rlm@441: [[./images/cat-drinking.jpg]] rlm@511: rlm@511: Nevertheless, it is beyond the state of the art for a computer rlm@516: vision program to describe what's happening in this image. Part of rlm@516: the problem is that many computer vision systems focus on rlm@516: pixel-level details or comparisons to example images (such as rlm@516: \cite{volume-action-recognition}), but the 3D world is so variable rlm@517: that it is hard to describe the world in terms of possible images. rlm@511: rlm@547: In fact, the contents of a scene may have much less to do with rlm@547: pixel probabilities than with recognizing various affordances: rlm@547: things you can move, objects you can grasp, spaces that can be rlm@547: filled . For example, what processes might enable you to see the rlm@547: chair in figure \ref{hidden-chair}? rlm@516: rlm@525: #+caption: The chair in this image is quite obvious to humans, but rlm@525: #+caption: it can't be found by any modern computer vision program. rlm@441: #+name: hidden-chair rlm@441: #+ATTR_LaTeX: :width 10cm rlm@441: [[./images/fat-person-sitting-at-desk.jpg]] rlm@511: rlm@441: Finally, how is it that you can easily tell the difference between rlm@551: how the girl's /muscles/ are working in figure \ref{girl}? rlm@441: rlm@441: #+caption: The mysterious ``common sense'' appears here as you are able rlm@441: #+caption: to discern the difference in how the girl's arm muscles rlm@551: #+caption: are activated between the two images. When you compare rlm@551: #+caption: these two images, do you feel something in your own arm rlm@551: #+caption: muscles? rlm@441: #+name: girl rlm@448: #+ATTR_LaTeX: :width 7cm rlm@441: [[./images/wall-push.png]] rlm@437: rlm@441: Each of these examples tells us something about what might be going rlm@517: on in our minds as we easily solve these recognition problems: rlm@441: rlm@547: - The hidden chair shows us that we are strongly triggered by cues rlm@547: relating to the position of human bodies, and that we can rlm@547: determine the overall physical configuration of a human body even rlm@547: if much of that body is occluded. rlm@547: rlm@547: - The picture of the girl pushing against the wall tells us that we rlm@547: have common sense knowledge about the kinetics of our own bodies. rlm@547: We know well how our muscles would have to work to maintain us in rlm@547: most positions, and we can easily project this self-knowledge to rlm@547: imagined positions triggered by images of the human body. rlm@547: rlm@547: - The cat tells us that imagination of some kind plays an important rlm@547: role in understanding actions. The question is: Can we be more rlm@547: precise about what sort of imagination is required to understand rlm@547: these actions? rlm@517: rlm@511: ** A step forward: the sensorimotor-centered approach rlm@516: rlm@511: In this thesis, I explore the idea that our knowledge of our own rlm@516: bodies, combined with our own rich senses, enables us to recognize rlm@516: the actions of others. rlm@516: rlm@516: For example, I think humans are able to label the cat video as rlm@516: ``drinking'' because they imagine /themselves/ as the cat, and rlm@516: imagine putting their face up against a stream of water and rlm@516: sticking out their tongue. In that imagined world, they can feel rlm@516: the cool water hitting their tongue, and feel the water entering rlm@516: their body, and are able to recognize that /feeling/ as drinking. rlm@516: So, the label of the action is not really in the pixels of the rlm@547: image, but is found clearly in a simulation / recollection inspired rlm@547: by those pixels. An imaginative system, having been trained on rlm@547: drinking and non-drinking examples and learning that the most rlm@551: important component of drinking is the feeling of water flowing rlm@547: down one's throat, would analyze a video of a cat drinking in the rlm@547: following manner: rlm@516: rlm@516: 1. Create a physical model of the video by putting a ``fuzzy'' rlm@516: model of its own body in place of the cat. Possibly also create rlm@516: a simulation of the stream of water. rlm@516: rlm@551: 2. Play out this simulated scene and generate imagined sensory rlm@516: experience. This will include relevant muscle contractions, a rlm@516: close up view of the stream from the cat's perspective, and most rlm@517: importantly, the imagined feeling of water entering the mouth. rlm@517: The imagined sensory experience can come from a simulation of rlm@517: the event, but can also be pattern-matched from previous, rlm@517: similar embodied experience. rlm@516: rlm@516: 3. The action is now easily identified as drinking by the sense of rlm@516: taste alone. The other senses (such as the tongue moving in and rlm@516: out) help to give plausibility to the simulated action. Note that rlm@516: the sense of vision, while critical in creating the simulation, rlm@516: is not critical for identifying the action from the simulation. rlm@516: rlm@516: For the chair examples, the process is even easier: rlm@516: rlm@516: 1. Align a model of your body to the person in the image. rlm@516: rlm@516: 2. Generate proprioceptive sensory data from this alignment. rlm@516: rlm@516: 3. Use the imagined proprioceptive data as a key to lookup related rlm@517: sensory experience associated with that particular proprioceptive rlm@516: feeling. rlm@516: rlm@516: 4. Retrieve the feeling of your bottom resting on a surface, your rlm@516: knees bent, and your leg muscles relaxed. rlm@516: rlm@516: 5. This sensory information is consistent with your =sitting?= rlm@516: sensory predicate, so you (and the entity in the image) must be rlm@516: sitting. rlm@516: rlm@516: 6. There must be a chair-like object since you are sitting. rlm@516: rlm@516: Empathy offers yet another alternative to the age-old AI rlm@516: representation question: ``What is a chair?'' --- A chair is the rlm@516: feeling of sitting! rlm@516: rlm@516: One powerful advantage of empathic problem solving is that it rlm@516: factors the action recognition problem into two easier problems. To rlm@516: use empathy, you need an /aligner/, which takes the video and a rlm@516: model of your body, and aligns the model with the video. Then, you rlm@516: need a /recognizer/, which uses the aligned model to interpret the rlm@516: action. The power in this method lies in the fact that you describe rlm@521: all actions from a body-centered viewpoint. You are less tied to rlm@516: the particulars of any visual representation of the actions. If you rlm@516: teach the system what ``running'' is, and you have a good enough rlm@516: aligner, the system will from then on be able to recognize running rlm@547: from any point of view -- even strange points of view like above or rlm@516: underneath the runner. This is in contrast to action recognition rlm@516: schemes that try to identify actions using a non-embodied approach. rlm@516: If these systems learn about running as viewed from the side, they rlm@516: will not automatically be able to recognize running from any other rlm@516: viewpoint. rlm@516: rlm@516: Another powerful advantage is that using the language of multiple rlm@547: body-centered rich senses to describe body-centered actions offers rlm@547: a massive boost in descriptive capability. Consider how difficult rlm@547: it would be to compose a set of HOG (Histogram of Oriented rlm@547: Gradients) filters to describe the action of a simple worm-creature rlm@547: ``curling'' so that its head touches its tail, and then behold the rlm@547: simplicity of describing thus action in a language designed for the rlm@547: task (listing \ref{grand-circle-intro}): rlm@516: rlm@517: #+caption: Body-centered actions are best expressed in a body-centered rlm@516: #+caption: language. This code detects when the worm has curled into a rlm@516: #+caption: full circle. Imagine how you would replicate this functionality rlm@516: #+caption: using low-level pixel features such as HOG filters! rlm@516: #+name: grand-circle-intro rlm@516: #+begin_listing clojure rlm@516: #+begin_src clojure rlm@516: (defn grand-circle? rlm@516: "Does the worm form a majestic circle (one end touching the other)?" rlm@516: [experiences] rlm@516: (and (curled? experiences) rlm@516: (let [worm-touch (:touch (peek experiences)) rlm@516: tail-touch (worm-touch 0) rlm@516: head-touch (worm-touch 4)] rlm@516: (and (< 0.2 (contact worm-segment-bottom-tip tail-touch)) rlm@516: (< 0.2 (contact worm-segment-top-tip head-touch)))))) rlm@516: #+end_src rlm@516: #+end_listing rlm@516: rlm@517: ** =EMPATH= recognizes actions using empathy rlm@517: rlm@517: Exploring these ideas further demands a concrete implementation, so rlm@517: first, I built a system for constructing virtual creatures with rlm@511: physiologically plausible sensorimotor systems and detailed rlm@551: environments. The result is =CORTEX=, which I describe in chapter rlm@517: \ref{sec-2}. rlm@511: rlm@511: Next, I wrote routines which enabled a simple worm-like creature to rlm@511: infer the actions of a second worm-like creature, using only its rlm@511: own prior sensorimotor experiences and knowledge of the second rlm@511: worm's joint positions. This program, =EMPATH=, is described in rlm@551: chapter \ref{sec-3}. It's main components are: rlm@517: rlm@517: - Embodied Action Definitions :: Many otherwise complicated actions rlm@517: are easily described in the language of a full suite of rlm@517: body-centered, rich senses and experiences. For example, rlm@551: drinking is the feeling of water flowing down your throat, and rlm@448: cooling your insides. It's often accompanied by bringing your rlm@448: hand close to your face, or bringing your face close to water. rlm@448: Sitting down is the feeling of bending your knees, activating rlm@448: your quadriceps, then feeling a surface with your bottom and rlm@448: relaxing your legs. These body-centered action descriptions rlm@448: can be either learned or hard coded. rlm@517: rlm@517: - Guided Play :: The creature moves around and experiences the rlm@517: world through its unique perspective. As the creature moves, rlm@517: it gathers experiences that satisfy the embodied action rlm@517: definitions. rlm@517: rlm@517: - Posture imitation :: When trying to interpret a video or image, rlm@448: the creature takes a model of itself and aligns it with rlm@517: whatever it sees. This alignment might even cross species, as rlm@448: when humans try to align themselves with things like ponies, rlm@448: dogs, or other humans with a different body type. rlm@517: rlm@517: - Empathy :: The alignment triggers associations with rlm@448: sensory data from prior experiences. For example, the rlm@448: alignment itself easily maps to proprioceptive data. Any rlm@448: sounds or obvious skin contact in the video can to a lesser rlm@517: extent trigger previous experience keyed to hearing or touch. rlm@517: Segments of previous experiences gained from play are stitched rlm@517: together to form a coherent and complete sensory portrait of rlm@517: the scene. rlm@517: rlm@547: - Recognition :: With the scene described in terms of remembered rlm@547: first person sensory events, the creature can now run its rlm@547: action-definition programs (such as the one in listing rlm@547: \ref{grand-circle-intro}) on this synthesized sensory data, rlm@517: just as it would if it were actually experiencing the scene rlm@517: first-hand. If previous experience has been accurately rlm@447: retrieved, and if it is analogous enough to the scene, then rlm@447: the creature will correctly identify the action in the scene. rlm@441: rlm@441: My program, =EMPATH= uses this empathic problem solving technique rlm@441: to interpret the actions of a simple, worm-like creature. rlm@437: rlm@441: #+caption: The worm performs many actions during free play such as rlm@441: #+caption: curling, wiggling, and resting. rlm@441: #+name: worm-intro rlm@446: #+ATTR_LaTeX: :width 15cm rlm@445: [[./images/worm-intro-white.png]] rlm@437: rlm@462: #+caption: =EMPATH= recognized and classified each of these rlm@462: #+caption: poses by inferring the complete sensory experience rlm@462: #+caption: from proprioceptive data. rlm@441: #+name: worm-recognition-intro rlm@446: #+ATTR_LaTeX: :width 15cm rlm@445: [[./images/worm-poses.png]] rlm@441: rlm@517: *** Main Results rlm@517: rlm@521: - After one-shot supervised training, =EMPATH= was able to rlm@521: recognize a wide variety of static poses and dynamic rlm@521: actions---ranging from curling in a circle to wiggling with a rlm@521: particular frequency --- with 95\% accuracy. rlm@517: rlm@517: - These results were completely independent of viewing angle rlm@517: because the underlying body-centered language fundamentally is rlm@517: independent; once an action is learned, it can be recognized rlm@517: equally well from any viewing angle. rlm@517: rlm@517: - =EMPATH= is surprisingly short; the sensorimotor-centered rlm@517: language provided by =CORTEX= resulted in extremely economical rlm@517: recognition routines --- about 500 lines in all --- suggesting rlm@517: that such representations are very powerful, and often rlm@517: indispensable for the types of recognition tasks considered here. rlm@517: rlm@551: - For expediency's sake, I relied on direct knowledge of joint rlm@551: positions in this proof of concept. However, I believe that the rlm@551: structure of =EMPATH= and =CORTEX= will make future work to rlm@551: enable video analysis much easier than it would otherwise be. rlm@517: rlm@517: ** =EMPATH= is built on =CORTEX=, a creature builder. rlm@435: rlm@448: I built =CORTEX= to be a general AI research platform for doing rlm@448: experiments involving multiple rich senses and a wide variety and rlm@448: number of creatures. I intend it to be useful as a library for many rlm@462: more projects than just this thesis. =CORTEX= was necessary to meet rlm@462: a need among AI researchers at CSAIL and beyond, which is that rlm@547: people often will invent wonderful ideas that are best expressed in rlm@547: the language of creatures and senses, but in order to explore those rlm@448: ideas they must first build a platform in which they can create rlm@448: simulated creatures with rich senses! There are many ideas that rlm@547: would be simple to execute (such as =EMPATH= or Larson's rlm@547: self-organizing maps (\cite{larson-symbols})), but attached to them rlm@547: is the multi-month effort to make a good creature simulator. Often, rlm@547: that initial investment of time proves to be too much, and the rlm@547: project must make do with a lesser environment or be abandoned rlm@547: entirely. rlm@435: rlm@448: =CORTEX= is well suited as an environment for embodied AI research rlm@448: for three reasons: rlm@448: rlm@547: - You can design new creatures using Blender (\cite{blender}), a rlm@551: popular, free 3D modeling program. Each sense can be specified rlm@551: using special blender nodes with biologically inspired rlm@551: parameters. You need not write any code to create a creature, and rlm@551: can use a wide library of pre-existing blender models as a base rlm@551: for your own creatures. rlm@448: rlm@511: - =CORTEX= implements a wide variety of senses: touch, rlm@448: proprioception, vision, hearing, and muscle tension. Complicated rlm@545: senses like touch and vision involve multiple sensory elements rlm@448: embedded in a 2D surface. You have complete control over the rlm@448: distribution of these sensor elements through the use of simple rlm@551: image files. =CORTEX= implements more comprehensive hearing than rlm@551: any other creature simulation system available. rlm@448: rlm@448: - =CORTEX= supports any number of creatures and any number of rlm@517: senses. Time in =CORTEX= dilates so that the simulated creatures rlm@517: always perceive a perfectly smooth flow of time, regardless of rlm@448: the actual computational load. rlm@448: rlm@517: =CORTEX= is built on top of =jMonkeyEngine3= rlm@517: (\cite{jmonkeyengine}), which is a video game engine designed to rlm@517: create cross-platform 3D desktop games. =CORTEX= is mainly written rlm@551: in clojure, a dialect of =LISP= that runs on the Java Virtual rlm@551: Machine (JVM). The API for creating and simulating creatures and rlm@517: senses is entirely expressed in clojure, though many senses are rlm@517: implemented at the layer of jMonkeyEngine or below. For example, rlm@517: for the sense of hearing I use a layer of clojure code on top of a rlm@517: layer of java JNI bindings that drive a layer of =C++= code which rlm@517: implements a modified version of =OpenAL= to support multiple rlm@517: listeners. =CORTEX= is the only simulation environment that I know rlm@517: of that can support multiple entities that can each hear the world rlm@517: from their own perspective. Other senses also require a small layer rlm@517: of Java code. =CORTEX= also uses =bullet=, a physics simulator rlm@517: written in =C=. rlm@448: rlm@516: #+caption: Here is the worm from figure \ref{worm-intro} modeled rlm@516: #+caption: in Blender, a free 3D-modeling program. Senses and rlm@516: #+caption: joints are described using special nodes in Blender. rlm@518: #+name: worm-recognition-intro-2 rlm@448: #+ATTR_LaTeX: :width 12cm rlm@448: [[./images/blender-worm.png]] rlm@448: rlm@521: Here are some things I anticipate that =CORTEX= might be used for: rlm@449: rlm@449: - exploring new ideas about sensory integration rlm@449: - distributed communication among swarm creatures rlm@449: - self-learning using free exploration, rlm@449: - evolutionary algorithms involving creature construction rlm@517: - exploration of exotic senses and effectors that are not possible rlm@517: in the real world (such as telekinesis or a semantic sense) rlm@449: - imagination using subworlds rlm@449: rlm@451: During one test with =CORTEX=, I created 3,000 creatures each with rlm@551: its own independent senses and ran them all at only 1/80 real time. rlm@551: In another test, I created a detailed model of my own hand, rlm@448: equipped with a realistic distribution of touch (more sensitive at rlm@448: the fingertips), as well as eyes and ears, and it ran at around 1/4 rlm@451: real time. rlm@448: rlm@451: #+BEGIN_LaTeX rlm@449: \begin{sidewaysfigure} rlm@449: \includegraphics[width=9.5in]{images/full-hand.png} rlm@451: \caption{ rlm@451: I modeled my own right hand in Blender and rigged it with all the rlm@451: senses that {\tt CORTEX} supports. My simulated hand has a rlm@451: biologically inspired distribution of touch sensors. The senses are rlm@451: displayed on the right, and the simulation is displayed on the rlm@451: left. Notice that my hand is curling its fingers, that it can see rlm@451: its own finger from the eye in its palm, and that it can feel its rlm@451: own thumb touching its palm.} rlm@449: \end{sidewaysfigure} rlm@451: #+END_LaTeX rlm@448: rlm@551: * COMMENT Designing =CORTEX= rlm@551: rlm@551: In this chapter, I outline the design decisions that went into rlm@516: making =CORTEX=, along with some details about its implementation. rlm@516: (A practical guide to getting started with =CORTEX=, which skips rlm@516: over the history and implementation details presented here, is rlm@516: provided in an appendix at the end of this thesis.) rlm@511: rlm@511: Throughout this project, I intended for =CORTEX= to be flexible and rlm@511: extensible enough to be useful for other researchers who want to rlm@547: test ideas of their own. To this end, wherever I have had to make rlm@517: architectural choices about =CORTEX=, I have chosen to give as much rlm@511: freedom to the user as possible, so that =CORTEX= may be used for rlm@517: things I have not foreseen. rlm@511: rlm@511: ** Building in simulation versus reality rlm@517: The most important architectural decision of all is the choice to rlm@517: use a computer-simulated environment in the first place! The world rlm@462: is a vast and rich place, and for now simulations are a very poor rlm@462: reflection of its complexity. It may be that there is a significant rlm@517: qualitative difference between dealing with senses in the real rlm@517: world and dealing with pale facsimiles of them in a simulation rlm@547: (\cite{brooks-representation}). What are the advantages and rlm@514: disadvantages of a simulation vs. reality? rlm@515: rlm@462: *** Simulation rlm@462: rlm@462: The advantages of virtual reality are that when everything is a rlm@462: simulation, experiments in that simulation are absolutely rlm@547: reproducible. It's also easier to change the creature and rlm@547: environment to explore new situations and different sensory rlm@547: combinations. rlm@462: rlm@462: If the world is to be simulated on a computer, then not only do rlm@547: you have to worry about whether the creature's senses are rich rlm@462: enough to learn from the world, but whether the world itself is rlm@462: rendered with enough detail and realism to give enough working rlm@547: material to the creature's senses. To name just a few rlm@462: difficulties facing modern physics simulators: destructibility of rlm@462: the environment, simulation of water/other fluids, large areas, rlm@462: nonrigid bodies, lots of objects, smoke. I don't know of any rlm@547: computer simulation that would allow a creature to take a rock rlm@462: and grind it into fine dust, then use that dust to make a clay rlm@462: sculpture, at least not without spending years calculating the rlm@462: interactions of every single small grain of dust. Maybe a rlm@462: simulated world with today's limitations doesn't provide enough rlm@462: richness for real intelligence to evolve. rlm@462: rlm@462: *** Reality rlm@462: rlm@462: The other approach for playing with senses is to hook your rlm@462: software up to real cameras, microphones, robots, etc., and let it rlm@462: loose in the real world. This has the advantage of eliminating rlm@462: concerns about simulating the world at the expense of increasing rlm@462: the complexity of implementing the senses. Instead of just rlm@462: grabbing the current rendered frame for processing, you have to rlm@462: use an actual camera with real lenses and interact with photons to rlm@547: get an image. It is much harder to change the creature, which is rlm@462: now partly a physical robot of some sort, since doing so involves rlm@462: changing things around in the real world instead of modifying rlm@462: lines of code. While the real world is very rich and definitely rlm@547: provides enough stimulation for intelligence to develop (as rlm@547: evidenced by our own existence), it is also uncontrollable in the rlm@462: sense that a particular situation cannot be recreated perfectly or rlm@547: saved for later use. It is harder to conduct Science because it is rlm@462: harder to repeat an experiment. The worst thing about using the rlm@462: real world instead of a simulation is the matter of time. Instead rlm@462: of simulated time you get the constant and unstoppable flow of rlm@462: real time. This severely limits the sorts of software you can use rlm@525: to program an AI, because all sense inputs must be handled in real rlm@462: time. Complicated ideas may have to be implemented in hardware or rlm@462: may simply be impossible given the current speed of our rlm@462: processors. Contrast this with a simulation, in which the flow of rlm@462: time in the simulated world can be slowed down to accommodate the rlm@547: limitations of the creature's programming. In terms of cost, doing rlm@547: everything in software is far cheaper than building custom rlm@462: real-time hardware. All you need is a laptop and some patience. rlm@515: rlm@516: ** Simulated time enables rapid prototyping \& simple programs rlm@435: rlm@462: I envision =CORTEX= being used to support rapid prototyping and rlm@462: iteration of ideas. Even if I could put together a well constructed rlm@462: kit for creating robots, it would still not be enough because of rlm@462: the scourge of real-time processing. Anyone who wants to test their rlm@462: ideas in the real world must always worry about getting their rlm@465: algorithms to run fast enough to process information in real time. rlm@465: The need for real time processing only increases if multiple senses rlm@465: are involved. In the extreme case, even simple algorithms will have rlm@465: to be accelerated by ASIC chips or FPGAs, turning what would rlm@517: otherwise be a few lines of code and a 10x speed penalty into a rlm@465: multi-month ordeal. For this reason, =CORTEX= supports rlm@547: /time-dilation/, which scales back the framerate of the simulation rlm@547: in proportion to the amount of processing each frame. From the rlm@547: perspective of the creatures inside the simulation, time always rlm@547: appears to flow at a constant rate, regardless of how complicated rlm@547: the environment becomes or how many creatures are in the rlm@547: simulation. The cost is that =CORTEX= can sometimes run slower than rlm@548: real time. Time dilation works both ways, however --- simulations rlm@547: of very simple creatures in =CORTEX= generally run at 40x real-time rlm@547: on my machine! rlm@462: rlm@511: ** All sense organs are two-dimensional surfaces rlm@514: rlm@468: If =CORTEX= is to support a wide variety of senses, it would help rlm@547: to have a better understanding of what a sense actually is! While rlm@547: vision, touch, and hearing all seem like they are quite different rlm@547: things, I was surprised to learn during the course of this thesis rlm@547: that they (and all physical senses) can be expressed as exactly the rlm@547: same mathematical object! rlm@468: rlm@468: Human beings are three-dimensional objects, and the nerves that rlm@468: transmit data from our various sense organs to our brain are rlm@468: essentially one-dimensional. This leaves up to two dimensions in rlm@468: which our sensory information may flow. For example, imagine your rlm@468: skin: it is a two-dimensional surface around a three-dimensional rlm@468: object (your body). It has discrete touch sensors embedded at rlm@468: various points, and the density of these sensors corresponds to the rlm@468: sensitivity of that region of skin. Each touch sensor connects to a rlm@468: nerve, all of which eventually are bundled together as they travel rlm@468: up the spinal cord to the brain. Intersect the spinal nerves with a rlm@468: guillotining plane and you will see all of the sensory data of the rlm@468: skin revealed in a roughly circular two-dimensional image which is rlm@468: the cross section of the spinal cord. Points on this image that are rlm@468: close together in this circle represent touch sensors that are rlm@468: /probably/ close together on the skin, although there is of course rlm@468: some cutting and rearrangement that has to be done to transfer the rlm@468: complicated surface of the skin onto a two dimensional image. rlm@468: rlm@468: Most human senses consist of many discrete sensors of various rlm@468: properties distributed along a surface at various densities. For rlm@468: skin, it is Pacinian corpuscles, Meissner's corpuscles, Merkel's rlm@547: disks, and Ruffini's endings (\cite{textbook901}), which detect rlm@517: pressure and vibration of various intensities. For ears, it is the rlm@517: stereocilia distributed along the basilar membrane inside the rlm@517: cochlea; each one is sensitive to a slightly different frequency of rlm@517: sound. For eyes, it is rods and cones distributed along the surface rlm@517: of the retina. In each case, we can describe the sense with a rlm@517: surface and a distribution of sensors along that surface. rlm@468: rlm@525: In fact, almost every human sense can be effectively described in rlm@525: terms of a surface containing embedded sensors. If the sense had rlm@525: any more dimensions, then there wouldn't be enough room in the rlm@547: spinal cord to transmit the information! rlm@468: rlm@468: Therefore, =CORTEX= must support the ability to create objects and rlm@468: then be able to ``paint'' points along their surfaces to describe rlm@468: each sense. rlm@468: rlm@468: Fortunately this idea is already a well known computer graphics rlm@548: technique called /UV-mapping/. In UV-mapping, the three-dimensional rlm@547: surface of a model is cut and smooshed until it fits on a rlm@547: two-dimensional image. You paint whatever you want on that image, rlm@547: and when the three-dimensional shape is rendered in a game the rlm@547: smooshing and cutting is reversed and the image appears on the rlm@547: three-dimensional object. rlm@468: rlm@468: To make a sense, interpret the UV-image as describing the rlm@468: distribution of that senses sensors. To get different types of rlm@468: sensors, you can either use a different color for each type of rlm@468: sensor, or use multiple UV-maps, each labeled with that sensor rlm@468: type. I generally use a white pixel to mean the presence of a rlm@468: sensor and a black pixel to mean the absence of a sensor, and use rlm@468: one UV-map for each sensor-type within a given sense. rlm@468: rlm@468: #+CAPTION: The UV-map for an elongated icososphere. The white rlm@468: #+caption: dots each represent a touch sensor. They are dense rlm@468: #+caption: in the regions that describe the tip of the finger, rlm@468: #+caption: and less dense along the dorsal side of the finger rlm@468: #+caption: opposite the tip. rlm@468: #+name: finger-UV rlm@468: #+ATTR_latex: :width 10cm rlm@468: [[./images/finger-UV.png]] rlm@468: rlm@468: #+caption: Ventral side of the UV-mapped finger. Notice the rlm@468: #+caption: density of touch sensors at the tip. rlm@468: #+name: finger-side-view rlm@468: #+ATTR_LaTeX: :width 10cm rlm@468: [[./images/finger-1.png]] rlm@468: rlm@507: ** Video game engines provide ready-made physics and shading rlm@462: rlm@462: I did not need to write my own physics simulation code or shader to rlm@462: build =CORTEX=. Doing so would lead to a system that is impossible rlm@462: for anyone but myself to use anyway. Instead, I use a video game rlm@517: engine as a base and modify it to accommodate the additional needs rlm@462: of =CORTEX=. Video game engines are an ideal starting point to rlm@462: build =CORTEX=, because they are not far from being creature rlm@463: building systems themselves. rlm@462: rlm@462: First off, general purpose video game engines come with a physics rlm@462: engine and lighting / sound system. The physics system provides rlm@462: tools that can be co-opted to serve as touch, proprioception, and rlm@462: muscles. Since some games support split screen views, a good video rlm@462: game engine will allow you to efficiently create multiple cameras rlm@463: in the simulated world that can be used as eyes. Video game systems rlm@463: offer integrated asset management for things like textures and rlm@547: creature models, providing an avenue for defining creatures. They rlm@468: also understand UV-mapping, since this technique is used to apply a rlm@468: texture to a model. Finally, because video game engines support a rlm@547: large number of developers, as long as =CORTEX= doesn't stray too rlm@547: far from the base system, other researchers can turn to this rlm@547: community for help when doing their research. rlm@463: rlm@507: ** =CORTEX= is based on jMonkeyEngine3 rlm@463: rlm@463: While preparing to build =CORTEX= I studied several video game rlm@463: engines to see which would best serve as a base. The top contenders rlm@463: were: rlm@463: rlm@547: - [[http://www.idsoftware.com][Quake II]]/[[http://www.bytonic.de/html/jake2.html][Jake2]] :: The Quake II engine was designed by ID software rlm@547: in 1997. All the source code was released by ID software into rlm@547: the Public Domain several years ago, and as a result it has rlm@547: been ported to many different languages. This engine was rlm@547: famous for its advanced use of realistic shading and it had rlm@547: decent and fast physics simulation. The main advantage of the rlm@547: Quake II engine is its simplicity, but I ultimately rejected rlm@547: it because the engine is too tied to the concept of a rlm@463: first-person shooter game. One of the problems I had was that rlm@463: there does not seem to be any easy way to attach multiple rlm@463: cameras to a single character. There are also several physics rlm@463: clipping issues that are corrected in a way that only applies rlm@463: to the main character and do not apply to arbitrary objects. rlm@463: rlm@463: - [[http://source.valvesoftware.com/][Source Engine]] :: The Source Engine evolved from the Quake II rlm@463: and Quake I engines and is used by Valve in the Half-Life rlm@463: series of games. The physics simulation in the Source Engine rlm@463: is quite accurate and probably the best out of all the engines rlm@463: I investigated. There is also an extensive community actively rlm@463: working with the engine. However, applications that use the rlm@463: Source Engine must be written in C++, the code is not open, it rlm@463: only runs on Windows, and the tools that come with the SDK to rlm@463: handle models and textures are complicated and awkward to use. rlm@463: rlm@463: - [[http://jmonkeyengine.com/][jMonkeyEngine3]] :: jMonkeyEngine3 is a new library for creating rlm@463: games in Java. It uses OpenGL to render to the screen and uses rlm@463: screengraphs to avoid drawing things that do not appear on the rlm@463: screen. It has an active community and several games in the rlm@463: pipeline. The engine was not built to serve any particular rlm@463: game but is instead meant to be used for any 3D game. rlm@463: rlm@521: I chose jMonkeyEngine3 because it had the most features out of all rlm@521: the free projects I looked at, and because I could then write my rlm@521: code in clojure, an implementation of =LISP= that runs on the JVM. rlm@435: rlm@507: ** =CORTEX= uses Blender to create creature models rlm@435: rlm@464: For the simple worm-like creatures I will use later on in this rlm@464: thesis, I could define a simple API in =CORTEX= that would allow rlm@464: one to create boxes, spheres, etc., and leave that API as the sole rlm@464: way to create creatures. However, for =CORTEX= to truly be useful rlm@468: for other projects, it needs a way to construct complicated rlm@464: creatures. If possible, it would be nice to leverage work that has rlm@464: already been done by the community of 3D modelers, or at least rlm@517: enable people who are talented at modeling but not programming to rlm@468: design =CORTEX= creatures. rlm@464: rlm@547: Therefore I use Blender, a free 3D modeling program, as the main rlm@464: way to create creatures in =CORTEX=. However, the creatures modeled rlm@464: in Blender must also be simple to simulate in jMonkeyEngine3's game rlm@468: engine, and must also be easy to rig with =CORTEX='s senses. I rlm@547: accomplish this with extensive use of Blender's ``empty nodes.'' rlm@464: rlm@468: Empty nodes have no mass, physical presence, or appearance, but rlm@468: they can hold metadata and have names. I use a tree structure of rlm@468: empty nodes to specify senses in the following manner: rlm@468: rlm@468: - Create a single top-level empty node whose name is the name of rlm@468: the sense. rlm@468: - Add empty nodes which each contain meta-data relevant to the rlm@468: sense, including a UV-map describing the number/distribution of rlm@468: sensors if applicable. rlm@468: - Make each empty-node the child of the top-level node. rlm@468: rlm@517: #+caption: An example of annotating a creature model with empty rlm@468: #+caption: nodes to describe the layout of senses. There are rlm@468: #+caption: multiple empty nodes which each describe the position rlm@468: #+caption: of muscles, ears, eyes, or joints. rlm@468: #+name: sense-nodes rlm@468: #+ATTR_LaTeX: :width 10cm rlm@468: [[./images/empty-sense-nodes.png]] rlm@468: rlm@508: ** Bodies are composed of segments connected by joints rlm@468: rlm@468: Blender is a general purpose animation tool, which has been used in rlm@468: the past to create high quality movies such as Sintel rlm@547: (\cite{blender}). Though Blender can model and render even rlm@547: complicated things like water, it is crucial to keep models that rlm@547: are meant to be simulated as creatures simple. =Bullet=, which rlm@547: =CORTEX= uses though jMonkeyEngine3, is a rigid-body physics rlm@547: system. This offers a compromise between the expressiveness of a rlm@547: game level and the speed at which it can be simulated, and it means rlm@547: that creatures should be naturally expressed as rigid components rlm@547: held together by joint constraints. rlm@468: rlm@517: But humans are more like a squishy bag wrapped around some hard rlm@517: bones which define the overall shape. When we move, our skin bends rlm@517: and stretches to accommodate the new positions of our bones. rlm@468: rlm@468: One way to make bodies composed of rigid pieces connected by joints rlm@468: /seem/ more human-like is to use an /armature/, (or /rigging/) rlm@468: system, which defines a overall ``body mesh'' and defines how the rlm@468: mesh deforms as a function of the position of each ``bone'' which rlm@468: is a standard rigid body. This technique is used extensively to rlm@468: model humans and create realistic animations. It is not a good rlm@517: technique for physical simulation because it is a lie -- the skin rlm@517: is not a physical part of the simulation and does not interact with rlm@517: any objects in the world or itself. Objects will pass right though rlm@517: the skin until they come in contact with the underlying bone, which rlm@517: is a physical object. Without simulating the skin, the sense of rlm@517: touch has little meaning, and the creature's own vision will lie to rlm@517: it about the true extent of its body. Simulating the skin as a rlm@517: physical object requires some way to continuously update the rlm@517: physical model of the skin along with the movement of the bones, rlm@517: which is unacceptably slow compared to rigid body simulation. rlm@468: rlm@547: Therefore, instead of using the human-like ``bony meatbag'' rlm@547: approach, I decided to base my body plans on multiple solid objects rlm@547: that are connected by joints, inspired by the robot =EVE= from the rlm@547: movie WALL-E. rlm@464: rlm@464: #+caption: =EVE= from the movie WALL-E. This body plan turns rlm@464: #+caption: out to be much better suited to my purposes than a more rlm@464: #+caption: human-like one. rlm@465: #+ATTR_LaTeX: :width 10cm rlm@464: [[./images/Eve.jpg]] rlm@464: rlm@464: =EVE='s body is composed of several rigid components that are held rlm@464: together by invisible joint constraints. This is what I mean by rlm@547: /eve-like/. The main reason that I use eve-like bodies is for rlm@547: simulation efficiency, and so that there will be correspondence rlm@547: between the AI's senses and the physical presence of its body. Each rlm@547: individual section is simulated by a separate rigid body that rlm@547: corresponds exactly with its visual representation and does not rlm@547: change. Sections are connected by invisible joints that are well rlm@547: supported in jMonkeyEngine3. Bullet, the physics backend for rlm@547: jMonkeyEngine3, can efficiently simulate hundreds of rigid bodies rlm@547: connected by joints. Just because sections are rigid does not mean rlm@547: they have to stay as one piece forever; they can be dynamically rlm@547: replaced with multiple sections to simulate splitting in two. This rlm@547: could be used to simulate retractable claws or =EVE='s hands, which rlm@547: are able to coalesce into one object in the movie. rlm@465: rlm@469: *** Solidifying/Connecting a body rlm@465: rlm@469: =CORTEX= creates a creature in two steps: first, it traverses the rlm@469: nodes in the blender file and creates physical representations for rlm@469: any of them that have mass defined in their blender meta-data. rlm@466: rlm@466: #+caption: Program for iterating through the nodes in a blender file rlm@466: #+caption: and generating physical jMonkeyEngine3 objects with mass rlm@466: #+caption: and a matching physics shape. rlm@518: #+name: physical rlm@466: #+begin_listing clojure rlm@466: #+begin_src clojure rlm@466: (defn physical! rlm@466: "Iterate through the nodes in creature and make them real physical rlm@466: objects in the simulation." rlm@466: [#^Node creature] rlm@466: (dorun rlm@466: (map rlm@466: (fn [geom] rlm@466: (let [physics-control rlm@466: (RigidBodyControl. rlm@466: (HullCollisionShape. rlm@466: (.getMesh geom)) rlm@466: (if-let [mass (meta-data geom "mass")] rlm@466: (float mass) (float 1)))] rlm@466: (.addControl geom physics-control))) rlm@466: (filter #(isa? (class %) Geometry ) rlm@466: (node-seq creature))))) rlm@466: #+end_src rlm@466: #+end_listing rlm@465: rlm@469: The next step to making a proper body is to connect those pieces rlm@469: together with joints. jMonkeyEngine has a large array of joints rlm@469: available via =bullet=, such as Point2Point, Cone, Hinge, and a rlm@469: generic Six Degree of Freedom joint, with or without spring rlm@469: restitution. rlm@465: rlm@469: Joints are treated a lot like proper senses, in that there is a rlm@469: top-level empty node named ``joints'' whose children each rlm@469: represent a joint. rlm@466: rlm@469: #+caption: View of the hand model in Blender showing the main ``joints'' rlm@469: #+caption: node (highlighted in yellow) and its children which each rlm@469: #+caption: represent a joint in the hand. Each joint node has metadata rlm@469: #+caption: specifying what sort of joint it is. rlm@469: #+name: blender-hand rlm@469: #+ATTR_LaTeX: :width 10cm rlm@469: [[./images/hand-screenshot1.png]] rlm@469: rlm@469: rlm@469: =CORTEX='s procedure for binding the creature together with joints rlm@469: is as follows: rlm@469: rlm@469: - Find the children of the ``joints'' node. rlm@469: - Determine the two spatials the joint is meant to connect. rlm@469: - Create the joint based on the meta-data of the empty node. rlm@469: rlm@469: The higher order function =sense-nodes= from =cortex.sense= rlm@469: simplifies finding the joints based on their parent ``joints'' rlm@469: node. rlm@466: rlm@466: #+caption: Retrieving the children empty nodes from a single rlm@466: #+caption: named empty node is a common pattern in =CORTEX= rlm@466: #+caption: further instances of this technique for the senses rlm@466: #+caption: will be omitted rlm@466: #+name: get-empty-nodes rlm@466: #+begin_listing clojure rlm@466: #+begin_src clojure rlm@466: (defn sense-nodes rlm@466: "For some senses there is a special empty blender node whose rlm@466: children are considered markers for an instance of that sense. This rlm@466: function generates functions to find those children, given the name rlm@466: of the special parent node." rlm@466: [parent-name] rlm@466: (fn [#^Node creature] rlm@466: (if-let [sense-node (.getChild creature parent-name)] rlm@466: (seq (.getChildren sense-node)) []))) rlm@466: rlm@466: (def rlm@466: ^{:doc "Return the children of the creature's \"joints\" node." rlm@466: :arglists '([creature])} rlm@466: joints rlm@466: (sense-nodes "joints")) rlm@466: #+end_src rlm@466: #+end_listing rlm@466: rlm@469: To find a joint's targets, =CORTEX= creates a small cube, centered rlm@469: around the empty-node, and grows the cube exponentially until it rlm@469: intersects two physical objects. The objects are ordered according rlm@469: to the joint's rotation, with the first one being the object that rlm@469: has more negative coordinates in the joint's reference frame. rlm@469: Since the objects must be physical, the empty-node itself escapes rlm@469: detection. Because the objects must be physical, =joint-targets= rlm@469: must be called /after/ =physical!= is called. rlm@464: rlm@469: #+caption: Program to find the targets of a joint node by rlm@517: #+caption: exponentially growth of a search cube. rlm@469: #+name: joint-targets rlm@469: #+begin_listing clojure rlm@469: #+begin_src clojure rlm@466: (defn joint-targets rlm@466: "Return the two closest two objects to the joint object, ordered rlm@466: from bottom to top according to the joint's rotation." rlm@466: [#^Node parts #^Node joint] rlm@466: (loop [radius (float 0.01)] rlm@466: (let [results (CollisionResults.)] rlm@466: (.collideWith rlm@466: parts rlm@466: (BoundingBox. (.getWorldTranslation joint) rlm@466: radius radius radius) results) rlm@466: (let [targets rlm@466: (distinct rlm@466: (map #(.getGeometry %) results))] rlm@466: (if (>= (count targets) 2) rlm@466: (sort-by rlm@466: #(let [joint-ref-frame-position rlm@466: (jme-to-blender rlm@466: (.mult rlm@466: (.inverse (.getWorldRotation joint)) rlm@466: (.subtract (.getWorldTranslation %) rlm@466: (.getWorldTranslation joint))))] rlm@466: (.dot (Vector3f. 1 1 1) joint-ref-frame-position)) rlm@466: (take 2 targets)) rlm@466: (recur (float (* radius 2)))))))) rlm@469: #+end_src rlm@469: #+end_listing rlm@464: rlm@469: Once =CORTEX= finds all joints and targets, it creates them using rlm@469: a dispatch on the metadata of each joint node. rlm@466: rlm@469: #+caption: Program to dispatch on blender metadata and create joints rlm@517: #+caption: suitable for physical simulation. rlm@469: #+name: joint-dispatch rlm@469: #+begin_listing clojure rlm@469: #+begin_src clojure rlm@466: (defmulti joint-dispatch rlm@466: "Translate blender pseudo-joints into real JME joints." rlm@466: (fn [constraints & _] rlm@466: (:type constraints))) rlm@466: rlm@466: (defmethod joint-dispatch :point rlm@466: [constraints control-a control-b pivot-a pivot-b rotation] rlm@466: (doto (SixDofJoint. control-a control-b pivot-a pivot-b false) rlm@466: (.setLinearLowerLimit Vector3f/ZERO) rlm@466: (.setLinearUpperLimit Vector3f/ZERO))) rlm@466: rlm@466: (defmethod joint-dispatch :hinge rlm@466: [constraints control-a control-b pivot-a pivot-b rotation] rlm@466: (let [axis (if-let [axis (:axis constraints)] axis Vector3f/UNIT_X) rlm@466: [limit-1 limit-2] (:limit constraints) rlm@466: hinge-axis (.mult rotation (blender-to-jme axis))] rlm@466: (doto (HingeJoint. control-a control-b pivot-a pivot-b rlm@466: hinge-axis hinge-axis) rlm@466: (.setLimit limit-1 limit-2)))) rlm@466: rlm@466: (defmethod joint-dispatch :cone rlm@466: [constraints control-a control-b pivot-a pivot-b rotation] rlm@466: (let [limit-xz (:limit-xz constraints) rlm@466: limit-xy (:limit-xy constraints) rlm@466: twist (:twist constraints)] rlm@466: (doto (ConeJoint. control-a control-b pivot-a pivot-b rlm@466: rotation rotation) rlm@466: (.setLimit (float limit-xz) (float limit-xy) rlm@466: (float twist))))) rlm@469: #+end_src rlm@469: #+end_listing rlm@466: rlm@522: All that is left for joints is to combine the above pieces into rlm@469: something that can operate on the collection of nodes that a rlm@469: blender file represents. rlm@466: rlm@469: #+caption: Program to completely create a joint given information rlm@469: #+caption: from a blender file. rlm@469: #+name: connect rlm@469: #+begin_listing clojure rlm@466: #+begin_src clojure rlm@466: (defn connect rlm@466: "Create a joint between 'obj-a and 'obj-b at the location of rlm@466: 'joint. The type of joint is determined by the metadata on 'joint. rlm@466: rlm@466: Here are some examples: rlm@466: {:type :point} rlm@466: {:type :hinge :limit [0 (/ Math/PI 2)] :axis (Vector3f. 0 1 0)} rlm@466: (:axis defaults to (Vector3f. 1 0 0) if not provided for hinge joints) rlm@466: rlm@466: {:type :cone :limit-xz 0] rlm@466: :limit-xy 0] rlm@466: :twist 0]} (use XZY rotation mode in blender!)" rlm@466: [#^Node obj-a #^Node obj-b #^Node joint] rlm@466: (let [control-a (.getControl obj-a RigidBodyControl) rlm@466: control-b (.getControl obj-b RigidBodyControl) rlm@466: joint-center (.getWorldTranslation joint) rlm@466: joint-rotation (.toRotationMatrix (.getWorldRotation joint)) rlm@466: pivot-a (world-to-local obj-a joint-center) rlm@466: pivot-b (world-to-local obj-b joint-center)] rlm@466: (if-let rlm@466: [constraints (map-vals eval (read-string (meta-data joint "joint")))] rlm@466: ;; A side-effect of creating a joint registers rlm@466: ;; it with both physics objects which in turn rlm@466: ;; will register the joint with the physics system rlm@466: ;; when the simulation is started. rlm@466: (joint-dispatch constraints rlm@466: control-a control-b rlm@466: pivot-a pivot-b rlm@466: joint-rotation)))) rlm@469: #+end_src rlm@469: #+end_listing rlm@466: rlm@469: In general, whenever =CORTEX= exposes a sense (or in this case rlm@469: physicality), it provides a function of the type =sense!=, which rlm@469: takes in a collection of nodes and augments it to support that rlm@517: sense. The function returns any controls necessary to use that rlm@517: sense. In this case =body!= creates a physical body and returns no rlm@469: control functions. rlm@466: rlm@469: #+caption: Program to give joints to a creature. rlm@518: #+name: joints rlm@469: #+begin_listing clojure rlm@469: #+begin_src clojure rlm@466: (defn joints! rlm@466: "Connect the solid parts of the creature with physical joints. The rlm@466: joints are taken from the \"joints\" node in the creature." rlm@466: [#^Node creature] rlm@466: (dorun rlm@466: (map rlm@466: (fn [joint] rlm@466: (let [[obj-a obj-b] (joint-targets creature joint)] rlm@466: (connect obj-a obj-b joint))) rlm@466: (joints creature)))) rlm@466: (defn body! rlm@466: "Endow the creature with a physical body connected with joints. The rlm@466: particulars of the joints and the masses of each body part are rlm@466: determined in blender." rlm@466: [#^Node creature] rlm@466: (physical! creature) rlm@466: (joints! creature)) rlm@469: #+end_src rlm@469: #+end_listing rlm@466: rlm@469: All of the code you have just seen amounts to only 130 lines, yet rlm@469: because it builds on top of Blender and jMonkeyEngine3, those few rlm@469: lines pack quite a punch! rlm@466: rlm@469: The hand from figure \ref{blender-hand}, which was modeled after rlm@469: my own right hand, can now be given joints and simulated as a rlm@469: creature. rlm@466: rlm@469: #+caption: With the ability to create physical creatures from blender, rlm@517: #+caption: =CORTEX= gets one step closer to becoming a full creature rlm@469: #+caption: simulation environment. rlm@518: #+name: physical-hand rlm@469: #+ATTR_LaTeX: :width 15cm rlm@469: [[./images/physical-hand.png]] rlm@468: rlm@511: ** Sight reuses standard video game components... rlm@436: rlm@470: Vision is one of the most important senses for humans, so I need to rlm@470: build a simulated sense of vision for my AI. I will do this with rlm@470: simulated eyes. Each eye can be independently moved and should see rlm@470: its own version of the world depending on where it is. rlm@470: rlm@470: Making these simulated eyes a reality is simple because rlm@470: jMonkeyEngine already contains extensive support for multiple views rlm@470: of the same 3D simulated world. The reason jMonkeyEngine has this rlm@470: support is because the support is necessary to create games with rlm@470: split-screen views. Multiple views are also used to create rlm@470: efficient pseudo-reflections by rendering the scene from a certain rlm@470: perspective and then projecting it back onto a surface in the 3D rlm@470: world. rlm@470: rlm@470: #+caption: jMonkeyEngine supports multiple views to enable rlm@470: #+caption: split-screen games, like GoldenEye, which was one of rlm@470: #+caption: the first games to use split-screen views. rlm@518: #+name: goldeneye rlm@470: #+ATTR_LaTeX: :width 10cm rlm@470: [[./images/goldeneye-4-player.png]] rlm@470: rlm@470: *** A Brief Description of jMonkeyEngine's Rendering Pipeline rlm@470: rlm@470: jMonkeyEngine allows you to create a =ViewPort=, which represents a rlm@470: view of the simulated world. You can create as many of these as you rlm@470: want. Every frame, the =RenderManager= iterates through each rlm@470: =ViewPort=, rendering the scene in the GPU. For each =ViewPort= there rlm@470: is a =FrameBuffer= which represents the rendered image in the GPU. rlm@470: rlm@470: #+caption: =ViewPorts= are cameras in the world. During each frame, rlm@470: #+caption: the =RenderManager= records a snapshot of what each view rlm@470: #+caption: is currently seeing; these snapshots are =FrameBuffer= objects. rlm@508: #+name: rendermanagers rlm@470: #+ATTR_LaTeX: :width 10cm rlm@508: [[./images/diagram_rendermanager2.png]] rlm@470: rlm@470: Each =ViewPort= can have any number of attached =SceneProcessor= rlm@470: objects, which are called every time a new frame is rendered. A rlm@470: =SceneProcessor= receives its =ViewPort's= =FrameBuffer= and can do rlm@470: whatever it wants to the data. Often this consists of invoking GPU rlm@470: specific operations on the rendered image. The =SceneProcessor= can rlm@470: also copy the GPU image data to RAM and process it with the CPU. rlm@470: rlm@470: *** Appropriating Views for Vision rlm@470: rlm@470: Each eye in the simulated creature needs its own =ViewPort= so rlm@470: that it can see the world from its own perspective. To this rlm@470: =ViewPort=, I add a =SceneProcessor= that feeds the visual data to rlm@470: any arbitrary continuation function for further processing. That rlm@470: continuation function may perform both CPU and GPU operations on rlm@470: the data. To make this easy for the continuation function, the rlm@470: =SceneProcessor= maintains appropriately sized buffers in RAM to rlm@470: hold the data. It does not do any copying from the GPU to the CPU rlm@470: itself because it is a slow operation. rlm@470: rlm@517: #+caption: Function to make the rendered scene in jMonkeyEngine rlm@470: #+caption: available for further processing. rlm@470: #+name: pipeline-1 rlm@470: #+begin_listing clojure rlm@470: #+begin_src clojure rlm@470: (defn vision-pipeline rlm@470: "Create a SceneProcessor object which wraps a vision processing rlm@470: continuation function. The continuation is a function that takes rlm@470: [#^Renderer r #^FrameBuffer fb #^ByteBuffer b #^BufferedImage bi], rlm@470: each of which has already been appropriately sized." rlm@470: [continuation] rlm@470: (let [byte-buffer (atom nil) rlm@470: renderer (atom nil) rlm@470: image (atom nil)] rlm@470: (proxy [SceneProcessor] [] rlm@470: (initialize rlm@470: [renderManager viewPort] rlm@470: (let [cam (.getCamera viewPort) rlm@470: width (.getWidth cam) rlm@470: height (.getHeight cam)] rlm@470: (reset! renderer (.getRenderer renderManager)) rlm@470: (reset! byte-buffer rlm@470: (BufferUtils/createByteBuffer rlm@470: (* width height 4))) rlm@470: (reset! image (BufferedImage. rlm@470: width height rlm@470: BufferedImage/TYPE_4BYTE_ABGR)))) rlm@470: (isInitialized [] (not (nil? @byte-buffer))) rlm@470: (reshape [_ _ _]) rlm@470: (preFrame [_]) rlm@470: (postQueue [_]) rlm@470: (postFrame rlm@470: [#^FrameBuffer fb] rlm@470: (.clear @byte-buffer) rlm@470: (continuation @renderer fb @byte-buffer @image)) rlm@470: (cleanup [])))) rlm@470: #+end_src rlm@470: #+end_listing rlm@470: rlm@470: The continuation function given to =vision-pipeline= above will be rlm@470: given a =Renderer= and three containers for image data. The rlm@470: =FrameBuffer= references the GPU image data, but the pixel data rlm@470: can not be used directly on the CPU. The =ByteBuffer= and rlm@470: =BufferedImage= are initially "empty" but are sized to hold the rlm@470: data in the =FrameBuffer=. I call transferring the GPU image data rlm@470: to the CPU structures "mixing" the image data. rlm@470: rlm@470: *** Optical sensor arrays are described with images and referenced with metadata rlm@470: rlm@470: The vision pipeline described above handles the flow of rendered rlm@470: images. Now, =CORTEX= needs simulated eyes to serve as the source rlm@470: of these images. rlm@470: rlm@470: An eye is described in blender in the same way as a joint. They rlm@470: are zero dimensional empty objects with no geometry whose local rlm@470: coordinate system determines the orientation of the resulting eye. rlm@470: All eyes are children of a parent node named "eyes" just as all rlm@470: joints have a parent named "joints". An eye binds to the nearest rlm@470: physical object with =bind-sense=. rlm@470: rlm@470: #+caption: Here, the camera is created based on metadata on the rlm@470: #+caption: eye-node and attached to the nearest physical object rlm@470: #+caption: with =bind-sense= rlm@470: #+name: add-eye rlm@470: #+begin_listing clojure rlm@545: #+begin_src clojure rlm@470: (defn add-eye! rlm@470: "Create a Camera centered on the current position of 'eye which rlm@470: follows the closest physical node in 'creature. The camera will rlm@470: point in the X direction and use the Z vector as up as determined rlm@470: by the rotation of these vectors in blender coordinate space. Use rlm@470: XZY rotation for the node in blender." rlm@470: [#^Node creature #^Spatial eye] rlm@470: (let [target (closest-node creature eye) rlm@470: [cam-width cam-height] rlm@470: ;;[640 480] ;; graphics card on laptop doesn't support rlm@517: ;; arbitrary dimensions. rlm@470: (eye-dimensions eye) rlm@470: cam (Camera. cam-width cam-height) rlm@470: rot (.getWorldRotation eye)] rlm@470: (.setLocation cam (.getWorldTranslation eye)) rlm@470: (.lookAtDirection rlm@470: cam ; this part is not a mistake and rlm@470: (.mult rot Vector3f/UNIT_X) ; is consistent with using Z in rlm@470: (.mult rot Vector3f/UNIT_Y)) ; blender as the UP vector. rlm@470: (.setFrustumPerspective rlm@470: cam (float 45) rlm@470: (float (/ (.getWidth cam) (.getHeight cam))) rlm@470: (float 1) rlm@470: (float 1000)) rlm@470: (bind-sense target cam) cam)) rlm@545: #+end_src rlm@470: #+end_listing rlm@470: rlm@470: *** Simulated Retina rlm@470: rlm@470: An eye is a surface (the retina) which contains many discrete rlm@470: sensors to detect light. These sensors can have different rlm@470: light-sensing properties. In humans, each discrete sensor is rlm@470: sensitive to red, blue, green, or gray. These different types of rlm@470: sensors can have different spatial distributions along the retina. rlm@470: In humans, there is a fovea in the center of the retina which has rlm@470: a very high density of color sensors, and a blind spot which has rlm@470: no sensors at all. Sensor density decreases in proportion to rlm@470: distance from the fovea. rlm@470: rlm@470: I want to be able to model any retinal configuration, so my rlm@470: eye-nodes in blender contain metadata pointing to images that rlm@470: describe the precise position of the individual sensors using rlm@470: white pixels. The meta-data also describes the precise sensitivity rlm@470: to light that the sensors described in the image have. An eye can rlm@470: contain any number of these images. For example, the metadata for rlm@470: an eye might look like this: rlm@470: rlm@470: #+begin_src clojure rlm@470: {0xFF0000 "Models/test-creature/retina-small.png"} rlm@470: #+end_src rlm@470: rlm@470: #+caption: An example retinal profile image. White pixels are rlm@470: #+caption: photo-sensitive elements. The distribution of white rlm@470: #+caption: pixels is denser in the middle and falls off at the rlm@470: #+caption: edges and is inspired by the human retina. rlm@470: #+name: retina rlm@510: #+ATTR_LaTeX: :width 7cm rlm@470: [[./images/retina-small.png]] rlm@470: rlm@545: Together, the number 0xFF0000 and the image above describe the rlm@545: placement of red-sensitive sensory elements. rlm@470: rlm@470: Meta-data to very crudely approximate a human eye might be rlm@470: something like this: rlm@470: rlm@470: #+begin_src clojure rlm@470: (let [retinal-profile "Models/test-creature/retina-small.png"] rlm@470: {0xFF0000 retinal-profile rlm@470: 0x00FF00 retinal-profile rlm@470: 0x0000FF retinal-profile rlm@470: 0xFFFFFF retinal-profile}) rlm@470: #+end_src rlm@470: rlm@470: The numbers that serve as keys in the map determine a sensor's rlm@470: relative sensitivity to the channels red, green, and blue. These rlm@470: sensitivity values are packed into an integer in the order rlm@470: =|_|R|G|B|= in 8-bit fields. The RGB values of a pixel in the rlm@470: image are added together with these sensitivities as linear rlm@470: weights. Therefore, 0xFF0000 means sensitive to red only while rlm@470: 0xFFFFFF means sensitive to all colors equally (gray). rlm@470: rlm@470: #+caption: This is the core of vision in =CORTEX=. A given eye node rlm@470: #+caption: is converted into a function that returns visual rlm@470: #+caption: information from the simulation. rlm@471: #+name: vision-kernel rlm@470: #+begin_listing clojure rlm@508: #+BEGIN_SRC clojure rlm@470: (defn vision-kernel rlm@470: "Returns a list of functions, each of which will return a color rlm@470: channel's worth of visual information when called inside a running rlm@470: simulation." rlm@470: [#^Node creature #^Spatial eye & {skip :skip :or {skip 0}}] rlm@470: (let [retinal-map (retina-sensor-profile eye) rlm@470: camera (add-eye! creature eye) rlm@470: vision-image rlm@470: (atom rlm@470: (BufferedImage. (.getWidth camera) rlm@470: (.getHeight camera) rlm@470: BufferedImage/TYPE_BYTE_BINARY)) rlm@470: register-eye! rlm@470: (runonce rlm@470: (fn [world] rlm@470: (add-camera! rlm@470: world camera rlm@470: (let [counter (atom 0)] rlm@470: (fn [r fb bb bi] rlm@470: (if (zero? (rem (swap! counter inc) (inc skip))) rlm@470: (reset! vision-image rlm@470: (BufferedImage! r fb bb bi))))))))] rlm@470: (vec rlm@470: (map rlm@470: (fn [[key image]] rlm@470: (let [whites (white-coordinates image) rlm@470: topology (vec (collapse whites)) rlm@470: sensitivity (sensitivity-presets key key)] rlm@470: (attached-viewport. rlm@470: (fn [world] rlm@470: (register-eye! world) rlm@470: (vector rlm@470: topology rlm@470: (vec rlm@470: (for [[x y] whites] rlm@470: (pixel-sense rlm@470: sensitivity rlm@470: (.getRGB @vision-image x y)))))) rlm@470: register-eye!))) rlm@470: retinal-map)))) rlm@508: #+END_SRC rlm@470: #+end_listing rlm@470: rlm@470: Note that since each of the functions generated by =vision-kernel= rlm@470: shares the same =register-eye!= function, the eye will be rlm@470: registered only once the first time any of the functions from the rlm@470: list returned by =vision-kernel= is called. Each of the functions rlm@470: returned by =vision-kernel= also allows access to the =Viewport= rlm@470: through which it receives images. rlm@470: rlm@470: All the hard work has been done; all that remains is to apply rlm@470: =vision-kernel= to each eye in the creature and gather the results rlm@470: into one list of functions. rlm@470: rlm@470: rlm@470: #+caption: With =vision!=, =CORTEX= is already a fine simulation rlm@470: #+caption: environment for experimenting with different types of rlm@470: #+caption: eyes. rlm@470: #+name: vision! rlm@470: #+begin_listing clojure rlm@508: #+BEGIN_SRC clojure rlm@470: (defn vision! rlm@470: "Returns a list of functions, each of which returns visual sensory rlm@470: data when called inside a running simulation." rlm@470: [#^Node creature & {skip :skip :or {skip 0}}] rlm@470: (reduce rlm@470: concat rlm@470: (for [eye (eyes creature)] rlm@470: (vision-kernel creature eye)))) rlm@508: #+END_SRC rlm@470: #+end_listing rlm@470: rlm@471: #+caption: Simulated vision with a test creature and the rlm@471: #+caption: human-like eye approximation. Notice how each channel rlm@471: #+caption: of the eye responds differently to the differently rlm@471: #+caption: colored balls. rlm@471: #+name: worm-vision-test. rlm@471: #+ATTR_LaTeX: :width 13cm rlm@471: [[./images/worm-vision.png]] rlm@470: rlm@471: The vision code is not much more complicated than the body code, rlm@471: and enables multiple further paths for simulated vision. For rlm@471: example, it is quite easy to create bifocal vision -- you just rlm@471: make two eyes next to each other in blender! It is also possible rlm@471: to encode vision transforms in the retinal files. For example, the rlm@471: human like retina file in figure \ref{retina} approximates a rlm@471: log-polar transform. rlm@470: rlm@471: This vision code has already been absorbed by the jMonkeyEngine rlm@471: community and is now (in modified form) part of a system for rlm@471: capturing in-game video to a file. rlm@470: rlm@511: ** ...but hearing must be built from scratch rlm@514: rlm@551: At the end of this chapter I will have simulated ears that work the rlm@551: same way as the simulated eyes in the last chapter. I will be able to rlm@472: place any number of ear-nodes in a blender file, and they will bind to rlm@472: the closest physical object and follow it as it moves around. Each ear rlm@472: will provide access to the sound data it picks up between every frame. rlm@472: rlm@472: Hearing is one of the more difficult senses to simulate, because there rlm@472: is less support for obtaining the actual sound data that is processed rlm@472: by jMonkeyEngine3. There is no "split-screen" support for rendering rlm@472: sound from different points of view, and there is no way to directly rlm@472: access the rendered sound data. rlm@472: rlm@472: =CORTEX='s hearing is unique because it does not have any rlm@472: limitations compared to other simulation environments. As far as I rlm@517: know, there is no other system that supports multiple listeners, rlm@551: and the sound demo at the end of this chapter is the first time rlm@472: it's been done in a video game environment. rlm@472: rlm@472: *** Brief Description of jMonkeyEngine's Sound System rlm@472: rlm@472: jMonkeyEngine's sound system works as follows: rlm@472: rlm@472: - jMonkeyEngine uses the =AppSettings= for the particular rlm@472: application to determine what sort of =AudioRenderer= should be rlm@472: used. rlm@472: - Although some support is provided for multiple AudioRendering rlm@472: backends, jMonkeyEngine at the time of this writing will either rlm@472: pick no =AudioRenderer= at all, or the =LwjglAudioRenderer=. rlm@472: - jMonkeyEngine tries to figure out what sort of system you're rlm@472: running and extracts the appropriate native libraries. rlm@472: - The =LwjglAudioRenderer= uses the [[http://lwjgl.org/][=LWJGL=]] (LightWeight Java Game rlm@472: Library) bindings to interface with a C library called [[http://kcat.strangesoft.net/openal.html][=OpenAL=]] rlm@472: - =OpenAL= renders the 3D sound and feeds the rendered sound rlm@472: directly to any of various sound output devices with which it rlm@472: knows how to communicate. rlm@472: rlm@472: A consequence of this is that there's no way to access the actual rlm@472: sound data produced by =OpenAL=. Even worse, =OpenAL= only supports rlm@472: one /listener/ (it renders sound data from only one perspective), rlm@472: which normally isn't a problem for games, but becomes a problem rlm@472: when trying to make multiple AI creatures that can each hear the rlm@472: world from a different perspective. rlm@472: rlm@472: To make many AI creatures in jMonkeyEngine that can each hear the rlm@472: world from their own perspective, or to make a single creature with rlm@472: many ears, it is necessary to go all the way back to =OpenAL= and rlm@472: implement support for simulated hearing there. rlm@472: rlm@472: *** Extending =OpenAl= rlm@472: rlm@472: Extending =OpenAL= to support multiple listeners requires 500 rlm@472: lines of =C= code and is too hairy to mention here. Instead, I rlm@472: will show a small amount of extension code and go over the high rlm@517: level strategy. Full source is of course available with the rlm@472: =CORTEX= distribution if you're interested. rlm@472: rlm@472: =OpenAL= goes to great lengths to support many different systems, rlm@472: all with different sound capabilities and interfaces. It rlm@472: accomplishes this difficult task by providing code for many rlm@472: different sound backends in pseudo-objects called /Devices/. rlm@472: There's a device for the Linux Open Sound System and the Advanced rlm@472: Linux Sound Architecture, there's one for Direct Sound on Windows, rlm@472: and there's even one for Solaris. =OpenAL= solves the problem of rlm@472: platform independence by providing all these Devices. rlm@472: rlm@472: Wrapper libraries such as LWJGL are free to examine the system on rlm@472: which they are running and then select an appropriate device for rlm@472: that system. rlm@472: rlm@472: There are also a few "special" devices that don't interface with rlm@472: any particular system. These include the Null Device, which rlm@472: doesn't do anything, and the Wave Device, which writes whatever rlm@472: sound it receives to a file, if everything has been set up rlm@472: correctly when configuring =OpenAL=. rlm@472: rlm@517: Actual mixing (Doppler shift and distance.environment-based rlm@472: attenuation) of the sound data happens in the Devices, and they rlm@472: are the only point in the sound rendering process where this data rlm@472: is available. rlm@472: rlm@472: Therefore, in order to support multiple listeners, and get the rlm@472: sound data in a form that the AIs can use, it is necessary to rlm@472: create a new Device which supports this feature. rlm@472: rlm@472: Adding a device to OpenAL is rather tricky -- there are five rlm@472: separate files in the =OpenAL= source tree that must be modified rlm@472: to do so. I named my device the "Multiple Audio Send" Device, or rlm@472: =Send= Device for short, since it sends audio data back to the rlm@472: calling application like an Aux-Send cable on a mixing board. rlm@472: rlm@472: The main idea behind the Send device is to take advantage of the rlm@472: fact that LWJGL only manages one /context/ when using OpenAL. A rlm@472: /context/ is like a container that holds samples and keeps track rlm@472: of where the listener is. In order to support multiple listeners, rlm@472: the Send device identifies the LWJGL context as the master rlm@472: context, and creates any number of slave contexts to represent rlm@472: additional listeners. Every time the device renders sound, it rlm@472: synchronizes every source from the master LWJGL context to the rlm@472: slave contexts. Then, it renders each context separately, using a rlm@472: different listener for each one. The rendered sound is made rlm@472: available via JNI to jMonkeyEngine. rlm@472: rlm@472: Switching between contexts is not the normal operation of a rlm@472: Device, and one of the problems with doing so is that a Device rlm@472: normally keeps around a few pieces of state such as the rlm@472: =ClickRemoval= array above which will become corrupted if the rlm@472: contexts are not rendered in parallel. The solution is to create a rlm@472: copy of this normally global device state for each context, and rlm@472: copy it back and forth into and out of the actual device state rlm@472: whenever a context is rendered. rlm@472: rlm@472: The core of the =Send= device is the =syncSources= function, which rlm@472: does the job of copying all relevant data from one context to rlm@472: another. rlm@472: rlm@472: #+caption: Program for extending =OpenAL= to support multiple rlm@472: #+caption: listeners via context copying/switching. rlm@472: #+name: sync-openal-sources rlm@509: #+begin_listing c rlm@509: #+BEGIN_SRC c rlm@472: void syncSources(ALsource *masterSource, ALsource *slaveSource, rlm@472: ALCcontext *masterCtx, ALCcontext *slaveCtx){ rlm@472: ALuint master = masterSource->source; rlm@472: ALuint slave = slaveSource->source; rlm@472: ALCcontext *current = alcGetCurrentContext(); rlm@472: rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_PITCH); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_GAIN); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_MAX_DISTANCE); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_ROLLOFF_FACTOR); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_REFERENCE_DISTANCE); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_MIN_GAIN); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_MAX_GAIN); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_CONE_OUTER_GAIN); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_CONE_INNER_ANGLE); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_CONE_OUTER_ANGLE); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_SEC_OFFSET); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_SAMPLE_OFFSET); rlm@472: syncSourcef(master,slave,masterCtx,slaveCtx,AL_BYTE_OFFSET); rlm@472: rlm@472: syncSource3f(master,slave,masterCtx,slaveCtx,AL_POSITION); rlm@472: syncSource3f(master,slave,masterCtx,slaveCtx,AL_VELOCITY); rlm@472: syncSource3f(master,slave,masterCtx,slaveCtx,AL_DIRECTION); rlm@472: rlm@472: syncSourcei(master,slave,masterCtx,slaveCtx,AL_SOURCE_RELATIVE); rlm@472: syncSourcei(master,slave,masterCtx,slaveCtx,AL_LOOPING); rlm@472: rlm@472: alcMakeContextCurrent(masterCtx); rlm@472: ALint source_type; rlm@472: alGetSourcei(master, AL_SOURCE_TYPE, &source_type); rlm@472: rlm@472: // Only static sources are currently synchronized! rlm@472: if (AL_STATIC == source_type){ rlm@472: ALint master_buffer; rlm@472: ALint slave_buffer; rlm@472: alGetSourcei(master, AL_BUFFER, &master_buffer); rlm@472: alcMakeContextCurrent(slaveCtx); rlm@472: alGetSourcei(slave, AL_BUFFER, &slave_buffer); rlm@472: if (master_buffer != slave_buffer){ rlm@472: alSourcei(slave, AL_BUFFER, master_buffer); rlm@472: } rlm@472: } rlm@472: rlm@472: // Synchronize the state of the two sources. rlm@472: alcMakeContextCurrent(masterCtx); rlm@472: ALint masterState; rlm@472: ALint slaveState; rlm@472: rlm@472: alGetSourcei(master, AL_SOURCE_STATE, &masterState); rlm@472: alcMakeContextCurrent(slaveCtx); rlm@472: alGetSourcei(slave, AL_SOURCE_STATE, &slaveState); rlm@472: rlm@472: if (masterState != slaveState){ rlm@472: switch (masterState){ rlm@472: case AL_INITIAL : alSourceRewind(slave); break; rlm@472: case AL_PLAYING : alSourcePlay(slave); break; rlm@472: case AL_PAUSED : alSourcePause(slave); break; rlm@472: case AL_STOPPED : alSourceStop(slave); break; rlm@472: } rlm@472: } rlm@472: // Restore whatever context was previously active. rlm@472: alcMakeContextCurrent(current); rlm@472: } rlm@508: #+END_SRC rlm@472: #+end_listing rlm@472: rlm@472: With this special context-switching device, and some ugly JNI rlm@472: bindings that are not worth mentioning, =CORTEX= gains the ability rlm@472: to access multiple sound streams from =OpenAL=. rlm@472: rlm@472: #+caption: Program to create an ear from a blender empty node. The ear rlm@472: #+caption: follows around the nearest physical object and passes rlm@472: #+caption: all sensory data to a continuation function. rlm@472: #+name: add-ear rlm@472: #+begin_listing clojure rlm@508: #+BEGIN_SRC clojure rlm@472: (defn add-ear! rlm@472: "Create a Listener centered on the current position of 'ear rlm@472: which follows the closest physical node in 'creature and rlm@472: sends sound data to 'continuation." rlm@472: [#^Application world #^Node creature #^Spatial ear continuation] rlm@472: (let [target (closest-node creature ear) rlm@472: lis (Listener.) rlm@472: audio-renderer (.getAudioRenderer world) rlm@472: sp (hearing-pipeline continuation)] rlm@472: (.setLocation lis (.getWorldTranslation ear)) rlm@472: (.setRotation lis (.getWorldRotation ear)) rlm@472: (bind-sense target lis) rlm@472: (update-listener-velocity! target lis) rlm@472: (.addListener audio-renderer lis) rlm@472: (.registerSoundProcessor audio-renderer lis sp))) rlm@508: #+END_SRC rlm@472: #+end_listing rlm@472: rlm@472: The =Send= device, unlike most of the other devices in =OpenAL=, rlm@472: does not render sound unless asked. This enables the system to rlm@472: slow down or speed up depending on the needs of the AIs who are rlm@472: using it to listen. If the device tried to render samples in rlm@472: real-time, a complicated AI whose mind takes 100 seconds of rlm@472: computer time to simulate 1 second of AI-time would miss almost rlm@472: all of the sound in its environment! rlm@472: rlm@472: #+caption: Program to enable arbitrary hearing in =CORTEX= rlm@472: #+name: hearing rlm@472: #+begin_listing clojure rlm@508: #+BEGIN_SRC clojure rlm@472: (defn hearing-kernel rlm@472: "Returns a function which returns auditory sensory data when called rlm@472: inside a running simulation." rlm@472: [#^Node creature #^Spatial ear] rlm@472: (let [hearing-data (atom []) rlm@472: register-listener! rlm@472: (runonce rlm@472: (fn [#^Application world] rlm@472: (add-ear! rlm@472: world creature ear rlm@472: (comp #(reset! hearing-data %) rlm@472: byteBuffer->pulse-vector))))] rlm@472: (fn [#^Application world] rlm@472: (register-listener! world) rlm@472: (let [data @hearing-data rlm@472: topology rlm@472: (vec (map #(vector % 0) (range 0 (count data))))] rlm@472: [topology data])))) rlm@472: rlm@472: (defn hearing! rlm@472: "Endow the creature in a particular world with the sense of rlm@472: hearing. Will return a sequence of functions, one for each ear, rlm@472: which when called will return the auditory data from that ear." rlm@472: [#^Node creature] rlm@472: (for [ear (ears creature)] rlm@472: (hearing-kernel creature ear))) rlm@508: #+END_SRC rlm@472: #+end_listing rlm@472: rlm@472: Armed with these functions, =CORTEX= is able to test possibly the rlm@472: first ever instance of multiple listeners in a video game engine rlm@472: based simulation! rlm@472: rlm@472: #+caption: Here a simple creature responds to sound by changing rlm@472: #+caption: its color from gray to green when the total volume rlm@472: #+caption: goes over a threshold. rlm@472: #+name: sound-test rlm@472: #+begin_listing java rlm@508: #+BEGIN_SRC java rlm@472: /** rlm@472: * Respond to sound! This is the brain of an AI entity that rlm@472: * hears its surroundings and reacts to them. rlm@472: */ rlm@472: public void process(ByteBuffer audioSamples, rlm@472: int numSamples, AudioFormat format) { rlm@472: audioSamples.clear(); rlm@472: byte[] data = new byte[numSamples]; rlm@472: float[] out = new float[numSamples]; rlm@472: audioSamples.get(data); rlm@472: FloatSampleTools. rlm@472: byte2floatInterleaved rlm@472: (data, 0, out, 0, numSamples/format.getFrameSize(), format); rlm@472: rlm@472: float max = Float.NEGATIVE_INFINITY; rlm@472: for (float f : out){if (f > max) max = f;} rlm@472: audioSamples.clear(); rlm@472: rlm@472: if (max > 0.1){ rlm@472: entity.getMaterial().setColor("Color", ColorRGBA.Green); rlm@472: } rlm@472: else { rlm@472: entity.getMaterial().setColor("Color", ColorRGBA.Gray); rlm@472: } rlm@508: #+END_SRC rlm@472: #+end_listing rlm@472: rlm@517: #+caption: First ever simulation of multiple listeners in =CORTEX=. rlm@472: #+caption: Each cube is a creature which processes sound data with rlm@472: #+caption: the =process= function from listing \ref{sound-test}. rlm@517: #+caption: the ball is constantly emitting a pure tone of rlm@472: #+caption: constant volume. As it approaches the cubes, they each rlm@472: #+caption: change color in response to the sound. rlm@472: #+name: sound-cubes. rlm@472: #+ATTR_LaTeX: :width 10cm rlm@509: [[./images/java-hearing-test.png]] rlm@472: rlm@472: This system of hearing has also been co-opted by the rlm@472: jMonkeyEngine3 community and is used to record audio for demo rlm@472: videos. rlm@472: rlm@511: ** Hundreds of hair-like elements provide a sense of touch rlm@436: rlm@474: Touch is critical to navigation and spatial reasoning and as such I rlm@474: need a simulated version of it to give to my AI creatures. rlm@474: rlm@474: Human skin has a wide array of touch sensors, each of which rlm@474: specialize in detecting different vibrational modes and pressures. rlm@474: These sensors can integrate a vast expanse of skin (i.e. your rlm@474: entire palm), or a tiny patch of skin at the tip of your finger. rlm@474: The hairs of the skin help detect objects before they even come rlm@474: into contact with the skin proper. rlm@474: rlm@474: However, touch in my simulated world can not exactly correspond to rlm@474: human touch because my creatures are made out of completely rigid rlm@474: segments that don't deform like human skin. rlm@474: rlm@474: Instead of measuring deformation or vibration, I surround each rlm@474: rigid part with a plenitude of hair-like objects (/feelers/) which rlm@474: do not interact with the physical world. Physical objects can pass rlm@474: through them with no effect. The feelers are able to tell when rlm@474: other objects pass through them, and they constantly report how rlm@474: much of their extent is covered. So even though the creature's body rlm@474: parts do not deform, the feelers create a margin around those body rlm@474: parts which achieves a sense of touch which is a hybrid between a rlm@474: human's sense of deformation and sense from hairs. rlm@474: rlm@474: Implementing touch in jMonkeyEngine follows a different technical rlm@474: route than vision and hearing. Those two senses piggybacked off rlm@474: jMonkeyEngine's 3D audio and video rendering subsystems. To rlm@474: simulate touch, I use jMonkeyEngine's physics system to execute rlm@474: many small collision detections, one for each feeler. The placement rlm@474: of the feelers is determined by a UV-mapped image which shows where rlm@474: each feeler should be on the 3D surface of the body. rlm@474: rlm@477: *** Defining Touch Meta-Data in Blender rlm@474: rlm@474: Each geometry can have a single UV map which describes the rlm@474: position of the feelers which will constitute its sense of touch. rlm@474: This image path is stored under the ``touch'' key. The image itself rlm@474: is black and white, with black meaning a feeler length of 0 (no rlm@474: feeler is present) and white meaning a feeler length of =scale=, rlm@474: which is a float stored under the key "scale". rlm@474: rlm@475: #+caption: Touch does not use empty nodes, to store metadata, rlm@475: #+caption: because the metadata of each solid part of a rlm@475: #+caption: creature's body is sufficient. rlm@475: #+name: touch-meta-data rlm@475: #+begin_listing clojure rlm@477: #+BEGIN_SRC clojure rlm@474: (defn tactile-sensor-profile rlm@474: "Return the touch-sensor distribution image in BufferedImage format, rlm@474: or nil if it does not exist." rlm@474: [#^Geometry obj] rlm@474: (if-let [image-path (meta-data obj "touch")] rlm@474: (load-image image-path))) rlm@474: rlm@474: (defn tactile-scale rlm@474: "Return the length of each feeler. Default scale is 0.01 rlm@474: jMonkeyEngine units." rlm@474: [#^Geometry obj] rlm@474: (if-let [scale (meta-data obj "scale")] rlm@474: scale 0.1)) rlm@477: #+END_SRC rlm@475: #+end_listing rlm@474: rlm@475: Here is an example of a UV-map which specifies the position of rlm@475: touch sensors along the surface of the upper segment of a fingertip. rlm@474: rlm@475: #+caption: This is the tactile-sensor-profile for the upper segment rlm@475: #+caption: of a fingertip. It defines regions of high touch sensitivity rlm@475: #+caption: (where there are many white pixels) and regions of low rlm@475: #+caption: sensitivity (where white pixels are sparse). rlm@486: #+name: fingertip-UV rlm@477: #+ATTR_LaTeX: :width 13cm rlm@477: [[./images/finger-UV.png]] rlm@474: rlm@477: *** Implementation Summary rlm@474: rlm@474: To simulate touch there are three conceptual steps. For each solid rlm@474: object in the creature, you first have to get UV image and scale rlm@474: parameter which define the position and length of the feelers. rlm@474: Then, you use the triangles which comprise the mesh and the UV rlm@474: data stored in the mesh to determine the world-space position and rlm@474: orientation of each feeler. Then once every frame, update these rlm@474: positions and orientations to match the current position and rlm@474: orientation of the object, and use physics collision detection to rlm@474: gather tactile data. rlm@474: rlm@474: Extracting the meta-data has already been described. The third rlm@474: step, physics collision detection, is handled in =touch-kernel=. rlm@474: Translating the positions and orientations of the feelers from the rlm@474: UV-map to world-space is itself a three-step process. rlm@474: rlm@475: - Find the triangles which make up the mesh in pixel-space and in rlm@505: world-space. \\(=triangles=, =pixel-triangles=). rlm@474: rlm@475: - Find the coordinates of each feeler in world-space. These are rlm@475: the origins of the feelers. (=feeler-origins=). rlm@474: rlm@475: - Calculate the normals of the triangles in world space, and add rlm@475: them to each of the origins of the feelers. These are the rlm@475: normalized coordinates of the tips of the feelers. rlm@475: (=feeler-tips=). rlm@474: rlm@477: *** Triangle Math rlm@474: rlm@475: The rigid objects which make up a creature have an underlying rlm@475: =Geometry=, which is a =Mesh= plus a =Material= and other rlm@475: important data involved with displaying the object. rlm@475: rlm@475: A =Mesh= is composed of =Triangles=, and each =Triangle= has three rlm@475: vertices which have coordinates in world space and UV space. rlm@475: rlm@475: Here, =triangles= gets all the world-space triangles which rlm@475: comprise a mesh, while =pixel-triangles= gets those same triangles rlm@475: expressed in pixel coordinates (which are UV coordinates scaled to rlm@475: fit the height and width of the UV image). rlm@474: rlm@475: #+caption: Programs to extract triangles from a geometry and get rlm@517: #+caption: their vertices in both world and UV-coordinates. rlm@475: #+name: get-triangles rlm@475: #+begin_listing clojure rlm@477: #+BEGIN_SRC clojure rlm@474: (defn triangle rlm@474: "Get the triangle specified by triangle-index from the mesh." rlm@474: [#^Geometry geo triangle-index] rlm@474: (triangle-seq rlm@474: (let [scratch (Triangle.)] rlm@474: (.getTriangle (.getMesh geo) triangle-index scratch) scratch))) rlm@474: rlm@474: (defn triangles rlm@474: "Return a sequence of all the Triangles which comprise a given rlm@474: Geometry." rlm@474: [#^Geometry geo] rlm@474: (map (partial triangle geo) (range (.getTriangleCount (.getMesh geo))))) rlm@474: rlm@474: (defn triangle-vertex-indices rlm@474: "Get the triangle vertex indices of a given triangle from a given rlm@474: mesh." rlm@474: [#^Mesh mesh triangle-index] rlm@474: (let [indices (int-array 3)] rlm@474: (.getTriangle mesh triangle-index indices) rlm@474: (vec indices))) rlm@474: rlm@475: (defn vertex-UV-coord rlm@474: "Get the UV-coordinates of the vertex named by vertex-index" rlm@474: [#^Mesh mesh vertex-index] rlm@474: (let [UV-buffer rlm@474: (.getData rlm@474: (.getBuffer rlm@474: mesh rlm@474: VertexBuffer$Type/TexCoord))] rlm@474: [(.get UV-buffer (* vertex-index 2)) rlm@474: (.get UV-buffer (+ 1 (* vertex-index 2)))])) rlm@474: rlm@474: (defn pixel-triangle [#^Geometry geo image index] rlm@474: (let [mesh (.getMesh geo) rlm@474: width (.getWidth image) rlm@474: height (.getHeight image)] rlm@474: (vec (map (fn [[u v]] (vector (* width u) (* height v))) rlm@474: (map (partial vertex-UV-coord mesh) rlm@474: (triangle-vertex-indices mesh index)))))) rlm@474: rlm@474: (defn pixel-triangles rlm@474: "The pixel-space triangles of the Geometry, in the same order as rlm@474: (triangles geo)" rlm@474: [#^Geometry geo image] rlm@474: (let [height (.getHeight image) rlm@474: width (.getWidth image)] rlm@474: (map (partial pixel-triangle geo image) rlm@474: (range (.getTriangleCount (.getMesh geo)))))) rlm@477: #+END_SRC rlm@475: #+end_listing rlm@475: rlm@474: *** The Affine Transform from one Triangle to Another rlm@474: rlm@475: =pixel-triangles= gives us the mesh triangles expressed in pixel rlm@475: coordinates and =triangles= gives us the mesh triangles expressed rlm@475: in world coordinates. The tactile-sensor-profile gives the rlm@475: position of each feeler in pixel-space. In order to convert rlm@475: pixel-space coordinates into world-space coordinates we need rlm@475: something that takes coordinates on the surface of one triangle rlm@475: and gives the corresponding coordinates on the surface of another rlm@475: triangle. rlm@475: rlm@475: Triangles are [[http://mathworld.wolfram.com/AffineTransformation.html ][affine]], which means any triangle can be transformed rlm@475: into any other by a combination of translation, scaling, and rlm@475: rotation. The affine transformation from one triangle to another rlm@475: is readily computable if the triangle is expressed in terms of a rlm@475: $4x4$ matrix. rlm@476: rlm@476: #+BEGIN_LaTeX rlm@476: $$ rlm@475: \begin{bmatrix} rlm@475: x_1 & x_2 & x_3 & n_x \\ rlm@475: y_1 & y_2 & y_3 & n_y \\ rlm@475: z_1 & z_2 & z_3 & n_z \\ rlm@475: 1 & 1 & 1 & 1 rlm@475: \end{bmatrix} rlm@476: $$ rlm@476: #+END_LaTeX rlm@475: rlm@475: Here, the first three columns of the matrix are the vertices of rlm@475: the triangle. The last column is the right-handed unit normal of rlm@475: the triangle. rlm@475: rlm@476: With two triangles $T_{1}$ and $T_{2}$ each expressed as a rlm@476: matrix like above, the affine transform from $T_{1}$ to $T_{2}$ rlm@476: is $T_{2}T_{1}^{-1}$. rlm@475: rlm@475: The clojure code below recapitulates the formulas above, using rlm@475: jMonkeyEngine's =Matrix4f= objects, which can describe any affine rlm@475: transformation. rlm@474: rlm@517: #+caption: Program to interpret triangles as affine transforms. rlm@475: #+name: triangle-affine rlm@475: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@474: (defn triangle->matrix4f rlm@474: "Converts the triangle into a 4x4 matrix: The first three columns rlm@474: contain the vertices of the triangle; the last contains the unit rlm@474: normal of the triangle. The bottom row is filled with 1s." rlm@474: [#^Triangle t] rlm@474: (let [mat (Matrix4f.) rlm@474: [vert-1 vert-2 vert-3] rlm@474: (mapv #(.get t %) (range 3)) rlm@474: unit-normal (do (.calculateNormal t)(.getNormal t)) rlm@474: vertices [vert-1 vert-2 vert-3 unit-normal]] rlm@474: (dorun rlm@474: (for [row (range 4) col (range 3)] rlm@474: (do rlm@474: (.set mat col row (.get (vertices row) col)) rlm@474: (.set mat 3 row 1)))) mat)) rlm@474: rlm@474: (defn triangles->affine-transform rlm@474: "Returns the affine transformation that converts each vertex in the rlm@474: first triangle into the corresponding vertex in the second rlm@474: triangle." rlm@474: [#^Triangle tri-1 #^Triangle tri-2] rlm@474: (.mult rlm@474: (triangle->matrix4f tri-2) rlm@474: (.invert (triangle->matrix4f tri-1)))) rlm@475: #+END_SRC rlm@475: #+end_listing rlm@474: rlm@477: *** Triangle Boundaries rlm@474: rlm@474: For efficiency's sake I will divide the tactile-profile image into rlm@474: small squares which inscribe each pixel-triangle, then extract the rlm@474: points which lie inside the triangle and map them to 3D-space using rlm@474: =triangle-transform= above. To do this I need a function, rlm@474: =convex-bounds= which finds the smallest box which inscribes a 2D rlm@474: triangle. rlm@474: rlm@474: =inside-triangle?= determines whether a point is inside a triangle rlm@474: in 2D pixel-space. rlm@474: rlm@517: #+caption: Program to efficiently determine point inclusion rlm@475: #+caption: in a triangle. rlm@475: #+name: in-triangle rlm@475: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@474: (defn convex-bounds rlm@474: "Returns the smallest square containing the given vertices, as a rlm@474: vector of integers [left top width height]." rlm@474: [verts] rlm@474: (let [xs (map first verts) rlm@474: ys (map second verts) rlm@474: x0 (Math/floor (apply min xs)) rlm@474: y0 (Math/floor (apply min ys)) rlm@474: x1 (Math/ceil (apply max xs)) rlm@474: y1 (Math/ceil (apply max ys))] rlm@474: [x0 y0 (- x1 x0) (- y1 y0)])) rlm@474: rlm@474: (defn same-side? rlm@474: "Given the points p1 and p2 and the reference point ref, is point p rlm@474: on the same side of the line that goes through p1 and p2 as ref is?" rlm@474: [p1 p2 ref p] rlm@474: (<= rlm@474: 0 rlm@474: (.dot rlm@474: (.cross (.subtract p2 p1) (.subtract p p1)) rlm@474: (.cross (.subtract p2 p1) (.subtract ref p1))))) rlm@474: rlm@474: (defn inside-triangle? rlm@474: "Is the point inside the triangle?" rlm@474: {:author "Dylan Holmes"} rlm@474: [#^Triangle tri #^Vector3f p] rlm@474: (let [[vert-1 vert-2 vert-3] [(.get1 tri) (.get2 tri) (.get3 tri)]] rlm@474: (and rlm@474: (same-side? vert-1 vert-2 vert-3 p) rlm@474: (same-side? vert-2 vert-3 vert-1 p) rlm@474: (same-side? vert-3 vert-1 vert-2 p)))) rlm@475: #+END_SRC rlm@475: #+end_listing rlm@474: rlm@477: *** Feeler Coordinates rlm@474: rlm@475: The triangle-related functions above make short work of rlm@475: calculating the positions and orientations of each feeler in rlm@475: world-space. rlm@474: rlm@475: #+caption: Program to get the coordinates of ``feelers '' in rlm@475: #+caption: both world and UV-coordinates. rlm@475: #+name: feeler-coordinates rlm@475: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@474: (defn feeler-pixel-coords rlm@474: "Returns the coordinates of the feelers in pixel space in lists, one rlm@474: list for each triangle, ordered in the same way as (triangles) and rlm@474: (pixel-triangles)." rlm@474: [#^Geometry geo image] rlm@474: (map rlm@474: (fn [pixel-triangle] rlm@474: (filter rlm@474: (fn [coord] rlm@474: (inside-triangle? (->triangle pixel-triangle) rlm@474: (->vector3f coord))) rlm@474: (white-coordinates image (convex-bounds pixel-triangle)))) rlm@474: (pixel-triangles geo image))) rlm@474: rlm@474: (defn feeler-world-coords rlm@474: "Returns the coordinates of the feelers in world space in lists, one rlm@474: list for each triangle, ordered in the same way as (triangles) and rlm@474: (pixel-triangles)." rlm@474: [#^Geometry geo image] rlm@474: (let [transforms rlm@474: (map #(triangles->affine-transform rlm@474: (->triangle %1) (->triangle %2)) rlm@474: (pixel-triangles geo image) rlm@474: (triangles geo))] rlm@474: (map (fn [transform coords] rlm@474: (map #(.mult transform (->vector3f %)) coords)) rlm@474: transforms (feeler-pixel-coords geo image)))) rlm@475: #+END_SRC rlm@475: #+end_listing rlm@474: rlm@475: #+caption: Program to get the position of the base and tip of rlm@475: #+caption: each ``feeler'' rlm@475: #+name: feeler-tips rlm@475: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@474: (defn feeler-origins rlm@474: "The world space coordinates of the root of each feeler." rlm@474: [#^Geometry geo image] rlm@474: (reduce concat (feeler-world-coords geo image))) rlm@474: rlm@474: (defn feeler-tips rlm@474: "The world space coordinates of the tip of each feeler." rlm@474: [#^Geometry geo image] rlm@474: (let [world-coords (feeler-world-coords geo image) rlm@474: normals rlm@474: (map rlm@474: (fn [triangle] rlm@474: (.calculateNormal triangle) rlm@474: (.clone (.getNormal triangle))) rlm@474: (map ->triangle (triangles geo)))] rlm@474: rlm@474: (mapcat (fn [origins normal] rlm@474: (map #(.add % normal) origins)) rlm@474: world-coords normals))) rlm@474: rlm@474: (defn touch-topology rlm@474: [#^Geometry geo image] rlm@474: (collapse (reduce concat (feeler-pixel-coords geo image)))) rlm@475: #+END_SRC rlm@475: #+end_listing rlm@474: rlm@477: *** Simulated Touch rlm@474: rlm@475: Now that the functions to construct feelers are complete, rlm@475: =touch-kernel= generates functions to be called from within a rlm@475: simulation that perform the necessary physics collisions to rlm@475: collect tactile data, and =touch!= recursively applies it to every rlm@475: node in the creature. rlm@474: rlm@475: #+caption: Efficient program to transform a ray from rlm@475: #+caption: one position to another. rlm@475: #+name: set-ray rlm@475: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@474: (defn set-ray [#^Ray ray #^Matrix4f transform rlm@474: #^Vector3f origin #^Vector3f tip] rlm@474: ;; Doing everything locally reduces garbage collection by enough to rlm@474: ;; be worth it. rlm@474: (.mult transform origin (.getOrigin ray)) rlm@474: (.mult transform tip (.getDirection ray)) rlm@474: (.subtractLocal (.getDirection ray) (.getOrigin ray)) rlm@474: (.normalizeLocal (.getDirection ray))) rlm@475: #+END_SRC rlm@475: #+end_listing rlm@474: rlm@475: #+caption: This is the core of touch in =CORTEX= each feeler rlm@475: #+caption: follows the object it is bound to, reporting any rlm@475: #+caption: collisions that may happen. rlm@475: #+name: touch-kernel rlm@475: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@474: (defn touch-kernel rlm@474: "Constructs a function which will return tactile sensory data from rlm@474: 'geo when called from inside a running simulation" rlm@474: [#^Geometry geo] rlm@474: (if-let rlm@474: [profile (tactile-sensor-profile geo)] rlm@474: (let [ray-reference-origins (feeler-origins geo profile) rlm@474: ray-reference-tips (feeler-tips geo profile) rlm@474: ray-length (tactile-scale geo) rlm@474: current-rays (map (fn [_] (Ray.)) ray-reference-origins) rlm@474: topology (touch-topology geo profile) rlm@474: correction (float (* ray-length -0.2))] rlm@474: ;; slight tolerance for very close collisions. rlm@474: (dorun rlm@474: (map (fn [origin tip] rlm@474: (.addLocal origin (.mult (.subtract tip origin) rlm@474: correction))) rlm@474: ray-reference-origins ray-reference-tips)) rlm@474: (dorun (map #(.setLimit % ray-length) current-rays)) rlm@474: (fn [node] rlm@474: (let [transform (.getWorldMatrix geo)] rlm@474: (dorun rlm@474: (map (fn [ray ref-origin ref-tip] rlm@474: (set-ray ray transform ref-origin ref-tip)) rlm@474: current-rays ray-reference-origins rlm@474: ray-reference-tips)) rlm@474: (vector rlm@474: topology rlm@474: (vec rlm@474: (for [ray current-rays] rlm@474: (do rlm@474: (let [results (CollisionResults.)] rlm@474: (.collideWith node ray results) rlm@474: (let [touch-objects rlm@474: (filter #(not (= geo (.getGeometry %))) rlm@474: results) rlm@474: limit (.getLimit ray)] rlm@474: [(if (empty? touch-objects) rlm@474: limit rlm@474: (let [response rlm@474: (apply min (map #(.getDistance %) rlm@474: touch-objects))] rlm@474: (FastMath/clamp rlm@474: (float rlm@474: (if (> response limit) (float 0.0) rlm@474: (+ response correction))) rlm@474: (float 0.0) rlm@474: limit))) rlm@474: limit]))))))))))) rlm@475: #+END_SRC rlm@475: #+end_listing rlm@474: rlm@475: Armed with the =touch!= function, =CORTEX= becomes capable of rlm@475: giving creatures a sense of touch. A simple test is to create a rlm@517: cube that is outfitted with a uniform distribution of touch rlm@475: sensors. It can feel the ground and any balls that it touches. rlm@475: rlm@475: #+caption: =CORTEX= interface for creating touch in a simulated rlm@475: #+caption: creature. rlm@475: #+name: touch rlm@475: #+begin_listing clojure rlm@475: #+BEGIN_SRC clojure rlm@474: (defn touch! rlm@474: "Endow the creature with the sense of touch. Returns a sequence of rlm@474: functions, one for each body part with a tactile-sensor-profile, rlm@474: each of which when called returns sensory data for that body part." rlm@474: [#^Node creature] rlm@474: (filter rlm@474: (comp not nil?) rlm@474: (map touch-kernel rlm@474: (filter #(isa? (class %) Geometry) rlm@474: (node-seq creature))))) rlm@475: #+END_SRC rlm@475: #+end_listing rlm@475: rlm@475: The tactile-sensor-profile image for the touch cube is a simple rlm@517: cross with a uniform distribution of touch sensors: rlm@474: rlm@475: #+caption: The touch profile for the touch-cube. Each pure white rlm@475: #+caption: pixel defines a touch sensitive feeler. rlm@475: #+name: touch-cube-uv-map rlm@495: #+ATTR_LaTeX: :width 7cm rlm@475: [[./images/touch-profile.png]] rlm@474: rlm@517: #+caption: The touch cube reacts to cannonballs. The black, red, rlm@475: #+caption: and white cross on the right is a visual display of rlm@475: #+caption: the creature's touch. White means that it is feeling rlm@475: #+caption: something strongly, black is not feeling anything, rlm@475: #+caption: and gray is in-between. The cube can feel both the rlm@475: #+caption: floor and the ball. Notice that when the ball causes rlm@475: #+caption: the cube to tip, that the bottom face can still feel rlm@475: #+caption: part of the ground. rlm@518: #+name: touch-cube-uv-map-2 rlm@475: #+ATTR_LaTeX: :width 15cm rlm@475: [[./images/touch-cube.png]] rlm@474: rlm@511: ** Proprioception provides knowledge of your own body's position rlm@436: rlm@479: Close your eyes, and touch your nose with your right index finger. rlm@479: How did you do it? You could not see your hand, and neither your rlm@479: hand nor your nose could use the sense of touch to guide the path rlm@479: of your hand. There are no sound cues, and Taste and Smell rlm@479: certainly don't provide any help. You know where your hand is rlm@479: without your other senses because of Proprioception. rlm@479: rlm@479: Humans can sometimes loose this sense through viral infections or rlm@479: damage to the spinal cord or brain, and when they do, they loose rlm@479: the ability to control their own bodies without looking directly at rlm@479: the parts they want to move. In [[http://en.wikipedia.org/wiki/The_Man_Who_Mistook_His_Wife_for_a_Hat][The Man Who Mistook His Wife for a rlm@518: Hat]] (\cite{man-wife-hat}), a woman named Christina looses this rlm@518: sense and has to learn how to move by carefully watching her arms rlm@518: and legs. She describes proprioception as the "eyes of the body, rlm@518: the way the body sees itself". rlm@479: rlm@479: Proprioception in humans is mediated by [[http://en.wikipedia.org/wiki/Articular_capsule][joint capsules]], [[http://en.wikipedia.org/wiki/Muscle_spindle][muscle rlm@479: spindles]], and the [[http://en.wikipedia.org/wiki/Golgi_tendon_organ][Golgi tendon organs]]. These measure the relative rlm@479: positions of each body part by monitoring muscle strain and length. rlm@479: rlm@479: It's clear that this is a vital sense for fluid, graceful movement. rlm@479: It's also particularly easy to implement in jMonkeyEngine. rlm@479: rlm@479: My simulated proprioception calculates the relative angles of each rlm@479: joint from the rest position defined in the blender file. This rlm@479: simulates the muscle-spindles and joint capsules. I will deal with rlm@479: Golgi tendon organs, which calculate muscle strain, in the next rlm@551: chapter. rlm@479: rlm@479: *** Helper functions rlm@479: rlm@479: =absolute-angle= calculates the angle between two vectors, rlm@479: relative to a third axis vector. This angle is the number of rlm@479: radians you have to move counterclockwise around the axis vector rlm@479: to get from the first to the second vector. It is not commutative rlm@479: like a normal dot-product angle is. rlm@479: rlm@479: The purpose of these functions is to build a system of angle rlm@517: measurement that is biologically plausible. rlm@479: rlm@479: #+caption: Program to measure angles along a vector rlm@479: #+name: helpers rlm@479: #+begin_listing clojure rlm@479: #+BEGIN_SRC clojure rlm@479: (defn right-handed? rlm@479: "true iff the three vectors form a right handed coordinate rlm@479: system. The three vectors do not have to be normalized or rlm@479: orthogonal." rlm@479: [vec1 vec2 vec3] rlm@479: (pos? (.dot (.cross vec1 vec2) vec3))) rlm@479: rlm@479: (defn absolute-angle rlm@479: "The angle between 'vec1 and 'vec2 around 'axis. In the range rlm@479: [0 (* 2 Math/PI)]." rlm@479: [vec1 vec2 axis] rlm@479: (let [angle (.angleBetween vec1 vec2)] rlm@479: (if (right-handed? vec1 vec2 axis) rlm@479: angle (- (* 2 Math/PI) angle)))) rlm@479: #+END_SRC rlm@479: #+end_listing rlm@479: rlm@479: *** Proprioception Kernel rlm@479: rlm@479: Given a joint, =proprioception-kernel= produces a function that rlm@545: calculates the Euler angles between the objects the joint rlm@479: connects. The only tricky part here is making the angles relative rlm@479: to the joint's initial ``straightness''. rlm@479: rlm@517: #+caption: Program to return biologically reasonable proprioceptive rlm@479: #+caption: data for each joint. rlm@479: #+name: proprioception rlm@479: #+begin_listing clojure rlm@479: #+BEGIN_SRC clojure rlm@479: (defn proprioception-kernel rlm@479: "Returns a function which returns proprioceptive sensory data when rlm@479: called inside a running simulation." rlm@479: [#^Node parts #^Node joint] rlm@479: (let [[obj-a obj-b] (joint-targets parts joint) rlm@479: joint-rot (.getWorldRotation joint) rlm@479: x0 (.mult joint-rot Vector3f/UNIT_X) rlm@479: y0 (.mult joint-rot Vector3f/UNIT_Y) rlm@479: z0 (.mult joint-rot Vector3f/UNIT_Z)] rlm@479: (fn [] rlm@479: (let [rot-a (.clone (.getWorldRotation obj-a)) rlm@479: rot-b (.clone (.getWorldRotation obj-b)) rlm@479: x (.mult rot-a x0) rlm@479: y (.mult rot-a y0) rlm@479: z (.mult rot-a z0) rlm@479: rlm@479: X (.mult rot-b x0) rlm@479: Y (.mult rot-b y0) rlm@479: Z (.mult rot-b z0) rlm@479: heading (Math/atan2 (.dot X z) (.dot X x)) rlm@479: pitch (Math/atan2 (.dot X y) (.dot X x)) rlm@479: rlm@479: ;; rotate x-vector back to origin rlm@479: reverse rlm@479: (doto (Quaternion.) rlm@479: (.fromAngleAxis rlm@479: (.angleBetween X x) rlm@479: (let [cross (.normalize (.cross X x))] rlm@479: (if (= 0 (.length cross)) y cross)))) rlm@479: roll (absolute-angle (.mult reverse Y) y x)] rlm@479: [heading pitch roll])))) rlm@479: rlm@479: (defn proprioception! rlm@479: "Endow the creature with the sense of proprioception. Returns a rlm@479: sequence of functions, one for each child of the \"joints\" node in rlm@479: the creature, which each report proprioceptive information about rlm@479: that joint." rlm@479: [#^Node creature] rlm@479: ;; extract the body's joints rlm@479: (let [senses (map (partial proprioception-kernel creature) rlm@479: (joints creature))] rlm@479: (fn [] rlm@479: (map #(%) senses)))) rlm@479: #+END_SRC rlm@479: #+end_listing rlm@479: rlm@479: =proprioception!= maps =proprioception-kernel= across all the rlm@479: joints of the creature. It uses the same list of joints that rlm@479: =joints= uses. Proprioception is the easiest sense to implement in rlm@479: =CORTEX=, and it will play a crucial role when efficiently rlm@479: implementing empathy. rlm@479: rlm@479: #+caption: In the upper right corner, the three proprioceptive rlm@479: #+caption: angle measurements are displayed. Red is yaw, Green is rlm@479: #+caption: pitch, and White is roll. rlm@479: #+name: proprio rlm@479: #+ATTR_LaTeX: :width 11cm rlm@479: [[./images/proprio.png]] rlm@479: rlm@511: ** Muscles contain both sensors and effectors rlm@481: rlm@481: Surprisingly enough, terrestrial creatures only move by using rlm@481: torque applied about their joints. There's not a single straight rlm@481: line of force in the human body at all! (A straight line of force rlm@481: would correspond to some sort of jet or rocket propulsion.) rlm@481: rlm@481: In humans, muscles are composed of muscle fibers which can contract rlm@481: to exert force. The muscle fibers which compose a muscle are rlm@481: partitioned into discrete groups which are each controlled by a rlm@481: single alpha motor neuron. A single alpha motor neuron might rlm@481: control as little as three or as many as one thousand muscle rlm@481: fibers. When the alpha motor neuron is engaged by the spinal cord, rlm@481: it activates all of the muscle fibers to which it is attached. The rlm@481: spinal cord generally engages the alpha motor neurons which control rlm@481: few muscle fibers before the motor neurons which control many rlm@481: muscle fibers. This recruitment strategy allows for precise rlm@481: movements at low strength. The collection of all motor neurons that rlm@481: control a muscle is called the motor pool. The brain essentially rlm@481: says "activate 30% of the motor pool" and the spinal cord recruits rlm@481: motor neurons until 30% are activated. Since the distribution of rlm@481: power among motor neurons is unequal and recruitment goes from rlm@481: weakest to strongest, the first 30% of the motor pool might be 5% rlm@481: of the strength of the muscle. rlm@481: rlm@481: My simulated muscles follow a similar design: Each muscle is rlm@481: defined by a 1-D array of numbers (the "motor pool"). Each entry in rlm@481: the array represents a motor neuron which controls a number of rlm@481: muscle fibers equal to the value of the entry. Each muscle has a rlm@481: scalar strength factor which determines the total force the muscle rlm@481: can exert when all motor neurons are activated. The effector rlm@481: function for a muscle takes a number to index into the motor pool, rlm@481: and then "activates" all the motor neurons whose index is lower or rlm@481: equal to the number. Each motor-neuron will apply force in rlm@481: proportion to its value in the array. Lower values cause less rlm@481: force. The lower values can be put at the "beginning" of the 1-D rlm@481: array to simulate the layout of actual human muscles, which are rlm@481: capable of more precise movements when exerting less force. Or, the rlm@481: motor pool can simulate more exotic recruitment strategies which do rlm@481: not correspond to human muscles. rlm@481: rlm@481: This 1D array is defined in an image file for ease of rlm@481: creation/visualization. Here is an example muscle profile image. rlm@481: rlm@481: #+caption: A muscle profile image that describes the strengths rlm@481: #+caption: of each motor neuron in a muscle. White is weakest rlm@481: #+caption: and dark red is strongest. This particular pattern rlm@481: #+caption: has weaker motor neurons at the beginning, just rlm@481: #+caption: like human muscle. rlm@481: #+name: muscle-recruit rlm@481: #+ATTR_LaTeX: :width 7cm rlm@481: [[./images/basic-muscle.png]] rlm@481: rlm@481: *** Muscle meta-data rlm@481: rlm@481: #+caption: Program to deal with loading muscle data from a blender rlm@481: #+caption: file's metadata. rlm@481: #+name: motor-pool rlm@481: #+begin_listing clojure rlm@481: #+BEGIN_SRC clojure rlm@481: (defn muscle-profile-image rlm@481: "Get the muscle-profile image from the node's blender meta-data." rlm@481: [#^Node muscle] rlm@481: (if-let [image (meta-data muscle "muscle")] rlm@481: (load-image image))) rlm@481: rlm@481: (defn muscle-strength rlm@481: "Return the strength of this muscle, or 1 if it is not defined." rlm@481: [#^Node muscle] rlm@481: (if-let [strength (meta-data muscle "strength")] rlm@481: strength 1)) rlm@481: rlm@481: (defn motor-pool rlm@481: "Return a vector where each entry is the strength of the \"motor rlm@481: neuron\" at that part in the muscle." rlm@481: [#^Node muscle] rlm@481: (let [profile (muscle-profile-image muscle)] rlm@481: (vec rlm@481: (let [width (.getWidth profile)] rlm@481: (for [x (range width)] rlm@481: (- 255 rlm@481: (bit-and rlm@481: 0x0000FF rlm@481: (.getRGB profile x 0)))))))) rlm@481: #+END_SRC rlm@481: #+end_listing rlm@481: rlm@481: Of note here is =motor-pool= which interprets the muscle-profile rlm@481: image in a way that allows me to use gradients between white and rlm@481: red, instead of shades of gray as I've been using for all the rlm@481: other senses. This is purely an aesthetic touch. rlm@481: rlm@481: *** Creating muscles rlm@481: rlm@517: #+caption: This is the core movement function in =CORTEX=, which rlm@481: #+caption: implements muscles that report on their activation. rlm@481: #+name: muscle-kernel rlm@481: #+begin_listing clojure rlm@481: #+BEGIN_SRC clojure rlm@481: (defn movement-kernel rlm@481: "Returns a function which when called with a integer value inside a rlm@481: running simulation will cause movement in the creature according rlm@481: to the muscle's position and strength profile. Each function rlm@481: returns the amount of force applied / max force." rlm@481: [#^Node creature #^Node muscle] rlm@481: (let [target (closest-node creature muscle) rlm@481: axis rlm@481: (.mult (.getWorldRotation muscle) Vector3f/UNIT_Y) rlm@481: strength (muscle-strength muscle) rlm@481: rlm@481: pool (motor-pool muscle) rlm@481: pool-integral (reductions + pool) rlm@481: forces rlm@481: (vec (map #(float (* strength (/ % (last pool-integral)))) rlm@481: pool-integral)) rlm@481: control (.getControl target RigidBodyControl)] rlm@481: ;;(println-repl (.getName target) axis) rlm@481: (fn [n] rlm@481: (let [pool-index (max 0 (min n (dec (count pool)))) rlm@481: force (forces pool-index)] rlm@481: (.applyTorque control (.mult axis force)) rlm@481: (float (/ force strength)))))) rlm@481: rlm@481: (defn movement! rlm@481: "Endow the creature with the power of movement. Returns a sequence rlm@481: of functions, each of which accept an integer value and will rlm@481: activate their corresponding muscle." rlm@481: [#^Node creature] rlm@481: (for [muscle (muscles creature)] rlm@481: (movement-kernel creature muscle))) rlm@481: #+END_SRC rlm@481: #+end_listing rlm@481: rlm@481: rlm@531: =movement-kernel= creates a function that controls the movement rlm@525: of the nearest physical node to the muscle node. The muscle exerts rlm@525: a rotational force dependent on it's orientation to the object in rlm@525: the blender file. The function returned by =movement-kernel= is rlm@525: also a sense function: it returns the percent of the total muscle rlm@525: strength that is currently being employed. This is analogous to rlm@525: muscle tension in humans and completes the sense of proprioception rlm@551: begun in the last chapter. rlm@488: rlm@507: ** =CORTEX= brings complex creatures to life! rlm@483: rlm@483: The ultimate test of =CORTEX= is to create a creature with the full rlm@483: gamut of senses and put it though its paces. rlm@483: rlm@483: With all senses enabled, my right hand model looks like an rlm@483: intricate marionette hand with several strings for each finger: rlm@483: rlm@483: #+caption: View of the hand model with all sense nodes. You can see rlm@517: #+caption: the joint, muscle, ear, and eye nodes here. rlm@483: #+name: hand-nodes-1 rlm@483: #+ATTR_LaTeX: :width 11cm rlm@483: [[./images/hand-with-all-senses2.png]] rlm@483: rlm@483: #+caption: An alternate view of the hand. rlm@483: #+name: hand-nodes-2 rlm@484: #+ATTR_LaTeX: :width 15cm rlm@484: [[./images/hand-with-all-senses3.png]] rlm@484: rlm@484: With the hand fully rigged with senses, I can run it though a test rlm@484: that will test everything. rlm@484: rlm@517: #+caption: A full test of the hand with all senses. Note especially rlm@495: #+caption: the interactions the hand has with itself: it feels rlm@484: #+caption: its own palm and fingers, and when it curls its fingers, rlm@484: #+caption: it sees them with its eye (which is located in the center rlm@484: #+caption: of the palm. The red block appears with a pure tone sound. rlm@484: #+caption: The hand then uses its muscles to launch the cube! rlm@484: #+name: integration rlm@484: #+ATTR_LaTeX: :width 16cm rlm@484: [[./images/integration.png]] rlm@436: rlm@517: ** =CORTEX= enables many possibilities for further research rlm@485: rlm@485: Often times, the hardest part of building a system involving rlm@485: creatures is dealing with physics and graphics. =CORTEX= removes rlm@485: much of this initial difficulty and leaves researchers free to rlm@485: directly pursue their ideas. I hope that even undergrads with a rlm@485: passing curiosity about simulated touch or creature evolution will rlm@485: be able to use cortex for experimentation. =CORTEX= is a completely rlm@485: simulated world, and far from being a disadvantage, its simulated rlm@485: nature enables you to create senses and creatures that would be rlm@485: impossible to make in the real world. rlm@485: rlm@485: While not by any means a complete list, here are some paths rlm@485: =CORTEX= is well suited to help you explore: rlm@485: rlm@485: - Empathy :: my empathy program leaves many areas for rlm@485: improvement, among which are using vision to infer rlm@485: proprioception and looking up sensory experience with imagined rlm@485: vision, touch, and sound. rlm@547: - Evolution :: Karl Sims created a rich environment for simulating rlm@547: the evolution of creatures on a Connection Machine rlm@547: (\cite{sims-evolving-creatures}). Today, this can be redone rlm@547: and expanded with =CORTEX= on an ordinary computer. rlm@485: - Exotic senses :: Cortex enables many fascinating senses that are rlm@485: not possible to build in the real world. For example, rlm@485: telekinesis is an interesting avenue to explore. You can also rlm@485: make a ``semantic'' sense which looks up metadata tags on rlm@485: objects in the environment the metadata tags might contain rlm@485: other sensory information. rlm@485: - Imagination via subworlds :: this would involve a creature with rlm@485: an effector which creates an entire new sub-simulation where rlm@485: the creature has direct control over placement/creation of rlm@485: objects via simulated telekinesis. The creature observes this rlm@547: sub-world through its normal senses and uses its observations rlm@485: to make predictions about its top level world. rlm@485: - Simulated prescience :: step the simulation forward a few ticks, rlm@485: gather sensory data, then supply this data for the creature as rlm@485: one of its actual senses. The cost of prescience is slowing rlm@485: the simulation down by a factor proportional to however far rlm@485: you want the entities to see into the future. What happens rlm@485: when two evolved creatures that can each see into the future rlm@485: fight each other? rlm@485: - Swarm creatures :: Program a group of creatures that cooperate rlm@485: with each other. Because the creatures would be simulated, you rlm@485: could investigate computationally complex rules of behavior rlm@485: which still, from the group's point of view, would happen in rlm@547: real time. Interactions could be as simple as cellular rlm@485: organisms communicating via flashing lights, or as complex as rlm@485: humanoids completing social tasks, etc. rlm@547: - =HACKER= for writing muscle-control programs :: Presented with a rlm@547: low-level muscle control / sense API, generate higher level rlm@485: programs for accomplishing various stated goals. Example goals rlm@485: might be "extend all your fingers" or "move your hand into the rlm@485: area with blue light" or "decrease the angle of this joint". rlm@485: It would be like Sussman's HACKER, except it would operate rlm@485: with much more data in a more realistic world. Start off with rlm@485: "calisthenics" to develop subroutines over the motor control rlm@547: API. The low level programming code might be a turning machine rlm@547: that could develop programs to iterate over a "tape" where rlm@547: each entry in the tape could control recruitment of the fibers rlm@547: in a muscle. rlm@547: - Sense fusion :: There is much work to be done on sense rlm@485: integration -- building up a coherent picture of the world and rlm@547: the things in it. With =CORTEX= as a base, you can explore rlm@485: concepts like self-organizing maps or cross modal clustering rlm@485: in ways that have never before been tried. rlm@485: - Inverse kinematics :: experiments in sense guided motor control rlm@485: are easy given =CORTEX='s support -- you can get right to the rlm@485: hard control problems without worrying about physics or rlm@485: senses. rlm@485: rlm@525: \newpage rlm@525: rlm@551: * COMMENT =EMPATH=: action recognition in a simulated worm rlm@435: rlm@449: Here I develop a computational model of empathy, using =CORTEX= as a rlm@449: base. Empathy in this context is the ability to observe another rlm@449: creature and infer what sorts of sensations that creature is rlm@449: feeling. My empathy algorithm involves multiple phases. First is rlm@449: free-play, where the creature moves around and gains sensory rlm@449: experience. From this experience I construct a representation of the rlm@449: creature's sensory state space, which I call \Phi-space. Using rlm@449: \Phi-space, I construct an efficient function which takes the rlm@449: limited data that comes from observing another creature and enriches rlm@525: it with a full compliment of imagined sensory data. I can then use rlm@525: the imagined sensory data to recognize what the observed creature is rlm@449: doing and feeling, using straightforward embodied action predicates. rlm@449: This is all demonstrated with using a simple worm-like creature, and rlm@449: recognizing worm-actions based on limited data. rlm@449: rlm@449: #+caption: Here is the worm with which we will be working. rlm@449: #+caption: It is composed of 5 segments. Each segment has a rlm@449: #+caption: pair of extensor and flexor muscles. Each of the rlm@449: #+caption: worm's four joints is a hinge joint which allows rlm@451: #+caption: about 30 degrees of rotation to either side. Each segment rlm@449: #+caption: of the worm is touch-capable and has a uniform rlm@449: #+caption: distribution of touch sensors on each of its faces. rlm@449: #+caption: Each joint has a proprioceptive sense to detect rlm@449: #+caption: relative positions. The worm segments are all the rlm@449: #+caption: same except for the first one, which has a much rlm@449: #+caption: higher weight than the others to allow for easy rlm@449: #+caption: manual motor control. rlm@449: #+name: basic-worm-view rlm@449: #+ATTR_LaTeX: :width 10cm rlm@449: [[./images/basic-worm-view.png]] rlm@449: rlm@449: #+caption: Program for reading a worm from a blender file and rlm@449: #+caption: outfitting it with the senses of proprioception, rlm@449: #+caption: touch, and the ability to move, as specified in the rlm@449: #+caption: blender file. rlm@449: #+name: get-worm rlm@449: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (defn worm [] rlm@449: (let [model (load-blender-model "Models/worm/worm.blend")] rlm@449: {:body (doto model (body!)) rlm@449: :touch (touch! model) rlm@449: :proprioception (proprioception! model) rlm@449: :muscles (movement! model)})) rlm@449: #+end_src rlm@449: #+end_listing rlm@452: rlm@531: ** Embodiment factors action recognition into manageable parts rlm@435: rlm@449: Using empathy, I divide the problem of action recognition into a rlm@449: recognition process expressed in the language of a full compliment rlm@517: of senses, and an imaginative process that generates full sensory rlm@449: data from partial sensory data. Splitting the action recognition rlm@449: problem in this manner greatly reduces the total amount of work to rlm@517: recognize actions: The imaginative process is mostly just matching rlm@449: previous experience, and the recognition process gets to use all rlm@449: the senses to directly describe any action. rlm@449: rlm@436: ** Action recognition is easy with a full gamut of senses rlm@435: rlm@449: Embodied representations using multiple senses such as touch, rlm@545: proprioception, and muscle tension turns out be exceedingly rlm@525: efficient at describing body-centered actions. It is the right rlm@525: language for the job. For example, it takes only around 5 lines of rlm@525: LISP code to describe the action of curling using embodied rlm@451: primitives. It takes about 10 lines to describe the seemingly rlm@449: complicated action of wiggling. rlm@449: rlm@449: The following action predicates each take a stream of sensory rlm@449: experience, observe however much of it they desire, and decide rlm@449: whether the worm is doing the action they describe. =curled?= rlm@449: relies on proprioception, =resting?= relies on touch, =wiggling?= rlm@517: relies on a Fourier analysis of muscle contraction, and rlm@525: =grand-circle?= relies on touch and reuses =curled?= in its rlm@525: definition, showing how embodied predicates can be composed. rlm@449: rlm@530: rlm@449: #+caption: Program for detecting whether the worm is curled. This is the rlm@449: #+caption: simplest action predicate, because it only uses the last frame rlm@449: #+caption: of sensory experience, and only uses proprioceptive data. Even rlm@449: #+caption: this simple predicate, however, is automatically frame rlm@530: #+caption: independent and ignores vermopomorphic\protect\footnotemark rlm@532: #+caption: \space differences such as worm textures and colors. rlm@449: #+name: curled rlm@509: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (defn curled? rlm@449: "Is the worm curled up?" rlm@449: [experiences] rlm@449: (every? rlm@449: (fn [[_ _ bend]] rlm@449: (> (Math/sin bend) 0.64)) rlm@449: (:proprioception (peek experiences)))) rlm@449: #+end_src rlm@449: #+end_listing rlm@530: rlm@530: #+BEGIN_LaTeX rlm@530: \footnotetext{Like \emph{anthropomorphic} except for worms instead of humans.} rlm@530: #+END_LaTeX rlm@449: rlm@449: #+caption: Program for summarizing the touch information in a patch rlm@449: #+caption: of skin. rlm@449: #+name: touch-summary rlm@509: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (defn contact rlm@449: "Determine how much contact a particular worm segment has with rlm@449: other objects. Returns a value between 0 and 1, where 1 is full rlm@449: contact and 0 is no contact." rlm@449: [touch-region [coords contact :as touch]] rlm@449: (-> (zipmap coords contact) rlm@449: (select-keys touch-region) rlm@449: (vals) rlm@449: (#(map first %)) rlm@449: (average) rlm@449: (* 10) rlm@449: (- 1) rlm@449: (Math/abs))) rlm@449: #+end_src rlm@449: #+end_listing rlm@449: rlm@449: rlm@449: #+caption: Program for detecting whether the worm is at rest. This program rlm@449: #+caption: uses a summary of the tactile information from the underbelly rlm@449: #+caption: of the worm, and is only true if every segment is touching the rlm@449: #+caption: floor. Note that this function contains no references to rlm@517: #+caption: proprioception at all. rlm@449: #+name: resting rlm@452: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (def worm-segment-bottom (rect-region [8 15] [14 22])) rlm@449: rlm@449: (defn resting? rlm@449: "Is the worm resting on the ground?" rlm@449: [experiences] rlm@449: (every? rlm@449: (fn [touch-data] rlm@449: (< 0.9 (contact worm-segment-bottom touch-data))) rlm@449: (:touch (peek experiences)))) rlm@449: #+end_src rlm@449: #+end_listing rlm@449: rlm@449: #+caption: Program for detecting whether the worm is curled up into a rlm@449: #+caption: full circle. Here the embodied approach begins to shine, as rlm@449: #+caption: I am able to both use a previous action predicate (=curled?=) rlm@449: #+caption: as well as the direct tactile experience of the head and tail. rlm@449: #+name: grand-circle rlm@452: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (def worm-segment-bottom-tip (rect-region [15 15] [22 22])) rlm@449: rlm@449: (def worm-segment-top-tip (rect-region [0 15] [7 22])) rlm@449: rlm@449: (defn grand-circle? rlm@449: "Does the worm form a majestic circle (one end touching the other)?" rlm@449: [experiences] rlm@449: (and (curled? experiences) rlm@449: (let [worm-touch (:touch (peek experiences)) rlm@449: tail-touch (worm-touch 0) rlm@449: head-touch (worm-touch 4)] rlm@449: (and (< 0.55 (contact worm-segment-bottom-tip tail-touch)) rlm@449: (< 0.55 (contact worm-segment-top-tip head-touch)))))) rlm@449: #+end_src rlm@449: #+end_listing rlm@449: rlm@449: rlm@449: #+caption: Program for detecting whether the worm has been wiggling for rlm@517: #+caption: the last few frames. It uses a Fourier analysis of the muscle rlm@449: #+caption: contractions of the worm's tail to determine wiggling. This is rlm@517: #+caption: significant because there is no particular frame that clearly rlm@449: #+caption: indicates that the worm is wiggling --- only when multiple frames rlm@449: #+caption: are analyzed together is the wiggling revealed. Defining rlm@449: #+caption: wiggling this way also gives the worm an opportunity to learn rlm@449: #+caption: and recognize ``frustrated wiggling'', where the worm tries to rlm@449: #+caption: wiggle but can't. Frustrated wiggling is very visually different rlm@449: #+caption: from actual wiggling, but this definition gives it to us for free. rlm@449: #+name: wiggling rlm@452: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (defn fft [nums] rlm@449: (map rlm@449: #(.getReal %) rlm@449: (.transform rlm@449: (FastFourierTransformer. DftNormalization/STANDARD) rlm@449: (double-array nums) TransformType/FORWARD))) rlm@449: rlm@449: (def indexed (partial map-indexed vector)) rlm@449: rlm@449: (defn max-indexed [s] rlm@449: (first (sort-by (comp - second) (indexed s)))) rlm@449: rlm@449: (defn wiggling? rlm@449: "Is the worm wiggling?" rlm@449: [experiences] rlm@449: (let [analysis-interval 0x40] rlm@449: (when (> (count experiences) analysis-interval) rlm@449: (let [a-flex 3 rlm@449: a-ex 2 rlm@449: muscle-activity rlm@449: (map :muscle (vector:last-n experiences analysis-interval)) rlm@449: base-activity rlm@449: (map #(- (% a-flex) (% a-ex)) muscle-activity)] rlm@449: (= 2 rlm@449: (first rlm@449: (max-indexed rlm@449: (map #(Math/abs %) rlm@449: (take 20 (fft base-activity)))))))))) rlm@449: #+end_src rlm@449: #+end_listing rlm@449: rlm@449: With these action predicates, I can now recognize the actions of rlm@449: the worm while it is moving under my control and I have access to rlm@449: all the worm's senses. rlm@449: rlm@449: #+caption: Use the action predicates defined earlier to report on rlm@449: #+caption: what the worm is doing while in simulation. rlm@449: #+name: report-worm-activity rlm@452: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (defn debug-experience rlm@449: [experiences text] rlm@449: (cond rlm@449: (grand-circle? experiences) (.setText text "Grand Circle") rlm@449: (curled? experiences) (.setText text "Curled") rlm@449: (wiggling? experiences) (.setText text "Wiggling") rlm@449: (resting? experiences) (.setText text "Resting"))) rlm@449: #+end_src rlm@449: #+end_listing rlm@449: rlm@449: #+caption: Using =debug-experience=, the body-centered predicates rlm@517: #+caption: work together to classify the behavior of the worm. rlm@451: #+caption: the predicates are operating with access to the worm's rlm@451: #+caption: full sensory data. rlm@449: #+name: basic-worm-view rlm@449: #+ATTR_LaTeX: :width 10cm rlm@449: [[./images/worm-identify-init.png]] rlm@449: rlm@449: These action predicates satisfy the recognition requirement of an rlm@451: empathic recognition system. There is power in the simplicity of rlm@451: the action predicates. They describe their actions without getting rlm@531: confused in visual details of the worm. Each one is independent of rlm@531: position and rotation, but more than that, they are each rlm@531: independent of irrelevant visual details of the worm and the rlm@531: environment. They will work regardless of whether the worm is a rlm@531: different color or heavily textured, or if the environment has rlm@531: strange lighting. rlm@531: rlm@531: Consider how the human act of jumping might be described with rlm@531: body-centered action predicates: You might specify that jumping is rlm@531: mainly the feeling of your knees bending, your thigh muscles rlm@531: contracting, and your inner ear experiencing a certain sort of back rlm@531: and forth acceleration. This representation is a very concrete rlm@531: description of jumping, couched in terms of muscles and senses, but rlm@531: it also has the ability to describe almost all kinds of jumping, a rlm@531: generality that you might think could only be achieved by a very rlm@531: abstract description. The body centered jumping predicate does not rlm@531: have terms that consider the color of a person's skin or whether rlm@531: they are male or female, instead it gets right to the meat of what rlm@531: jumping actually /is/. rlm@531: rlm@531: Of course, the action predicates are not directly applicable to rlm@547: video data, which lacks the advanced sensory information which they rlm@531: require! rlm@449: rlm@449: The trick now is to make the action predicates work even when the rlm@449: sensory data on which they depend is absent. If I can do that, then rlm@525: I will have gained much. rlm@435: rlm@531: ** \Phi-space describes the worm's experiences rlm@449: rlm@449: As a first step towards building empathy, I need to gather all of rlm@449: the worm's experiences during free play. I use a simple vector to rlm@449: store all the experiences. rlm@449: rlm@449: Each element of the experience vector exists in the vast space of rlm@449: all possible worm-experiences. Most of this vast space is actually rlm@449: unreachable due to physical constraints of the worm's body. For rlm@449: example, the worm's segments are connected by hinge joints that put rlm@451: a practical limit on the worm's range of motions without limiting rlm@451: its degrees of freedom. Some groupings of senses are impossible; rlm@451: the worm can not be bent into a circle so that its ends are rlm@451: touching and at the same time not also experience the sensation of rlm@451: touching itself. rlm@449: rlm@451: As the worm moves around during free play and its experience vector rlm@451: grows larger, the vector begins to define a subspace which is all rlm@517: the sensations the worm can practically experience during normal rlm@451: operation. I call this subspace \Phi-space, short for rlm@451: physical-space. The experience vector defines a path through rlm@451: \Phi-space. This path has interesting properties that all derive rlm@533: from physical embodiment. The proprioceptive components of the path rlm@533: vary smoothly, because in order for the worm to move from one rlm@451: position to another, it must pass through the intermediate rlm@533: positions. The path invariably forms loops as common actions are rlm@533: repeated. Finally and most importantly, proprioception alone rlm@533: actually gives very strong inference about the other senses. For rlm@533: example, when the worm is proprioceptively flat over several rlm@533: frames, you can infer that it is touching the ground and that its rlm@451: muscles are not active, because if the muscles were active, the rlm@533: worm would be moving and would not remain perfectly flat. In order rlm@533: to stay flat, the worm has to be touching the ground, or it would rlm@451: again be moving out of the flat position due to gravity. If the rlm@451: worm is positioned in such a way that it interacts with itself, rlm@451: then it is very likely to be feeling the same tactile feelings as rlm@451: the last time it was in that position, because it has the same body rlm@533: as then. As you observe multiple frames of proprioceptive data, you rlm@533: can become increasingly confident about the exact activations of rlm@533: the worm's muscles, because it generally takes a unique combination rlm@533: of muscle contractions to transform the worm's body along a rlm@533: specific path through \Phi-space. rlm@533: rlm@533: The worm's total life experience is a long looping path through rlm@533: \Phi-space. I will now introduce simple way of taking that rlm@548: experience path and building a function that can infer complete rlm@533: sensory experience given only a stream of proprioceptive data. This rlm@533: /empathy/ function will provide a bridge to use the body centered rlm@533: action predicates on video-like streams of information. rlm@533: rlm@535: ** Empathy is the process of building paths in \Phi-space rlm@449: rlm@450: Here is the core of a basic empathy algorithm, starting with an rlm@451: experience vector: rlm@451: rlm@533: An /experience-index/ is an index into the grand experience vector rlm@534: that defines the worm's life. It is a time-stamp for each set of rlm@533: sensations the worm has experienced. rlm@533: rlm@533: First, group the experience-indices into bins according to the rlm@533: similarity of their proprioceptive data. I organize my bins into a rlm@534: 3 level hierarchy. The smallest bins have an approximate size of rlm@533: 0.001 radians in all proprioceptive dimensions. Each higher level rlm@533: is 10x bigger than the level below it. rlm@533: rlm@533: The bins serve as a hashing function for proprioceptive data. Given rlm@533: a single piece of proprioceptive experience, the bins allow us to rlm@534: rapidly find all other similar experience-indices of past rlm@534: experience that had a very similar proprioceptive configuration. rlm@533: When looking up a proprioceptive experience, if the smallest bin rlm@534: does not match any previous experience, then successively larger rlm@533: bins are used until a match is found or we reach the largest bin. rlm@450: rlm@533: Given a sequence of proprioceptive input, I use the bins to rlm@534: generate a set of similar experiences for each input using the rlm@533: tiered proprioceptive bins. rlm@533: rlm@533: Finally, to infer sensory data, I select the longest consecutive rlm@534: chain of experiences that threads through the sets of similar rlm@535: experiences, starting with the current moment as a root and going rlm@535: backwards. Consecutive experience means that the experiences appear rlm@535: next to each other in the experience vector. rlm@535: rlm@535: A stream of proprioceptive input might be: rlm@533: rlm@535: #+BEGIN_EXAMPLE rlm@535: [ flat, flat, flat, flat, flat, flat, lift-head ] rlm@535: #+END_EXAMPLE rlm@535: rlm@535: The worm's previous experience of lying on the ground and lifting rlm@547: its head generates possible interpretations for each frame (the rlm@547: numbers are experience-indices): rlm@535: rlm@535: #+BEGIN_EXAMPLE rlm@535: [ flat, flat, flat, flat, flat, flat, flat, lift-head ] rlm@535: 1 1 1 1 1 1 1 4 rlm@535: 2 2 2 2 2 2 2 rlm@535: 3 3 3 3 3 3 3 rlm@535: 7 7 7 7 7 7 7 rlm@535: 8 8 8 8 8 8 8 rlm@535: 9 9 9 9 9 9 9 rlm@535: #+END_EXAMPLE rlm@535: rlm@535: These interpretations suggest a new path through phi space: rlm@535: rlm@535: #+BEGIN_EXAMPLE rlm@535: [ flat, flat, flat, flat, flat, flat, flat, lift-head ] rlm@535: 6 7 8 9 1 2 3 4 rlm@535: #+END_EXAMPLE rlm@535: rlm@535: The new path through \Phi-space is synthesized from two actual rlm@547: paths that the creature has experienced: the "1-2-3-4" chain and rlm@547: the "6-7-8-9" chain. The "1-2-3-4" chain is necessary because it rlm@547: ends with the worm lifting its head. It originated from a short rlm@535: training session where the worm rested on the floor for a brief rlm@535: while and then raised its head. The "6-7-8-9" chain is part of a rlm@535: longer chain of inactivity where the worm simply rested on the rlm@535: floor without moving. It is preferred over a "1-2-3" chain (which rlm@535: also describes inactivity) because it is longer. The main ideas rlm@535: again: rlm@535: rlm@535: - Imagined \Phi-space paths are synthesized by looping and mixing rlm@535: previous experiences. rlm@535: rlm@535: - Longer experience paths (less edits) are preferred. rlm@535: rlm@535: - The present is more important than the past --- more recent rlm@535: events take precedence in interpretation. rlm@533: rlm@450: This algorithm has three advantages: rlm@450: rlm@450: 1. It's simple rlm@450: rlm@451: 3. It's very fast -- retrieving possible interpretations takes rlm@451: constant time. Tracing through chains of interpretations takes rlm@451: time proportional to the average number of experiences in a rlm@451: proprioceptive bin. Redundant experiences in \Phi-space can be rlm@451: merged to save computation. rlm@450: rlm@450: 2. It protects from wrong interpretations of transient ambiguous rlm@451: proprioceptive data. For example, if the worm is flat for just rlm@517: an instant, this flatness will not be interpreted as implying rlm@517: that the worm has its muscles relaxed, since the flatness is rlm@450: part of a longer chain which includes a distinct pattern of rlm@451: muscle activation. Markov chains or other memoryless statistical rlm@451: models that operate on individual frames may very well make this rlm@451: mistake. rlm@450: rlm@450: #+caption: Program to convert an experience vector into a rlm@450: #+caption: proprioceptively binned lookup function. rlm@450: #+name: bin rlm@452: #+begin_listing clojure rlm@450: #+begin_src clojure rlm@449: (defn bin [digits] rlm@449: (fn [angles] rlm@449: (->> angles rlm@449: (flatten) rlm@449: (map (juxt #(Math/sin %) #(Math/cos %))) rlm@449: (flatten) rlm@449: (mapv #(Math/round (* % (Math/pow 10 (dec digits)))))))) rlm@449: rlm@449: (defn gen-phi-scan rlm@450: "Nearest-neighbors with binning. Only returns a result if rlm@517: the proprioceptive data is within 10% of a previously recorded rlm@450: result in all dimensions." rlm@450: [phi-space] rlm@449: (let [bin-keys (map bin [3 2 1]) rlm@449: bin-maps rlm@449: (map (fn [bin-key] rlm@449: (group-by rlm@449: (comp bin-key :proprioception phi-space) rlm@449: (range (count phi-space)))) bin-keys) rlm@449: lookups (map (fn [bin-key bin-map] rlm@450: (fn [proprio] (bin-map (bin-key proprio)))) rlm@450: bin-keys bin-maps)] rlm@449: (fn lookup [proprio-data] rlm@449: (set (some #(% proprio-data) lookups))))) rlm@450: #+end_src rlm@450: #+end_listing rlm@449: rlm@451: #+caption: =longest-thread= finds the longest path of consecutive rlm@536: #+caption: past experiences to explain proprioceptive worm data from rlm@520: #+caption: previous data. Here, the film strip represents the rlm@531: #+caption: creature's previous experience. Sort sequences of rlm@520: #+caption: memories are spliced together to match the rlm@520: #+caption: proprioceptive data. Their carry the other senses rlm@520: #+caption: along with them. rlm@451: #+name: phi-space-history-scan rlm@451: #+ATTR_LaTeX: :width 10cm rlm@520: [[./images/film-of-imagination.png]] rlm@451: rlm@451: =longest-thread= infers sensory data by stitching together pieces rlm@451: from previous experience. It prefers longer chains of previous rlm@451: experience to shorter ones. For example, during training the worm rlm@451: might rest on the ground for one second before it performs its rlm@517: exercises. If during recognition the worm rests on the ground for rlm@517: five seconds, =longest-thread= will accommodate this five second rlm@451: rest period by looping the one second rest chain five times. rlm@451: rlm@517: =longest-thread= takes time proportional to the average number of rlm@451: entries in a proprioceptive bin, because for each element in the rlm@517: starting bin it performs a series of set lookups in the preceding rlm@536: bins. If the total history is limited, then this takes time rlm@548: proportional to a only a constant multiple of the number of entries rlm@536: in the starting bin. This analysis also applies, even if the action rlm@536: requires multiple longest chains -- it's still the average number rlm@536: of entries in a proprioceptive bin times the desired chain length. rlm@536: Because =longest-thread= is so efficient and simple, I can rlm@536: interpret worm-actions in real time. rlm@449: rlm@450: #+caption: Program to calculate empathy by tracing though \Phi-space rlm@450: #+caption: and finding the longest (ie. most coherent) interpretation rlm@450: #+caption: of the data. rlm@450: #+name: longest-thread rlm@452: #+begin_listing clojure rlm@450: #+begin_src clojure rlm@449: (defn longest-thread rlm@449: "Find the longest thread from phi-index-sets. The index sets should rlm@449: be ordered from most recent to least recent." rlm@449: [phi-index-sets] rlm@449: (loop [result '() rlm@449: [thread-bases & remaining :as phi-index-sets] phi-index-sets] rlm@449: (if (empty? phi-index-sets) rlm@449: (vec result) rlm@449: (let [threads rlm@449: (for [thread-base thread-bases] rlm@449: (loop [thread (list thread-base) rlm@449: remaining remaining] rlm@449: (let [next-index (dec (first thread))] rlm@449: (cond (empty? remaining) thread rlm@449: (contains? (first remaining) next-index) rlm@449: (recur rlm@449: (cons next-index thread) (rest remaining)) rlm@449: :else thread)))) rlm@449: longest-thread rlm@449: (reduce (fn [thread-a thread-b] rlm@449: (if (> (count thread-a) (count thread-b)) rlm@449: thread-a thread-b)) rlm@449: '(nil) rlm@449: threads)] rlm@449: (recur (concat longest-thread result) rlm@449: (drop (count longest-thread) phi-index-sets)))))) rlm@450: #+end_src rlm@450: #+end_listing rlm@450: rlm@451: There is one final piece, which is to replace missing sensory data rlm@451: with a best-guess estimate. While I could fill in missing data by rlm@451: using a gradient over the closest known sensory data points, rlm@451: averages can be misleading. It is certainly possible to create an rlm@451: impossible sensory state by averaging two possible sensory states. rlm@536: For example, consider moving your hand in an arc over your head. If rlm@536: for some reason you only have the initial and final positions of rlm@536: this movement in your \Phi-space, averaging them together will rlm@536: produce the proprioceptive sensation of having your hand /inside/ rlm@536: your head, which is physically impossible to ever experience rlm@536: (barring motor adaption illusions). Therefore I simply replicate rlm@536: the most recent sensory experience to fill in the gaps. rlm@449: rlm@449: #+caption: Fill in blanks in sensory experience by replicating the most rlm@449: #+caption: recent experience. rlm@449: #+name: infer-nils rlm@452: #+begin_listing clojure rlm@449: #+begin_src clojure rlm@449: (defn infer-nils rlm@449: "Replace nils with the next available non-nil element in the rlm@449: sequence, or barring that, 0." rlm@449: [s] rlm@449: (loop [i (dec (count s)) rlm@449: v (transient s)] rlm@449: (if (zero? i) (persistent! v) rlm@449: (if-let [cur (v i)] rlm@449: (if (get v (dec i) 0) rlm@449: (recur (dec i) v) rlm@449: (recur (dec i) (assoc! v (dec i) cur))) rlm@449: (recur i (assoc! v i 0)))))) rlm@449: #+end_src rlm@449: #+end_listing rlm@435: rlm@541: ** =EMPATH= recognizes actions efficiently rlm@451: rlm@451: To use =EMPATH= with the worm, I first need to gather a set of rlm@451: experiences from the worm that includes the actions I want to rlm@452: recognize. The =generate-phi-space= program (listing rlm@451: \ref{generate-phi-space} runs the worm through a series of rlm@545: exercises and gathers those experiences into a vector. The rlm@451: =do-all-the-things= program is a routine expressed in a simple rlm@452: muscle contraction script language for automated worm control. It rlm@452: causes the worm to rest, curl, and wiggle over about 700 frames rlm@452: (approx. 11 seconds). rlm@425: rlm@451: #+caption: Program to gather the worm's experiences into a vector for rlm@451: #+caption: further processing. The =motor-control-program= line uses rlm@451: #+caption: a motor control script that causes the worm to execute a series rlm@517: #+caption: of ``exercises'' that include all the action predicates. rlm@451: #+name: generate-phi-space rlm@452: #+begin_listing clojure rlm@451: #+begin_src clojure rlm@451: (def do-all-the-things rlm@451: (concat rlm@451: curl-script rlm@451: [[300 :d-ex 40] rlm@451: [320 :d-ex 0]] rlm@451: (shift-script 280 (take 16 wiggle-script)))) rlm@451: rlm@451: (defn generate-phi-space [] rlm@451: (let [experiences (atom [])] rlm@451: (run-world rlm@451: (apply-map rlm@451: worm-world rlm@451: (merge rlm@451: (worm-world-defaults) rlm@451: {:end-frame 700 rlm@451: :motor-control rlm@451: (motor-control-program worm-muscle-labels do-all-the-things) rlm@451: :experiences experiences}))) rlm@451: @experiences)) rlm@451: #+end_src rlm@451: #+end_listing rlm@451: rlm@536: #+caption: Use =longest-thread= and a \Phi-space generated from a short rlm@451: #+caption: exercise routine to interpret actions during free play. rlm@451: #+name: empathy-debug rlm@452: #+begin_listing clojure rlm@451: #+begin_src clojure rlm@451: (defn init [] rlm@451: (def phi-space (generate-phi-space)) rlm@451: (def phi-scan (gen-phi-scan phi-space))) rlm@451: rlm@451: (defn empathy-demonstration [] rlm@451: (let [proprio (atom ())] rlm@451: (fn rlm@451: [experiences text] rlm@451: (let [phi-indices (phi-scan (:proprioception (peek experiences)))] rlm@451: (swap! proprio (partial cons phi-indices)) rlm@451: (let [exp-thread (longest-thread (take 300 @proprio)) rlm@451: empathy (mapv phi-space (infer-nils exp-thread))] rlm@451: (println-repl (vector:last-n exp-thread 22)) rlm@451: (cond rlm@451: (grand-circle? empathy) (.setText text "Grand Circle") rlm@451: (curled? empathy) (.setText text "Curled") rlm@451: (wiggling? empathy) (.setText text "Wiggling") rlm@451: (resting? empathy) (.setText text "Resting") rlm@536: :else (.setText text "Unknown"))))))) rlm@451: rlm@451: (defn empathy-experiment [record] rlm@451: (.start (worm-world :experience-watch (debug-experience-phi) rlm@451: :record record :worm worm*))) rlm@451: #+end_src rlm@451: #+end_listing rlm@536: rlm@536: These programs create a test for the empathy system. First, the rlm@536: worm's \Phi-space is generated from a simple motor script. Then the rlm@536: worm is re-created in an environment almost exactly identical to rlm@536: the testing environment for the action-predicates, with one major rlm@536: difference : the only sensory information available to the system rlm@536: is proprioception. From just the proprioception data and rlm@548: \Phi-space, =longest-thread= synthesizes a complete record the last rlm@536: 300 sensory experiences of the worm. These synthesized experiences rlm@536: are fed directly into the action predicates =grand-circle?=, rlm@536: =curled?=, =wiggling?=, and =resting?= from before and their output rlm@536: is printed to the screen at each frame. rlm@451: rlm@451: The result of running =empathy-experiment= is that the system is rlm@451: generally able to interpret worm actions using the action-predicates rlm@451: on simulated sensory data just as well as with actual data. Figure rlm@451: \ref{empathy-debug-image} was generated using =empathy-experiment=: rlm@451: rlm@451: #+caption: From only proprioceptive data, =EMPATH= was able to infer rlm@451: #+caption: the complete sensory experience and classify four poses rlm@517: #+caption: (The last panel shows a composite image of /wiggling/, rlm@451: #+caption: a dynamic pose.) rlm@451: #+name: empathy-debug-image rlm@451: #+ATTR_LaTeX: :width 10cm :placement [H] rlm@451: [[./images/empathy-1.png]] rlm@451: rlm@451: One way to measure the performance of =EMPATH= is to compare the rlm@517: suitability of the imagined sense experience to trigger the same rlm@451: action predicates as the real sensory experience. rlm@451: rlm@451: #+caption: Determine how closely empathy approximates actual rlm@451: #+caption: sensory data. rlm@451: #+name: test-empathy-accuracy rlm@452: #+begin_listing clojure rlm@451: #+begin_src clojure rlm@451: (def worm-action-label rlm@451: (juxt grand-circle? curled? wiggling?)) rlm@451: rlm@451: (defn compare-empathy-with-baseline [matches] rlm@451: (let [proprio (atom ())] rlm@451: (fn rlm@451: [experiences text] rlm@451: (let [phi-indices (phi-scan (:proprioception (peek experiences)))] rlm@451: (swap! proprio (partial cons phi-indices)) rlm@451: (let [exp-thread (longest-thread (take 300 @proprio)) rlm@451: empathy (mapv phi-space (infer-nils exp-thread)) rlm@451: experience-matches-empathy rlm@451: (= (worm-action-label experiences) rlm@451: (worm-action-label empathy))] rlm@451: (println-repl experience-matches-empathy) rlm@451: (swap! matches #(conj % experience-matches-empathy))))))) rlm@451: rlm@451: (defn accuracy [v] rlm@451: (float (/ (count (filter true? v)) (count v)))) rlm@451: rlm@451: (defn test-empathy-accuracy [] rlm@451: (let [res (atom [])] rlm@451: (run-world rlm@451: (worm-world :experience-watch rlm@451: (compare-empathy-with-baseline res) rlm@451: :worm worm*)) rlm@451: (accuracy @res))) rlm@451: #+end_src rlm@451: #+end_listing rlm@451: rlm@451: Running =test-empathy-accuracy= using the very short exercise rlm@451: program defined in listing \ref{generate-phi-space}, and then doing rlm@517: a similar pattern of activity manually yields an accuracy of around rlm@451: 73%. This is based on very limited worm experience. By training the rlm@451: worm for longer, the accuracy dramatically improves. rlm@451: rlm@451: #+caption: Program to generate \Phi-space using manual training. rlm@451: #+name: manual-phi-space rlm@451: #+begin_listing clojure rlm@451: #+begin_src clojure rlm@451: (defn init-interactive [] rlm@451: (def phi-space rlm@451: (let [experiences (atom [])] rlm@451: (run-world rlm@451: (apply-map rlm@451: worm-world rlm@451: (merge rlm@451: (worm-world-defaults) rlm@451: {:experiences experiences}))) rlm@451: @experiences)) rlm@451: (def phi-scan (gen-phi-scan phi-space))) rlm@451: #+end_src rlm@451: #+end_listing rlm@451: rlm@451: After about 1 minute of manual training, I was able to achieve 95% rlm@451: accuracy on manual testing of the worm using =init-interactive= and rlm@549: =test-empathy-accuracy=. The majority of disagreements are near the rlm@549: transition boundaries from one type of action to another. During rlm@549: these transitions the exact label for the action is often unclear, rlm@549: and disagreement between empathy and experience is practically rlm@549: irrelevant. Thus, the system's effective identification accuracy is rlm@549: even higher than 95%. When I watch this system myself, I generally rlm@549: see no errors in action identification compared to my own judgment rlm@549: of what the worm is doing. rlm@536: rlm@541: ** Digression: Learning touch sensor layout through free play rlm@514: rlm@551: In the previous chapter I showed how to compute actions in terms of rlm@539: body-centered predicates, but some of those predicates relied on rlm@539: the average touch activation of pre-defined regions of the worm's rlm@539: skin. What if, instead of receiving touch pre-grouped into the six rlm@539: faces of each worm segment, the true topology of the worm's skin rlm@539: was unknown? This is more similar to how a nerve fiber bundle might rlm@539: be arranged inside an animal. While two fibers that are close in a rlm@539: nerve bundle /might/ correspond to two touch sensors that are close rlm@539: together on the skin, the process of taking a complicated surface rlm@539: and forcing it into essentially a circle requires that some regions rlm@539: of skin that are close together in the animal end up far apart in rlm@539: the nerve bundle. rlm@452: rlm@551: In this chapter I show how to automatically learn the skin-topology of rlm@452: a worm segment by free exploration. As the worm rolls around on the rlm@452: floor, large sections of its surface get activated. If the worm has rlm@452: stopped moving, then whatever region of skin that is touching the rlm@452: floor is probably an important region, and should be recorded. rlm@452: rlm@452: #+caption: Program to detect whether the worm is in a resting state rlm@452: #+caption: with one face touching the floor. rlm@452: #+name: pure-touch rlm@452: #+begin_listing clojure rlm@452: #+begin_src clojure rlm@452: (def full-contact [(float 0.0) (float 0.1)]) rlm@452: rlm@452: (defn pure-touch? rlm@452: "This is worm specific code to determine if a large region of touch rlm@452: sensors is either all on or all off." rlm@452: [[coords touch :as touch-data]] rlm@452: (= (set (map first touch)) (set full-contact))) rlm@452: #+end_src rlm@452: #+end_listing rlm@452: rlm@452: After collecting these important regions, there will many nearly rlm@517: similar touch regions. While for some purposes the subtle rlm@452: differences between these regions will be important, for my rlm@517: purposes I collapse them into mostly non-overlapping sets using rlm@517: =remove-similar= in listing \ref{remove-similar} rlm@517: rlm@517: #+caption: Program to take a list of sets of points and ``collapse them'' rlm@517: #+caption: so that the remaining sets in the list are significantly rlm@452: #+caption: different from each other. Prefer smaller sets to larger ones. rlm@517: #+name: remove-similar rlm@452: #+begin_listing clojure rlm@452: #+begin_src clojure rlm@452: (defn remove-similar rlm@452: [coll] rlm@452: (loop [result () coll (sort-by (comp - count) coll)] rlm@452: (if (empty? coll) result rlm@452: (let [[x & xs] coll rlm@452: c (count x)] rlm@452: (if (some rlm@452: (fn [other-set] rlm@452: (let [oc (count other-set)] rlm@452: (< (- (count (union other-set x)) c) (* oc 0.1)))) rlm@452: xs) rlm@452: (recur result xs) rlm@452: (recur (cons x result) xs)))))) rlm@452: #+end_src rlm@452: #+end_listing rlm@452: rlm@452: Actually running this simulation is easy given =CORTEX='s facilities. rlm@452: rlm@452: #+caption: Collect experiences while the worm moves around. Filter the touch rlm@517: #+caption: sensations by stable ones, collapse similar ones together, rlm@452: #+caption: and report the regions learned. rlm@452: #+name: learn-touch rlm@452: #+begin_listing clojure rlm@452: #+begin_src clojure rlm@452: (defn learn-touch-regions [] rlm@452: (let [experiences (atom []) rlm@452: world (apply-map rlm@452: worm-world rlm@452: (assoc (worm-segment-defaults) rlm@452: :experiences experiences))] rlm@452: (run-world world) rlm@452: (->> rlm@452: @experiences rlm@452: (drop 175) rlm@452: ;; access the single segment's touch data rlm@452: (map (comp first :touch)) rlm@452: ;; only deal with "pure" touch data to determine surfaces rlm@452: (filter pure-touch?) rlm@452: ;; associate coordinates with touch values rlm@452: (map (partial apply zipmap)) rlm@452: ;; select those regions where contact is being made rlm@452: (map (partial group-by second)) rlm@452: (map #(get % full-contact)) rlm@452: (map (partial map first)) rlm@452: ;; remove redundant/subset regions rlm@452: (map set) rlm@452: remove-similar))) rlm@452: rlm@452: (defn learn-and-view-touch-regions [] rlm@452: (map view-touch-region rlm@452: (learn-touch-regions))) rlm@452: #+end_src rlm@452: #+end_listing rlm@452: rlm@517: The only thing remaining to define is the particular motion the worm rlm@452: must take. I accomplish this with a simple motor control program. rlm@452: rlm@452: #+caption: Motor control program for making the worm roll on the ground. rlm@452: #+caption: This could also be replaced with random motion. rlm@452: #+name: worm-roll rlm@452: #+begin_listing clojure rlm@452: #+begin_src clojure rlm@452: (defn touch-kinesthetics [] rlm@452: [[170 :lift-1 40] rlm@452: [190 :lift-1 19] rlm@452: [206 :lift-1 0] rlm@452: rlm@452: [400 :lift-2 40] rlm@452: [410 :lift-2 0] rlm@452: rlm@452: [570 :lift-2 40] rlm@452: [590 :lift-2 21] rlm@452: [606 :lift-2 0] rlm@452: rlm@452: [800 :lift-1 30] rlm@452: [809 :lift-1 0] rlm@452: rlm@452: [900 :roll-2 40] rlm@452: [905 :roll-2 20] rlm@452: [910 :roll-2 0] rlm@452: rlm@452: [1000 :roll-2 40] rlm@452: [1005 :roll-2 20] rlm@452: [1010 :roll-2 0] rlm@452: rlm@452: [1100 :roll-2 40] rlm@452: [1105 :roll-2 20] rlm@452: [1110 :roll-2 0] rlm@452: ]) rlm@452: #+end_src rlm@452: #+end_listing rlm@452: rlm@452: rlm@452: #+caption: The small worm rolls around on the floor, driven rlm@452: #+caption: by the motor control program in listing \ref{worm-roll}. rlm@452: #+name: worm-roll rlm@452: #+ATTR_LaTeX: :width 12cm rlm@452: [[./images/worm-roll.png]] rlm@452: rlm@452: #+caption: After completing its adventures, the worm now knows rlm@548: #+caption: how its touch sensors are arranged along its skin. Each of these six rectangles are touch sensory patterns that were rlm@548: #+caption: deemed important by rlm@537: #+caption: =learn-touch-regions=. Each white square in the rectangles rlm@537: #+caption: above is a cluster of ``related" touch nodes as determined rlm@548: #+caption: by the system. The worm has correctly discovered that it has six faces, and has partitioned its sensory map into these six faces. rlm@452: #+name: worm-touch-map rlm@452: #+ATTR_LaTeX: :width 12cm rlm@452: [[./images/touch-learn.png]] rlm@452: rlm@452: While simple, =learn-touch-regions= exploits regularities in both rlm@452: the worm's physiology and the worm's environment to correctly rlm@452: deduce that the worm has six sides. Note that =learn-touch-regions= rlm@452: would work just as well even if the worm's touch sense data were rlm@517: completely scrambled. The cross shape is just for convenience. This rlm@452: example justifies the use of pre-defined touch regions in =EMPATH=. rlm@452: rlm@548: ** Recognizing an object using embodied representation rlm@548: rlm@548: At the beginning of the thesis, I suggested that we might recognize rlm@548: the chair in Figure \ref{hidden-chair} by imagining ourselves in rlm@548: the position of the man and realizing that he must be sitting on rlm@548: something in order to maintain that position. Here, I present a rlm@548: brief elaboration on how to this might be done. rlm@548: rlm@548: First, I need the feeling of leaning or resting /on/ some other rlm@548: object that is not the floor. This feeling is easy to describe rlm@548: using an embodied representation. rlm@548: rlm@548: #+caption: Program describing the sense of leaning or resting on something. rlm@548: #+caption: This involves a relaxed posture, the feeling of touching something, rlm@548: #+caption: and a period of stability where the worm does not move. rlm@548: #+name: draped rlm@548: #+begin_listing clojure rlm@548: #+begin_src clojure rlm@548: (defn draped? rlm@548: "Is the worm: rlm@548: -- not flat (the floor is not a 'chair') rlm@548: -- supported (not using its muscles to hold its position) rlm@548: -- stable (not changing its position) rlm@548: -- touching something (must register contact)" rlm@548: [experiences] rlm@548: (let [b2-hash (bin 2) rlm@548: touch (:touch (peek experiences)) rlm@548: total-contact rlm@548: (reduce rlm@548: + rlm@548: (map #(contact all-touch-coordinates %) rlm@548: (rest touch)))] rlm@548: (println total-contact) rlm@548: (and (not (resting? experiences)) rlm@548: (every? rlm@548: zero? rlm@548: (-> experiences rlm@548: (vector:last-n 25) rlm@548: (#(map :muscle %)) rlm@548: (flatten))) rlm@548: (-> experiences rlm@548: (vector:last-n 20) rlm@548: (#(map (comp b2-hash flatten :proprioception) %)) rlm@548: (set) rlm@548: (count) (= 1)) rlm@548: (< 0.03 total-contact)))) rlm@548: #+end_src rlm@548: #+end_listing rlm@548: rlm@548: #+caption: The =draped?= predicate detects the presence of the rlm@548: #+caption: cube whenever the worm interacts with it. The details of the rlm@548: #+caption: cube are irrelevant; only the way it influences the worm's rlm@548: #+caption: body matters. rlm@548: #+name: draped-video rlm@548: #+ATTR_LaTeX: :width 13cm rlm@548: [[./images/draped.png]] rlm@548: rlm@548: Though this is a simple example, using the =draped?= predicate to rlm@550: detect a cube has interesting advantages. The =draped?= predicate rlm@548: describes the cube not in terms of properties that the cube has, rlm@548: but instead in terms of how the worm interacts with it physically. rlm@548: This means that the cube can still be detected even if it is not rlm@548: visible, as long as its influence on the worm's body is visible. rlm@548: rlm@548: This system will also see the virtual cube created by a rlm@548: ``mimeworm", which uses its muscles in a very controlled way to rlm@548: mimic the appearance of leaning on a cube. The system will rlm@548: anticipate that there is an actual invisible cube that provides rlm@548: support! rlm@548: rlm@548: #+caption: Can you see the thing that this person is leaning on? rlm@548: #+caption: What properties does it have, other than how it makes the man's rlm@548: #+caption: elbow and shoulder feel? I wonder if people who can actually rlm@548: #+caption: maintain this pose easily still see the support? rlm@548: #+name: mime rlm@548: #+ATTR_LaTeX: :width 6cm rlm@548: [[./images/pablo-the-mime.png]] rlm@548: rlm@548: This makes me wonder about the psychology of actual mimes. Suppose rlm@548: for a moment that people have something analogous to \Phi-space and rlm@548: that one of the ways that they find objects in a scene is by their rlm@548: relation to other people's bodies. Suppose that a person watches a rlm@548: person miming an invisible wall. For a person with no experience rlm@548: with miming, their \Phi-space will only have entries that describe rlm@548: the scene with the sensation of their hands touching a wall. This rlm@548: sensation of touch will create a strong impression of a wall, even rlm@548: though the wall would have to be invisible. A person with rlm@548: experience in miming however, will have entries in their \Phi-space rlm@548: that describe the wall-miming position without a sense of touch. It rlm@548: will not seem to such as person that an invisible wall is present, rlm@548: but merely that the mime is holding out their hands in a special rlm@548: way. Thus, the theory that humans use something like \Phi-space rlm@548: weakly predicts that learning how to mime should break the power of rlm@548: miming illusions. Most optical illusions still work no matter how rlm@548: much you know about them, so this proposal would be quite rlm@548: interesting to test, as it predicts a non-standard result! rlm@548: rlm@548: rlm@548: #+BEGIN_LaTeX rlm@548: \clearpage rlm@548: #+END_LaTeX rlm@548: rlm@551: * COMMENT Contributions rlm@548: rlm@548: The big idea behind this thesis is a new way to represent and rlm@548: recognize physical actions, which I call /empathic representation/. rlm@548: Actions are represented as predicates which have access to the rlm@548: totality of a creature's sensory abilities. To recognize the rlm@548: physical actions of another creature similar to yourself, you rlm@548: imagine what they would feel by examining the position of their body rlm@548: and relating it to your own previous experience. rlm@454: rlm@548: Empathic representation of physical actions is robust and general. rlm@548: Because the representation is body-centered, it avoids baking in a rlm@548: particular viewpoint like you might get from learning from example rlm@548: videos. Because empathic representation relies on all of a rlm@542: creature's senses, it can describe exactly what an action /feels rlm@542: like/ without getting caught up in irrelevant details such as visual rlm@542: appearance. I think it is important that a correct description of rlm@548: jumping (for example) should not include irrelevant details such as rlm@548: the color of a person's clothes or skin; empathic representation can rlm@548: get right to the heart of what jumping is by describing it in terms rlm@548: of touch, muscle contractions, and a brief feeling of rlm@548: weightlessness. Empathic representation is very low-level in that it rlm@548: describes actions using concrete sensory data with little rlm@548: abstraction, but it has the generality of much more abstract rlm@548: representations! rlm@542: rlm@542: Another important contribution of this thesis is the development of rlm@542: the =CORTEX= system, a complete environment for creating simulated rlm@542: creatures. You have seen how to implement five senses: touch, rlm@542: proprioception, hearing, vision, and muscle tension. You have seen rlm@542: how to create new creatures using blender, a 3D modeling tool. rlm@542: rlm@461: As a minor digression, you also saw how I used =CORTEX= to enable a rlm@461: tiny worm to discover the topology of its skin simply by rolling on rlm@548: the ground. You also saw how to detect objects using only embodied rlm@548: predicates. rlm@548: rlm@548: In conclusion, for this thesis I: rlm@548: rlm@548: - Developed the idea of embodied representation, which describes rlm@548: actions that a creature can do in terms of first-person sensory rlm@548: data. rlm@548: rlm@548: - Developed a method of empathic action recognition which uses rlm@548: previous embodied experience and embodied representation of rlm@548: actions to greatly constrain the possible interpretations of an rlm@548: action. rlm@548: rlm@548: - Created =EMPATH=, a program which uses empathic action rlm@548: recognition to recognize physical actions in a simple model rlm@548: involving segmented worm-like creatures. rlm@548: rlm@548: - Created =CORTEX=, a comprehensive platform for embodied AI rlm@548: experiments. It is the base on which =EMPATH= is built. rlm@517: rlm@488: #+BEGIN_LaTeX rlm@548: \clearpage rlm@488: \appendix rlm@488: #+END_LaTeX rlm@517: rlm@551: * COMMENT Appendix: =CORTEX= User Guide rlm@488: rlm@488: Those who write a thesis should endeavor to make their code not only rlm@517: accessible, but actually usable, as a way to pay back the community rlm@488: that made the thesis possible in the first place. This thesis would rlm@488: not be possible without Free Software such as jMonkeyEngine3, rlm@488: Blender, clojure, emacs, ffmpeg, and many other tools. That is why I rlm@488: have included this user guide, in the hope that someone else might rlm@488: find =CORTEX= useful. rlm@488: rlm@488: ** Obtaining =CORTEX= rlm@488: rlm@488: You can get cortex from its mercurial repository at rlm@488: http://hg.bortreb.com/cortex. You may also download =CORTEX= rlm@488: releases at http://aurellem.org/cortex/releases/. As a condition of rlm@488: making this thesis, I have also provided Professor Winston the rlm@488: =CORTEX= source, and he knows how to run the demos and get started. rlm@488: You may also email me at =cortex@aurellem.org= and I may help where rlm@488: I can. rlm@488: rlm@488: ** Running =CORTEX= rlm@488: rlm@488: =CORTEX= comes with README and INSTALL files that will guide you rlm@488: through installation and running the test suite. In particular you rlm@488: should look at test =cortex.test= which contains test suites that rlm@488: run through all senses and multiple creatures. rlm@488: rlm@488: ** Creating creatures rlm@488: rlm@488: Creatures are created using /Blender/, a free 3D modeling program. rlm@488: You will need Blender version 2.6 when using the =CORTEX= included rlm@517: in this thesis. You create a =CORTEX= creature in a similar manner rlm@488: to modeling anything in Blender, except that you also create rlm@488: several trees of empty nodes which define the creature's senses. rlm@488: rlm@488: *** Mass rlm@488: rlm@488: To give an object mass in =CORTEX=, add a ``mass'' metadata label rlm@488: to the object with the mass in jMonkeyEngine units. Note that rlm@488: setting the mass to 0 causes the object to be immovable. rlm@488: rlm@488: *** Joints rlm@488: rlm@488: Joints are created by creating an empty node named =joints= and rlm@488: then creating any number of empty child nodes to represent your rlm@488: creature's joints. The joint will automatically connect the rlm@488: closest two physical objects. It will help to set the empty node's rlm@488: display mode to ``Arrows'' so that you can clearly see the rlm@488: direction of the axes. rlm@488: rlm@488: Joint nodes should have the following metadata under the ``joint'' rlm@488: label: rlm@488: rlm@488: #+BEGIN_SRC clojure rlm@540: ;; ONE of the following, under the label "joint": rlm@488: {:type :point} rlm@488: rlm@488: ;; OR rlm@488: rlm@488: {:type :hinge rlm@488: :limit [ ] rlm@488: :axis (Vector3f. )} rlm@488: ;;(:axis defaults to (Vector3f. 1 0 0) if not provided for hinge joints) rlm@488: rlm@488: ;; OR rlm@488: rlm@488: {:type :cone rlm@488: :limit-xz rlm@488: :limit-xy rlm@488: :twist } ;(use XZY rotation mode in blender!) rlm@488: #+END_SRC rlm@488: rlm@488: *** Eyes rlm@488: rlm@488: Eyes are created by creating an empty node named =eyes= and then rlm@488: creating any number of empty child nodes to represent your rlm@488: creature's eyes. rlm@488: rlm@488: Eye nodes should have the following metadata under the ``eye'' rlm@488: label: rlm@488: rlm@488: #+BEGIN_SRC clojure rlm@488: {:red rlm@488: :blue rlm@488: :green rlm@488: :all rlm@488: (<0xrrggbb> )... rlm@488: } rlm@488: #+END_SRC rlm@488: rlm@488: Any of the color channels may be omitted. You may also include rlm@488: your own color selectors, and in fact :red is equivalent to rlm@488: 0xFF0000 and so forth. The eye will be placed at the same position rlm@488: as the empty node and will bind to the neatest physical object. rlm@488: The eye will point outward from the X-axis of the node, and ``up'' rlm@488: will be in the direction of the X-axis of the node. It will help rlm@488: to set the empty node's display mode to ``Arrows'' so that you can rlm@488: clearly see the direction of the axes. rlm@488: rlm@517: Each retina file should contain white pixels wherever you want to be rlm@488: sensitive to your chosen color. If you want the entire field of rlm@488: view, specify :all of 0xFFFFFF and a retinal map that is entirely rlm@488: white. rlm@488: rlm@488: Here is a sample retinal map: rlm@488: rlm@488: #+caption: An example retinal profile image. White pixels are rlm@488: #+caption: photo-sensitive elements. The distribution of white rlm@488: #+caption: pixels is denser in the middle and falls off at the rlm@488: #+caption: edges and is inspired by the human retina. rlm@488: #+name: retina rlm@488: #+ATTR_LaTeX: :width 7cm :placement [H] rlm@488: [[./images/retina-small.png]] rlm@488: rlm@488: *** Hearing rlm@488: rlm@488: Ears are created by creating an empty node named =ears= and then rlm@488: creating any number of empty child nodes to represent your rlm@488: creature's ears. rlm@488: rlm@488: Ear nodes do not require any metadata. rlm@488: rlm@488: The ear will bind to and follow the closest physical node. rlm@488: rlm@488: *** Touch rlm@488: rlm@488: Touch is handled similarly to mass. To make a particular object rlm@488: touch sensitive, add metadata of the following form under the rlm@488: object's ``touch'' metadata field: rlm@488: rlm@488: #+BEGIN_EXAMPLE rlm@488: rlm@488: #+END_EXAMPLE rlm@488: rlm@488: You may also include an optional ``scale'' metadata number to rlm@517: specify the length of the touch feelers. The default is $0.1$, rlm@488: and this is generally sufficient. rlm@488: rlm@488: The touch UV should contain white pixels for each touch sensor. rlm@488: rlm@488: Here is an example touch-uv map that approximates a human finger, rlm@488: and its corresponding model. rlm@488: rlm@488: #+caption: This is the tactile-sensor-profile for the upper segment rlm@488: #+caption: of a fingertip. It defines regions of high touch sensitivity rlm@488: #+caption: (where there are many white pixels) and regions of low rlm@488: #+caption: sensitivity (where white pixels are sparse). rlm@488: #+name: guide-fingertip-UV rlm@488: #+ATTR_LaTeX: :width 9cm :placement [H] rlm@488: [[./images/finger-UV.png]] rlm@488: rlm@488: #+caption: The fingertip UV-image form above applied to a simple rlm@488: #+caption: model of a fingertip. rlm@488: #+name: guide-fingertip rlm@488: #+ATTR_LaTeX: :width 9cm :placement [H] rlm@488: [[./images/finger-2.png]] rlm@488: rlm@517: *** Proprioception rlm@488: rlm@488: Proprioception is tied to each joint node -- nothing special must rlm@488: be done in a blender model to enable proprioception other than rlm@488: creating joint nodes. rlm@488: rlm@488: *** Muscles rlm@488: rlm@488: Muscles are created by creating an empty node named =muscles= and rlm@488: then creating any number of empty child nodes to represent your rlm@488: creature's muscles. rlm@488: rlm@488: rlm@488: Muscle nodes should have the following metadata under the rlm@488: ``muscle'' label: rlm@488: rlm@488: #+BEGIN_EXAMPLE rlm@488: rlm@488: #+END_EXAMPLE rlm@488: rlm@488: Muscles should also have a ``strength'' metadata entry describing rlm@488: the muscle's total strength at full activation. rlm@488: rlm@488: Muscle profiles are simple images that contain the relative amount rlm@488: of muscle power in each simulated alpha motor neuron. The width of rlm@488: the image is the total size of the motor pool, and the redness of rlm@488: each neuron is the relative power of that motor pool. rlm@488: rlm@488: While the profile image can have any dimensions, only the first rlm@488: line of pixels is used to define the muscle. Here is a sample rlm@488: muscle profile image that defines a human-like muscle. rlm@488: rlm@488: #+caption: A muscle profile image that describes the strengths rlm@488: #+caption: of each motor neuron in a muscle. White is weakest rlm@488: #+caption: and dark red is strongest. This particular pattern rlm@488: #+caption: has weaker motor neurons at the beginning, just rlm@488: #+caption: like human muscle. rlm@488: #+name: muscle-recruit rlm@488: #+ATTR_LaTeX: :width 7cm :placement [H] rlm@488: [[./images/basic-muscle.png]] rlm@488: rlm@488: Muscles twist the nearest physical object about the muscle node's rlm@488: Z-axis. I recommend using the ``Single Arrow'' display mode for rlm@488: muscles and using the right hand rule to determine which way the rlm@488: muscle will twist. To make a segment that can twist in multiple rlm@488: directions, create multiple, differently aligned muscles. rlm@488: rlm@488: ** =CORTEX= API rlm@488: rlm@488: These are the some functions exposed by =CORTEX= for creating rlm@488: worlds and simulating creatures. These are in addition to rlm@488: jMonkeyEngine3's extensive library, which is documented elsewhere. rlm@488: rlm@488: *** Simulation rlm@488: - =(world root-node key-map setup-fn update-fn)= :: create rlm@488: a simulation. rlm@488: - /root-node/ :: a =com.jme3.scene.Node= object which rlm@488: contains all of the objects that should be in the rlm@488: simulation. rlm@488: rlm@488: - /key-map/ :: a map from strings describing keys to rlm@488: functions that should be executed whenever that key is rlm@488: pressed. the functions should take a SimpleApplication rlm@488: object and a boolean value. The SimpleApplication is the rlm@488: current simulation that is running, and the boolean is true rlm@488: if the key is being pressed, and false if it is being rlm@488: released. As an example, rlm@488: #+BEGIN_SRC clojure rlm@488: {"key-j" (fn [game value] (if value (println "key j pressed")))} rlm@488: #+END_SRC rlm@488: is a valid key-map which will cause the simulation to print rlm@488: a message whenever the 'j' key on the keyboard is pressed. rlm@488: rlm@488: - /setup-fn/ :: a function that takes a =SimpleApplication= rlm@488: object. It is called once when initializing the simulation. rlm@488: Use it to create things like lights, change the gravity, rlm@488: initialize debug nodes, etc. rlm@488: rlm@488: - /update-fn/ :: this function takes a =SimpleApplication= rlm@488: object and a float and is called every frame of the rlm@488: simulation. The float tells how many seconds is has been rlm@488: since the last frame was rendered, according to whatever rlm@488: clock jme is currently using. The default is to use IsoTimer rlm@488: which will result in this value always being the same. rlm@488: rlm@488: - =(position-camera world position rotation)= :: set the position rlm@488: of the simulation's main camera. rlm@488: rlm@488: - =(enable-debug world)= :: turn on debug wireframes for each rlm@488: simulated object. rlm@488: rlm@488: - =(set-gravity world gravity)= :: set the gravity of a running rlm@488: simulation. rlm@488: rlm@488: - =(box length width height & {options})= :: create a box in the rlm@488: simulation. Options is a hash map specifying texture, mass, rlm@488: etc. Possible options are =:name=, =:color=, =:mass=, rlm@488: =:friction=, =:texture=, =:material=, =:position=, rlm@488: =:rotation=, =:shape=, and =:physical?=. rlm@488: rlm@488: - =(sphere radius & {options})= :: create a sphere in the simulation. rlm@488: Options are the same as in =box=. rlm@488: rlm@488: - =(load-blender-model file-name)= :: create a node structure rlm@540: representing the model described in a blender file. rlm@488: rlm@488: - =(light-up-everything world)= :: distribute a standard compliment rlm@517: of lights throughout the simulation. Should be adequate for most rlm@488: purposes. rlm@488: rlm@517: - =(node-seq node)= :: return a recursive list of the node's rlm@488: children. rlm@488: rlm@488: - =(nodify name children)= :: construct a node given a node-name and rlm@488: desired children. rlm@488: rlm@488: - =(add-element world element)= :: add an object to a running world rlm@488: simulation. rlm@488: rlm@488: - =(set-accuracy world accuracy)= :: change the accuracy of the rlm@488: world's physics simulator. rlm@488: rlm@488: - =(asset-manager)= :: get an /AssetManager/, a jMonkeyEngine rlm@488: construct that is useful for loading textures and is required rlm@488: for smooth interaction with jMonkeyEngine library functions. rlm@488: rlm@540: - =(load-bullet)= :: unpack native libraries and initialize the rlm@540: bullet physics subsystem. This function is required before rlm@540: other world building functions are called. rlm@488: rlm@488: *** Creature Manipulation / Import rlm@488: rlm@488: - =(body! creature)= :: give the creature a physical body. rlm@488: rlm@488: - =(vision! creature)= :: give the creature a sense of vision. rlm@488: Returns a list of functions which will each, when called rlm@488: during a simulation, return the vision data for the channel of rlm@488: one of the eyes. The functions are ordered depending on the rlm@488: alphabetical order of the names of the eye nodes in the rlm@488: blender file. The data returned by the functions is a vector rlm@488: containing the eye's /topology/, a vector of coordinates, and rlm@488: the eye's /data/, a vector of RGB values filtered by the eye's rlm@488: sensitivity. rlm@488: rlm@488: - =(hearing! creature)= :: give the creature a sense of hearing. rlm@488: Returns a list of functions, one for each ear, that when rlm@488: called will return a frame's worth of hearing data for that rlm@488: ear. The functions are ordered depending on the alphabetical rlm@488: order of the names of the ear nodes in the blender file. The rlm@540: data returned by the functions is an array of PCM (pulse code rlm@540: modulated) wav data. rlm@488: rlm@488: - =(touch! creature)= :: give the creature a sense of touch. Returns rlm@488: a single function that must be called with the /root node/ of rlm@488: the world, and which will return a vector of /touch-data/ rlm@488: one entry for each touch sensitive component, each entry of rlm@488: which contains a /topology/ that specifies the distribution of rlm@488: touch sensors, and the /data/, which is a vector of rlm@488: =[activation, length]= pairs for each touch hair. rlm@488: rlm@488: - =(proprioception! creature)= :: give the creature the sense of rlm@488: proprioception. Returns a list of functions, one for each rlm@488: joint, that when called during a running simulation will rlm@517: report the =[heading, pitch, roll]= of the joint. rlm@488: rlm@488: - =(movement! creature)= :: give the creature the power of movement. rlm@488: Creates a list of functions, one for each muscle, that when rlm@488: called with an integer, will set the recruitment of that rlm@488: muscle to that integer, and will report the current power rlm@488: being exerted by the muscle. Order of muscles is determined by rlm@488: the alphabetical sort order of the names of the muscle nodes. rlm@488: rlm@488: *** Visualization/Debug rlm@488: rlm@488: - =(view-vision)= :: create a function that when called with a list rlm@488: of visual data returned from the functions made by =vision!=, rlm@488: will display that visual data on the screen. rlm@488: rlm@488: - =(view-hearing)= :: same as =view-vision= but for hearing. rlm@488: rlm@488: - =(view-touch)= :: same as =view-vision= but for touch. rlm@488: rlm@488: - =(view-proprioception)= :: same as =view-vision= but for rlm@488: proprioception. rlm@488: rlm@540: - =(view-movement)= :: same as =view-vision= but for muscles. rlm@488: rlm@488: - =(view anything)= :: =view= is a polymorphic function that allows rlm@488: you to inspect almost anything you could reasonably expect to rlm@488: be able to ``see'' in =CORTEX=. rlm@488: rlm@488: - =(text anything)= :: =text= is a polymorphic function that allows rlm@488: you to convert practically anything into a text string. rlm@488: rlm@488: - =(println-repl anything)= :: print messages to clojure's repl rlm@488: instead of the simulation's terminal window. rlm@488: rlm@488: - =(mega-import-jme3)= :: for experimenting at the REPL. This rlm@488: function will import all jMonkeyEngine3 classes for immediate rlm@488: use. rlm@488: rlm@517: - =(display-dilated-time world timer)= :: Shows the time as it is rlm@488: flowing in the simulation on a HUD display. rlm@488: rlm@488: rlm@488: rlm@547: TODO -- add a paper about detecting biological motion from only a few dots.