annotate thesis/cortex.org @ 563:3c3dc4dbb973

adding changes from winston
author Robert McIntyre <rlm@mit.edu>
date Mon, 12 May 2014 12:49:18 -0400
parents 6299450f9618
children ecae29320b00
rev   line source
rlm@425 1 #+title: =CORTEX=
rlm@425 2 #+author: Robert McIntyre
rlm@425 3 #+email: rlm@mit.edu
rlm@425 4 #+description: Using embodied AI to facilitate Artificial Imagination.
rlm@425 5 #+keywords: AI, clojure, embodiment
rlm@451 6 #+LaTeX_CLASS_OPTIONS: [nofloat]
rlm@422 7
rlm@465 8 * COMMENT templates
rlm@470 9 #+caption:
rlm@470 10 #+caption:
rlm@470 11 #+caption:
rlm@470 12 #+caption:
rlm@470 13 #+name: name
rlm@470 14 #+begin_listing clojure
rlm@479 15 #+BEGIN_SRC clojure
rlm@479 16 #+END_SRC
rlm@470 17 #+end_listing
rlm@465 18
rlm@470 19 #+caption:
rlm@470 20 #+caption:
rlm@470 21 #+caption:
rlm@470 22 #+name: name
rlm@470 23 #+ATTR_LaTeX: :width 10cm
rlm@470 24 [[./images/aurellem-gray.png]]
rlm@470 25
rlm@470 26 #+caption:
rlm@470 27 #+caption:
rlm@470 28 #+caption:
rlm@470 29 #+caption:
rlm@470 30 #+name: name
rlm@470 31 #+begin_listing clojure
rlm@475 32 #+BEGIN_SRC clojure
rlm@475 33 #+END_SRC
rlm@470 34 #+end_listing
rlm@470 35
rlm@470 36 #+caption:
rlm@470 37 #+caption:
rlm@470 38 #+caption:
rlm@470 39 #+name: name
rlm@470 40 #+ATTR_LaTeX: :width 10cm
rlm@470 41 [[./images/aurellem-gray.png]]
rlm@470 42
rlm@465 43
rlm@541 44 * Empathy \& Embodiment: problem solving strategies
rlm@516 45
rlm@551 46 By the time you have read this thesis, you will understand a novel
rlm@551 47 approach to representing and recognizing physical actions using
rlm@551 48 embodiment and empathy. You will also see one way to efficiently
rlm@551 49 implement physical empathy for embodied creatures. Finally, you will
rlm@551 50 become familiar with =CORTEX=, a system for designing and simulating
rlm@551 51 creatures with rich senses, which I have designed as a library that
rlm@551 52 you can use in your own research. Note that I /do not/ process video
rlm@551 53 directly --- I start with knowledge of the positions of a creature's
rlm@551 54 body parts and work from there.
rlm@437 55
rlm@516 56 This is the core vision of my thesis: That one of the important ways
rlm@516 57 in which we understand others is by imagining ourselves in their
rlm@561 58 position and empathically feeling experiences relative to our own
rlm@516 59 bodies. By understanding events in terms of our own previous
rlm@516 60 corporeal experience, we greatly constrain the possibilities of what
rlm@516 61 would otherwise be an unwieldy exponential search. This extra
rlm@516 62 constraint can be the difference between easily understanding what
rlm@516 63 is happening in a video and being completely lost in a sea of
rlm@516 64 incomprehensible color and movement.
rlm@516 65
rlm@525 66 ** The problem: recognizing actions is hard!
rlm@511 67
rlm@551 68 Examine figure \ref{cat-drink}. What is happening? As you, and
rlm@551 69 indeed very young children, can easily determine, this is an image
rlm@551 70 of drinking.
rlm@516 71
rlm@441 72 #+caption: A cat drinking some water. Identifying this action is
rlm@511 73 #+caption: beyond the capabilities of existing computer vision systems.
rlm@551 74 #+name: cat-drink
rlm@441 75 #+ATTR_LaTeX: :width 7cm
rlm@441 76 [[./images/cat-drinking.jpg]]
rlm@511 77
rlm@511 78 Nevertheless, it is beyond the state of the art for a computer
rlm@516 79 vision program to describe what's happening in this image. Part of
rlm@516 80 the problem is that many computer vision systems focus on
rlm@516 81 pixel-level details or comparisons to example images (such as
rlm@516 82 \cite{volume-action-recognition}), but the 3D world is so variable
rlm@517 83 that it is hard to describe the world in terms of possible images.
rlm@511 84
rlm@547 85 In fact, the contents of a scene may have much less to do with
rlm@547 86 pixel probabilities than with recognizing various affordances:
rlm@547 87 things you can move, objects you can grasp, spaces that can be
rlm@547 88 filled . For example, what processes might enable you to see the
rlm@547 89 chair in figure \ref{hidden-chair}?
rlm@516 90
rlm@525 91 #+caption: The chair in this image is quite obvious to humans, but
rlm@525 92 #+caption: it can't be found by any modern computer vision program.
rlm@441 93 #+name: hidden-chair
rlm@441 94 #+ATTR_LaTeX: :width 10cm
rlm@441 95 [[./images/fat-person-sitting-at-desk.jpg]]
rlm@511 96
rlm@441 97 Finally, how is it that you can easily tell the difference between
rlm@551 98 how the girl's /muscles/ are working in figure \ref{girl}?
rlm@441 99
rlm@441 100 #+caption: The mysterious ``common sense'' appears here as you are able
rlm@441 101 #+caption: to discern the difference in how the girl's arm muscles
rlm@551 102 #+caption: are activated between the two images. When you compare
rlm@551 103 #+caption: these two images, do you feel something in your own arm
rlm@551 104 #+caption: muscles?
rlm@441 105 #+name: girl
rlm@448 106 #+ATTR_LaTeX: :width 7cm
rlm@441 107 [[./images/wall-push.png]]
rlm@437 108
rlm@441 109 Each of these examples tells us something about what might be going
rlm@517 110 on in our minds as we easily solve these recognition problems:
rlm@441 111
rlm@547 112 - The hidden chair shows us that we are strongly triggered by cues
rlm@547 113 relating to the position of human bodies, and that we can
rlm@547 114 determine the overall physical configuration of a human body even
rlm@547 115 if much of that body is occluded.
rlm@547 116
rlm@547 117 - The picture of the girl pushing against the wall tells us that we
rlm@547 118 have common sense knowledge about the kinetics of our own bodies.
rlm@547 119 We know well how our muscles would have to work to maintain us in
rlm@547 120 most positions, and we can easily project this self-knowledge to
rlm@547 121 imagined positions triggered by images of the human body.
rlm@547 122
rlm@547 123 - The cat tells us that imagination of some kind plays an important
rlm@547 124 role in understanding actions. The question is: Can we be more
rlm@547 125 precise about what sort of imagination is required to understand
rlm@547 126 these actions?
rlm@517 127
rlm@511 128 ** A step forward: the sensorimotor-centered approach
rlm@516 129
rlm@511 130 In this thesis, I explore the idea that our knowledge of our own
rlm@516 131 bodies, combined with our own rich senses, enables us to recognize
rlm@516 132 the actions of others.
rlm@516 133
rlm@516 134 For example, I think humans are able to label the cat video as
rlm@516 135 ``drinking'' because they imagine /themselves/ as the cat, and
rlm@516 136 imagine putting their face up against a stream of water and
rlm@516 137 sticking out their tongue. In that imagined world, they can feel
rlm@516 138 the cool water hitting their tongue, and feel the water entering
rlm@516 139 their body, and are able to recognize that /feeling/ as drinking.
rlm@516 140 So, the label of the action is not really in the pixels of the
rlm@547 141 image, but is found clearly in a simulation / recollection inspired
rlm@547 142 by those pixels. An imaginative system, having been trained on
rlm@547 143 drinking and non-drinking examples and learning that the most
rlm@551 144 important component of drinking is the feeling of water flowing
rlm@547 145 down one's throat, would analyze a video of a cat drinking in the
rlm@547 146 following manner:
rlm@516 147
rlm@516 148 1. Create a physical model of the video by putting a ``fuzzy''
rlm@516 149 model of its own body in place of the cat. Possibly also create
rlm@516 150 a simulation of the stream of water.
rlm@516 151
rlm@551 152 2. Play out this simulated scene and generate imagined sensory
rlm@516 153 experience. This will include relevant muscle contractions, a
rlm@516 154 close up view of the stream from the cat's perspective, and most
rlm@517 155 importantly, the imagined feeling of water entering the mouth.
rlm@517 156 The imagined sensory experience can come from a simulation of
rlm@517 157 the event, but can also be pattern-matched from previous,
rlm@517 158 similar embodied experience.
rlm@516 159
rlm@516 160 3. The action is now easily identified as drinking by the sense of
rlm@516 161 taste alone. The other senses (such as the tongue moving in and
rlm@516 162 out) help to give plausibility to the simulated action. Note that
rlm@516 163 the sense of vision, while critical in creating the simulation,
rlm@516 164 is not critical for identifying the action from the simulation.
rlm@516 165
rlm@516 166 For the chair examples, the process is even easier:
rlm@516 167
rlm@516 168 1. Align a model of your body to the person in the image.
rlm@516 169
rlm@516 170 2. Generate proprioceptive sensory data from this alignment.
rlm@516 171
rlm@516 172 3. Use the imagined proprioceptive data as a key to lookup related
rlm@517 173 sensory experience associated with that particular proprioceptive
rlm@516 174 feeling.
rlm@516 175
rlm@516 176 4. Retrieve the feeling of your bottom resting on a surface, your
rlm@516 177 knees bent, and your leg muscles relaxed.
rlm@516 178
rlm@516 179 5. This sensory information is consistent with your =sitting?=
rlm@516 180 sensory predicate, so you (and the entity in the image) must be
rlm@516 181 sitting.
rlm@516 182
rlm@516 183 6. There must be a chair-like object since you are sitting.
rlm@516 184
rlm@516 185 Empathy offers yet another alternative to the age-old AI
rlm@516 186 representation question: ``What is a chair?'' --- A chair is the
rlm@516 187 feeling of sitting!
rlm@516 188
rlm@516 189 One powerful advantage of empathic problem solving is that it
rlm@516 190 factors the action recognition problem into two easier problems. To
rlm@516 191 use empathy, you need an /aligner/, which takes the video and a
rlm@516 192 model of your body, and aligns the model with the video. Then, you
rlm@516 193 need a /recognizer/, which uses the aligned model to interpret the
rlm@516 194 action. The power in this method lies in the fact that you describe
rlm@521 195 all actions from a body-centered viewpoint. You are less tied to
rlm@516 196 the particulars of any visual representation of the actions. If you
rlm@516 197 teach the system what ``running'' is, and you have a good enough
rlm@516 198 aligner, the system will from then on be able to recognize running
rlm@547 199 from any point of view -- even strange points of view like above or
rlm@516 200 underneath the runner. This is in contrast to action recognition
rlm@516 201 schemes that try to identify actions using a non-embodied approach.
rlm@516 202 If these systems learn about running as viewed from the side, they
rlm@516 203 will not automatically be able to recognize running from any other
rlm@516 204 viewpoint.
rlm@516 205
rlm@516 206 Another powerful advantage is that using the language of multiple
rlm@547 207 body-centered rich senses to describe body-centered actions offers
rlm@547 208 a massive boost in descriptive capability. Consider how difficult
rlm@547 209 it would be to compose a set of HOG (Histogram of Oriented
rlm@547 210 Gradients) filters to describe the action of a simple worm-creature
rlm@547 211 ``curling'' so that its head touches its tail, and then behold the
rlm@547 212 simplicity of describing thus action in a language designed for the
rlm@547 213 task (listing \ref{grand-circle-intro}):
rlm@516 214
rlm@517 215 #+caption: Body-centered actions are best expressed in a body-centered
rlm@516 216 #+caption: language. This code detects when the worm has curled into a
rlm@516 217 #+caption: full circle. Imagine how you would replicate this functionality
rlm@516 218 #+caption: using low-level pixel features such as HOG filters!
rlm@516 219 #+name: grand-circle-intro
rlm@516 220 #+begin_listing clojure
rlm@516 221 #+begin_src clojure
rlm@516 222 (defn grand-circle?
rlm@516 223 "Does the worm form a majestic circle (one end touching the other)?"
rlm@516 224 [experiences]
rlm@516 225 (and (curled? experiences)
rlm@516 226 (let [worm-touch (:touch (peek experiences))
rlm@516 227 tail-touch (worm-touch 0)
rlm@516 228 head-touch (worm-touch 4)]
rlm@516 229 (and (< 0.2 (contact worm-segment-bottom-tip tail-touch))
rlm@516 230 (< 0.2 (contact worm-segment-top-tip head-touch))))))
rlm@516 231 #+end_src
rlm@516 232 #+end_listing
rlm@516 233
rlm@517 234 ** =EMPATH= recognizes actions using empathy
rlm@517 235
rlm@517 236 Exploring these ideas further demands a concrete implementation, so
rlm@517 237 first, I built a system for constructing virtual creatures with
rlm@511 238 physiologically plausible sensorimotor systems and detailed
rlm@551 239 environments. The result is =CORTEX=, which I describe in chapter
rlm@517 240 \ref{sec-2}.
rlm@511 241
rlm@511 242 Next, I wrote routines which enabled a simple worm-like creature to
rlm@511 243 infer the actions of a second worm-like creature, using only its
rlm@511 244 own prior sensorimotor experiences and knowledge of the second
rlm@511 245 worm's joint positions. This program, =EMPATH=, is described in
rlm@551 246 chapter \ref{sec-3}. It's main components are:
rlm@517 247
rlm@517 248 - Embodied Action Definitions :: Many otherwise complicated actions
rlm@517 249 are easily described in the language of a full suite of
rlm@517 250 body-centered, rich senses and experiences. For example,
rlm@551 251 drinking is the feeling of water flowing down your throat, and
rlm@448 252 cooling your insides. It's often accompanied by bringing your
rlm@448 253 hand close to your face, or bringing your face close to water.
rlm@448 254 Sitting down is the feeling of bending your knees, activating
rlm@448 255 your quadriceps, then feeling a surface with your bottom and
rlm@448 256 relaxing your legs. These body-centered action descriptions
rlm@448 257 can be either learned or hard coded.
rlm@517 258
rlm@517 259 - Guided Play :: The creature moves around and experiences the
rlm@517 260 world through its unique perspective. As the creature moves,
rlm@517 261 it gathers experiences that satisfy the embodied action
rlm@517 262 definitions.
rlm@517 263
rlm@562 264 - Posture Imitation :: When trying to interpret a video or image,
rlm@448 265 the creature takes a model of itself and aligns it with
rlm@517 266 whatever it sees. This alignment might even cross species, as
rlm@448 267 when humans try to align themselves with things like ponies,
rlm@448 268 dogs, or other humans with a different body type.
rlm@517 269
rlm@517 270 - Empathy :: The alignment triggers associations with
rlm@448 271 sensory data from prior experiences. For example, the
rlm@448 272 alignment itself easily maps to proprioceptive data. Any
rlm@448 273 sounds or obvious skin contact in the video can to a lesser
rlm@517 274 extent trigger previous experience keyed to hearing or touch.
rlm@517 275 Segments of previous experiences gained from play are stitched
rlm@517 276 together to form a coherent and complete sensory portrait of
rlm@517 277 the scene.
rlm@517 278
rlm@547 279 - Recognition :: With the scene described in terms of remembered
rlm@547 280 first person sensory events, the creature can now run its
rlm@547 281 action-definition programs (such as the one in listing
rlm@547 282 \ref{grand-circle-intro}) on this synthesized sensory data,
rlm@517 283 just as it would if it were actually experiencing the scene
rlm@517 284 first-hand. If previous experience has been accurately
rlm@447 285 retrieved, and if it is analogous enough to the scene, then
rlm@447 286 the creature will correctly identify the action in the scene.
rlm@441 287
rlm@562 288 My program =EMPATH= uses this empathic problem solving technique
rlm@441 289 to interpret the actions of a simple, worm-like creature.
rlm@437 290
rlm@441 291 #+caption: The worm performs many actions during free play such as
rlm@441 292 #+caption: curling, wiggling, and resting.
rlm@441 293 #+name: worm-intro
rlm@446 294 #+ATTR_LaTeX: :width 15cm
rlm@445 295 [[./images/worm-intro-white.png]]
rlm@437 296
rlm@462 297 #+caption: =EMPATH= recognized and classified each of these
rlm@462 298 #+caption: poses by inferring the complete sensory experience
rlm@462 299 #+caption: from proprioceptive data.
rlm@441 300 #+name: worm-recognition-intro
rlm@446 301 #+ATTR_LaTeX: :width 15cm
rlm@445 302 [[./images/worm-poses.png]]
rlm@441 303
rlm@517 304 *** Main Results
rlm@517 305
rlm@521 306 - After one-shot supervised training, =EMPATH= was able to
rlm@521 307 recognize a wide variety of static poses and dynamic
rlm@521 308 actions---ranging from curling in a circle to wiggling with a
rlm@521 309 particular frequency --- with 95\% accuracy.
rlm@517 310
rlm@517 311 - These results were completely independent of viewing angle
rlm@517 312 because the underlying body-centered language fundamentally is
rlm@517 313 independent; once an action is learned, it can be recognized
rlm@517 314 equally well from any viewing angle.
rlm@517 315
rlm@517 316 - =EMPATH= is surprisingly short; the sensorimotor-centered
rlm@517 317 language provided by =CORTEX= resulted in extremely economical
rlm@517 318 recognition routines --- about 500 lines in all --- suggesting
rlm@517 319 that such representations are very powerful, and often
rlm@517 320 indispensable for the types of recognition tasks considered here.
rlm@517 321
rlm@551 322 - For expediency's sake, I relied on direct knowledge of joint
rlm@551 323 positions in this proof of concept. However, I believe that the
rlm@551 324 structure of =EMPATH= and =CORTEX= will make future work to
rlm@551 325 enable video analysis much easier than it would otherwise be.
rlm@517 326
rlm@563 327 ** =EMPATH= is built on =CORTEX=, a creature builder.
rlm@435 328
rlm@448 329 I built =CORTEX= to be a general AI research platform for doing
rlm@448 330 experiments involving multiple rich senses and a wide variety and
rlm@448 331 number of creatures. I intend it to be useful as a library for many
rlm@462 332 more projects than just this thesis. =CORTEX= was necessary to meet
rlm@462 333 a need among AI researchers at CSAIL and beyond, which is that
rlm@547 334 people often will invent wonderful ideas that are best expressed in
rlm@547 335 the language of creatures and senses, but in order to explore those
rlm@448 336 ideas they must first build a platform in which they can create
rlm@448 337 simulated creatures with rich senses! There are many ideas that
rlm@547 338 would be simple to execute (such as =EMPATH= or Larson's
rlm@547 339 self-organizing maps (\cite{larson-symbols})), but attached to them
rlm@547 340 is the multi-month effort to make a good creature simulator. Often,
rlm@547 341 that initial investment of time proves to be too much, and the
rlm@547 342 project must make do with a lesser environment or be abandoned
rlm@547 343 entirely.
rlm@435 344
rlm@448 345 =CORTEX= is well suited as an environment for embodied AI research
rlm@448 346 for three reasons:
rlm@448 347
rlm@547 348 - You can design new creatures using Blender (\cite{blender}), a
rlm@551 349 popular, free 3D modeling program. Each sense can be specified
rlm@562 350 using special Blender nodes with biologically inspired
rlm@551 351 parameters. You need not write any code to create a creature, and
rlm@551 352 can use a wide library of pre-existing blender models as a base
rlm@551 353 for your own creatures.
rlm@448 354
rlm@511 355 - =CORTEX= implements a wide variety of senses: touch,
rlm@448 356 proprioception, vision, hearing, and muscle tension. Complicated
rlm@545 357 senses like touch and vision involve multiple sensory elements
rlm@448 358 embedded in a 2D surface. You have complete control over the
rlm@448 359 distribution of these sensor elements through the use of simple
rlm@551 360 image files. =CORTEX= implements more comprehensive hearing than
rlm@551 361 any other creature simulation system available.
rlm@448 362
rlm@448 363 - =CORTEX= supports any number of creatures and any number of
rlm@517 364 senses. Time in =CORTEX= dilates so that the simulated creatures
rlm@517 365 always perceive a perfectly smooth flow of time, regardless of
rlm@448 366 the actual computational load.
rlm@448 367
rlm@517 368 =CORTEX= is built on top of =jMonkeyEngine3=
rlm@517 369 (\cite{jmonkeyengine}), which is a video game engine designed to
rlm@517 370 create cross-platform 3D desktop games. =CORTEX= is mainly written
rlm@551 371 in clojure, a dialect of =LISP= that runs on the Java Virtual
rlm@551 372 Machine (JVM). The API for creating and simulating creatures and
rlm@517 373 senses is entirely expressed in clojure, though many senses are
rlm@517 374 implemented at the layer of jMonkeyEngine or below. For example,
rlm@517 375 for the sense of hearing I use a layer of clojure code on top of a
rlm@517 376 layer of java JNI bindings that drive a layer of =C++= code which
rlm@517 377 implements a modified version of =OpenAL= to support multiple
rlm@517 378 listeners. =CORTEX= is the only simulation environment that I know
rlm@517 379 of that can support multiple entities that can each hear the world
rlm@517 380 from their own perspective. Other senses also require a small layer
rlm@517 381 of Java code. =CORTEX= also uses =bullet=, a physics simulator
rlm@517 382 written in =C=.
rlm@448 383
rlm@516 384 #+caption: Here is the worm from figure \ref{worm-intro} modeled
rlm@516 385 #+caption: in Blender, a free 3D-modeling program. Senses and
rlm@516 386 #+caption: joints are described using special nodes in Blender.
rlm@518 387 #+name: worm-recognition-intro-2
rlm@448 388 #+ATTR_LaTeX: :width 12cm
rlm@448 389 [[./images/blender-worm.png]]
rlm@448 390
rlm@521 391 Here are some things I anticipate that =CORTEX= might be used for:
rlm@449 392
rlm@449 393 - exploring new ideas about sensory integration
rlm@449 394 - distributed communication among swarm creatures
rlm@449 395 - self-learning using free exploration,
rlm@449 396 - evolutionary algorithms involving creature construction
rlm@517 397 - exploration of exotic senses and effectors that are not possible
rlm@517 398 in the real world (such as telekinesis or a semantic sense)
rlm@449 399 - imagination using subworlds
rlm@449 400
rlm@451 401 During one test with =CORTEX=, I created 3,000 creatures each with
rlm@551 402 its own independent senses and ran them all at only 1/80 real time.
rlm@551 403 In another test, I created a detailed model of my own hand,
rlm@448 404 equipped with a realistic distribution of touch (more sensitive at
rlm@448 405 the fingertips), as well as eyes and ears, and it ran at around 1/4
rlm@451 406 real time.
rlm@448 407
rlm@451 408 #+BEGIN_LaTeX
rlm@449 409 \begin{sidewaysfigure}
rlm@449 410 \includegraphics[width=9.5in]{images/full-hand.png}
rlm@451 411 \caption{
rlm@451 412 I modeled my own right hand in Blender and rigged it with all the
rlm@451 413 senses that {\tt CORTEX} supports. My simulated hand has a
rlm@451 414 biologically inspired distribution of touch sensors. The senses are
rlm@562 415 displayed on the right (the red/black squares are raw sensory output),
rlm@562 416 and the simulation is displayed on the
rlm@451 417 left. Notice that my hand is curling its fingers, that it can see
rlm@451 418 its own finger from the eye in its palm, and that it can feel its
rlm@451 419 own thumb touching its palm.}
rlm@449 420 \end{sidewaysfigure}
rlm@451 421 #+END_LaTeX
rlm@448 422
rlm@558 423 * Designing =CORTEX=
rlm@551 424
rlm@551 425 In this chapter, I outline the design decisions that went into
rlm@516 426 making =CORTEX=, along with some details about its implementation.
rlm@516 427 (A practical guide to getting started with =CORTEX=, which skips
rlm@516 428 over the history and implementation details presented here, is
rlm@516 429 provided in an appendix at the end of this thesis.)
rlm@511 430
rlm@511 431 Throughout this project, I intended for =CORTEX= to be flexible and
rlm@511 432 extensible enough to be useful for other researchers who want to
rlm@547 433 test ideas of their own. To this end, wherever I have had to make
rlm@517 434 architectural choices about =CORTEX=, I have chosen to give as much
rlm@511 435 freedom to the user as possible, so that =CORTEX= may be used for
rlm@517 436 things I have not foreseen.
rlm@511 437
rlm@511 438 ** Building in simulation versus reality
rlm@517 439 The most important architectural decision of all is the choice to
rlm@517 440 use a computer-simulated environment in the first place! The world
rlm@462 441 is a vast and rich place, and for now simulations are a very poor
rlm@462 442 reflection of its complexity. It may be that there is a significant
rlm@517 443 qualitative difference between dealing with senses in the real
rlm@517 444 world and dealing with pale facsimiles of them in a simulation
rlm@547 445 (\cite{brooks-representation}). What are the advantages and
rlm@514 446 disadvantages of a simulation vs. reality?
rlm@515 447
rlm@462 448 *** Simulation
rlm@462 449
rlm@462 450 The advantages of virtual reality are that when everything is a
rlm@462 451 simulation, experiments in that simulation are absolutely
rlm@547 452 reproducible. It's also easier to change the creature and
rlm@547 453 environment to explore new situations and different sensory
rlm@547 454 combinations.
rlm@462 455
rlm@462 456 If the world is to be simulated on a computer, then not only do
rlm@547 457 you have to worry about whether the creature's senses are rich
rlm@462 458 enough to learn from the world, but whether the world itself is
rlm@462 459 rendered with enough detail and realism to give enough working
rlm@547 460 material to the creature's senses. To name just a few
rlm@462 461 difficulties facing modern physics simulators: destructibility of
rlm@462 462 the environment, simulation of water/other fluids, large areas,
rlm@462 463 nonrigid bodies, lots of objects, smoke. I don't know of any
rlm@547 464 computer simulation that would allow a creature to take a rock
rlm@462 465 and grind it into fine dust, then use that dust to make a clay
rlm@462 466 sculpture, at least not without spending years calculating the
rlm@462 467 interactions of every single small grain of dust. Maybe a
rlm@462 468 simulated world with today's limitations doesn't provide enough
rlm@462 469 richness for real intelligence to evolve.
rlm@462 470
rlm@462 471 *** Reality
rlm@462 472
rlm@462 473 The other approach for playing with senses is to hook your
rlm@462 474 software up to real cameras, microphones, robots, etc., and let it
rlm@462 475 loose in the real world. This has the advantage of eliminating
rlm@462 476 concerns about simulating the world at the expense of increasing
rlm@462 477 the complexity of implementing the senses. Instead of just
rlm@462 478 grabbing the current rendered frame for processing, you have to
rlm@462 479 use an actual camera with real lenses and interact with photons to
rlm@547 480 get an image. It is much harder to change the creature, which is
rlm@462 481 now partly a physical robot of some sort, since doing so involves
rlm@462 482 changing things around in the real world instead of modifying
rlm@462 483 lines of code. While the real world is very rich and definitely
rlm@547 484 provides enough stimulation for intelligence to develop (as
rlm@547 485 evidenced by our own existence), it is also uncontrollable in the
rlm@462 486 sense that a particular situation cannot be recreated perfectly or
rlm@547 487 saved for later use. It is harder to conduct Science because it is
rlm@462 488 harder to repeat an experiment. The worst thing about using the
rlm@462 489 real world instead of a simulation is the matter of time. Instead
rlm@462 490 of simulated time you get the constant and unstoppable flow of
rlm@462 491 real time. This severely limits the sorts of software you can use
rlm@525 492 to program an AI, because all sense inputs must be handled in real
rlm@462 493 time. Complicated ideas may have to be implemented in hardware or
rlm@462 494 may simply be impossible given the current speed of our
rlm@462 495 processors. Contrast this with a simulation, in which the flow of
rlm@462 496 time in the simulated world can be slowed down to accommodate the
rlm@547 497 limitations of the creature's programming. In terms of cost, doing
rlm@547 498 everything in software is far cheaper than building custom
rlm@462 499 real-time hardware. All you need is a laptop and some patience.
rlm@515 500
rlm@516 501 ** Simulated time enables rapid prototyping \& simple programs
rlm@435 502
rlm@462 503 I envision =CORTEX= being used to support rapid prototyping and
rlm@462 504 iteration of ideas. Even if I could put together a well constructed
rlm@462 505 kit for creating robots, it would still not be enough because of
rlm@462 506 the scourge of real-time processing. Anyone who wants to test their
rlm@462 507 ideas in the real world must always worry about getting their
rlm@465 508 algorithms to run fast enough to process information in real time.
rlm@465 509 The need for real time processing only increases if multiple senses
rlm@465 510 are involved. In the extreme case, even simple algorithms will have
rlm@465 511 to be accelerated by ASIC chips or FPGAs, turning what would
rlm@517 512 otherwise be a few lines of code and a 10x speed penalty into a
rlm@465 513 multi-month ordeal. For this reason, =CORTEX= supports
rlm@547 514 /time-dilation/, which scales back the framerate of the simulation
rlm@547 515 in proportion to the amount of processing each frame. From the
rlm@547 516 perspective of the creatures inside the simulation, time always
rlm@547 517 appears to flow at a constant rate, regardless of how complicated
rlm@547 518 the environment becomes or how many creatures are in the
rlm@547 519 simulation. The cost is that =CORTEX= can sometimes run slower than
rlm@548 520 real time. Time dilation works both ways, however --- simulations
rlm@547 521 of very simple creatures in =CORTEX= generally run at 40x real-time
rlm@547 522 on my machine!
rlm@462 523
rlm@511 524 ** All sense organs are two-dimensional surfaces
rlm@514 525
rlm@468 526 If =CORTEX= is to support a wide variety of senses, it would help
rlm@547 527 to have a better understanding of what a sense actually is! While
rlm@547 528 vision, touch, and hearing all seem like they are quite different
rlm@547 529 things, I was surprised to learn during the course of this thesis
rlm@547 530 that they (and all physical senses) can be expressed as exactly the
rlm@547 531 same mathematical object!
rlm@468 532
rlm@468 533 Human beings are three-dimensional objects, and the nerves that
rlm@468 534 transmit data from our various sense organs to our brain are
rlm@468 535 essentially one-dimensional. This leaves up to two dimensions in
rlm@468 536 which our sensory information may flow. For example, imagine your
rlm@468 537 skin: it is a two-dimensional surface around a three-dimensional
rlm@468 538 object (your body). It has discrete touch sensors embedded at
rlm@468 539 various points, and the density of these sensors corresponds to the
rlm@468 540 sensitivity of that region of skin. Each touch sensor connects to a
rlm@468 541 nerve, all of which eventually are bundled together as they travel
rlm@468 542 up the spinal cord to the brain. Intersect the spinal nerves with a
rlm@468 543 guillotining plane and you will see all of the sensory data of the
rlm@468 544 skin revealed in a roughly circular two-dimensional image which is
rlm@468 545 the cross section of the spinal cord. Points on this image that are
rlm@468 546 close together in this circle represent touch sensors that are
rlm@468 547 /probably/ close together on the skin, although there is of course
rlm@468 548 some cutting and rearrangement that has to be done to transfer the
rlm@468 549 complicated surface of the skin onto a two dimensional image.
rlm@468 550
rlm@468 551 Most human senses consist of many discrete sensors of various
rlm@468 552 properties distributed along a surface at various densities. For
rlm@468 553 skin, it is Pacinian corpuscles, Meissner's corpuscles, Merkel's
rlm@547 554 disks, and Ruffini's endings (\cite{textbook901}), which detect
rlm@517 555 pressure and vibration of various intensities. For ears, it is the
rlm@517 556 stereocilia distributed along the basilar membrane inside the
rlm@517 557 cochlea; each one is sensitive to a slightly different frequency of
rlm@517 558 sound. For eyes, it is rods and cones distributed along the surface
rlm@517 559 of the retina. In each case, we can describe the sense with a
rlm@517 560 surface and a distribution of sensors along that surface.
rlm@468 561
rlm@525 562 In fact, almost every human sense can be effectively described in
rlm@525 563 terms of a surface containing embedded sensors. If the sense had
rlm@525 564 any more dimensions, then there wouldn't be enough room in the
rlm@547 565 spinal cord to transmit the information!
rlm@468 566
rlm@468 567 Therefore, =CORTEX= must support the ability to create objects and
rlm@468 568 then be able to ``paint'' points along their surfaces to describe
rlm@468 569 each sense.
rlm@468 570
rlm@468 571 Fortunately this idea is already a well known computer graphics
rlm@548 572 technique called /UV-mapping/. In UV-mapping, the three-dimensional
rlm@547 573 surface of a model is cut and smooshed until it fits on a
rlm@547 574 two-dimensional image. You paint whatever you want on that image,
rlm@547 575 and when the three-dimensional shape is rendered in a game the
rlm@547 576 smooshing and cutting is reversed and the image appears on the
rlm@547 577 three-dimensional object.
rlm@468 578
rlm@468 579 To make a sense, interpret the UV-image as describing the
rlm@563 580 distribution of that senses' sensors. To get different types of
rlm@468 581 sensors, you can either use a different color for each type of
rlm@468 582 sensor, or use multiple UV-maps, each labeled with that sensor
rlm@468 583 type. I generally use a white pixel to mean the presence of a
rlm@468 584 sensor and a black pixel to mean the absence of a sensor, and use
rlm@563 585 one UV-map for each sensor-type within a given sense.
rlm@468 586
rlm@468 587 #+CAPTION: The UV-map for an elongated icososphere. The white
rlm@468 588 #+caption: dots each represent a touch sensor. They are dense
rlm@468 589 #+caption: in the regions that describe the tip of the finger,
rlm@468 590 #+caption: and less dense along the dorsal side of the finger
rlm@468 591 #+caption: opposite the tip.
rlm@468 592 #+name: finger-UV
rlm@468 593 #+ATTR_latex: :width 10cm
rlm@468 594 [[./images/finger-UV.png]]
rlm@468 595
rlm@563 596 #+caption: Ventral side of the UV-mapped finger. Note the
rlm@468 597 #+caption: density of touch sensors at the tip.
rlm@468 598 #+name: finger-side-view
rlm@468 599 #+ATTR_LaTeX: :width 10cm
rlm@468 600 [[./images/finger-1.png]]
rlm@468 601
rlm@507 602 ** Video game engines provide ready-made physics and shading
rlm@462 603
rlm@462 604 I did not need to write my own physics simulation code or shader to
rlm@462 605 build =CORTEX=. Doing so would lead to a system that is impossible
rlm@462 606 for anyone but myself to use anyway. Instead, I use a video game
rlm@517 607 engine as a base and modify it to accommodate the additional needs
rlm@462 608 of =CORTEX=. Video game engines are an ideal starting point to
rlm@462 609 build =CORTEX=, because they are not far from being creature
rlm@463 610 building systems themselves.
rlm@462 611
rlm@462 612 First off, general purpose video game engines come with a physics
rlm@462 613 engine and lighting / sound system. The physics system provides
rlm@462 614 tools that can be co-opted to serve as touch, proprioception, and
rlm@563 615 muscles. Because some games support split screen views, a good
rlm@563 616 video game engine will allow you to efficiently create multiple
rlm@563 617 cameras in the simulated world that can be used as eyes. Video game
rlm@563 618 systems offer integrated asset management for things like textures
rlm@563 619 and creature models, providing an avenue for defining creatures.
rlm@563 620 They also understand UV-mapping, because this technique is used to
rlm@563 621 apply a texture to a model. Finally, because video game engines
rlm@563 622 support a large number of developers, as long as =CORTEX= doesn't
rlm@563 623 stray too far from the base system, other researchers can turn to
rlm@563 624 this community for help when doing their research.
rlm@463 625
rlm@507 626 ** =CORTEX= is based on jMonkeyEngine3
rlm@463 627
rlm@463 628 While preparing to build =CORTEX= I studied several video game
rlm@463 629 engines to see which would best serve as a base. The top contenders
rlm@463 630 were:
rlm@463 631
rlm@547 632 - [[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 633 in 1997. All the source code was released by ID software into
rlm@547 634 the Public Domain several years ago, and as a result it has
rlm@547 635 been ported to many different languages. This engine was
rlm@547 636 famous for its advanced use of realistic shading and it had
rlm@547 637 decent and fast physics simulation. The main advantage of the
rlm@547 638 Quake II engine is its simplicity, but I ultimately rejected
rlm@547 639 it because the engine is too tied to the concept of a
rlm@463 640 first-person shooter game. One of the problems I had was that
rlm@463 641 there does not seem to be any easy way to attach multiple
rlm@463 642 cameras to a single character. There are also several physics
rlm@463 643 clipping issues that are corrected in a way that only applies
rlm@463 644 to the main character and do not apply to arbitrary objects.
rlm@463 645
rlm@463 646 - [[http://source.valvesoftware.com/][Source Engine]] :: The Source Engine evolved from the Quake II
rlm@463 647 and Quake I engines and is used by Valve in the Half-Life
rlm@463 648 series of games. The physics simulation in the Source Engine
rlm@463 649 is quite accurate and probably the best out of all the engines
rlm@463 650 I investigated. There is also an extensive community actively
rlm@463 651 working with the engine. However, applications that use the
rlm@463 652 Source Engine must be written in C++, the code is not open, it
rlm@463 653 only runs on Windows, and the tools that come with the SDK to
rlm@463 654 handle models and textures are complicated and awkward to use.
rlm@463 655
rlm@463 656 - [[http://jmonkeyengine.com/][jMonkeyEngine3]] :: jMonkeyEngine3 is a new library for creating
rlm@463 657 games in Java. It uses OpenGL to render to the screen and uses
rlm@463 658 screengraphs to avoid drawing things that do not appear on the
rlm@463 659 screen. It has an active community and several games in the
rlm@463 660 pipeline. The engine was not built to serve any particular
rlm@463 661 game but is instead meant to be used for any 3D game.
rlm@463 662
rlm@521 663 I chose jMonkeyEngine3 because it had the most features out of all
rlm@521 664 the free projects I looked at, and because I could then write my
rlm@521 665 code in clojure, an implementation of =LISP= that runs on the JVM.
rlm@435 666
rlm@507 667 ** =CORTEX= uses Blender to create creature models
rlm@435 668
rlm@464 669 For the simple worm-like creatures I will use later on in this
rlm@464 670 thesis, I could define a simple API in =CORTEX= that would allow
rlm@464 671 one to create boxes, spheres, etc., and leave that API as the sole
rlm@464 672 way to create creatures. However, for =CORTEX= to truly be useful
rlm@468 673 for other projects, it needs a way to construct complicated
rlm@464 674 creatures. If possible, it would be nice to leverage work that has
rlm@464 675 already been done by the community of 3D modelers, or at least
rlm@517 676 enable people who are talented at modeling but not programming to
rlm@468 677 design =CORTEX= creatures.
rlm@464 678
rlm@547 679 Therefore I use Blender, a free 3D modeling program, as the main
rlm@464 680 way to create creatures in =CORTEX=. However, the creatures modeled
rlm@464 681 in Blender must also be simple to simulate in jMonkeyEngine3's game
rlm@468 682 engine, and must also be easy to rig with =CORTEX='s senses. I
rlm@547 683 accomplish this with extensive use of Blender's ``empty nodes.''
rlm@464 684
rlm@468 685 Empty nodes have no mass, physical presence, or appearance, but
rlm@468 686 they can hold metadata and have names. I use a tree structure of
rlm@468 687 empty nodes to specify senses in the following manner:
rlm@468 688
rlm@468 689 - Create a single top-level empty node whose name is the name of
rlm@468 690 the sense.
rlm@468 691 - Add empty nodes which each contain meta-data relevant to the
rlm@468 692 sense, including a UV-map describing the number/distribution of
rlm@468 693 sensors if applicable.
rlm@468 694 - Make each empty-node the child of the top-level node.
rlm@468 695
rlm@517 696 #+caption: An example of annotating a creature model with empty
rlm@468 697 #+caption: nodes to describe the layout of senses. There are
rlm@468 698 #+caption: multiple empty nodes which each describe the position
rlm@468 699 #+caption: of muscles, ears, eyes, or joints.
rlm@468 700 #+name: sense-nodes
rlm@468 701 #+ATTR_LaTeX: :width 10cm
rlm@468 702 [[./images/empty-sense-nodes.png]]
rlm@468 703
rlm@508 704 ** Bodies are composed of segments connected by joints
rlm@468 705
rlm@468 706 Blender is a general purpose animation tool, which has been used in
rlm@468 707 the past to create high quality movies such as Sintel
rlm@547 708 (\cite{blender}). Though Blender can model and render even
rlm@547 709 complicated things like water, it is crucial to keep models that
rlm@547 710 are meant to be simulated as creatures simple. =Bullet=, which
rlm@547 711 =CORTEX= uses though jMonkeyEngine3, is a rigid-body physics
rlm@547 712 system. This offers a compromise between the expressiveness of a
rlm@547 713 game level and the speed at which it can be simulated, and it means
rlm@547 714 that creatures should be naturally expressed as rigid components
rlm@547 715 held together by joint constraints.
rlm@468 716
rlm@517 717 But humans are more like a squishy bag wrapped around some hard
rlm@517 718 bones which define the overall shape. When we move, our skin bends
rlm@517 719 and stretches to accommodate the new positions of our bones.
rlm@468 720
rlm@468 721 One way to make bodies composed of rigid pieces connected by joints
rlm@468 722 /seem/ more human-like is to use an /armature/, (or /rigging/)
rlm@468 723 system, which defines a overall ``body mesh'' and defines how the
rlm@468 724 mesh deforms as a function of the position of each ``bone'' which
rlm@468 725 is a standard rigid body. This technique is used extensively to
rlm@468 726 model humans and create realistic animations. It is not a good
rlm@517 727 technique for physical simulation because it is a lie -- the skin
rlm@517 728 is not a physical part of the simulation and does not interact with
rlm@517 729 any objects in the world or itself. Objects will pass right though
rlm@517 730 the skin until they come in contact with the underlying bone, which
rlm@517 731 is a physical object. Without simulating the skin, the sense of
rlm@517 732 touch has little meaning, and the creature's own vision will lie to
rlm@517 733 it about the true extent of its body. Simulating the skin as a
rlm@517 734 physical object requires some way to continuously update the
rlm@517 735 physical model of the skin along with the movement of the bones,
rlm@517 736 which is unacceptably slow compared to rigid body simulation.
rlm@468 737
rlm@547 738 Therefore, instead of using the human-like ``bony meatbag''
rlm@547 739 approach, I decided to base my body plans on multiple solid objects
rlm@547 740 that are connected by joints, inspired by the robot =EVE= from the
rlm@547 741 movie WALL-E.
rlm@464 742
rlm@464 743 #+caption: =EVE= from the movie WALL-E. This body plan turns
rlm@464 744 #+caption: out to be much better suited to my purposes than a more
rlm@464 745 #+caption: human-like one.
rlm@465 746 #+ATTR_LaTeX: :width 10cm
rlm@464 747 [[./images/Eve.jpg]]
rlm@464 748
rlm@464 749 =EVE='s body is composed of several rigid components that are held
rlm@464 750 together by invisible joint constraints. This is what I mean by
rlm@547 751 /eve-like/. The main reason that I use eve-like bodies is for
rlm@547 752 simulation efficiency, and so that there will be correspondence
rlm@547 753 between the AI's senses and the physical presence of its body. Each
rlm@547 754 individual section is simulated by a separate rigid body that
rlm@547 755 corresponds exactly with its visual representation and does not
rlm@547 756 change. Sections are connected by invisible joints that are well
rlm@547 757 supported in jMonkeyEngine3. Bullet, the physics backend for
rlm@547 758 jMonkeyEngine3, can efficiently simulate hundreds of rigid bodies
rlm@547 759 connected by joints. Just because sections are rigid does not mean
rlm@547 760 they have to stay as one piece forever; they can be dynamically
rlm@547 761 replaced with multiple sections to simulate splitting in two. This
rlm@547 762 could be used to simulate retractable claws or =EVE='s hands, which
rlm@547 763 are able to coalesce into one object in the movie.
rlm@465 764
rlm@469 765 *** Solidifying/Connecting a body
rlm@465 766
rlm@469 767 =CORTEX= creates a creature in two steps: first, it traverses the
rlm@562 768 nodes in the Blender file and creates physical representations for
rlm@562 769 any of them that have mass defined in their Blender meta-data.
rlm@466 770
rlm@466 771 #+caption: Program for iterating through the nodes in a blender file
rlm@466 772 #+caption: and generating physical jMonkeyEngine3 objects with mass
rlm@466 773 #+caption: and a matching physics shape.
rlm@518 774 #+name: physical
rlm@466 775 #+begin_listing clojure
rlm@466 776 #+begin_src clojure
rlm@466 777 (defn physical!
rlm@466 778 "Iterate through the nodes in creature and make them real physical
rlm@466 779 objects in the simulation."
rlm@466 780 [#^Node creature]
rlm@466 781 (dorun
rlm@466 782 (map
rlm@466 783 (fn [geom]
rlm@466 784 (let [physics-control
rlm@466 785 (RigidBodyControl.
rlm@466 786 (HullCollisionShape.
rlm@466 787 (.getMesh geom))
rlm@466 788 (if-let [mass (meta-data geom "mass")]
rlm@466 789 (float mass) (float 1)))]
rlm@466 790 (.addControl geom physics-control)))
rlm@466 791 (filter #(isa? (class %) Geometry )
rlm@466 792 (node-seq creature)))))
rlm@466 793 #+end_src
rlm@466 794 #+end_listing
rlm@465 795
rlm@469 796 The next step to making a proper body is to connect those pieces
rlm@469 797 together with joints. jMonkeyEngine has a large array of joints
rlm@469 798 available via =bullet=, such as Point2Point, Cone, Hinge, and a
rlm@469 799 generic Six Degree of Freedom joint, with or without spring
rlm@469 800 restitution.
rlm@465 801
rlm@469 802 Joints are treated a lot like proper senses, in that there is a
rlm@469 803 top-level empty node named ``joints'' whose children each
rlm@469 804 represent a joint.
rlm@466 805
rlm@469 806 #+caption: View of the hand model in Blender showing the main ``joints''
rlm@469 807 #+caption: node (highlighted in yellow) and its children which each
rlm@469 808 #+caption: represent a joint in the hand. Each joint node has metadata
rlm@469 809 #+caption: specifying what sort of joint it is.
rlm@469 810 #+name: blender-hand
rlm@469 811 #+ATTR_LaTeX: :width 10cm
rlm@469 812 [[./images/hand-screenshot1.png]]
rlm@469 813
rlm@469 814
rlm@469 815 =CORTEX='s procedure for binding the creature together with joints
rlm@469 816 is as follows:
rlm@469 817
rlm@469 818 - Find the children of the ``joints'' node.
rlm@469 819 - Determine the two spatials the joint is meant to connect.
rlm@469 820 - Create the joint based on the meta-data of the empty node.
rlm@469 821
rlm@469 822 The higher order function =sense-nodes= from =cortex.sense=
rlm@469 823 simplifies finding the joints based on their parent ``joints''
rlm@469 824 node.
rlm@466 825
rlm@466 826 #+caption: Retrieving the children empty nodes from a single
rlm@563 827 #+caption: named empty node is a common pattern in =CORTEX=.
rlm@563 828 #+caption: Further instances of this technique for the senses
rlm@466 829 #+caption: will be omitted
rlm@466 830 #+name: get-empty-nodes
rlm@466 831 #+begin_listing clojure
rlm@466 832 #+begin_src clojure
rlm@466 833 (defn sense-nodes
rlm@562 834 "For some senses there is a special empty Blender node whose
rlm@466 835 children are considered markers for an instance of that sense. This
rlm@466 836 function generates functions to find those children, given the name
rlm@466 837 of the special parent node."
rlm@466 838 [parent-name]
rlm@466 839 (fn [#^Node creature]
rlm@466 840 (if-let [sense-node (.getChild creature parent-name)]
rlm@466 841 (seq (.getChildren sense-node)) [])))
rlm@466 842
rlm@466 843 (def
rlm@466 844 ^{:doc "Return the children of the creature's \"joints\" node."
rlm@466 845 :arglists '([creature])}
rlm@466 846 joints
rlm@466 847 (sense-nodes "joints"))
rlm@466 848 #+end_src
rlm@466 849 #+end_listing
rlm@466 850
rlm@469 851 To find a joint's targets, =CORTEX= creates a small cube, centered
rlm@469 852 around the empty-node, and grows the cube exponentially until it
rlm@469 853 intersects two physical objects. The objects are ordered according
rlm@469 854 to the joint's rotation, with the first one being the object that
rlm@469 855 has more negative coordinates in the joint's reference frame.
rlm@563 856 Because the objects must be physical, the empty-node itself
rlm@563 857 escapes detection. Because the objects must be physical,
rlm@563 858 =joint-targets= must be called /after/ =physical!= is called.
rlm@464 859
rlm@469 860 #+caption: Program to find the targets of a joint node by
rlm@517 861 #+caption: exponentially growth of a search cube.
rlm@469 862 #+name: joint-targets
rlm@469 863 #+begin_listing clojure
rlm@469 864 #+begin_src clojure
rlm@466 865 (defn joint-targets
rlm@466 866 "Return the two closest two objects to the joint object, ordered
rlm@466 867 from bottom to top according to the joint's rotation."
rlm@466 868 [#^Node parts #^Node joint]
rlm@466 869 (loop [radius (float 0.01)]
rlm@466 870 (let [results (CollisionResults.)]
rlm@466 871 (.collideWith
rlm@466 872 parts
rlm@466 873 (BoundingBox. (.getWorldTranslation joint)
rlm@466 874 radius radius radius) results)
rlm@466 875 (let [targets
rlm@466 876 (distinct
rlm@466 877 (map #(.getGeometry %) results))]
rlm@466 878 (if (>= (count targets) 2)
rlm@466 879 (sort-by
rlm@466 880 #(let [joint-ref-frame-position
rlm@466 881 (jme-to-blender
rlm@466 882 (.mult
rlm@466 883 (.inverse (.getWorldRotation joint))
rlm@466 884 (.subtract (.getWorldTranslation %)
rlm@466 885 (.getWorldTranslation joint))))]
rlm@466 886 (.dot (Vector3f. 1 1 1) joint-ref-frame-position))
rlm@466 887 (take 2 targets))
rlm@466 888 (recur (float (* radius 2))))))))
rlm@469 889 #+end_src
rlm@469 890 #+end_listing
rlm@464 891
rlm@469 892 Once =CORTEX= finds all joints and targets, it creates them using
rlm@469 893 a dispatch on the metadata of each joint node.
rlm@466 894
rlm@562 895 #+caption: Program to dispatch on Blender metadata and create joints
rlm@517 896 #+caption: suitable for physical simulation.
rlm@469 897 #+name: joint-dispatch
rlm@469 898 #+begin_listing clojure
rlm@469 899 #+begin_src clojure
rlm@466 900 (defmulti joint-dispatch
rlm@562 901 "Translate Blender pseudo-joints into real JME joints."
rlm@466 902 (fn [constraints & _]
rlm@466 903 (:type constraints)))
rlm@466 904
rlm@466 905 (defmethod joint-dispatch :point
rlm@466 906 [constraints control-a control-b pivot-a pivot-b rotation]
rlm@466 907 (doto (SixDofJoint. control-a control-b pivot-a pivot-b false)
rlm@466 908 (.setLinearLowerLimit Vector3f/ZERO)
rlm@466 909 (.setLinearUpperLimit Vector3f/ZERO)))
rlm@466 910
rlm@466 911 (defmethod joint-dispatch :hinge
rlm@466 912 [constraints control-a control-b pivot-a pivot-b rotation]
rlm@466 913 (let [axis (if-let [axis (:axis constraints)] axis Vector3f/UNIT_X)
rlm@466 914 [limit-1 limit-2] (:limit constraints)
rlm@466 915 hinge-axis (.mult rotation (blender-to-jme axis))]
rlm@466 916 (doto (HingeJoint. control-a control-b pivot-a pivot-b
rlm@466 917 hinge-axis hinge-axis)
rlm@466 918 (.setLimit limit-1 limit-2))))
rlm@466 919
rlm@466 920 (defmethod joint-dispatch :cone
rlm@466 921 [constraints control-a control-b pivot-a pivot-b rotation]
rlm@466 922 (let [limit-xz (:limit-xz constraints)
rlm@466 923 limit-xy (:limit-xy constraints)
rlm@466 924 twist (:twist constraints)]
rlm@466 925 (doto (ConeJoint. control-a control-b pivot-a pivot-b
rlm@466 926 rotation rotation)
rlm@466 927 (.setLimit (float limit-xz) (float limit-xy)
rlm@466 928 (float twist)))))
rlm@469 929 #+end_src
rlm@469 930 #+end_listing
rlm@466 931
rlm@522 932 All that is left for joints is to combine the above pieces into
rlm@469 933 something that can operate on the collection of nodes that a
rlm@562 934 Blender file represents.
rlm@466 935
rlm@469 936 #+caption: Program to completely create a joint given information
rlm@562 937 #+caption: from a Blender file.
rlm@469 938 #+name: connect
rlm@469 939 #+begin_listing clojure
rlm@466 940 #+begin_src clojure
rlm@466 941 (defn connect
rlm@466 942 "Create a joint between 'obj-a and 'obj-b at the location of
rlm@466 943 'joint. The type of joint is determined by the metadata on 'joint.
rlm@466 944
rlm@466 945 Here are some examples:
rlm@466 946 {:type :point}
rlm@466 947 {:type :hinge :limit [0 (/ Math/PI 2)] :axis (Vector3f. 0 1 0)}
rlm@466 948 (:axis defaults to (Vector3f. 1 0 0) if not provided for hinge joints)
rlm@466 949
rlm@466 950 {:type :cone :limit-xz 0]
rlm@466 951 :limit-xy 0]
rlm@562 952 :twist 0]} (use XZY rotation mode in Blender!)"
rlm@466 953 [#^Node obj-a #^Node obj-b #^Node joint]
rlm@466 954 (let [control-a (.getControl obj-a RigidBodyControl)
rlm@466 955 control-b (.getControl obj-b RigidBodyControl)
rlm@466 956 joint-center (.getWorldTranslation joint)
rlm@466 957 joint-rotation (.toRotationMatrix (.getWorldRotation joint))
rlm@466 958 pivot-a (world-to-local obj-a joint-center)
rlm@466 959 pivot-b (world-to-local obj-b joint-center)]
rlm@466 960 (if-let
rlm@466 961 [constraints (map-vals eval (read-string (meta-data joint "joint")))]
rlm@466 962 ;; A side-effect of creating a joint registers
rlm@466 963 ;; it with both physics objects which in turn
rlm@466 964 ;; will register the joint with the physics system
rlm@466 965 ;; when the simulation is started.
rlm@466 966 (joint-dispatch constraints
rlm@466 967 control-a control-b
rlm@466 968 pivot-a pivot-b
rlm@466 969 joint-rotation))))
rlm@469 970 #+end_src
rlm@469 971 #+end_listing
rlm@466 972
rlm@469 973 In general, whenever =CORTEX= exposes a sense (or in this case
rlm@469 974 physicality), it provides a function of the type =sense!=, which
rlm@469 975 takes in a collection of nodes and augments it to support that
rlm@517 976 sense. The function returns any controls necessary to use that
rlm@517 977 sense. In this case =body!= creates a physical body and returns no
rlm@469 978 control functions.
rlm@466 979
rlm@469 980 #+caption: Program to give joints to a creature.
rlm@518 981 #+name: joints
rlm@469 982 #+begin_listing clojure
rlm@469 983 #+begin_src clojure
rlm@466 984 (defn joints!
rlm@466 985 "Connect the solid parts of the creature with physical joints. The
rlm@466 986 joints are taken from the \"joints\" node in the creature."
rlm@466 987 [#^Node creature]
rlm@466 988 (dorun
rlm@466 989 (map
rlm@466 990 (fn [joint]
rlm@466 991 (let [[obj-a obj-b] (joint-targets creature joint)]
rlm@466 992 (connect obj-a obj-b joint)))
rlm@466 993 (joints creature))))
rlm@466 994 (defn body!
rlm@466 995 "Endow the creature with a physical body connected with joints. The
rlm@466 996 particulars of the joints and the masses of each body part are
rlm@562 997 determined in Blender."
rlm@466 998 [#^Node creature]
rlm@466 999 (physical! creature)
rlm@466 1000 (joints! creature))
rlm@469 1001 #+end_src
rlm@469 1002 #+end_listing
rlm@466 1003
rlm@469 1004 All of the code you have just seen amounts to only 130 lines, yet
rlm@469 1005 because it builds on top of Blender and jMonkeyEngine3, those few
rlm@469 1006 lines pack quite a punch!
rlm@466 1007
rlm@469 1008 The hand from figure \ref{blender-hand}, which was modeled after
rlm@469 1009 my own right hand, can now be given joints and simulated as a
rlm@469 1010 creature.
rlm@466 1011
rlm@562 1012 #+caption: With the ability to create physical creatures from Blender,
rlm@517 1013 #+caption: =CORTEX= gets one step closer to becoming a full creature
rlm@469 1014 #+caption: simulation environment.
rlm@518 1015 #+name: physical-hand
rlm@469 1016 #+ATTR_LaTeX: :width 15cm
rlm@469 1017 [[./images/physical-hand.png]]
rlm@468 1018
rlm@511 1019 ** Sight reuses standard video game components...
rlm@436 1020
rlm@470 1021 Vision is one of the most important senses for humans, so I need to
rlm@470 1022 build a simulated sense of vision for my AI. I will do this with
rlm@470 1023 simulated eyes. Each eye can be independently moved and should see
rlm@470 1024 its own version of the world depending on where it is.
rlm@470 1025
rlm@470 1026 Making these simulated eyes a reality is simple because
rlm@470 1027 jMonkeyEngine already contains extensive support for multiple views
rlm@470 1028 of the same 3D simulated world. The reason jMonkeyEngine has this
rlm@470 1029 support is because the support is necessary to create games with
rlm@470 1030 split-screen views. Multiple views are also used to create
rlm@470 1031 efficient pseudo-reflections by rendering the scene from a certain
rlm@470 1032 perspective and then projecting it back onto a surface in the 3D
rlm@470 1033 world.
rlm@470 1034
rlm@470 1035 #+caption: jMonkeyEngine supports multiple views to enable
rlm@470 1036 #+caption: split-screen games, like GoldenEye, which was one of
rlm@470 1037 #+caption: the first games to use split-screen views.
rlm@518 1038 #+name: goldeneye
rlm@470 1039 #+ATTR_LaTeX: :width 10cm
rlm@470 1040 [[./images/goldeneye-4-player.png]]
rlm@470 1041
rlm@470 1042 *** A Brief Description of jMonkeyEngine's Rendering Pipeline
rlm@470 1043
rlm@470 1044 jMonkeyEngine allows you to create a =ViewPort=, which represents a
rlm@470 1045 view of the simulated world. You can create as many of these as you
rlm@470 1046 want. Every frame, the =RenderManager= iterates through each
rlm@470 1047 =ViewPort=, rendering the scene in the GPU. For each =ViewPort= there
rlm@470 1048 is a =FrameBuffer= which represents the rendered image in the GPU.
rlm@470 1049
rlm@470 1050 #+caption: =ViewPorts= are cameras in the world. During each frame,
rlm@470 1051 #+caption: the =RenderManager= records a snapshot of what each view
rlm@470 1052 #+caption: is currently seeing; these snapshots are =FrameBuffer= objects.
rlm@508 1053 #+name: rendermanagers
rlm@470 1054 #+ATTR_LaTeX: :width 10cm
rlm@508 1055 [[./images/diagram_rendermanager2.png]]
rlm@470 1056
rlm@470 1057 Each =ViewPort= can have any number of attached =SceneProcessor=
rlm@470 1058 objects, which are called every time a new frame is rendered. A
rlm@470 1059 =SceneProcessor= receives its =ViewPort's= =FrameBuffer= and can do
rlm@470 1060 whatever it wants to the data. Often this consists of invoking GPU
rlm@470 1061 specific operations on the rendered image. The =SceneProcessor= can
rlm@470 1062 also copy the GPU image data to RAM and process it with the CPU.
rlm@470 1063
rlm@470 1064 *** Appropriating Views for Vision
rlm@470 1065
rlm@470 1066 Each eye in the simulated creature needs its own =ViewPort= so
rlm@470 1067 that it can see the world from its own perspective. To this
rlm@470 1068 =ViewPort=, I add a =SceneProcessor= that feeds the visual data to
rlm@470 1069 any arbitrary continuation function for further processing. That
rlm@470 1070 continuation function may perform both CPU and GPU operations on
rlm@470 1071 the data. To make this easy for the continuation function, the
rlm@470 1072 =SceneProcessor= maintains appropriately sized buffers in RAM to
rlm@470 1073 hold the data. It does not do any copying from the GPU to the CPU
rlm@470 1074 itself because it is a slow operation.
rlm@470 1075
rlm@517 1076 #+caption: Function to make the rendered scene in jMonkeyEngine
rlm@470 1077 #+caption: available for further processing.
rlm@470 1078 #+name: pipeline-1
rlm@470 1079 #+begin_listing clojure
rlm@470 1080 #+begin_src clojure
rlm@470 1081 (defn vision-pipeline
rlm@470 1082 "Create a SceneProcessor object which wraps a vision processing
rlm@470 1083 continuation function. The continuation is a function that takes
rlm@470 1084 [#^Renderer r #^FrameBuffer fb #^ByteBuffer b #^BufferedImage bi],
rlm@470 1085 each of which has already been appropriately sized."
rlm@470 1086 [continuation]
rlm@470 1087 (let [byte-buffer (atom nil)
rlm@470 1088 renderer (atom nil)
rlm@470 1089 image (atom nil)]
rlm@470 1090 (proxy [SceneProcessor] []
rlm@470 1091 (initialize
rlm@470 1092 [renderManager viewPort]
rlm@470 1093 (let [cam (.getCamera viewPort)
rlm@470 1094 width (.getWidth cam)
rlm@470 1095 height (.getHeight cam)]
rlm@470 1096 (reset! renderer (.getRenderer renderManager))
rlm@470 1097 (reset! byte-buffer
rlm@470 1098 (BufferUtils/createByteBuffer
rlm@470 1099 (* width height 4)))
rlm@470 1100 (reset! image (BufferedImage.
rlm@470 1101 width height
rlm@470 1102 BufferedImage/TYPE_4BYTE_ABGR))))
rlm@470 1103 (isInitialized [] (not (nil? @byte-buffer)))
rlm@470 1104 (reshape [_ _ _])
rlm@470 1105 (preFrame [_])
rlm@470 1106 (postQueue [_])
rlm@470 1107 (postFrame
rlm@470 1108 [#^FrameBuffer fb]
rlm@470 1109 (.clear @byte-buffer)
rlm@470 1110 (continuation @renderer fb @byte-buffer @image))
rlm@470 1111 (cleanup []))))
rlm@470 1112 #+end_src
rlm@470 1113 #+end_listing
rlm@470 1114
rlm@470 1115 The continuation function given to =vision-pipeline= above will be
rlm@470 1116 given a =Renderer= and three containers for image data. The
rlm@470 1117 =FrameBuffer= references the GPU image data, but the pixel data
rlm@470 1118 can not be used directly on the CPU. The =ByteBuffer= and
rlm@470 1119 =BufferedImage= are initially "empty" but are sized to hold the
rlm@470 1120 data in the =FrameBuffer=. I call transferring the GPU image data
rlm@470 1121 to the CPU structures "mixing" the image data.
rlm@470 1122
rlm@470 1123 *** Optical sensor arrays are described with images and referenced with metadata
rlm@470 1124
rlm@470 1125 The vision pipeline described above handles the flow of rendered
rlm@470 1126 images. Now, =CORTEX= needs simulated eyes to serve as the source
rlm@470 1127 of these images.
rlm@470 1128
rlm@562 1129 An eye is described in Blender in the same way as a joint. They
rlm@470 1130 are zero dimensional empty objects with no geometry whose local
rlm@470 1131 coordinate system determines the orientation of the resulting eye.
rlm@470 1132 All eyes are children of a parent node named "eyes" just as all
rlm@470 1133 joints have a parent named "joints". An eye binds to the nearest
rlm@470 1134 physical object with =bind-sense=.
rlm@470 1135
rlm@470 1136 #+caption: Here, the camera is created based on metadata on the
rlm@470 1137 #+caption: eye-node and attached to the nearest physical object
rlm@470 1138 #+caption: with =bind-sense=
rlm@470 1139 #+name: add-eye
rlm@470 1140 #+begin_listing clojure
rlm@545 1141 #+begin_src clojure
rlm@470 1142 (defn add-eye!
rlm@470 1143 "Create a Camera centered on the current position of 'eye which
rlm@470 1144 follows the closest physical node in 'creature. The camera will
rlm@470 1145 point in the X direction and use the Z vector as up as determined
rlm@562 1146 by the rotation of these vectors in Blender coordinate space. Use
rlm@470 1147 XZY rotation for the node in blender."
rlm@470 1148 [#^Node creature #^Spatial eye]
rlm@470 1149 (let [target (closest-node creature eye)
rlm@470 1150 [cam-width cam-height]
rlm@470 1151 ;;[640 480] ;; graphics card on laptop doesn't support
rlm@517 1152 ;; arbitrary dimensions.
rlm@470 1153 (eye-dimensions eye)
rlm@470 1154 cam (Camera. cam-width cam-height)
rlm@470 1155 rot (.getWorldRotation eye)]
rlm@470 1156 (.setLocation cam (.getWorldTranslation eye))
rlm@470 1157 (.lookAtDirection
rlm@470 1158 cam ; this part is not a mistake and
rlm@470 1159 (.mult rot Vector3f/UNIT_X) ; is consistent with using Z in
rlm@562 1160 (.mult rot Vector3f/UNIT_Y)) ; Blender as the UP vector.
rlm@470 1161 (.setFrustumPerspective
rlm@470 1162 cam (float 45)
rlm@470 1163 (float (/ (.getWidth cam) (.getHeight cam)))
rlm@470 1164 (float 1)
rlm@470 1165 (float 1000))
rlm@470 1166 (bind-sense target cam) cam))
rlm@545 1167 #+end_src
rlm@470 1168 #+end_listing
rlm@470 1169
rlm@470 1170 *** Simulated Retina
rlm@470 1171
rlm@470 1172 An eye is a surface (the retina) which contains many discrete
rlm@470 1173 sensors to detect light. These sensors can have different
rlm@470 1174 light-sensing properties. In humans, each discrete sensor is
rlm@470 1175 sensitive to red, blue, green, or gray. These different types of
rlm@470 1176 sensors can have different spatial distributions along the retina.
rlm@470 1177 In humans, there is a fovea in the center of the retina which has
rlm@470 1178 a very high density of color sensors, and a blind spot which has
rlm@470 1179 no sensors at all. Sensor density decreases in proportion to
rlm@470 1180 distance from the fovea.
rlm@470 1181
rlm@470 1182 I want to be able to model any retinal configuration, so my
rlm@562 1183 eye-nodes in Blender contain metadata pointing to images that
rlm@470 1184 describe the precise position of the individual sensors using
rlm@470 1185 white pixels. The meta-data also describes the precise sensitivity
rlm@470 1186 to light that the sensors described in the image have. An eye can
rlm@470 1187 contain any number of these images. For example, the metadata for
rlm@470 1188 an eye might look like this:
rlm@470 1189
rlm@470 1190 #+begin_src clojure
rlm@470 1191 {0xFF0000 "Models/test-creature/retina-small.png"}
rlm@470 1192 #+end_src
rlm@470 1193
rlm@470 1194 #+caption: An example retinal profile image. White pixels are
rlm@470 1195 #+caption: photo-sensitive elements. The distribution of white
rlm@470 1196 #+caption: pixels is denser in the middle and falls off at the
rlm@470 1197 #+caption: edges and is inspired by the human retina.
rlm@470 1198 #+name: retina
rlm@510 1199 #+ATTR_LaTeX: :width 7cm
rlm@470 1200 [[./images/retina-small.png]]
rlm@470 1201
rlm@545 1202 Together, the number 0xFF0000 and the image above describe the
rlm@545 1203 placement of red-sensitive sensory elements.
rlm@470 1204
rlm@470 1205 Meta-data to very crudely approximate a human eye might be
rlm@470 1206 something like this:
rlm@470 1207
rlm@470 1208 #+begin_src clojure
rlm@470 1209 (let [retinal-profile "Models/test-creature/retina-small.png"]
rlm@470 1210 {0xFF0000 retinal-profile
rlm@470 1211 0x00FF00 retinal-profile
rlm@470 1212 0x0000FF retinal-profile
rlm@470 1213 0xFFFFFF retinal-profile})
rlm@470 1214 #+end_src
rlm@470 1215
rlm@470 1216 The numbers that serve as keys in the map determine a sensor's
rlm@470 1217 relative sensitivity to the channels red, green, and blue. These
rlm@470 1218 sensitivity values are packed into an integer in the order
rlm@470 1219 =|_|R|G|B|= in 8-bit fields. The RGB values of a pixel in the
rlm@470 1220 image are added together with these sensitivities as linear
rlm@470 1221 weights. Therefore, 0xFF0000 means sensitive to red only while
rlm@470 1222 0xFFFFFF means sensitive to all colors equally (gray).
rlm@470 1223
rlm@470 1224 #+caption: This is the core of vision in =CORTEX=. A given eye node
rlm@470 1225 #+caption: is converted into a function that returns visual
rlm@470 1226 #+caption: information from the simulation.
rlm@471 1227 #+name: vision-kernel
rlm@470 1228 #+begin_listing clojure
rlm@508 1229 #+BEGIN_SRC clojure
rlm@470 1230 (defn vision-kernel
rlm@470 1231 "Returns a list of functions, each of which will return a color
rlm@470 1232 channel's worth of visual information when called inside a running
rlm@470 1233 simulation."
rlm@470 1234 [#^Node creature #^Spatial eye & {skip :skip :or {skip 0}}]
rlm@470 1235 (let [retinal-map (retina-sensor-profile eye)
rlm@470 1236 camera (add-eye! creature eye)
rlm@470 1237 vision-image
rlm@470 1238 (atom
rlm@470 1239 (BufferedImage. (.getWidth camera)
rlm@470 1240 (.getHeight camera)
rlm@470 1241 BufferedImage/TYPE_BYTE_BINARY))
rlm@470 1242 register-eye!
rlm@470 1243 (runonce
rlm@470 1244 (fn [world]
rlm@470 1245 (add-camera!
rlm@470 1246 world camera
rlm@470 1247 (let [counter (atom 0)]
rlm@470 1248 (fn [r fb bb bi]
rlm@470 1249 (if (zero? (rem (swap! counter inc) (inc skip)))
rlm@470 1250 (reset! vision-image
rlm@470 1251 (BufferedImage! r fb bb bi))))))))]
rlm@470 1252 (vec
rlm@470 1253 (map
rlm@470 1254 (fn [[key image]]
rlm@470 1255 (let [whites (white-coordinates image)
rlm@470 1256 topology (vec (collapse whites))
rlm@470 1257 sensitivity (sensitivity-presets key key)]
rlm@470 1258 (attached-viewport.
rlm@470 1259 (fn [world]
rlm@470 1260 (register-eye! world)
rlm@470 1261 (vector
rlm@470 1262 topology
rlm@470 1263 (vec
rlm@470 1264 (for [[x y] whites]
rlm@470 1265 (pixel-sense
rlm@470 1266 sensitivity
rlm@470 1267 (.getRGB @vision-image x y))))))
rlm@470 1268 register-eye!)))
rlm@470 1269 retinal-map))))
rlm@508 1270 #+END_SRC
rlm@470 1271 #+end_listing
rlm@470 1272
rlm@563 1273 Note that because each of the functions generated by
rlm@563 1274 =vision-kernel= shares the same =register-eye!= function, the eye
rlm@563 1275 will be registered only once the first time any of the functions
rlm@563 1276 from the list returned by =vision-kernel= is called. Each of the
rlm@563 1277 functions returned by =vision-kernel= also allows access to the
rlm@563 1278 =Viewport= through which it receives images.
rlm@470 1279
rlm@470 1280 All the hard work has been done; all that remains is to apply
rlm@470 1281 =vision-kernel= to each eye in the creature and gather the results
rlm@470 1282 into one list of functions.
rlm@470 1283
rlm@470 1284
rlm@470 1285 #+caption: With =vision!=, =CORTEX= is already a fine simulation
rlm@470 1286 #+caption: environment for experimenting with different types of
rlm@470 1287 #+caption: eyes.
rlm@470 1288 #+name: vision!
rlm@470 1289 #+begin_listing clojure
rlm@508 1290 #+BEGIN_SRC clojure
rlm@470 1291 (defn vision!
rlm@470 1292 "Returns a list of functions, each of which returns visual sensory
rlm@470 1293 data when called inside a running simulation."
rlm@470 1294 [#^Node creature & {skip :skip :or {skip 0}}]
rlm@470 1295 (reduce
rlm@470 1296 concat
rlm@470 1297 (for [eye (eyes creature)]
rlm@470 1298 (vision-kernel creature eye))))
rlm@508 1299 #+END_SRC
rlm@470 1300 #+end_listing
rlm@470 1301
rlm@471 1302 #+caption: Simulated vision with a test creature and the
rlm@471 1303 #+caption: human-like eye approximation. Notice how each channel
rlm@471 1304 #+caption: of the eye responds differently to the differently
rlm@471 1305 #+caption: colored balls.
rlm@471 1306 #+name: worm-vision-test.
rlm@471 1307 #+ATTR_LaTeX: :width 13cm
rlm@471 1308 [[./images/worm-vision.png]]
rlm@470 1309
rlm@471 1310 The vision code is not much more complicated than the body code,
rlm@471 1311 and enables multiple further paths for simulated vision. For
rlm@471 1312 example, it is quite easy to create bifocal vision -- you just
rlm@471 1313 make two eyes next to each other in blender! It is also possible
rlm@471 1314 to encode vision transforms in the retinal files. For example, the
rlm@471 1315 human like retina file in figure \ref{retina} approximates a
rlm@471 1316 log-polar transform.
rlm@470 1317
rlm@471 1318 This vision code has already been absorbed by the jMonkeyEngine
rlm@471 1319 community and is now (in modified form) part of a system for
rlm@471 1320 capturing in-game video to a file.
rlm@470 1321
rlm@511 1322 ** ...but hearing must be built from scratch
rlm@514 1323
rlm@551 1324 At the end of this chapter I will have simulated ears that work the
rlm@551 1325 same way as the simulated eyes in the last chapter. I will be able to
rlm@562 1326 place any number of ear-nodes in a Blender file, and they will bind to
rlm@472 1327 the closest physical object and follow it as it moves around. Each ear
rlm@472 1328 will provide access to the sound data it picks up between every frame.
rlm@472 1329
rlm@472 1330 Hearing is one of the more difficult senses to simulate, because there
rlm@472 1331 is less support for obtaining the actual sound data that is processed
rlm@472 1332 by jMonkeyEngine3. There is no "split-screen" support for rendering
rlm@472 1333 sound from different points of view, and there is no way to directly
rlm@472 1334 access the rendered sound data.
rlm@472 1335
rlm@472 1336 =CORTEX='s hearing is unique because it does not have any
rlm@472 1337 limitations compared to other simulation environments. As far as I
rlm@517 1338 know, there is no other system that supports multiple listeners,
rlm@551 1339 and the sound demo at the end of this chapter is the first time
rlm@472 1340 it's been done in a video game environment.
rlm@472 1341
rlm@472 1342 *** Brief Description of jMonkeyEngine's Sound System
rlm@472 1343
rlm@472 1344 jMonkeyEngine's sound system works as follows:
rlm@472 1345
rlm@472 1346 - jMonkeyEngine uses the =AppSettings= for the particular
rlm@472 1347 application to determine what sort of =AudioRenderer= should be
rlm@472 1348 used.
rlm@556 1349 - Although some support is provided for multiple AudioRenderer
rlm@472 1350 backends, jMonkeyEngine at the time of this writing will either
rlm@472 1351 pick no =AudioRenderer= at all, or the =LwjglAudioRenderer=.
rlm@472 1352 - jMonkeyEngine tries to figure out what sort of system you're
rlm@472 1353 running and extracts the appropriate native libraries.
rlm@472 1354 - The =LwjglAudioRenderer= uses the [[http://lwjgl.org/][=LWJGL=]] (LightWeight Java Game
rlm@472 1355 Library) bindings to interface with a C library called [[http://kcat.strangesoft.net/openal.html][=OpenAL=]]
rlm@472 1356 - =OpenAL= renders the 3D sound and feeds the rendered sound
rlm@472 1357 directly to any of various sound output devices with which it
rlm@472 1358 knows how to communicate.
rlm@472 1359
rlm@472 1360 A consequence of this is that there's no way to access the actual
rlm@472 1361 sound data produced by =OpenAL=. Even worse, =OpenAL= only supports
rlm@472 1362 one /listener/ (it renders sound data from only one perspective),
rlm@472 1363 which normally isn't a problem for games, but becomes a problem
rlm@472 1364 when trying to make multiple AI creatures that can each hear the
rlm@472 1365 world from a different perspective.
rlm@472 1366
rlm@472 1367 To make many AI creatures in jMonkeyEngine that can each hear the
rlm@472 1368 world from their own perspective, or to make a single creature with
rlm@472 1369 many ears, it is necessary to go all the way back to =OpenAL= and
rlm@472 1370 implement support for simulated hearing there.
rlm@472 1371
rlm@472 1372 *** Extending =OpenAl=
rlm@472 1373
rlm@472 1374 Extending =OpenAL= to support multiple listeners requires 500
rlm@563 1375 lines of =C= code and is too complicated to mention here. Instead,
rlm@563 1376 I will show a small amount of extension code and go over the high
rlm@517 1377 level strategy. Full source is of course available with the
rlm@472 1378 =CORTEX= distribution if you're interested.
rlm@472 1379
rlm@472 1380 =OpenAL= goes to great lengths to support many different systems,
rlm@472 1381 all with different sound capabilities and interfaces. It
rlm@472 1382 accomplishes this difficult task by providing code for many
rlm@472 1383 different sound backends in pseudo-objects called /Devices/.
rlm@472 1384 There's a device for the Linux Open Sound System and the Advanced
rlm@472 1385 Linux Sound Architecture, there's one for Direct Sound on Windows,
rlm@472 1386 and there's even one for Solaris. =OpenAL= solves the problem of
rlm@472 1387 platform independence by providing all these Devices.
rlm@472 1388
rlm@472 1389 Wrapper libraries such as LWJGL are free to examine the system on
rlm@472 1390 which they are running and then select an appropriate device for
rlm@472 1391 that system.
rlm@472 1392
rlm@472 1393 There are also a few "special" devices that don't interface with
rlm@472 1394 any particular system. These include the Null Device, which
rlm@472 1395 doesn't do anything, and the Wave Device, which writes whatever
rlm@472 1396 sound it receives to a file, if everything has been set up
rlm@472 1397 correctly when configuring =OpenAL=.
rlm@472 1398
rlm@517 1399 Actual mixing (Doppler shift and distance.environment-based
rlm@472 1400 attenuation) of the sound data happens in the Devices, and they
rlm@472 1401 are the only point in the sound rendering process where this data
rlm@472 1402 is available.
rlm@472 1403
rlm@472 1404 Therefore, in order to support multiple listeners, and get the
rlm@472 1405 sound data in a form that the AIs can use, it is necessary to
rlm@472 1406 create a new Device which supports this feature.
rlm@472 1407
rlm@472 1408 Adding a device to OpenAL is rather tricky -- there are five
rlm@472 1409 separate files in the =OpenAL= source tree that must be modified
rlm@472 1410 to do so. I named my device the "Multiple Audio Send" Device, or
rlm@472 1411 =Send= Device for short, since it sends audio data back to the
rlm@472 1412 calling application like an Aux-Send cable on a mixing board.
rlm@472 1413
rlm@472 1414 The main idea behind the Send device is to take advantage of the
rlm@472 1415 fact that LWJGL only manages one /context/ when using OpenAL. A
rlm@472 1416 /context/ is like a container that holds samples and keeps track
rlm@472 1417 of where the listener is. In order to support multiple listeners,
rlm@472 1418 the Send device identifies the LWJGL context as the master
rlm@472 1419 context, and creates any number of slave contexts to represent
rlm@472 1420 additional listeners. Every time the device renders sound, it
rlm@472 1421 synchronizes every source from the master LWJGL context to the
rlm@472 1422 slave contexts. Then, it renders each context separately, using a
rlm@472 1423 different listener for each one. The rendered sound is made
rlm@472 1424 available via JNI to jMonkeyEngine.
rlm@472 1425
rlm@472 1426 Switching between contexts is not the normal operation of a
rlm@472 1427 Device, and one of the problems with doing so is that a Device
rlm@472 1428 normally keeps around a few pieces of state such as the
rlm@472 1429 =ClickRemoval= array above which will become corrupted if the
rlm@472 1430 contexts are not rendered in parallel. The solution is to create a
rlm@472 1431 copy of this normally global device state for each context, and
rlm@472 1432 copy it back and forth into and out of the actual device state
rlm@472 1433 whenever a context is rendered.
rlm@472 1434
rlm@472 1435 The core of the =Send= device is the =syncSources= function, which
rlm@472 1436 does the job of copying all relevant data from one context to
rlm@472 1437 another.
rlm@472 1438
rlm@472 1439 #+caption: Program for extending =OpenAL= to support multiple
rlm@472 1440 #+caption: listeners via context copying/switching.
rlm@472 1441 #+name: sync-openal-sources
rlm@509 1442 #+begin_listing c
rlm@509 1443 #+BEGIN_SRC c
rlm@472 1444 void syncSources(ALsource *masterSource, ALsource *slaveSource,
rlm@472 1445 ALCcontext *masterCtx, ALCcontext *slaveCtx){
rlm@472 1446 ALuint master = masterSource->source;
rlm@472 1447 ALuint slave = slaveSource->source;
rlm@472 1448 ALCcontext *current = alcGetCurrentContext();
rlm@472 1449
rlm@472 1450 syncSourcef(master,slave,masterCtx,slaveCtx,AL_PITCH);
rlm@472 1451 syncSourcef(master,slave,masterCtx,slaveCtx,AL_GAIN);
rlm@472 1452 syncSourcef(master,slave,masterCtx,slaveCtx,AL_MAX_DISTANCE);
rlm@472 1453 syncSourcef(master,slave,masterCtx,slaveCtx,AL_ROLLOFF_FACTOR);
rlm@472 1454 syncSourcef(master,slave,masterCtx,slaveCtx,AL_REFERENCE_DISTANCE);
rlm@472 1455 syncSourcef(master,slave,masterCtx,slaveCtx,AL_MIN_GAIN);
rlm@472 1456 syncSourcef(master,slave,masterCtx,slaveCtx,AL_MAX_GAIN);
rlm@472 1457 syncSourcef(master,slave,masterCtx,slaveCtx,AL_CONE_OUTER_GAIN);
rlm@472 1458 syncSourcef(master,slave,masterCtx,slaveCtx,AL_CONE_INNER_ANGLE);
rlm@472 1459 syncSourcef(master,slave,masterCtx,slaveCtx,AL_CONE_OUTER_ANGLE);
rlm@472 1460 syncSourcef(master,slave,masterCtx,slaveCtx,AL_SEC_OFFSET);
rlm@472 1461 syncSourcef(master,slave,masterCtx,slaveCtx,AL_SAMPLE_OFFSET);
rlm@472 1462 syncSourcef(master,slave,masterCtx,slaveCtx,AL_BYTE_OFFSET);
rlm@472 1463
rlm@472 1464 syncSource3f(master,slave,masterCtx,slaveCtx,AL_POSITION);
rlm@472 1465 syncSource3f(master,slave,masterCtx,slaveCtx,AL_VELOCITY);
rlm@472 1466 syncSource3f(master,slave,masterCtx,slaveCtx,AL_DIRECTION);
rlm@472 1467
rlm@472 1468 syncSourcei(master,slave,masterCtx,slaveCtx,AL_SOURCE_RELATIVE);
rlm@472 1469 syncSourcei(master,slave,masterCtx,slaveCtx,AL_LOOPING);
rlm@472 1470
rlm@472 1471 alcMakeContextCurrent(masterCtx);
rlm@472 1472 ALint source_type;
rlm@472 1473 alGetSourcei(master, AL_SOURCE_TYPE, &source_type);
rlm@472 1474
rlm@472 1475 // Only static sources are currently synchronized!
rlm@472 1476 if (AL_STATIC == source_type){
rlm@472 1477 ALint master_buffer;
rlm@472 1478 ALint slave_buffer;
rlm@472 1479 alGetSourcei(master, AL_BUFFER, &master_buffer);
rlm@472 1480 alcMakeContextCurrent(slaveCtx);
rlm@472 1481 alGetSourcei(slave, AL_BUFFER, &slave_buffer);
rlm@472 1482 if (master_buffer != slave_buffer){
rlm@472 1483 alSourcei(slave, AL_BUFFER, master_buffer);
rlm@472 1484 }
rlm@472 1485 }
rlm@472 1486
rlm@472 1487 // Synchronize the state of the two sources.
rlm@472 1488 alcMakeContextCurrent(masterCtx);
rlm@472 1489 ALint masterState;
rlm@472 1490 ALint slaveState;
rlm@472 1491
rlm@472 1492 alGetSourcei(master, AL_SOURCE_STATE, &masterState);
rlm@472 1493 alcMakeContextCurrent(slaveCtx);
rlm@472 1494 alGetSourcei(slave, AL_SOURCE_STATE, &slaveState);
rlm@472 1495
rlm@472 1496 if (masterState != slaveState){
rlm@472 1497 switch (masterState){
rlm@472 1498 case AL_INITIAL : alSourceRewind(slave); break;
rlm@472 1499 case AL_PLAYING : alSourcePlay(slave); break;
rlm@472 1500 case AL_PAUSED : alSourcePause(slave); break;
rlm@472 1501 case AL_STOPPED : alSourceStop(slave); break;
rlm@472 1502 }
rlm@472 1503 }
rlm@472 1504 // Restore whatever context was previously active.
rlm@472 1505 alcMakeContextCurrent(current);
rlm@472 1506 }
rlm@508 1507 #+END_SRC
rlm@472 1508 #+end_listing
rlm@472 1509
rlm@472 1510 With this special context-switching device, and some ugly JNI
rlm@472 1511 bindings that are not worth mentioning, =CORTEX= gains the ability
rlm@472 1512 to access multiple sound streams from =OpenAL=.
rlm@472 1513
rlm@472 1514 #+caption: Program to create an ear from a blender empty node. The ear
rlm@472 1515 #+caption: follows around the nearest physical object and passes
rlm@472 1516 #+caption: all sensory data to a continuation function.
rlm@472 1517 #+name: add-ear
rlm@472 1518 #+begin_listing clojure
rlm@508 1519 #+BEGIN_SRC clojure
rlm@472 1520 (defn add-ear!
rlm@472 1521 "Create a Listener centered on the current position of 'ear
rlm@472 1522 which follows the closest physical node in 'creature and
rlm@472 1523 sends sound data to 'continuation."
rlm@472 1524 [#^Application world #^Node creature #^Spatial ear continuation]
rlm@472 1525 (let [target (closest-node creature ear)
rlm@472 1526 lis (Listener.)
rlm@472 1527 audio-renderer (.getAudioRenderer world)
rlm@472 1528 sp (hearing-pipeline continuation)]
rlm@472 1529 (.setLocation lis (.getWorldTranslation ear))
rlm@472 1530 (.setRotation lis (.getWorldRotation ear))
rlm@472 1531 (bind-sense target lis)
rlm@472 1532 (update-listener-velocity! target lis)
rlm@472 1533 (.addListener audio-renderer lis)
rlm@472 1534 (.registerSoundProcessor audio-renderer lis sp)))
rlm@508 1535 #+END_SRC
rlm@472 1536 #+end_listing
rlm@472 1537
rlm@472 1538 The =Send= device, unlike most of the other devices in =OpenAL=,
rlm@472 1539 does not render sound unless asked. This enables the system to
rlm@472 1540 slow down or speed up depending on the needs of the AIs who are
rlm@472 1541 using it to listen. If the device tried to render samples in
rlm@472 1542 real-time, a complicated AI whose mind takes 100 seconds of
rlm@472 1543 computer time to simulate 1 second of AI-time would miss almost
rlm@472 1544 all of the sound in its environment!
rlm@472 1545
rlm@472 1546 #+caption: Program to enable arbitrary hearing in =CORTEX=
rlm@472 1547 #+name: hearing
rlm@472 1548 #+begin_listing clojure
rlm@508 1549 #+BEGIN_SRC clojure
rlm@472 1550 (defn hearing-kernel
rlm@472 1551 "Returns a function which returns auditory sensory data when called
rlm@472 1552 inside a running simulation."
rlm@472 1553 [#^Node creature #^Spatial ear]
rlm@472 1554 (let [hearing-data (atom [])
rlm@472 1555 register-listener!
rlm@472 1556 (runonce
rlm@472 1557 (fn [#^Application world]
rlm@472 1558 (add-ear!
rlm@472 1559 world creature ear
rlm@472 1560 (comp #(reset! hearing-data %)
rlm@472 1561 byteBuffer->pulse-vector))))]
rlm@472 1562 (fn [#^Application world]
rlm@472 1563 (register-listener! world)
rlm@472 1564 (let [data @hearing-data
rlm@472 1565 topology
rlm@472 1566 (vec (map #(vector % 0) (range 0 (count data))))]
rlm@472 1567 [topology data]))))
rlm@472 1568
rlm@472 1569 (defn hearing!
rlm@472 1570 "Endow the creature in a particular world with the sense of
rlm@472 1571 hearing. Will return a sequence of functions, one for each ear,
rlm@472 1572 which when called will return the auditory data from that ear."
rlm@472 1573 [#^Node creature]
rlm@472 1574 (for [ear (ears creature)]
rlm@472 1575 (hearing-kernel creature ear)))
rlm@508 1576 #+END_SRC
rlm@472 1577 #+end_listing
rlm@472 1578
rlm@472 1579 Armed with these functions, =CORTEX= is able to test possibly the
rlm@472 1580 first ever instance of multiple listeners in a video game engine
rlm@472 1581 based simulation!
rlm@472 1582
rlm@472 1583 #+caption: Here a simple creature responds to sound by changing
rlm@472 1584 #+caption: its color from gray to green when the total volume
rlm@472 1585 #+caption: goes over a threshold.
rlm@472 1586 #+name: sound-test
rlm@472 1587 #+begin_listing java
rlm@508 1588 #+BEGIN_SRC java
rlm@472 1589 /**
rlm@472 1590 * Respond to sound! This is the brain of an AI entity that
rlm@472 1591 * hears its surroundings and reacts to them.
rlm@472 1592 */
rlm@472 1593 public void process(ByteBuffer audioSamples,
rlm@472 1594 int numSamples, AudioFormat format) {
rlm@472 1595 audioSamples.clear();
rlm@472 1596 byte[] data = new byte[numSamples];
rlm@472 1597 float[] out = new float[numSamples];
rlm@472 1598 audioSamples.get(data);
rlm@472 1599 FloatSampleTools.
rlm@472 1600 byte2floatInterleaved
rlm@472 1601 (data, 0, out, 0, numSamples/format.getFrameSize(), format);
rlm@472 1602
rlm@472 1603 float max = Float.NEGATIVE_INFINITY;
rlm@472 1604 for (float f : out){if (f > max) max = f;}
rlm@472 1605 audioSamples.clear();
rlm@472 1606
rlm@472 1607 if (max > 0.1){
rlm@472 1608 entity.getMaterial().setColor("Color", ColorRGBA.Green);
rlm@472 1609 }
rlm@472 1610 else {
rlm@472 1611 entity.getMaterial().setColor("Color", ColorRGBA.Gray);
rlm@472 1612 }
rlm@508 1613 #+END_SRC
rlm@472 1614 #+end_listing
rlm@472 1615
rlm@517 1616 #+caption: First ever simulation of multiple listeners in =CORTEX=.
rlm@472 1617 #+caption: Each cube is a creature which processes sound data with
rlm@472 1618 #+caption: the =process= function from listing \ref{sound-test}.
rlm@517 1619 #+caption: the ball is constantly emitting a pure tone of
rlm@472 1620 #+caption: constant volume. As it approaches the cubes, they each
rlm@472 1621 #+caption: change color in response to the sound.
rlm@472 1622 #+name: sound-cubes.
rlm@472 1623 #+ATTR_LaTeX: :width 10cm
rlm@509 1624 [[./images/java-hearing-test.png]]
rlm@472 1625
rlm@472 1626 This system of hearing has also been co-opted by the
rlm@472 1627 jMonkeyEngine3 community and is used to record audio for demo
rlm@472 1628 videos.
rlm@472 1629
rlm@511 1630 ** Hundreds of hair-like elements provide a sense of touch
rlm@436 1631
rlm@474 1632 Touch is critical to navigation and spatial reasoning and as such I
rlm@474 1633 need a simulated version of it to give to my AI creatures.
rlm@474 1634
rlm@474 1635 Human skin has a wide array of touch sensors, each of which
rlm@474 1636 specialize in detecting different vibrational modes and pressures.
rlm@474 1637 These sensors can integrate a vast expanse of skin (i.e. your
rlm@474 1638 entire palm), or a tiny patch of skin at the tip of your finger.
rlm@474 1639 The hairs of the skin help detect objects before they even come
rlm@474 1640 into contact with the skin proper.
rlm@474 1641
rlm@474 1642 However, touch in my simulated world can not exactly correspond to
rlm@474 1643 human touch because my creatures are made out of completely rigid
rlm@474 1644 segments that don't deform like human skin.
rlm@474 1645
rlm@474 1646 Instead of measuring deformation or vibration, I surround each
rlm@474 1647 rigid part with a plenitude of hair-like objects (/feelers/) which
rlm@474 1648 do not interact with the physical world. Physical objects can pass
rlm@474 1649 through them with no effect. The feelers are able to tell when
rlm@474 1650 other objects pass through them, and they constantly report how
rlm@474 1651 much of their extent is covered. So even though the creature's body
rlm@474 1652 parts do not deform, the feelers create a margin around those body
rlm@474 1653 parts which achieves a sense of touch which is a hybrid between a
rlm@474 1654 human's sense of deformation and sense from hairs.
rlm@474 1655
rlm@474 1656 Implementing touch in jMonkeyEngine follows a different technical
rlm@474 1657 route than vision and hearing. Those two senses piggybacked off
rlm@474 1658 jMonkeyEngine's 3D audio and video rendering subsystems. To
rlm@474 1659 simulate touch, I use jMonkeyEngine's physics system to execute
rlm@474 1660 many small collision detections, one for each feeler. The placement
rlm@474 1661 of the feelers is determined by a UV-mapped image which shows where
rlm@474 1662 each feeler should be on the 3D surface of the body.
rlm@474 1663
rlm@477 1664 *** Defining Touch Meta-Data in Blender
rlm@474 1665
rlm@474 1666 Each geometry can have a single UV map which describes the
rlm@474 1667 position of the feelers which will constitute its sense of touch.
rlm@474 1668 This image path is stored under the ``touch'' key. The image itself
rlm@474 1669 is black and white, with black meaning a feeler length of 0 (no
rlm@474 1670 feeler is present) and white meaning a feeler length of =scale=,
rlm@474 1671 which is a float stored under the key "scale".
rlm@474 1672
rlm@475 1673 #+caption: Touch does not use empty nodes, to store metadata,
rlm@475 1674 #+caption: because the metadata of each solid part of a
rlm@475 1675 #+caption: creature's body is sufficient.
rlm@475 1676 #+name: touch-meta-data
rlm@475 1677 #+begin_listing clojure
rlm@477 1678 #+BEGIN_SRC clojure
rlm@474 1679 (defn tactile-sensor-profile
rlm@474 1680 "Return the touch-sensor distribution image in BufferedImage format,
rlm@474 1681 or nil if it does not exist."
rlm@474 1682 [#^Geometry obj]
rlm@474 1683 (if-let [image-path (meta-data obj "touch")]
rlm@474 1684 (load-image image-path)))
rlm@474 1685
rlm@474 1686 (defn tactile-scale
rlm@474 1687 "Return the length of each feeler. Default scale is 0.01
rlm@474 1688 jMonkeyEngine units."
rlm@474 1689 [#^Geometry obj]
rlm@474 1690 (if-let [scale (meta-data obj "scale")]
rlm@474 1691 scale 0.1))
rlm@477 1692 #+END_SRC
rlm@475 1693 #+end_listing
rlm@474 1694
rlm@475 1695 Here is an example of a UV-map which specifies the position of
rlm@475 1696 touch sensors along the surface of the upper segment of a fingertip.
rlm@474 1697
rlm@475 1698 #+caption: This is the tactile-sensor-profile for the upper segment
rlm@475 1699 #+caption: of a fingertip. It defines regions of high touch sensitivity
rlm@475 1700 #+caption: (where there are many white pixels) and regions of low
rlm@475 1701 #+caption: sensitivity (where white pixels are sparse).
rlm@486 1702 #+name: fingertip-UV
rlm@477 1703 #+ATTR_LaTeX: :width 13cm
rlm@477 1704 [[./images/finger-UV.png]]
rlm@474 1705
rlm@477 1706 *** Implementation Summary
rlm@474 1707
rlm@474 1708 To simulate touch there are three conceptual steps. For each solid
rlm@474 1709 object in the creature, you first have to get UV image and scale
rlm@474 1710 parameter which define the position and length of the feelers.
rlm@474 1711 Then, you use the triangles which comprise the mesh and the UV
rlm@474 1712 data stored in the mesh to determine the world-space position and
rlm@474 1713 orientation of each feeler. Then once every frame, update these
rlm@474 1714 positions and orientations to match the current position and
rlm@474 1715 orientation of the object, and use physics collision detection to
rlm@474 1716 gather tactile data.
rlm@474 1717
rlm@474 1718 Extracting the meta-data has already been described. The third
rlm@474 1719 step, physics collision detection, is handled in =touch-kernel=.
rlm@474 1720 Translating the positions and orientations of the feelers from the
rlm@474 1721 UV-map to world-space is itself a three-step process.
rlm@474 1722
rlm@475 1723 - Find the triangles which make up the mesh in pixel-space and in
rlm@505 1724 world-space. \\(=triangles=, =pixel-triangles=).
rlm@474 1725
rlm@475 1726 - Find the coordinates of each feeler in world-space. These are
rlm@475 1727 the origins of the feelers. (=feeler-origins=).
rlm@474 1728
rlm@475 1729 - Calculate the normals of the triangles in world space, and add
rlm@475 1730 them to each of the origins of the feelers. These are the
rlm@475 1731 normalized coordinates of the tips of the feelers.
rlm@475 1732 (=feeler-tips=).
rlm@474 1733
rlm@477 1734 *** Triangle Math
rlm@474 1735
rlm@475 1736 The rigid objects which make up a creature have an underlying
rlm@475 1737 =Geometry=, which is a =Mesh= plus a =Material= and other
rlm@475 1738 important data involved with displaying the object.
rlm@475 1739
rlm@475 1740 A =Mesh= is composed of =Triangles=, and each =Triangle= has three
rlm@475 1741 vertices which have coordinates in world space and UV space.
rlm@475 1742
rlm@475 1743 Here, =triangles= gets all the world-space triangles which
rlm@475 1744 comprise a mesh, while =pixel-triangles= gets those same triangles
rlm@475 1745 expressed in pixel coordinates (which are UV coordinates scaled to
rlm@475 1746 fit the height and width of the UV image).
rlm@474 1747
rlm@475 1748 #+caption: Programs to extract triangles from a geometry and get
rlm@517 1749 #+caption: their vertices in both world and UV-coordinates.
rlm@475 1750 #+name: get-triangles
rlm@475 1751 #+begin_listing clojure
rlm@477 1752 #+BEGIN_SRC clojure
rlm@474 1753 (defn triangle
rlm@474 1754 "Get the triangle specified by triangle-index from the mesh."
rlm@474 1755 [#^Geometry geo triangle-index]
rlm@474 1756 (triangle-seq
rlm@474 1757 (let [scratch (Triangle.)]
rlm@474 1758 (.getTriangle (.getMesh geo) triangle-index scratch) scratch)))
rlm@474 1759
rlm@474 1760 (defn triangles
rlm@474 1761 "Return a sequence of all the Triangles which comprise a given
rlm@474 1762 Geometry."
rlm@474 1763 [#^Geometry geo]
rlm@474 1764 (map (partial triangle geo) (range (.getTriangleCount (.getMesh geo)))))
rlm@474 1765
rlm@474 1766 (defn triangle-vertex-indices
rlm@474 1767 "Get the triangle vertex indices of a given triangle from a given
rlm@474 1768 mesh."
rlm@474 1769 [#^Mesh mesh triangle-index]
rlm@474 1770 (let [indices (int-array 3)]
rlm@474 1771 (.getTriangle mesh triangle-index indices)
rlm@474 1772 (vec indices)))
rlm@474 1773
rlm@475 1774 (defn vertex-UV-coord
rlm@474 1775 "Get the UV-coordinates of the vertex named by vertex-index"
rlm@474 1776 [#^Mesh mesh vertex-index]
rlm@474 1777 (let [UV-buffer
rlm@474 1778 (.getData
rlm@474 1779 (.getBuffer
rlm@474 1780 mesh
rlm@474 1781 VertexBuffer$Type/TexCoord))]
rlm@474 1782 [(.get UV-buffer (* vertex-index 2))
rlm@474 1783 (.get UV-buffer (+ 1 (* vertex-index 2)))]))
rlm@474 1784
rlm@474 1785 (defn pixel-triangle [#^Geometry geo image index]
rlm@474 1786 (let [mesh (.getMesh geo)
rlm@474 1787 width (.getWidth image)
rlm@474 1788 height (.getHeight image)]
rlm@474 1789 (vec (map (fn [[u v]] (vector (* width u) (* height v)))
rlm@474 1790 (map (partial vertex-UV-coord mesh)
rlm@474 1791 (triangle-vertex-indices mesh index))))))
rlm@474 1792
rlm@474 1793 (defn pixel-triangles
rlm@474 1794 "The pixel-space triangles of the Geometry, in the same order as
rlm@474 1795 (triangles geo)"
rlm@474 1796 [#^Geometry geo image]
rlm@474 1797 (let [height (.getHeight image)
rlm@474 1798 width (.getWidth image)]
rlm@474 1799 (map (partial pixel-triangle geo image)
rlm@474 1800 (range (.getTriangleCount (.getMesh geo))))))
rlm@477 1801 #+END_SRC
rlm@475 1802 #+end_listing
rlm@475 1803
rlm@474 1804 *** The Affine Transform from one Triangle to Another
rlm@474 1805
rlm@475 1806 =pixel-triangles= gives us the mesh triangles expressed in pixel
rlm@475 1807 coordinates and =triangles= gives us the mesh triangles expressed
rlm@475 1808 in world coordinates. The tactile-sensor-profile gives the
rlm@475 1809 position of each feeler in pixel-space. In order to convert
rlm@475 1810 pixel-space coordinates into world-space coordinates we need
rlm@475 1811 something that takes coordinates on the surface of one triangle
rlm@475 1812 and gives the corresponding coordinates on the surface of another
rlm@475 1813 triangle.
rlm@475 1814
rlm@475 1815 Triangles are [[http://mathworld.wolfram.com/AffineTransformation.html ][affine]], which means any triangle can be transformed
rlm@475 1816 into any other by a combination of translation, scaling, and
rlm@475 1817 rotation. The affine transformation from one triangle to another
rlm@475 1818 is readily computable if the triangle is expressed in terms of a
rlm@475 1819 $4x4$ matrix.
rlm@476 1820
rlm@476 1821 #+BEGIN_LaTeX
rlm@476 1822 $$
rlm@475 1823 \begin{bmatrix}
rlm@475 1824 x_1 & x_2 & x_3 & n_x \\
rlm@475 1825 y_1 & y_2 & y_3 & n_y \\
rlm@475 1826 z_1 & z_2 & z_3 & n_z \\
rlm@475 1827 1 & 1 & 1 & 1
rlm@475 1828 \end{bmatrix}
rlm@476 1829 $$
rlm@476 1830 #+END_LaTeX
rlm@475 1831
rlm@475 1832 Here, the first three columns of the matrix are the vertices of
rlm@475 1833 the triangle. The last column is the right-handed unit normal of
rlm@475 1834 the triangle.
rlm@475 1835
rlm@476 1836 With two triangles $T_{1}$ and $T_{2}$ each expressed as a
rlm@476 1837 matrix like above, the affine transform from $T_{1}$ to $T_{2}$
rlm@476 1838 is $T_{2}T_{1}^{-1}$.
rlm@475 1839
rlm@475 1840 The clojure code below recapitulates the formulas above, using
rlm@475 1841 jMonkeyEngine's =Matrix4f= objects, which can describe any affine
rlm@475 1842 transformation.
rlm@474 1843
rlm@517 1844 #+caption: Program to interpret triangles as affine transforms.
rlm@475 1845 #+name: triangle-affine
rlm@475 1846 #+begin_listing clojure
rlm@475 1847 #+BEGIN_SRC clojure
rlm@474 1848 (defn triangle->matrix4f
rlm@474 1849 "Converts the triangle into a 4x4 matrix: The first three columns
rlm@474 1850 contain the vertices of the triangle; the last contains the unit
rlm@474 1851 normal of the triangle. The bottom row is filled with 1s."
rlm@474 1852 [#^Triangle t]
rlm@474 1853 (let [mat (Matrix4f.)
rlm@474 1854 [vert-1 vert-2 vert-3]
rlm@474 1855 (mapv #(.get t %) (range 3))
rlm@474 1856 unit-normal (do (.calculateNormal t)(.getNormal t))
rlm@474 1857 vertices [vert-1 vert-2 vert-3 unit-normal]]
rlm@474 1858 (dorun
rlm@474 1859 (for [row (range 4) col (range 3)]
rlm@474 1860 (do
rlm@474 1861 (.set mat col row (.get (vertices row) col))
rlm@474 1862 (.set mat 3 row 1)))) mat))
rlm@474 1863
rlm@474 1864 (defn triangles->affine-transform
rlm@474 1865 "Returns the affine transformation that converts each vertex in the
rlm@474 1866 first triangle into the corresponding vertex in the second
rlm@474 1867 triangle."
rlm@474 1868 [#^Triangle tri-1 #^Triangle tri-2]
rlm@474 1869 (.mult
rlm@474 1870 (triangle->matrix4f tri-2)
rlm@474 1871 (.invert (triangle->matrix4f tri-1))))
rlm@475 1872 #+END_SRC
rlm@475 1873 #+end_listing
rlm@474 1874
rlm@477 1875 *** Triangle Boundaries
rlm@474 1876
rlm@474 1877 For efficiency's sake I will divide the tactile-profile image into
rlm@474 1878 small squares which inscribe each pixel-triangle, then extract the
rlm@474 1879 points which lie inside the triangle and map them to 3D-space using
rlm@474 1880 =triangle-transform= above. To do this I need a function,
rlm@474 1881 =convex-bounds= which finds the smallest box which inscribes a 2D
rlm@474 1882 triangle.
rlm@474 1883
rlm@474 1884 =inside-triangle?= determines whether a point is inside a triangle
rlm@474 1885 in 2D pixel-space.
rlm@474 1886
rlm@517 1887 #+caption: Program to efficiently determine point inclusion
rlm@475 1888 #+caption: in a triangle.
rlm@475 1889 #+name: in-triangle
rlm@475 1890 #+begin_listing clojure
rlm@475 1891 #+BEGIN_SRC clojure
rlm@474 1892 (defn convex-bounds
rlm@474 1893 "Returns the smallest square containing the given vertices, as a
rlm@474 1894 vector of integers [left top width height]."
rlm@474 1895 [verts]
rlm@474 1896 (let [xs (map first verts)
rlm@474 1897 ys (map second verts)
rlm@474 1898 x0 (Math/floor (apply min xs))
rlm@474 1899 y0 (Math/floor (apply min ys))
rlm@474 1900 x1 (Math/ceil (apply max xs))
rlm@474 1901 y1 (Math/ceil (apply max ys))]
rlm@474 1902 [x0 y0 (- x1 x0) (- y1 y0)]))
rlm@474 1903
rlm@474 1904 (defn same-side?
rlm@474 1905 "Given the points p1 and p2 and the reference point ref, is point p
rlm@474 1906 on the same side of the line that goes through p1 and p2 as ref is?"
rlm@474 1907 [p1 p2 ref p]
rlm@474 1908 (<=
rlm@474 1909 0
rlm@474 1910 (.dot
rlm@474 1911 (.cross (.subtract p2 p1) (.subtract p p1))
rlm@474 1912 (.cross (.subtract p2 p1) (.subtract ref p1)))))
rlm@474 1913
rlm@474 1914 (defn inside-triangle?
rlm@474 1915 "Is the point inside the triangle?"
rlm@474 1916 {:author "Dylan Holmes"}
rlm@474 1917 [#^Triangle tri #^Vector3f p]
rlm@474 1918 (let [[vert-1 vert-2 vert-3] [(.get1 tri) (.get2 tri) (.get3 tri)]]
rlm@474 1919 (and
rlm@474 1920 (same-side? vert-1 vert-2 vert-3 p)
rlm@474 1921 (same-side? vert-2 vert-3 vert-1 p)
rlm@474 1922 (same-side? vert-3 vert-1 vert-2 p))))
rlm@475 1923 #+END_SRC
rlm@475 1924 #+end_listing
rlm@474 1925
rlm@477 1926 *** Feeler Coordinates
rlm@474 1927
rlm@475 1928 The triangle-related functions above make short work of
rlm@475 1929 calculating the positions and orientations of each feeler in
rlm@475 1930 world-space.
rlm@474 1931
rlm@475 1932 #+caption: Program to get the coordinates of ``feelers '' in
rlm@475 1933 #+caption: both world and UV-coordinates.
rlm@475 1934 #+name: feeler-coordinates
rlm@475 1935 #+begin_listing clojure
rlm@475 1936 #+BEGIN_SRC clojure
rlm@474 1937 (defn feeler-pixel-coords
rlm@474 1938 "Returns the coordinates of the feelers in pixel space in lists, one
rlm@474 1939 list for each triangle, ordered in the same way as (triangles) and
rlm@474 1940 (pixel-triangles)."
rlm@474 1941 [#^Geometry geo image]
rlm@474 1942 (map
rlm@474 1943 (fn [pixel-triangle]
rlm@474 1944 (filter
rlm@474 1945 (fn [coord]
rlm@474 1946 (inside-triangle? (->triangle pixel-triangle)
rlm@474 1947 (->vector3f coord)))
rlm@474 1948 (white-coordinates image (convex-bounds pixel-triangle))))
rlm@474 1949 (pixel-triangles geo image)))
rlm@474 1950
rlm@474 1951 (defn feeler-world-coords
rlm@474 1952 "Returns the coordinates of the feelers in world space in lists, one
rlm@474 1953 list for each triangle, ordered in the same way as (triangles) and
rlm@474 1954 (pixel-triangles)."
rlm@474 1955 [#^Geometry geo image]
rlm@474 1956 (let [transforms
rlm@474 1957 (map #(triangles->affine-transform
rlm@474 1958 (->triangle %1) (->triangle %2))
rlm@474 1959 (pixel-triangles geo image)
rlm@474 1960 (triangles geo))]
rlm@474 1961 (map (fn [transform coords]
rlm@474 1962 (map #(.mult transform (->vector3f %)) coords))
rlm@474 1963 transforms (feeler-pixel-coords geo image))))
rlm@475 1964 #+END_SRC
rlm@475 1965 #+end_listing
rlm@474 1966
rlm@475 1967 #+caption: Program to get the position of the base and tip of
rlm@475 1968 #+caption: each ``feeler''
rlm@475 1969 #+name: feeler-tips
rlm@475 1970 #+begin_listing clojure
rlm@475 1971 #+BEGIN_SRC clojure
rlm@474 1972 (defn feeler-origins
rlm@474 1973 "The world space coordinates of the root of each feeler."
rlm@474 1974 [#^Geometry geo image]
rlm@474 1975 (reduce concat (feeler-world-coords geo image)))
rlm@474 1976
rlm@474 1977 (defn feeler-tips
rlm@474 1978 "The world space coordinates of the tip of each feeler."
rlm@474 1979 [#^Geometry geo image]
rlm@474 1980 (let [world-coords (feeler-world-coords geo image)
rlm@474 1981 normals
rlm@474 1982 (map
rlm@474 1983 (fn [triangle]
rlm@474 1984 (.calculateNormal triangle)
rlm@474 1985 (.clone (.getNormal triangle)))
rlm@474 1986 (map ->triangle (triangles geo)))]
rlm@474 1987
rlm@474 1988 (mapcat (fn [origins normal]
rlm@474 1989 (map #(.add % normal) origins))
rlm@474 1990 world-coords normals)))
rlm@474 1991
rlm@474 1992 (defn touch-topology
rlm@474 1993 [#^Geometry geo image]
rlm@474 1994 (collapse (reduce concat (feeler-pixel-coords geo image))))
rlm@475 1995 #+END_SRC
rlm@475 1996 #+end_listing
rlm@474 1997
rlm@477 1998 *** Simulated Touch
rlm@474 1999
rlm@475 2000 Now that the functions to construct feelers are complete,
rlm@475 2001 =touch-kernel= generates functions to be called from within a
rlm@475 2002 simulation that perform the necessary physics collisions to
rlm@475 2003 collect tactile data, and =touch!= recursively applies it to every
rlm@475 2004 node in the creature.
rlm@474 2005
rlm@475 2006 #+caption: Efficient program to transform a ray from
rlm@475 2007 #+caption: one position to another.
rlm@475 2008 #+name: set-ray
rlm@475 2009 #+begin_listing clojure
rlm@475 2010 #+BEGIN_SRC clojure
rlm@474 2011 (defn set-ray [#^Ray ray #^Matrix4f transform
rlm@474 2012 #^Vector3f origin #^Vector3f tip]
rlm@474 2013 ;; Doing everything locally reduces garbage collection by enough to
rlm@474 2014 ;; be worth it.
rlm@474 2015 (.mult transform origin (.getOrigin ray))
rlm@474 2016 (.mult transform tip (.getDirection ray))
rlm@474 2017 (.subtractLocal (.getDirection ray) (.getOrigin ray))
rlm@474 2018 (.normalizeLocal (.getDirection ray)))
rlm@475 2019 #+END_SRC
rlm@475 2020 #+end_listing
rlm@474 2021
rlm@475 2022 #+caption: This is the core of touch in =CORTEX= each feeler
rlm@475 2023 #+caption: follows the object it is bound to, reporting any
rlm@475 2024 #+caption: collisions that may happen.
rlm@475 2025 #+name: touch-kernel
rlm@475 2026 #+begin_listing clojure
rlm@475 2027 #+BEGIN_SRC clojure
rlm@474 2028 (defn touch-kernel
rlm@474 2029 "Constructs a function which will return tactile sensory data from
rlm@474 2030 'geo when called from inside a running simulation"
rlm@474 2031 [#^Geometry geo]
rlm@474 2032 (if-let
rlm@474 2033 [profile (tactile-sensor-profile geo)]
rlm@474 2034 (let [ray-reference-origins (feeler-origins geo profile)
rlm@474 2035 ray-reference-tips (feeler-tips geo profile)
rlm@474 2036 ray-length (tactile-scale geo)
rlm@474 2037 current-rays (map (fn [_] (Ray.)) ray-reference-origins)
rlm@474 2038 topology (touch-topology geo profile)
rlm@474 2039 correction (float (* ray-length -0.2))]
rlm@474 2040 ;; slight tolerance for very close collisions.
rlm@474 2041 (dorun
rlm@474 2042 (map (fn [origin tip]
rlm@474 2043 (.addLocal origin (.mult (.subtract tip origin)
rlm@474 2044 correction)))
rlm@474 2045 ray-reference-origins ray-reference-tips))
rlm@474 2046 (dorun (map #(.setLimit % ray-length) current-rays))
rlm@474 2047 (fn [node]
rlm@474 2048 (let [transform (.getWorldMatrix geo)]
rlm@474 2049 (dorun
rlm@474 2050 (map (fn [ray ref-origin ref-tip]
rlm@474 2051 (set-ray ray transform ref-origin ref-tip))
rlm@474 2052 current-rays ray-reference-origins
rlm@474 2053 ray-reference-tips))
rlm@474 2054 (vector
rlm@474 2055 topology
rlm@474 2056 (vec
rlm@474 2057 (for [ray current-rays]
rlm@474 2058 (do
rlm@474 2059 (let [results (CollisionResults.)]
rlm@474 2060 (.collideWith node ray results)
rlm@474 2061 (let [touch-objects
rlm@474 2062 (filter #(not (= geo (.getGeometry %)))
rlm@474 2063 results)
rlm@474 2064 limit (.getLimit ray)]
rlm@474 2065 [(if (empty? touch-objects)
rlm@474 2066 limit
rlm@474 2067 (let [response
rlm@474 2068 (apply min (map #(.getDistance %)
rlm@474 2069 touch-objects))]
rlm@474 2070 (FastMath/clamp
rlm@474 2071 (float
rlm@474 2072 (if (> response limit) (float 0.0)
rlm@474 2073 (+ response correction)))
rlm@474 2074 (float 0.0)
rlm@474 2075 limit)))
rlm@474 2076 limit])))))))))))
rlm@475 2077 #+END_SRC
rlm@475 2078 #+end_listing
rlm@474 2079
rlm@475 2080 Armed with the =touch!= function, =CORTEX= becomes capable of
rlm@475 2081 giving creatures a sense of touch. A simple test is to create a
rlm@517 2082 cube that is outfitted with a uniform distribution of touch
rlm@475 2083 sensors. It can feel the ground and any balls that it touches.
rlm@475 2084
rlm@475 2085 #+caption: =CORTEX= interface for creating touch in a simulated
rlm@475 2086 #+caption: creature.
rlm@475 2087 #+name: touch
rlm@475 2088 #+begin_listing clojure
rlm@475 2089 #+BEGIN_SRC clojure
rlm@474 2090 (defn touch!
rlm@474 2091 "Endow the creature with the sense of touch. Returns a sequence of
rlm@474 2092 functions, one for each body part with a tactile-sensor-profile,
rlm@474 2093 each of which when called returns sensory data for that body part."
rlm@474 2094 [#^Node creature]
rlm@474 2095 (filter
rlm@474 2096 (comp not nil?)
rlm@474 2097 (map touch-kernel
rlm@474 2098 (filter #(isa? (class %) Geometry)
rlm@474 2099 (node-seq creature)))))
rlm@475 2100 #+END_SRC
rlm@475 2101 #+end_listing
rlm@475 2102
rlm@475 2103 The tactile-sensor-profile image for the touch cube is a simple
rlm@517 2104 cross with a uniform distribution of touch sensors:
rlm@474 2105
rlm@475 2106 #+caption: The touch profile for the touch-cube. Each pure white
rlm@475 2107 #+caption: pixel defines a touch sensitive feeler.
rlm@475 2108 #+name: touch-cube-uv-map
rlm@495 2109 #+ATTR_LaTeX: :width 7cm
rlm@475 2110 [[./images/touch-profile.png]]
rlm@474 2111
rlm@517 2112 #+caption: The touch cube reacts to cannonballs. The black, red,
rlm@475 2113 #+caption: and white cross on the right is a visual display of
rlm@475 2114 #+caption: the creature's touch. White means that it is feeling
rlm@475 2115 #+caption: something strongly, black is not feeling anything,
rlm@475 2116 #+caption: and gray is in-between. The cube can feel both the
rlm@475 2117 #+caption: floor and the ball. Notice that when the ball causes
rlm@475 2118 #+caption: the cube to tip, that the bottom face can still feel
rlm@475 2119 #+caption: part of the ground.
rlm@518 2120 #+name: touch-cube-uv-map-2
rlm@475 2121 #+ATTR_LaTeX: :width 15cm
rlm@475 2122 [[./images/touch-cube.png]]
rlm@474 2123
rlm@511 2124 ** Proprioception provides knowledge of your own body's position
rlm@436 2125
rlm@479 2126 Close your eyes, and touch your nose with your right index finger.
rlm@479 2127 How did you do it? You could not see your hand, and neither your
rlm@479 2128 hand nor your nose could use the sense of touch to guide the path
rlm@479 2129 of your hand. There are no sound cues, and Taste and Smell
rlm@479 2130 certainly don't provide any help. You know where your hand is
rlm@479 2131 without your other senses because of Proprioception.
rlm@479 2132
rlm@479 2133 Humans can sometimes loose this sense through viral infections or
rlm@479 2134 damage to the spinal cord or brain, and when they do, they loose
rlm@479 2135 the ability to control their own bodies without looking directly at
rlm@479 2136 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 2137 Hat]] (\cite{man-wife-hat}), a woman named Christina looses this
rlm@518 2138 sense and has to learn how to move by carefully watching her arms
rlm@518 2139 and legs. She describes proprioception as the "eyes of the body,
rlm@518 2140 the way the body sees itself".
rlm@479 2141
rlm@479 2142 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 2143 spindles]], and the [[http://en.wikipedia.org/wiki/Golgi_tendon_organ][Golgi tendon organs]]. These measure the relative
rlm@479 2144 positions of each body part by monitoring muscle strain and length.
rlm@479 2145
rlm@479 2146 It's clear that this is a vital sense for fluid, graceful movement.
rlm@479 2147 It's also particularly easy to implement in jMonkeyEngine.
rlm@479 2148
rlm@479 2149 My simulated proprioception calculates the relative angles of each
rlm@562 2150 joint from the rest position defined in the Blender file. This
rlm@479 2151 simulates the muscle-spindles and joint capsules. I will deal with
rlm@479 2152 Golgi tendon organs, which calculate muscle strain, in the next
rlm@551 2153 chapter.
rlm@479 2154
rlm@479 2155 *** Helper functions
rlm@479 2156
rlm@479 2157 =absolute-angle= calculates the angle between two vectors,
rlm@479 2158 relative to a third axis vector. This angle is the number of
rlm@479 2159 radians you have to move counterclockwise around the axis vector
rlm@479 2160 to get from the first to the second vector. It is not commutative
rlm@479 2161 like a normal dot-product angle is.
rlm@479 2162
rlm@479 2163 The purpose of these functions is to build a system of angle
rlm@517 2164 measurement that is biologically plausible.
rlm@479 2165
rlm@479 2166 #+caption: Program to measure angles along a vector
rlm@479 2167 #+name: helpers
rlm@479 2168 #+begin_listing clojure
rlm@479 2169 #+BEGIN_SRC clojure
rlm@479 2170 (defn right-handed?
rlm@479 2171 "true iff the three vectors form a right handed coordinate
rlm@479 2172 system. The three vectors do not have to be normalized or
rlm@479 2173 orthogonal."
rlm@479 2174 [vec1 vec2 vec3]
rlm@479 2175 (pos? (.dot (.cross vec1 vec2) vec3)))
rlm@479 2176
rlm@479 2177 (defn absolute-angle
rlm@479 2178 "The angle between 'vec1 and 'vec2 around 'axis. In the range
rlm@479 2179 [0 (* 2 Math/PI)]."
rlm@479 2180 [vec1 vec2 axis]
rlm@479 2181 (let [angle (.angleBetween vec1 vec2)]
rlm@479 2182 (if (right-handed? vec1 vec2 axis)
rlm@479 2183 angle (- (* 2 Math/PI) angle))))
rlm@479 2184 #+END_SRC
rlm@479 2185 #+end_listing
rlm@479 2186
rlm@479 2187 *** Proprioception Kernel
rlm@479 2188
rlm@479 2189 Given a joint, =proprioception-kernel= produces a function that
rlm@545 2190 calculates the Euler angles between the objects the joint
rlm@479 2191 connects. The only tricky part here is making the angles relative
rlm@479 2192 to the joint's initial ``straightness''.
rlm@479 2193
rlm@517 2194 #+caption: Program to return biologically reasonable proprioceptive
rlm@479 2195 #+caption: data for each joint.
rlm@479 2196 #+name: proprioception
rlm@479 2197 #+begin_listing clojure
rlm@479 2198 #+BEGIN_SRC clojure
rlm@479 2199 (defn proprioception-kernel
rlm@479 2200 "Returns a function which returns proprioceptive sensory data when
rlm@479 2201 called inside a running simulation."
rlm@479 2202 [#^Node parts #^Node joint]
rlm@479 2203 (let [[obj-a obj-b] (joint-targets parts joint)
rlm@479 2204 joint-rot (.getWorldRotation joint)
rlm@479 2205 x0 (.mult joint-rot Vector3f/UNIT_X)
rlm@479 2206 y0 (.mult joint-rot Vector3f/UNIT_Y)
rlm@479 2207 z0 (.mult joint-rot Vector3f/UNIT_Z)]
rlm@479 2208 (fn []
rlm@479 2209 (let [rot-a (.clone (.getWorldRotation obj-a))
rlm@479 2210 rot-b (.clone (.getWorldRotation obj-b))
rlm@479 2211 x (.mult rot-a x0)
rlm@479 2212 y (.mult rot-a y0)
rlm@479 2213 z (.mult rot-a z0)
rlm@479 2214
rlm@479 2215 X (.mult rot-b x0)
rlm@479 2216 Y (.mult rot-b y0)
rlm@479 2217 Z (.mult rot-b z0)
rlm@479 2218 heading (Math/atan2 (.dot X z) (.dot X x))
rlm@479 2219 pitch (Math/atan2 (.dot X y) (.dot X x))
rlm@479 2220
rlm@479 2221 ;; rotate x-vector back to origin
rlm@479 2222 reverse
rlm@479 2223 (doto (Quaternion.)
rlm@479 2224 (.fromAngleAxis
rlm@479 2225 (.angleBetween X x)
rlm@479 2226 (let [cross (.normalize (.cross X x))]
rlm@479 2227 (if (= 0 (.length cross)) y cross))))
rlm@479 2228 roll (absolute-angle (.mult reverse Y) y x)]
rlm@479 2229 [heading pitch roll]))))
rlm@479 2230
rlm@479 2231 (defn proprioception!
rlm@479 2232 "Endow the creature with the sense of proprioception. Returns a
rlm@479 2233 sequence of functions, one for each child of the \"joints\" node in
rlm@479 2234 the creature, which each report proprioceptive information about
rlm@479 2235 that joint."
rlm@479 2236 [#^Node creature]
rlm@479 2237 ;; extract the body's joints
rlm@479 2238 (let [senses (map (partial proprioception-kernel creature)
rlm@479 2239 (joints creature))]
rlm@479 2240 (fn []
rlm@479 2241 (map #(%) senses))))
rlm@479 2242 #+END_SRC
rlm@479 2243 #+end_listing
rlm@479 2244
rlm@479 2245 =proprioception!= maps =proprioception-kernel= across all the
rlm@479 2246 joints of the creature. It uses the same list of joints that
rlm@479 2247 =joints= uses. Proprioception is the easiest sense to implement in
rlm@479 2248 =CORTEX=, and it will play a crucial role when efficiently
rlm@479 2249 implementing empathy.
rlm@479 2250
rlm@479 2251 #+caption: In the upper right corner, the three proprioceptive
rlm@479 2252 #+caption: angle measurements are displayed. Red is yaw, Green is
rlm@479 2253 #+caption: pitch, and White is roll.
rlm@479 2254 #+name: proprio
rlm@479 2255 #+ATTR_LaTeX: :width 11cm
rlm@479 2256 [[./images/proprio.png]]
rlm@479 2257
rlm@511 2258 ** Muscles contain both sensors and effectors
rlm@481 2259
rlm@481 2260 Surprisingly enough, terrestrial creatures only move by using
rlm@481 2261 torque applied about their joints. There's not a single straight
rlm@481 2262 line of force in the human body at all! (A straight line of force
rlm@481 2263 would correspond to some sort of jet or rocket propulsion.)
rlm@481 2264
rlm@481 2265 In humans, muscles are composed of muscle fibers which can contract
rlm@481 2266 to exert force. The muscle fibers which compose a muscle are
rlm@481 2267 partitioned into discrete groups which are each controlled by a
rlm@481 2268 single alpha motor neuron. A single alpha motor neuron might
rlm@481 2269 control as little as three or as many as one thousand muscle
rlm@481 2270 fibers. When the alpha motor neuron is engaged by the spinal cord,
rlm@481 2271 it activates all of the muscle fibers to which it is attached. The
rlm@481 2272 spinal cord generally engages the alpha motor neurons which control
rlm@481 2273 few muscle fibers before the motor neurons which control many
rlm@481 2274 muscle fibers. This recruitment strategy allows for precise
rlm@481 2275 movements at low strength. The collection of all motor neurons that
rlm@481 2276 control a muscle is called the motor pool. The brain essentially
rlm@481 2277 says "activate 30% of the motor pool" and the spinal cord recruits
rlm@481 2278 motor neurons until 30% are activated. Since the distribution of
rlm@481 2279 power among motor neurons is unequal and recruitment goes from
rlm@481 2280 weakest to strongest, the first 30% of the motor pool might be 5%
rlm@481 2281 of the strength of the muscle.
rlm@481 2282
rlm@481 2283 My simulated muscles follow a similar design: Each muscle is
rlm@481 2284 defined by a 1-D array of numbers (the "motor pool"). Each entry in
rlm@481 2285 the array represents a motor neuron which controls a number of
rlm@481 2286 muscle fibers equal to the value of the entry. Each muscle has a
rlm@481 2287 scalar strength factor which determines the total force the muscle
rlm@481 2288 can exert when all motor neurons are activated. The effector
rlm@481 2289 function for a muscle takes a number to index into the motor pool,
rlm@481 2290 and then "activates" all the motor neurons whose index is lower or
rlm@481 2291 equal to the number. Each motor-neuron will apply force in
rlm@481 2292 proportion to its value in the array. Lower values cause less
rlm@481 2293 force. The lower values can be put at the "beginning" of the 1-D
rlm@481 2294 array to simulate the layout of actual human muscles, which are
rlm@481 2295 capable of more precise movements when exerting less force. Or, the
rlm@481 2296 motor pool can simulate more exotic recruitment strategies which do
rlm@481 2297 not correspond to human muscles.
rlm@481 2298
rlm@481 2299 This 1D array is defined in an image file for ease of
rlm@481 2300 creation/visualization. Here is an example muscle profile image.
rlm@481 2301
rlm@481 2302 #+caption: A muscle profile image that describes the strengths
rlm@481 2303 #+caption: of each motor neuron in a muscle. White is weakest
rlm@481 2304 #+caption: and dark red is strongest. This particular pattern
rlm@481 2305 #+caption: has weaker motor neurons at the beginning, just
rlm@481 2306 #+caption: like human muscle.
rlm@481 2307 #+name: muscle-recruit
rlm@481 2308 #+ATTR_LaTeX: :width 7cm
rlm@481 2309 [[./images/basic-muscle.png]]
rlm@481 2310
rlm@481 2311 *** Muscle meta-data
rlm@481 2312
rlm@562 2313 #+caption: Program to deal with loading muscle data from a Blender
rlm@481 2314 #+caption: file's metadata.
rlm@481 2315 #+name: motor-pool
rlm@481 2316 #+begin_listing clojure
rlm@481 2317 #+BEGIN_SRC clojure
rlm@481 2318 (defn muscle-profile-image
rlm@481 2319 "Get the muscle-profile image from the node's blender meta-data."
rlm@481 2320 [#^Node muscle]
rlm@481 2321 (if-let [image (meta-data muscle "muscle")]
rlm@481 2322 (load-image image)))
rlm@481 2323
rlm@481 2324 (defn muscle-strength
rlm@481 2325 "Return the strength of this muscle, or 1 if it is not defined."
rlm@481 2326 [#^Node muscle]
rlm@481 2327 (if-let [strength (meta-data muscle "strength")]
rlm@481 2328 strength 1))
rlm@481 2329
rlm@481 2330 (defn motor-pool
rlm@481 2331 "Return a vector where each entry is the strength of the \"motor
rlm@481 2332 neuron\" at that part in the muscle."
rlm@481 2333 [#^Node muscle]
rlm@481 2334 (let [profile (muscle-profile-image muscle)]
rlm@481 2335 (vec
rlm@481 2336 (let [width (.getWidth profile)]
rlm@481 2337 (for [x (range width)]
rlm@481 2338 (- 255
rlm@481 2339 (bit-and
rlm@481 2340 0x0000FF
rlm@481 2341 (.getRGB profile x 0))))))))
rlm@481 2342 #+END_SRC
rlm@481 2343 #+end_listing
rlm@481 2344
rlm@481 2345 Of note here is =motor-pool= which interprets the muscle-profile
rlm@481 2346 image in a way that allows me to use gradients between white and
rlm@481 2347 red, instead of shades of gray as I've been using for all the
rlm@481 2348 other senses. This is purely an aesthetic touch.
rlm@481 2349
rlm@481 2350 *** Creating muscles
rlm@481 2351
rlm@517 2352 #+caption: This is the core movement function in =CORTEX=, which
rlm@481 2353 #+caption: implements muscles that report on their activation.
rlm@481 2354 #+name: muscle-kernel
rlm@481 2355 #+begin_listing clojure
rlm@481 2356 #+BEGIN_SRC clojure
rlm@481 2357 (defn movement-kernel
rlm@481 2358 "Returns a function which when called with a integer value inside a
rlm@481 2359 running simulation will cause movement in the creature according
rlm@481 2360 to the muscle's position and strength profile. Each function
rlm@481 2361 returns the amount of force applied / max force."
rlm@481 2362 [#^Node creature #^Node muscle]
rlm@481 2363 (let [target (closest-node creature muscle)
rlm@481 2364 axis
rlm@481 2365 (.mult (.getWorldRotation muscle) Vector3f/UNIT_Y)
rlm@481 2366 strength (muscle-strength muscle)
rlm@481 2367
rlm@481 2368 pool (motor-pool muscle)
rlm@481 2369 pool-integral (reductions + pool)
rlm@481 2370 forces
rlm@481 2371 (vec (map #(float (* strength (/ % (last pool-integral))))
rlm@481 2372 pool-integral))
rlm@481 2373 control (.getControl target RigidBodyControl)]
rlm@481 2374 (fn [n]
rlm@481 2375 (let [pool-index (max 0 (min n (dec (count pool))))
rlm@481 2376 force (forces pool-index)]
rlm@481 2377 (.applyTorque control (.mult axis force))
rlm@481 2378 (float (/ force strength))))))
rlm@481 2379
rlm@481 2380 (defn movement!
rlm@481 2381 "Endow the creature with the power of movement. Returns a sequence
rlm@481 2382 of functions, each of which accept an integer value and will
rlm@481 2383 activate their corresponding muscle."
rlm@481 2384 [#^Node creature]
rlm@481 2385 (for [muscle (muscles creature)]
rlm@481 2386 (movement-kernel creature muscle)))
rlm@481 2387 #+END_SRC
rlm@481 2388 #+end_listing
rlm@481 2389
rlm@481 2390
rlm@531 2391 =movement-kernel= creates a function that controls the movement
rlm@525 2392 of the nearest physical node to the muscle node. The muscle exerts
rlm@525 2393 a rotational force dependent on it's orientation to the object in
rlm@562 2394 the Blender file. The function returned by =movement-kernel= is
rlm@525 2395 also a sense function: it returns the percent of the total muscle
rlm@525 2396 strength that is currently being employed. This is analogous to
rlm@525 2397 muscle tension in humans and completes the sense of proprioception
rlm@551 2398 begun in the last chapter.
rlm@488 2399
rlm@507 2400 ** =CORTEX= brings complex creatures to life!
rlm@483 2401
rlm@483 2402 The ultimate test of =CORTEX= is to create a creature with the full
rlm@483 2403 gamut of senses and put it though its paces.
rlm@483 2404
rlm@483 2405 With all senses enabled, my right hand model looks like an
rlm@483 2406 intricate marionette hand with several strings for each finger:
rlm@483 2407
rlm@483 2408 #+caption: View of the hand model with all sense nodes. You can see
rlm@517 2409 #+caption: the joint, muscle, ear, and eye nodes here.
rlm@483 2410 #+name: hand-nodes-1
rlm@483 2411 #+ATTR_LaTeX: :width 11cm
rlm@483 2412 [[./images/hand-with-all-senses2.png]]
rlm@483 2413
rlm@483 2414 #+caption: An alternate view of the hand.
rlm@483 2415 #+name: hand-nodes-2
rlm@484 2416 #+ATTR_LaTeX: :width 15cm
rlm@484 2417 [[./images/hand-with-all-senses3.png]]
rlm@484 2418
rlm@484 2419 With the hand fully rigged with senses, I can run it though a test
rlm@484 2420 that will test everything.
rlm@484 2421
rlm@553 2422 #+caption: Selected frames from a full test of the hand with all
rlm@553 2423 #+caption: senses. Note especially the interactions the hand has
rlm@553 2424 #+caption: with itself: it feels its own palm and fingers, and when
rlm@553 2425 #+caption: it curls its fingers, it sees them with its eye (which
rlm@553 2426 #+caption: is located in the center of the palm. The red block
rlm@553 2427 #+caption: appears with a pure tone sound. The hand then uses its
rlm@553 2428 #+caption: muscles to launch the cube!
rlm@484 2429 #+name: integration
rlm@553 2430 #+ATTR_LaTeX: :width 15cm
rlm@484 2431 [[./images/integration.png]]
rlm@436 2432
rlm@517 2433 ** =CORTEX= enables many possibilities for further research
rlm@485 2434
rlm@485 2435 Often times, the hardest part of building a system involving
rlm@485 2436 creatures is dealing with physics and graphics. =CORTEX= removes
rlm@485 2437 much of this initial difficulty and leaves researchers free to
rlm@485 2438 directly pursue their ideas. I hope that even undergrads with a
rlm@485 2439 passing curiosity about simulated touch or creature evolution will
rlm@485 2440 be able to use cortex for experimentation. =CORTEX= is a completely
rlm@485 2441 simulated world, and far from being a disadvantage, its simulated
rlm@485 2442 nature enables you to create senses and creatures that would be
rlm@485 2443 impossible to make in the real world.
rlm@485 2444
rlm@485 2445 While not by any means a complete list, here are some paths
rlm@485 2446 =CORTEX= is well suited to help you explore:
rlm@485 2447
rlm@485 2448 - Empathy :: my empathy program leaves many areas for
rlm@485 2449 improvement, among which are using vision to infer
rlm@485 2450 proprioception and looking up sensory experience with imagined
rlm@485 2451 vision, touch, and sound.
rlm@547 2452 - Evolution :: Karl Sims created a rich environment for simulating
rlm@547 2453 the evolution of creatures on a Connection Machine
rlm@547 2454 (\cite{sims-evolving-creatures}). Today, this can be redone
rlm@547 2455 and expanded with =CORTEX= on an ordinary computer.
rlm@485 2456 - Exotic senses :: Cortex enables many fascinating senses that are
rlm@485 2457 not possible to build in the real world. For example,
rlm@485 2458 telekinesis is an interesting avenue to explore. You can also
rlm@485 2459 make a ``semantic'' sense which looks up metadata tags on
rlm@485 2460 objects in the environment the metadata tags might contain
rlm@485 2461 other sensory information.
rlm@485 2462 - Imagination via subworlds :: this would involve a creature with
rlm@485 2463 an effector which creates an entire new sub-simulation where
rlm@485 2464 the creature has direct control over placement/creation of
rlm@485 2465 objects via simulated telekinesis. The creature observes this
rlm@547 2466 sub-world through its normal senses and uses its observations
rlm@485 2467 to make predictions about its top level world.
rlm@485 2468 - Simulated prescience :: step the simulation forward a few ticks,
rlm@485 2469 gather sensory data, then supply this data for the creature as
rlm@485 2470 one of its actual senses. The cost of prescience is slowing
rlm@485 2471 the simulation down by a factor proportional to however far
rlm@485 2472 you want the entities to see into the future. What happens
rlm@485 2473 when two evolved creatures that can each see into the future
rlm@485 2474 fight each other?
rlm@485 2475 - Swarm creatures :: Program a group of creatures that cooperate
rlm@485 2476 with each other. Because the creatures would be simulated, you
rlm@485 2477 could investigate computationally complex rules of behavior
rlm@485 2478 which still, from the group's point of view, would happen in
rlm@547 2479 real time. Interactions could be as simple as cellular
rlm@485 2480 organisms communicating via flashing lights, or as complex as
rlm@485 2481 humanoids completing social tasks, etc.
rlm@547 2482 - =HACKER= for writing muscle-control programs :: Presented with a
rlm@547 2483 low-level muscle control / sense API, generate higher level
rlm@485 2484 programs for accomplishing various stated goals. Example goals
rlm@485 2485 might be "extend all your fingers" or "move your hand into the
rlm@485 2486 area with blue light" or "decrease the angle of this joint".
rlm@485 2487 It would be like Sussman's HACKER, except it would operate
rlm@485 2488 with much more data in a more realistic world. Start off with
rlm@485 2489 "calisthenics" to develop subroutines over the motor control
rlm@547 2490 API. The low level programming code might be a turning machine
rlm@547 2491 that could develop programs to iterate over a "tape" where
rlm@547 2492 each entry in the tape could control recruitment of the fibers
rlm@547 2493 in a muscle.
rlm@547 2494 - Sense fusion :: There is much work to be done on sense
rlm@485 2495 integration -- building up a coherent picture of the world and
rlm@547 2496 the things in it. With =CORTEX= as a base, you can explore
rlm@485 2497 concepts like self-organizing maps or cross modal clustering
rlm@485 2498 in ways that have never before been tried.
rlm@485 2499 - Inverse kinematics :: experiments in sense guided motor control
rlm@485 2500 are easy given =CORTEX='s support -- you can get right to the
rlm@485 2501 hard control problems without worrying about physics or
rlm@485 2502 senses.
rlm@485 2503
rlm@525 2504 \newpage
rlm@525 2505
rlm@558 2506 * =EMPATH=: action recognition in a simulated worm
rlm@435 2507
rlm@449 2508 Here I develop a computational model of empathy, using =CORTEX= as a
rlm@449 2509 base. Empathy in this context is the ability to observe another
rlm@449 2510 creature and infer what sorts of sensations that creature is
rlm@449 2511 feeling. My empathy algorithm involves multiple phases. First is
rlm@449 2512 free-play, where the creature moves around and gains sensory
rlm@449 2513 experience. From this experience I construct a representation of the
rlm@449 2514 creature's sensory state space, which I call \Phi-space. Using
rlm@449 2515 \Phi-space, I construct an efficient function which takes the
rlm@449 2516 limited data that comes from observing another creature and enriches
rlm@525 2517 it with a full compliment of imagined sensory data. I can then use
rlm@525 2518 the imagined sensory data to recognize what the observed creature is
rlm@449 2519 doing and feeling, using straightforward embodied action predicates.
rlm@449 2520 This is all demonstrated with using a simple worm-like creature, and
rlm@449 2521 recognizing worm-actions based on limited data.
rlm@449 2522
rlm@555 2523 #+caption: Here is the worm with which we will be working. It is
rlm@555 2524 #+caption: composed of 5 segments. Each segment has a pair of
rlm@555 2525 #+caption: extensor and flexor muscles. Each of the worm's four
rlm@555 2526 #+caption: joints is a hinge joint which allows about 30 degrees of
rlm@555 2527 #+caption: rotation to either side. Each segment of the worm is
rlm@555 2528 #+caption: touch-capable and has a uniform distribution of touch
rlm@555 2529 #+caption: sensors on each of its faces. Each joint has a
rlm@555 2530 #+caption: proprioceptive sense to detect relative positions. The
rlm@555 2531 #+caption: worm segments are all the same except for the first one,
rlm@555 2532 #+caption: which has a much higher weight than the others to allow
rlm@555 2533 #+caption: for easy manual motor control.
rlm@449 2534 #+name: basic-worm-view
rlm@449 2535 #+ATTR_LaTeX: :width 10cm
rlm@449 2536 [[./images/basic-worm-view.png]]
rlm@449 2537
rlm@562 2538 #+caption: Program for reading a worm from a Blender file and
rlm@449 2539 #+caption: outfitting it with the senses of proprioception,
rlm@449 2540 #+caption: touch, and the ability to move, as specified in the
rlm@562 2541 #+caption: Blender file.
rlm@449 2542 #+name: get-worm
rlm@449 2543 #+begin_listing clojure
rlm@449 2544 #+begin_src clojure
rlm@449 2545 (defn worm []
rlm@449 2546 (let [model (load-blender-model "Models/worm/worm.blend")]
rlm@449 2547 {:body (doto model (body!))
rlm@449 2548 :touch (touch! model)
rlm@449 2549 :proprioception (proprioception! model)
rlm@449 2550 :muscles (movement! model)}))
rlm@449 2551 #+end_src
rlm@449 2552 #+end_listing
rlm@452 2553
rlm@531 2554 ** Embodiment factors action recognition into manageable parts
rlm@435 2555
rlm@449 2556 Using empathy, I divide the problem of action recognition into a
rlm@449 2557 recognition process expressed in the language of a full compliment
rlm@517 2558 of senses, and an imaginative process that generates full sensory
rlm@449 2559 data from partial sensory data. Splitting the action recognition
rlm@449 2560 problem in this manner greatly reduces the total amount of work to
rlm@517 2561 recognize actions: The imaginative process is mostly just matching
rlm@449 2562 previous experience, and the recognition process gets to use all
rlm@449 2563 the senses to directly describe any action.
rlm@449 2564
rlm@436 2565 ** Action recognition is easy with a full gamut of senses
rlm@435 2566
rlm@554 2567 Embodied representation using multiple senses such as touch,
rlm@545 2568 proprioception, and muscle tension turns out be exceedingly
rlm@525 2569 efficient at describing body-centered actions. It is the right
rlm@525 2570 language for the job. For example, it takes only around 5 lines of
rlm@554 2571 clojure code to describe the action of curling using embodied
rlm@451 2572 primitives. It takes about 10 lines to describe the seemingly
rlm@449 2573 complicated action of wiggling.
rlm@449 2574
rlm@449 2575 The following action predicates each take a stream of sensory
rlm@449 2576 experience, observe however much of it they desire, and decide
rlm@449 2577 whether the worm is doing the action they describe. =curled?=
rlm@449 2578 relies on proprioception, =resting?= relies on touch, =wiggling?=
rlm@517 2579 relies on a Fourier analysis of muscle contraction, and
rlm@525 2580 =grand-circle?= relies on touch and reuses =curled?= in its
rlm@525 2581 definition, showing how embodied predicates can be composed.
rlm@449 2582
rlm@530 2583
rlm@449 2584 #+caption: Program for detecting whether the worm is curled. This is the
rlm@449 2585 #+caption: simplest action predicate, because it only uses the last frame
rlm@449 2586 #+caption: of sensory experience, and only uses proprioceptive data. Even
rlm@449 2587 #+caption: this simple predicate, however, is automatically frame
rlm@530 2588 #+caption: independent and ignores vermopomorphic\protect\footnotemark
rlm@532 2589 #+caption: \space differences such as worm textures and colors.
rlm@449 2590 #+name: curled
rlm@509 2591 #+begin_listing clojure
rlm@449 2592 #+begin_src clojure
rlm@449 2593 (defn curled?
rlm@449 2594 "Is the worm curled up?"
rlm@449 2595 [experiences]
rlm@449 2596 (every?
rlm@449 2597 (fn [[_ _ bend]]
rlm@449 2598 (> (Math/sin bend) 0.64))
rlm@449 2599 (:proprioception (peek experiences))))
rlm@449 2600 #+end_src
rlm@449 2601 #+end_listing
rlm@530 2602
rlm@530 2603 #+BEGIN_LaTeX
rlm@530 2604 \footnotetext{Like \emph{anthropomorphic} except for worms instead of humans.}
rlm@530 2605 #+END_LaTeX
rlm@449 2606
rlm@449 2607 #+caption: Program for summarizing the touch information in a patch
rlm@449 2608 #+caption: of skin.
rlm@449 2609 #+name: touch-summary
rlm@509 2610 #+begin_listing clojure
rlm@449 2611 #+begin_src clojure
rlm@449 2612 (defn contact
rlm@449 2613 "Determine how much contact a particular worm segment has with
rlm@449 2614 other objects. Returns a value between 0 and 1, where 1 is full
rlm@449 2615 contact and 0 is no contact."
rlm@449 2616 [touch-region [coords contact :as touch]]
rlm@449 2617 (-> (zipmap coords contact)
rlm@449 2618 (select-keys touch-region)
rlm@449 2619 (vals)
rlm@449 2620 (#(map first %))
rlm@449 2621 (average)
rlm@449 2622 (* 10)
rlm@449 2623 (- 1)
rlm@449 2624 (Math/abs)))
rlm@449 2625 #+end_src
rlm@449 2626 #+end_listing
rlm@449 2627
rlm@449 2628
rlm@449 2629 #+caption: Program for detecting whether the worm is at rest. This program
rlm@449 2630 #+caption: uses a summary of the tactile information from the underbelly
rlm@449 2631 #+caption: of the worm, and is only true if every segment is touching the
rlm@449 2632 #+caption: floor. Note that this function contains no references to
rlm@517 2633 #+caption: proprioception at all.
rlm@449 2634 #+name: resting
rlm@452 2635 #+begin_listing clojure
rlm@449 2636 #+begin_src clojure
rlm@449 2637 (def worm-segment-bottom (rect-region [8 15] [14 22]))
rlm@449 2638
rlm@449 2639 (defn resting?
rlm@449 2640 "Is the worm resting on the ground?"
rlm@449 2641 [experiences]
rlm@449 2642 (every?
rlm@449 2643 (fn [touch-data]
rlm@449 2644 (< 0.9 (contact worm-segment-bottom touch-data)))
rlm@449 2645 (:touch (peek experiences))))
rlm@449 2646 #+end_src
rlm@449 2647 #+end_listing
rlm@449 2648
rlm@449 2649 #+caption: Program for detecting whether the worm is curled up into a
rlm@449 2650 #+caption: full circle. Here the embodied approach begins to shine, as
rlm@449 2651 #+caption: I am able to both use a previous action predicate (=curled?=)
rlm@449 2652 #+caption: as well as the direct tactile experience of the head and tail.
rlm@449 2653 #+name: grand-circle
rlm@452 2654 #+begin_listing clojure
rlm@449 2655 #+begin_src clojure
rlm@449 2656 (def worm-segment-bottom-tip (rect-region [15 15] [22 22]))
rlm@449 2657
rlm@449 2658 (def worm-segment-top-tip (rect-region [0 15] [7 22]))
rlm@449 2659
rlm@449 2660 (defn grand-circle?
rlm@449 2661 "Does the worm form a majestic circle (one end touching the other)?"
rlm@449 2662 [experiences]
rlm@449 2663 (and (curled? experiences)
rlm@449 2664 (let [worm-touch (:touch (peek experiences))
rlm@449 2665 tail-touch (worm-touch 0)
rlm@449 2666 head-touch (worm-touch 4)]
rlm@449 2667 (and (< 0.55 (contact worm-segment-bottom-tip tail-touch))
rlm@449 2668 (< 0.55 (contact worm-segment-top-tip head-touch))))))
rlm@449 2669 #+end_src
rlm@449 2670 #+end_listing
rlm@449 2671
rlm@449 2672
rlm@449 2673 #+caption: Program for detecting whether the worm has been wiggling for
rlm@517 2674 #+caption: the last few frames. It uses a Fourier analysis of the muscle
rlm@449 2675 #+caption: contractions of the worm's tail to determine wiggling. This is
rlm@517 2676 #+caption: significant because there is no particular frame that clearly
rlm@449 2677 #+caption: indicates that the worm is wiggling --- only when multiple frames
rlm@449 2678 #+caption: are analyzed together is the wiggling revealed. Defining
rlm@449 2679 #+caption: wiggling this way also gives the worm an opportunity to learn
rlm@449 2680 #+caption: and recognize ``frustrated wiggling'', where the worm tries to
rlm@449 2681 #+caption: wiggle but can't. Frustrated wiggling is very visually different
rlm@449 2682 #+caption: from actual wiggling, but this definition gives it to us for free.
rlm@449 2683 #+name: wiggling
rlm@452 2684 #+begin_listing clojure
rlm@449 2685 #+begin_src clojure
rlm@449 2686 (defn fft [nums]
rlm@449 2687 (map
rlm@449 2688 #(.getReal %)
rlm@449 2689 (.transform
rlm@449 2690 (FastFourierTransformer. DftNormalization/STANDARD)
rlm@449 2691 (double-array nums) TransformType/FORWARD)))
rlm@449 2692
rlm@449 2693 (def indexed (partial map-indexed vector))
rlm@449 2694
rlm@449 2695 (defn max-indexed [s]
rlm@449 2696 (first (sort-by (comp - second) (indexed s))))
rlm@449 2697
rlm@449 2698 (defn wiggling?
rlm@449 2699 "Is the worm wiggling?"
rlm@449 2700 [experiences]
rlm@449 2701 (let [analysis-interval 0x40]
rlm@449 2702 (when (> (count experiences) analysis-interval)
rlm@449 2703 (let [a-flex 3
rlm@449 2704 a-ex 2
rlm@449 2705 muscle-activity
rlm@449 2706 (map :muscle (vector:last-n experiences analysis-interval))
rlm@449 2707 base-activity
rlm@449 2708 (map #(- (% a-flex) (% a-ex)) muscle-activity)]
rlm@449 2709 (= 2
rlm@449 2710 (first
rlm@449 2711 (max-indexed
rlm@449 2712 (map #(Math/abs %)
rlm@449 2713 (take 20 (fft base-activity))))))))))
rlm@449 2714 #+end_src
rlm@449 2715 #+end_listing
rlm@449 2716
rlm@449 2717 With these action predicates, I can now recognize the actions of
rlm@449 2718 the worm while it is moving under my control and I have access to
rlm@449 2719 all the worm's senses.
rlm@449 2720
rlm@449 2721 #+caption: Use the action predicates defined earlier to report on
rlm@449 2722 #+caption: what the worm is doing while in simulation.
rlm@449 2723 #+name: report-worm-activity
rlm@452 2724 #+begin_listing clojure
rlm@449 2725 #+begin_src clojure
rlm@449 2726 (defn debug-experience
rlm@449 2727 [experiences text]
rlm@449 2728 (cond
rlm@449 2729 (grand-circle? experiences) (.setText text "Grand Circle")
rlm@449 2730 (curled? experiences) (.setText text "Curled")
rlm@449 2731 (wiggling? experiences) (.setText text "Wiggling")
rlm@449 2732 (resting? experiences) (.setText text "Resting")))
rlm@449 2733 #+end_src
rlm@449 2734 #+end_listing
rlm@449 2735
rlm@449 2736 #+caption: Using =debug-experience=, the body-centered predicates
rlm@517 2737 #+caption: work together to classify the behavior of the worm.
rlm@451 2738 #+caption: the predicates are operating with access to the worm's
rlm@451 2739 #+caption: full sensory data.
rlm@449 2740 #+name: basic-worm-view
rlm@449 2741 #+ATTR_LaTeX: :width 10cm
rlm@449 2742 [[./images/worm-identify-init.png]]
rlm@449 2743
rlm@449 2744 These action predicates satisfy the recognition requirement of an
rlm@451 2745 empathic recognition system. There is power in the simplicity of
rlm@451 2746 the action predicates. They describe their actions without getting
rlm@531 2747 confused in visual details of the worm. Each one is independent of
rlm@531 2748 position and rotation, but more than that, they are each
rlm@531 2749 independent of irrelevant visual details of the worm and the
rlm@531 2750 environment. They will work regardless of whether the worm is a
rlm@531 2751 different color or heavily textured, or if the environment has
rlm@531 2752 strange lighting.
rlm@531 2753
rlm@531 2754 Consider how the human act of jumping might be described with
rlm@531 2755 body-centered action predicates: You might specify that jumping is
rlm@531 2756 mainly the feeling of your knees bending, your thigh muscles
rlm@531 2757 contracting, and your inner ear experiencing a certain sort of back
rlm@531 2758 and forth acceleration. This representation is a very concrete
rlm@531 2759 description of jumping, couched in terms of muscles and senses, but
rlm@531 2760 it also has the ability to describe almost all kinds of jumping, a
rlm@531 2761 generality that you might think could only be achieved by a very
rlm@531 2762 abstract description. The body centered jumping predicate does not
rlm@531 2763 have terms that consider the color of a person's skin or whether
rlm@531 2764 they are male or female, instead it gets right to the meat of what
rlm@531 2765 jumping actually /is/.
rlm@531 2766
rlm@531 2767 Of course, the action predicates are not directly applicable to
rlm@547 2768 video data, which lacks the advanced sensory information which they
rlm@531 2769 require!
rlm@449 2770
rlm@449 2771 The trick now is to make the action predicates work even when the
rlm@554 2772 sensory data on which they depend is absent!
rlm@435 2773
rlm@531 2774 ** \Phi-space describes the worm's experiences
rlm@449 2775
rlm@449 2776 As a first step towards building empathy, I need to gather all of
rlm@449 2777 the worm's experiences during free play. I use a simple vector to
rlm@449 2778 store all the experiences.
rlm@449 2779
rlm@449 2780 Each element of the experience vector exists in the vast space of
rlm@449 2781 all possible worm-experiences. Most of this vast space is actually
rlm@449 2782 unreachable due to physical constraints of the worm's body. For
rlm@449 2783 example, the worm's segments are connected by hinge joints that put
rlm@451 2784 a practical limit on the worm's range of motions without limiting
rlm@451 2785 its degrees of freedom. Some groupings of senses are impossible;
rlm@451 2786 the worm can not be bent into a circle so that its ends are
rlm@451 2787 touching and at the same time not also experience the sensation of
rlm@451 2788 touching itself.
rlm@449 2789
rlm@451 2790 As the worm moves around during free play and its experience vector
rlm@451 2791 grows larger, the vector begins to define a subspace which is all
rlm@517 2792 the sensations the worm can practically experience during normal
rlm@451 2793 operation. I call this subspace \Phi-space, short for
rlm@451 2794 physical-space. The experience vector defines a path through
rlm@451 2795 \Phi-space. This path has interesting properties that all derive
rlm@533 2796 from physical embodiment. The proprioceptive components of the path
rlm@533 2797 vary smoothly, because in order for the worm to move from one
rlm@451 2798 position to another, it must pass through the intermediate
rlm@533 2799 positions. The path invariably forms loops as common actions are
rlm@533 2800 repeated. Finally and most importantly, proprioception alone
rlm@533 2801 actually gives very strong inference about the other senses. For
rlm@533 2802 example, when the worm is proprioceptively flat over several
rlm@533 2803 frames, you can infer that it is touching the ground and that its
rlm@451 2804 muscles are not active, because if the muscles were active, the
rlm@533 2805 worm would be moving and would not remain perfectly flat. In order
rlm@533 2806 to stay flat, the worm has to be touching the ground, or it would
rlm@451 2807 again be moving out of the flat position due to gravity. If the
rlm@451 2808 worm is positioned in such a way that it interacts with itself,
rlm@451 2809 then it is very likely to be feeling the same tactile feelings as
rlm@451 2810 the last time it was in that position, because it has the same body
rlm@533 2811 as then. As you observe multiple frames of proprioceptive data, you
rlm@533 2812 can become increasingly confident about the exact activations of
rlm@533 2813 the worm's muscles, because it generally takes a unique combination
rlm@533 2814 of muscle contractions to transform the worm's body along a
rlm@533 2815 specific path through \Phi-space.
rlm@533 2816
rlm@533 2817 The worm's total life experience is a long looping path through
rlm@533 2818 \Phi-space. I will now introduce simple way of taking that
rlm@548 2819 experience path and building a function that can infer complete
rlm@533 2820 sensory experience given only a stream of proprioceptive data. This
rlm@533 2821 /empathy/ function will provide a bridge to use the body centered
rlm@533 2822 action predicates on video-like streams of information.
rlm@533 2823
rlm@535 2824 ** Empathy is the process of building paths in \Phi-space
rlm@449 2825
rlm@450 2826 Here is the core of a basic empathy algorithm, starting with an
rlm@451 2827 experience vector:
rlm@451 2828
rlm@533 2829 An /experience-index/ is an index into the grand experience vector
rlm@534 2830 that defines the worm's life. It is a time-stamp for each set of
rlm@533 2831 sensations the worm has experienced.
rlm@533 2832
rlm@562 2833 First, I group the experience-indices into bins according to the
rlm@533 2834 similarity of their proprioceptive data. I organize my bins into a
rlm@534 2835 3 level hierarchy. The smallest bins have an approximate size of
rlm@533 2836 0.001 radians in all proprioceptive dimensions. Each higher level
rlm@533 2837 is 10x bigger than the level below it.
rlm@533 2838
rlm@533 2839 The bins serve as a hashing function for proprioceptive data. Given
rlm@562 2840 a single piece of proprioceptive experience, the bins allow me to
rlm@534 2841 rapidly find all other similar experience-indices of past
rlm@534 2842 experience that had a very similar proprioceptive configuration.
rlm@533 2843 When looking up a proprioceptive experience, if the smallest bin
rlm@562 2844 does not match any previous experience, then I use successively
rlm@562 2845 larger bins until a match is found or I reach the largest bin.
rlm@450 2846
rlm@533 2847 Given a sequence of proprioceptive input, I use the bins to
rlm@534 2848 generate a set of similar experiences for each input using the
rlm@533 2849 tiered proprioceptive bins.
rlm@533 2850
rlm@533 2851 Finally, to infer sensory data, I select the longest consecutive
rlm@534 2852 chain of experiences that threads through the sets of similar
rlm@535 2853 experiences, starting with the current moment as a root and going
rlm@535 2854 backwards. Consecutive experience means that the experiences appear
rlm@535 2855 next to each other in the experience vector.
rlm@535 2856
rlm@535 2857 A stream of proprioceptive input might be:
rlm@533 2858
rlm@535 2859 #+BEGIN_EXAMPLE
rlm@535 2860 [ flat, flat, flat, flat, flat, flat, lift-head ]
rlm@535 2861 #+END_EXAMPLE
rlm@535 2862
rlm@535 2863 The worm's previous experience of lying on the ground and lifting
rlm@547 2864 its head generates possible interpretations for each frame (the
rlm@547 2865 numbers are experience-indices):
rlm@535 2866
rlm@535 2867 #+BEGIN_EXAMPLE
rlm@535 2868 [ flat, flat, flat, flat, flat, flat, flat, lift-head ]
rlm@535 2869 1 1 1 1 1 1 1 4
rlm@535 2870 2 2 2 2 2 2 2
rlm@535 2871 3 3 3 3 3 3 3
rlm@554 2872 6 6 6 6 6 6 6
rlm@535 2873 7 7 7 7 7 7 7
rlm@535 2874 8 8 8 8 8 8 8
rlm@535 2875 9 9 9 9 9 9 9
rlm@535 2876 #+END_EXAMPLE
rlm@535 2877
rlm@535 2878 These interpretations suggest a new path through phi space:
rlm@535 2879
rlm@535 2880 #+BEGIN_EXAMPLE
rlm@535 2881 [ flat, flat, flat, flat, flat, flat, flat, lift-head ]
rlm@535 2882 6 7 8 9 1 2 3 4
rlm@535 2883 #+END_EXAMPLE
rlm@535 2884
rlm@535 2885 The new path through \Phi-space is synthesized from two actual
rlm@547 2886 paths that the creature has experienced: the "1-2-3-4" chain and
rlm@547 2887 the "6-7-8-9" chain. The "1-2-3-4" chain is necessary because it
rlm@547 2888 ends with the worm lifting its head. It originated from a short
rlm@535 2889 training session where the worm rested on the floor for a brief
rlm@535 2890 while and then raised its head. The "6-7-8-9" chain is part of a
rlm@535 2891 longer chain of inactivity where the worm simply rested on the
rlm@535 2892 floor without moving. It is preferred over a "1-2-3" chain (which
rlm@535 2893 also describes inactivity) because it is longer. The main ideas
rlm@535 2894 again:
rlm@535 2895
rlm@535 2896 - Imagined \Phi-space paths are synthesized by looping and mixing
rlm@535 2897 previous experiences.
rlm@535 2898
rlm@535 2899 - Longer experience paths (less edits) are preferred.
rlm@535 2900
rlm@535 2901 - The present is more important than the past --- more recent
rlm@535 2902 events take precedence in interpretation.
rlm@533 2903
rlm@450 2904 This algorithm has three advantages:
rlm@450 2905
rlm@450 2906 1. It's simple
rlm@450 2907
rlm@451 2908 3. It's very fast -- retrieving possible interpretations takes
rlm@451 2909 constant time. Tracing through chains of interpretations takes
rlm@451 2910 time proportional to the average number of experiences in a
rlm@451 2911 proprioceptive bin. Redundant experiences in \Phi-space can be
rlm@451 2912 merged to save computation.
rlm@450 2913
rlm@450 2914 2. It protects from wrong interpretations of transient ambiguous
rlm@451 2915 proprioceptive data. For example, if the worm is flat for just
rlm@517 2916 an instant, this flatness will not be interpreted as implying
rlm@517 2917 that the worm has its muscles relaxed, since the flatness is
rlm@450 2918 part of a longer chain which includes a distinct pattern of
rlm@451 2919 muscle activation. Markov chains or other memoryless statistical
rlm@451 2920 models that operate on individual frames may very well make this
rlm@451 2921 mistake.
rlm@450 2922
rlm@450 2923 #+caption: Program to convert an experience vector into a
rlm@450 2924 #+caption: proprioceptively binned lookup function.
rlm@450 2925 #+name: bin
rlm@452 2926 #+begin_listing clojure
rlm@450 2927 #+begin_src clojure
rlm@449 2928 (defn bin [digits]
rlm@449 2929 (fn [angles]
rlm@449 2930 (->> angles
rlm@449 2931 (flatten)
rlm@449 2932 (map (juxt #(Math/sin %) #(Math/cos %)))
rlm@449 2933 (flatten)
rlm@449 2934 (mapv #(Math/round (* % (Math/pow 10 (dec digits))))))))
rlm@449 2935
rlm@449 2936 (defn gen-phi-scan
rlm@450 2937 "Nearest-neighbors with binning. Only returns a result if
rlm@517 2938 the proprioceptive data is within 10% of a previously recorded
rlm@450 2939 result in all dimensions."
rlm@450 2940 [phi-space]
rlm@449 2941 (let [bin-keys (map bin [3 2 1])
rlm@449 2942 bin-maps
rlm@449 2943 (map (fn [bin-key]
rlm@449 2944 (group-by
rlm@449 2945 (comp bin-key :proprioception phi-space)
rlm@449 2946 (range (count phi-space)))) bin-keys)
rlm@449 2947 lookups (map (fn [bin-key bin-map]
rlm@450 2948 (fn [proprio] (bin-map (bin-key proprio))))
rlm@450 2949 bin-keys bin-maps)]
rlm@449 2950 (fn lookup [proprio-data]
rlm@449 2951 (set (some #(% proprio-data) lookups)))))
rlm@450 2952 #+end_src
rlm@450 2953 #+end_listing
rlm@449 2954
rlm@451 2955 #+caption: =longest-thread= finds the longest path of consecutive
rlm@536 2956 #+caption: past experiences to explain proprioceptive worm data from
rlm@520 2957 #+caption: previous data. Here, the film strip represents the
rlm@531 2958 #+caption: creature's previous experience. Sort sequences of
rlm@520 2959 #+caption: memories are spliced together to match the
rlm@520 2960 #+caption: proprioceptive data. Their carry the other senses
rlm@520 2961 #+caption: along with them.
rlm@451 2962 #+name: phi-space-history-scan
rlm@451 2963 #+ATTR_LaTeX: :width 10cm
rlm@520 2964 [[./images/film-of-imagination.png]]
rlm@451 2965
rlm@451 2966 =longest-thread= infers sensory data by stitching together pieces
rlm@451 2967 from previous experience. It prefers longer chains of previous
rlm@451 2968 experience to shorter ones. For example, during training the worm
rlm@451 2969 might rest on the ground for one second before it performs its
rlm@517 2970 exercises. If during recognition the worm rests on the ground for
rlm@517 2971 five seconds, =longest-thread= will accommodate this five second
rlm@451 2972 rest period by looping the one second rest chain five times.
rlm@451 2973
rlm@517 2974 =longest-thread= takes time proportional to the average number of
rlm@451 2975 entries in a proprioceptive bin, because for each element in the
rlm@517 2976 starting bin it performs a series of set lookups in the preceding
rlm@536 2977 bins. If the total history is limited, then this takes time
rlm@548 2978 proportional to a only a constant multiple of the number of entries
rlm@536 2979 in the starting bin. This analysis also applies, even if the action
rlm@536 2980 requires multiple longest chains -- it's still the average number
rlm@536 2981 of entries in a proprioceptive bin times the desired chain length.
rlm@536 2982 Because =longest-thread= is so efficient and simple, I can
rlm@536 2983 interpret worm-actions in real time.
rlm@449 2984
rlm@450 2985 #+caption: Program to calculate empathy by tracing though \Phi-space
rlm@450 2986 #+caption: and finding the longest (ie. most coherent) interpretation
rlm@450 2987 #+caption: of the data.
rlm@450 2988 #+name: longest-thread
rlm@452 2989 #+begin_listing clojure
rlm@450 2990 #+begin_src clojure
rlm@449 2991 (defn longest-thread
rlm@449 2992 "Find the longest thread from phi-index-sets. The index sets should
rlm@449 2993 be ordered from most recent to least recent."
rlm@449 2994 [phi-index-sets]
rlm@449 2995 (loop [result '()
rlm@449 2996 [thread-bases & remaining :as phi-index-sets] phi-index-sets]
rlm@449 2997 (if (empty? phi-index-sets)
rlm@449 2998 (vec result)
rlm@449 2999 (let [threads
rlm@449 3000 (for [thread-base thread-bases]
rlm@449 3001 (loop [thread (list thread-base)
rlm@449 3002 remaining remaining]
rlm@449 3003 (let [next-index (dec (first thread))]
rlm@449 3004 (cond (empty? remaining) thread
rlm@449 3005 (contains? (first remaining) next-index)
rlm@449 3006 (recur
rlm@449 3007 (cons next-index thread) (rest remaining))
rlm@449 3008 :else thread))))
rlm@449 3009 longest-thread
rlm@449 3010 (reduce (fn [thread-a thread-b]
rlm@449 3011 (if (> (count thread-a) (count thread-b))
rlm@449 3012 thread-a thread-b))
rlm@449 3013 '(nil)
rlm@449 3014 threads)]
rlm@449 3015 (recur (concat longest-thread result)
rlm@449 3016 (drop (count longest-thread) phi-index-sets))))))
rlm@450 3017 #+end_src
rlm@450 3018 #+end_listing
rlm@450 3019
rlm@451 3020 There is one final piece, which is to replace missing sensory data
rlm@451 3021 with a best-guess estimate. While I could fill in missing data by
rlm@451 3022 using a gradient over the closest known sensory data points,
rlm@451 3023 averages can be misleading. It is certainly possible to create an
rlm@451 3024 impossible sensory state by averaging two possible sensory states.
rlm@536 3025 For example, consider moving your hand in an arc over your head. If
rlm@536 3026 for some reason you only have the initial and final positions of
rlm@536 3027 this movement in your \Phi-space, averaging them together will
rlm@536 3028 produce the proprioceptive sensation of having your hand /inside/
rlm@536 3029 your head, which is physically impossible to ever experience
rlm@536 3030 (barring motor adaption illusions). Therefore I simply replicate
rlm@536 3031 the most recent sensory experience to fill in the gaps.
rlm@449 3032
rlm@449 3033 #+caption: Fill in blanks in sensory experience by replicating the most
rlm@449 3034 #+caption: recent experience.
rlm@449 3035 #+name: infer-nils
rlm@452 3036 #+begin_listing clojure
rlm@449 3037 #+begin_src clojure
rlm@449 3038 (defn infer-nils
rlm@449 3039 "Replace nils with the next available non-nil element in the
rlm@449 3040 sequence, or barring that, 0."
rlm@449 3041 [s]
rlm@449 3042 (loop [i (dec (count s))
rlm@449 3043 v (transient s)]
rlm@449 3044 (if (zero? i) (persistent! v)
rlm@449 3045 (if-let [cur (v i)]
rlm@449 3046 (if (get v (dec i) 0)
rlm@449 3047 (recur (dec i) v)
rlm@449 3048 (recur (dec i) (assoc! v (dec i) cur)))
rlm@449 3049 (recur i (assoc! v i 0))))))
rlm@449 3050 #+end_src
rlm@449 3051 #+end_listing
rlm@435 3052
rlm@541 3053 ** =EMPATH= recognizes actions efficiently
rlm@451 3054
rlm@451 3055 To use =EMPATH= with the worm, I first need to gather a set of
rlm@451 3056 experiences from the worm that includes the actions I want to
rlm@452 3057 recognize. The =generate-phi-space= program (listing
rlm@451 3058 \ref{generate-phi-space} runs the worm through a series of
rlm@545 3059 exercises and gathers those experiences into a vector. The
rlm@451 3060 =do-all-the-things= program is a routine expressed in a simple
rlm@452 3061 muscle contraction script language for automated worm control. It
rlm@452 3062 causes the worm to rest, curl, and wiggle over about 700 frames
rlm@452 3063 (approx. 11 seconds).
rlm@425 3064
rlm@451 3065 #+caption: Program to gather the worm's experiences into a vector for
rlm@451 3066 #+caption: further processing. The =motor-control-program= line uses
rlm@451 3067 #+caption: a motor control script that causes the worm to execute a series
rlm@517 3068 #+caption: of ``exercises'' that include all the action predicates.
rlm@451 3069 #+name: generate-phi-space
rlm@452 3070 #+begin_listing clojure
rlm@451 3071 #+begin_src clojure
rlm@451 3072 (def do-all-the-things
rlm@451 3073 (concat
rlm@451 3074 curl-script
rlm@451 3075 [[300 :d-ex 40]
rlm@451 3076 [320 :d-ex 0]]
rlm@451 3077 (shift-script 280 (take 16 wiggle-script))))
rlm@451 3078
rlm@451 3079 (defn generate-phi-space []
rlm@451 3080 (let [experiences (atom [])]
rlm@451 3081 (run-world
rlm@451 3082 (apply-map
rlm@451 3083 worm-world
rlm@451 3084 (merge
rlm@451 3085 (worm-world-defaults)
rlm@451 3086 {:end-frame 700
rlm@451 3087 :motor-control
rlm@451 3088 (motor-control-program worm-muscle-labels do-all-the-things)
rlm@451 3089 :experiences experiences})))
rlm@451 3090 @experiences))
rlm@451 3091 #+end_src
rlm@451 3092 #+end_listing
rlm@451 3093
rlm@536 3094 #+caption: Use =longest-thread= and a \Phi-space generated from a short
rlm@451 3095 #+caption: exercise routine to interpret actions during free play.
rlm@451 3096 #+name: empathy-debug
rlm@452 3097 #+begin_listing clojure
rlm@451 3098 #+begin_src clojure
rlm@451 3099 (defn init []
rlm@451 3100 (def phi-space (generate-phi-space))
rlm@451 3101 (def phi-scan (gen-phi-scan phi-space)))
rlm@451 3102
rlm@451 3103 (defn empathy-demonstration []
rlm@451 3104 (let [proprio (atom ())]
rlm@451 3105 (fn
rlm@451 3106 [experiences text]
rlm@451 3107 (let [phi-indices (phi-scan (:proprioception (peek experiences)))]
rlm@451 3108 (swap! proprio (partial cons phi-indices))
rlm@451 3109 (let [exp-thread (longest-thread (take 300 @proprio))
rlm@451 3110 empathy (mapv phi-space (infer-nils exp-thread))]
rlm@451 3111 (println-repl (vector:last-n exp-thread 22))
rlm@451 3112 (cond
rlm@451 3113 (grand-circle? empathy) (.setText text "Grand Circle")
rlm@451 3114 (curled? empathy) (.setText text "Curled")
rlm@451 3115 (wiggling? empathy) (.setText text "Wiggling")
rlm@451 3116 (resting? empathy) (.setText text "Resting")
rlm@536 3117 :else (.setText text "Unknown")))))))
rlm@451 3118
rlm@451 3119 (defn empathy-experiment [record]
rlm@451 3120 (.start (worm-world :experience-watch (debug-experience-phi)
rlm@451 3121 :record record :worm worm*)))
rlm@451 3122 #+end_src
rlm@451 3123 #+end_listing
rlm@536 3124
rlm@536 3125 These programs create a test for the empathy system. First, the
rlm@536 3126 worm's \Phi-space is generated from a simple motor script. Then the
rlm@536 3127 worm is re-created in an environment almost exactly identical to
rlm@536 3128 the testing environment for the action-predicates, with one major
rlm@536 3129 difference : the only sensory information available to the system
rlm@536 3130 is proprioception. From just the proprioception data and
rlm@548 3131 \Phi-space, =longest-thread= synthesizes a complete record the last
rlm@536 3132 300 sensory experiences of the worm. These synthesized experiences
rlm@536 3133 are fed directly into the action predicates =grand-circle?=,
rlm@553 3134 =curled?=, =wiggling?=, and =resting?= and their outputs are
rlm@553 3135 printed to the screen at each frame.
rlm@451 3136
rlm@451 3137 The result of running =empathy-experiment= is that the system is
rlm@451 3138 generally able to interpret worm actions using the action-predicates
rlm@451 3139 on simulated sensory data just as well as with actual data. Figure
rlm@451 3140 \ref{empathy-debug-image} was generated using =empathy-experiment=:
rlm@451 3141
rlm@451 3142 #+caption: From only proprioceptive data, =EMPATH= was able to infer
rlm@451 3143 #+caption: the complete sensory experience and classify four poses
rlm@517 3144 #+caption: (The last panel shows a composite image of /wiggling/,
rlm@451 3145 #+caption: a dynamic pose.)
rlm@451 3146 #+name: empathy-debug-image
rlm@451 3147 #+ATTR_LaTeX: :width 10cm :placement [H]
rlm@451 3148 [[./images/empathy-1.png]]
rlm@451 3149
rlm@451 3150 One way to measure the performance of =EMPATH= is to compare the
rlm@517 3151 suitability of the imagined sense experience to trigger the same
rlm@451 3152 action predicates as the real sensory experience.
rlm@451 3153
rlm@451 3154 #+caption: Determine how closely empathy approximates actual
rlm@451 3155 #+caption: sensory data.
rlm@451 3156 #+name: test-empathy-accuracy
rlm@452 3157 #+begin_listing clojure
rlm@451 3158 #+begin_src clojure
rlm@451 3159 (def worm-action-label
rlm@451 3160 (juxt grand-circle? curled? wiggling?))
rlm@451 3161
rlm@451 3162 (defn compare-empathy-with-baseline [matches]
rlm@451 3163 (let [proprio (atom ())]
rlm@451 3164 (fn
rlm@451 3165 [experiences text]
rlm@451 3166 (let [phi-indices (phi-scan (:proprioception (peek experiences)))]
rlm@451 3167 (swap! proprio (partial cons phi-indices))
rlm@451 3168 (let [exp-thread (longest-thread (take 300 @proprio))
rlm@451 3169 empathy (mapv phi-space (infer-nils exp-thread))
rlm@451 3170 experience-matches-empathy
rlm@451 3171 (= (worm-action-label experiences)
rlm@451 3172 (worm-action-label empathy))]
rlm@451 3173 (println-repl experience-matches-empathy)
rlm@451 3174 (swap! matches #(conj % experience-matches-empathy)))))))
rlm@451 3175
rlm@451 3176 (defn accuracy [v]
rlm@451 3177 (float (/ (count (filter true? v)) (count v))))
rlm@451 3178
rlm@451 3179 (defn test-empathy-accuracy []
rlm@451 3180 (let [res (atom [])]
rlm@451 3181 (run-world
rlm@451 3182 (worm-world :experience-watch
rlm@451 3183 (compare-empathy-with-baseline res)
rlm@451 3184 :worm worm*))
rlm@451 3185 (accuracy @res)))
rlm@451 3186 #+end_src
rlm@451 3187 #+end_listing
rlm@451 3188
rlm@451 3189 Running =test-empathy-accuracy= using the very short exercise
rlm@555 3190 program =do-all-the-things= defined in listing
rlm@555 3191 \ref{generate-phi-space}, and then doing a similar pattern of
rlm@555 3192 activity using manual control of the worm, yields an accuracy of
rlm@555 3193 around 73%. This is based on very limited worm experience, and
rlm@555 3194 almost all errors are due to the worm's \Phi-space being too
rlm@555 3195 incomplete to properly interpret common poses. By manually training
rlm@555 3196 the worm for longer using =init-interactive= defined in listing
rlm@555 3197 \ref{manual-phi-space}, the accuracy dramatically improves:
rlm@451 3198
rlm@451 3199 #+caption: Program to generate \Phi-space using manual training.
rlm@451 3200 #+name: manual-phi-space
rlm@451 3201 #+begin_listing clojure
rlm@451 3202 #+begin_src clojure
rlm@451 3203 (defn init-interactive []
rlm@451 3204 (def phi-space
rlm@451 3205 (let [experiences (atom [])]
rlm@451 3206 (run-world
rlm@451 3207 (apply-map
rlm@451 3208 worm-world
rlm@451 3209 (merge
rlm@451 3210 (worm-world-defaults)
rlm@451 3211 {:experiences experiences})))
rlm@451 3212 @experiences))
rlm@451 3213 (def phi-scan (gen-phi-scan phi-space)))
rlm@451 3214 #+end_src
rlm@451 3215 #+end_listing
rlm@451 3216
rlm@555 3217 =init-interactive= allows me to take direct control of the worm's
rlm@555 3218 muscles and run it through each characteristic movement I care
rlm@555 3219 about. After about 1 minute of manual training, I was able to
rlm@555 3220 achieve 95% accuracy on manual testing of the worm using
rlm@549 3221 =test-empathy-accuracy=. The majority of disagreements are near the
rlm@555 3222 transition boundaries from one type of action to another. During
rlm@549 3223 these transitions the exact label for the action is often unclear,
rlm@549 3224 and disagreement between empathy and experience is practically
rlm@549 3225 irrelevant. Thus, the system's effective identification accuracy is
rlm@549 3226 even higher than 95%. When I watch this system myself, I generally
rlm@549 3227 see no errors in action identification compared to my own judgment
rlm@549 3228 of what the worm is doing.
rlm@536 3229
rlm@541 3230 ** Digression: Learning touch sensor layout through free play
rlm@514 3231
rlm@551 3232 In the previous chapter I showed how to compute actions in terms of
rlm@539 3233 body-centered predicates, but some of those predicates relied on
rlm@539 3234 the average touch activation of pre-defined regions of the worm's
rlm@539 3235 skin. What if, instead of receiving touch pre-grouped into the six
rlm@555 3236 faces of each worm segment, the true partitioning of the worm's
rlm@555 3237 skin was unknown? This is more similar to how a nerve fiber bundle
rlm@555 3238 might be arranged inside an animal. While two fibers that are close
rlm@555 3239 in a nerve bundle /might/ correspond to two touch sensors that are
rlm@555 3240 close together on the skin, the process of taking a complicated
rlm@555 3241 surface and forcing it into essentially a 2D circle requires that
rlm@555 3242 some regions of skin that are close together in the animal end up
rlm@555 3243 far apart in the nerve bundle.
rlm@452 3244
rlm@555 3245 In this chapter I show how to automatically learn the
rlm@555 3246 skin-partitioning of a worm segment by free exploration. As the
rlm@555 3247 worm rolls around on the floor, large sections of its surface get
rlm@555 3248 activated. If the worm has stopped moving, then whatever region of
rlm@555 3249 skin that is touching the floor is probably an important region,
rlm@555 3250 and should be recorded. The code I provide relies on the worm
rlm@555 3251 segment having flat faces, but still demonstrates a primitive kind
rlm@555 3252 of multi-sensory bootstrapping that I find appealing.
rlm@555 3253
rlm@452 3254 #+caption: Program to detect whether the worm is in a resting state
rlm@452 3255 #+caption: with one face touching the floor.
rlm@452 3256 #+name: pure-touch
rlm@452 3257 #+begin_listing clojure
rlm@452 3258 #+begin_src clojure
rlm@452 3259 (def full-contact [(float 0.0) (float 0.1)])
rlm@452 3260
rlm@452 3261 (defn pure-touch?
rlm@452 3262 "This is worm specific code to determine if a large region of touch
rlm@452 3263 sensors is either all on or all off."
rlm@452 3264 [[coords touch :as touch-data]]
rlm@452 3265 (= (set (map first touch)) (set full-contact)))
rlm@452 3266 #+end_src
rlm@452 3267 #+end_listing
rlm@452 3268
rlm@452 3269 After collecting these important regions, there will many nearly
rlm@517 3270 similar touch regions. While for some purposes the subtle
rlm@452 3271 differences between these regions will be important, for my
rlm@517 3272 purposes I collapse them into mostly non-overlapping sets using
rlm@517 3273 =remove-similar= in listing \ref{remove-similar}
rlm@517 3274
rlm@517 3275 #+caption: Program to take a list of sets of points and ``collapse them''
rlm@517 3276 #+caption: so that the remaining sets in the list are significantly
rlm@452 3277 #+caption: different from each other. Prefer smaller sets to larger ones.
rlm@517 3278 #+name: remove-similar
rlm@452 3279 #+begin_listing clojure
rlm@452 3280 #+begin_src clojure
rlm@452 3281 (defn remove-similar
rlm@452 3282 [coll]
rlm@452 3283 (loop [result () coll (sort-by (comp - count) coll)]
rlm@452 3284 (if (empty? coll) result
rlm@452 3285 (let [[x & xs] coll
rlm@452 3286 c (count x)]
rlm@452 3287 (if (some
rlm@452 3288 (fn [other-set]
rlm@452 3289 (let [oc (count other-set)]
rlm@452 3290 (< (- (count (union other-set x)) c) (* oc 0.1))))
rlm@452 3291 xs)
rlm@452 3292 (recur result xs)
rlm@452 3293 (recur (cons x result) xs))))))
rlm@452 3294 #+end_src
rlm@452 3295 #+end_listing
rlm@452 3296
rlm@452 3297 Actually running this simulation is easy given =CORTEX='s facilities.
rlm@452 3298
rlm@452 3299 #+caption: Collect experiences while the worm moves around. Filter the touch
rlm@517 3300 #+caption: sensations by stable ones, collapse similar ones together,
rlm@452 3301 #+caption: and report the regions learned.
rlm@452 3302 #+name: learn-touch
rlm@452 3303 #+begin_listing clojure
rlm@452 3304 #+begin_src clojure
rlm@452 3305 (defn learn-touch-regions []
rlm@452 3306 (let [experiences (atom [])
rlm@452 3307 world (apply-map
rlm@452 3308 worm-world
rlm@452 3309 (assoc (worm-segment-defaults)
rlm@452 3310 :experiences experiences))]
rlm@452 3311 (run-world world)
rlm@452 3312 (->>
rlm@452 3313 @experiences
rlm@452 3314 (drop 175)
rlm@452 3315 ;; access the single segment's touch data
rlm@452 3316 (map (comp first :touch))
rlm@452 3317 ;; only deal with "pure" touch data to determine surfaces
rlm@452 3318 (filter pure-touch?)
rlm@452 3319 ;; associate coordinates with touch values
rlm@452 3320 (map (partial apply zipmap))
rlm@452 3321 ;; select those regions where contact is being made
rlm@452 3322 (map (partial group-by second))
rlm@452 3323 (map #(get % full-contact))
rlm@452 3324 (map (partial map first))
rlm@452 3325 ;; remove redundant/subset regions
rlm@452 3326 (map set)
rlm@452 3327 remove-similar)))
rlm@452 3328
rlm@452 3329 (defn learn-and-view-touch-regions []
rlm@452 3330 (map view-touch-region
rlm@452 3331 (learn-touch-regions)))
rlm@452 3332 #+end_src
rlm@452 3333 #+end_listing
rlm@452 3334
rlm@517 3335 The only thing remaining to define is the particular motion the worm
rlm@452 3336 must take. I accomplish this with a simple motor control program.
rlm@452 3337
rlm@452 3338 #+caption: Motor control program for making the worm roll on the ground.
rlm@452 3339 #+caption: This could also be replaced with random motion.
rlm@452 3340 #+name: worm-roll
rlm@452 3341 #+begin_listing clojure
rlm@452 3342 #+begin_src clojure
rlm@452 3343 (defn touch-kinesthetics []
rlm@452 3344 [[170 :lift-1 40]
rlm@452 3345 [190 :lift-1 19]
rlm@452 3346 [206 :lift-1 0]
rlm@452 3347
rlm@452 3348 [400 :lift-2 40]
rlm@452 3349 [410 :lift-2 0]
rlm@452 3350
rlm@452 3351 [570 :lift-2 40]
rlm@452 3352 [590 :lift-2 21]
rlm@452 3353 [606 :lift-2 0]
rlm@452 3354
rlm@452 3355 [800 :lift-1 30]
rlm@452 3356 [809 :lift-1 0]
rlm@452 3357
rlm@452 3358 [900 :roll-2 40]
rlm@452 3359 [905 :roll-2 20]
rlm@452 3360 [910 :roll-2 0]
rlm@452 3361
rlm@452 3362 [1000 :roll-2 40]
rlm@452 3363 [1005 :roll-2 20]
rlm@452 3364 [1010 :roll-2 0]
rlm@452 3365
rlm@452 3366 [1100 :roll-2 40]
rlm@452 3367 [1105 :roll-2 20]
rlm@452 3368 [1110 :roll-2 0]
rlm@452 3369 ])
rlm@452 3370 #+end_src
rlm@452 3371 #+end_listing
rlm@452 3372
rlm@452 3373
rlm@452 3374 #+caption: The small worm rolls around on the floor, driven
rlm@452 3375 #+caption: by the motor control program in listing \ref{worm-roll}.
rlm@452 3376 #+name: worm-roll
rlm@452 3377 #+ATTR_LaTeX: :width 12cm
rlm@452 3378 [[./images/worm-roll.png]]
rlm@452 3379
rlm@452 3380 #+caption: After completing its adventures, the worm now knows
rlm@548 3381 #+caption: how its touch sensors are arranged along its skin. Each of these six rectangles are touch sensory patterns that were
rlm@548 3382 #+caption: deemed important by
rlm@537 3383 #+caption: =learn-touch-regions=. Each white square in the rectangles
rlm@537 3384 #+caption: above is a cluster of ``related" touch nodes as determined
rlm@548 3385 #+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 3386 #+name: worm-touch-map
rlm@452 3387 #+ATTR_LaTeX: :width 12cm
rlm@452 3388 [[./images/touch-learn.png]]
rlm@452 3389
rlm@452 3390 While simple, =learn-touch-regions= exploits regularities in both
rlm@452 3391 the worm's physiology and the worm's environment to correctly
rlm@452 3392 deduce that the worm has six sides. Note that =learn-touch-regions=
rlm@452 3393 would work just as well even if the worm's touch sense data were
rlm@517 3394 completely scrambled. The cross shape is just for convenience. This
rlm@452 3395 example justifies the use of pre-defined touch regions in =EMPATH=.
rlm@452 3396
rlm@548 3397 ** Recognizing an object using embodied representation
rlm@548 3398
rlm@548 3399 At the beginning of the thesis, I suggested that we might recognize
rlm@548 3400 the chair in Figure \ref{hidden-chair} by imagining ourselves in
rlm@548 3401 the position of the man and realizing that he must be sitting on
rlm@548 3402 something in order to maintain that position. Here, I present a
rlm@548 3403 brief elaboration on how to this might be done.
rlm@548 3404
rlm@548 3405 First, I need the feeling of leaning or resting /on/ some other
rlm@548 3406 object that is not the floor. This feeling is easy to describe
rlm@548 3407 using an embodied representation.
rlm@548 3408
rlm@548 3409 #+caption: Program describing the sense of leaning or resting on something.
rlm@548 3410 #+caption: This involves a relaxed posture, the feeling of touching something,
rlm@548 3411 #+caption: and a period of stability where the worm does not move.
rlm@548 3412 #+name: draped
rlm@548 3413 #+begin_listing clojure
rlm@548 3414 #+begin_src clojure
rlm@548 3415 (defn draped?
rlm@548 3416 "Is the worm:
rlm@548 3417 -- not flat (the floor is not a 'chair')
rlm@548 3418 -- supported (not using its muscles to hold its position)
rlm@548 3419 -- stable (not changing its position)
rlm@548 3420 -- touching something (must register contact)"
rlm@548 3421 [experiences]
rlm@548 3422 (let [b2-hash (bin 2)
rlm@548 3423 touch (:touch (peek experiences))
rlm@548 3424 total-contact
rlm@548 3425 (reduce
rlm@548 3426 +
rlm@548 3427 (map #(contact all-touch-coordinates %)
rlm@548 3428 (rest touch)))]
rlm@548 3429 (println total-contact)
rlm@548 3430 (and (not (resting? experiences))
rlm@548 3431 (every?
rlm@548 3432 zero?
rlm@548 3433 (-> experiences
rlm@548 3434 (vector:last-n 25)
rlm@548 3435 (#(map :muscle %))
rlm@548 3436 (flatten)))
rlm@548 3437 (-> experiences
rlm@548 3438 (vector:last-n 20)
rlm@548 3439 (#(map (comp b2-hash flatten :proprioception) %))
rlm@548 3440 (set)
rlm@548 3441 (count) (= 1))
rlm@548 3442 (< 0.03 total-contact))))
rlm@548 3443 #+end_src
rlm@548 3444 #+end_listing
rlm@548 3445
rlm@553 3446 #+caption: The =draped?= predicate detects the presence of the cube
rlm@553 3447 #+caption: whenever the worm interacts with it. The details of the
rlm@553 3448 #+caption: cube are irrelevant; only the way it influences the
rlm@553 3449 #+caption: worm's body matters. The ``unknown'' label on the fifth
rlm@553 3450 #+caption: frame is due to the fact that the worm is not
rlm@556 3451 #+caption: stationary. =draped?= will only declare that the worm
rlm@553 3452 #+caption: is draped if it has been still for a while.
rlm@548 3453 #+name: draped-video
rlm@548 3454 #+ATTR_LaTeX: :width 13cm
rlm@548 3455 [[./images/draped.png]]
rlm@548 3456
rlm@548 3457 Though this is a simple example, using the =draped?= predicate to
rlm@550 3458 detect a cube has interesting advantages. The =draped?= predicate
rlm@548 3459 describes the cube not in terms of properties that the cube has,
rlm@548 3460 but instead in terms of how the worm interacts with it physically.
rlm@548 3461 This means that the cube can still be detected even if it is not
rlm@548 3462 visible, as long as its influence on the worm's body is visible.
rlm@548 3463
rlm@548 3464 This system will also see the virtual cube created by a
rlm@548 3465 ``mimeworm", which uses its muscles in a very controlled way to
rlm@548 3466 mimic the appearance of leaning on a cube. The system will
rlm@548 3467 anticipate that there is an actual invisible cube that provides
rlm@548 3468 support!
rlm@548 3469
rlm@548 3470 #+caption: Can you see the thing that this person is leaning on?
rlm@553 3471 #+caption: What properties does it have, other than how it makes
rlm@553 3472 #+caption: the man's elbow and shoulder feel? I wonder if people
rlm@553 3473 #+caption: who can actually maintain this pose easily still see the
rlm@553 3474 #+caption: support?
rlm@548 3475 #+name: mime
rlm@548 3476 #+ATTR_LaTeX: :width 6cm
rlm@548 3477 [[./images/pablo-the-mime.png]]
rlm@548 3478
rlm@548 3479 This makes me wonder about the psychology of actual mimes. Suppose
rlm@548 3480 for a moment that people have something analogous to \Phi-space and
rlm@548 3481 that one of the ways that they find objects in a scene is by their
rlm@548 3482 relation to other people's bodies. Suppose that a person watches a
rlm@548 3483 person miming an invisible wall. For a person with no experience
rlm@548 3484 with miming, their \Phi-space will only have entries that describe
rlm@548 3485 the scene with the sensation of their hands touching a wall. This
rlm@548 3486 sensation of touch will create a strong impression of a wall, even
rlm@548 3487 though the wall would have to be invisible. A person with
rlm@548 3488 experience in miming however, will have entries in their \Phi-space
rlm@548 3489 that describe the wall-miming position without a sense of touch. It
rlm@548 3490 will not seem to such as person that an invisible wall is present,
rlm@548 3491 but merely that the mime is holding out their hands in a special
rlm@548 3492 way. Thus, the theory that humans use something like \Phi-space
rlm@548 3493 weakly predicts that learning how to mime should break the power of
rlm@548 3494 miming illusions. Most optical illusions still work no matter how
rlm@548 3495 much you know about them, so this proposal would be quite
rlm@548 3496 interesting to test, as it predicts a non-standard result!
rlm@548 3497
rlm@548 3498
rlm@548 3499 #+BEGIN_LaTeX
rlm@548 3500 \clearpage
rlm@548 3501 #+END_LaTeX
rlm@548 3502
rlm@558 3503 * Contributions
rlm@548 3504
rlm@548 3505 The big idea behind this thesis is a new way to represent and
rlm@548 3506 recognize physical actions, which I call /empathic representation/.
rlm@548 3507 Actions are represented as predicates which have access to the
rlm@548 3508 totality of a creature's sensory abilities. To recognize the
rlm@548 3509 physical actions of another creature similar to yourself, you
rlm@548 3510 imagine what they would feel by examining the position of their body
rlm@548 3511 and relating it to your own previous experience.
rlm@454 3512
rlm@548 3513 Empathic representation of physical actions is robust and general.
rlm@548 3514 Because the representation is body-centered, it avoids baking in a
rlm@548 3515 particular viewpoint like you might get from learning from example
rlm@548 3516 videos. Because empathic representation relies on all of a
rlm@542 3517 creature's senses, it can describe exactly what an action /feels
rlm@542 3518 like/ without getting caught up in irrelevant details such as visual
rlm@542 3519 appearance. I think it is important that a correct description of
rlm@548 3520 jumping (for example) should not include irrelevant details such as
rlm@548 3521 the color of a person's clothes or skin; empathic representation can
rlm@548 3522 get right to the heart of what jumping is by describing it in terms
rlm@548 3523 of touch, muscle contractions, and a brief feeling of
rlm@548 3524 weightlessness. Empathic representation is very low-level in that it
rlm@548 3525 describes actions using concrete sensory data with little
rlm@548 3526 abstraction, but it has the generality of much more abstract
rlm@548 3527 representations!
rlm@542 3528
rlm@542 3529 Another important contribution of this thesis is the development of
rlm@542 3530 the =CORTEX= system, a complete environment for creating simulated
rlm@542 3531 creatures. You have seen how to implement five senses: touch,
rlm@542 3532 proprioception, hearing, vision, and muscle tension. You have seen
rlm@562 3533 how to create new creatures using Blender, a 3D modeling tool.
rlm@542 3534
rlm@461 3535 As a minor digression, you also saw how I used =CORTEX= to enable a
rlm@461 3536 tiny worm to discover the topology of its skin simply by rolling on
rlm@548 3537 the ground. You also saw how to detect objects using only embodied
rlm@548 3538 predicates.
rlm@548 3539
rlm@548 3540 In conclusion, for this thesis I:
rlm@548 3541
rlm@548 3542 - Developed the idea of embodied representation, which describes
rlm@548 3543 actions that a creature can do in terms of first-person sensory
rlm@548 3544 data.
rlm@548 3545
rlm@548 3546 - Developed a method of empathic action recognition which uses
rlm@548 3547 previous embodied experience and embodied representation of
rlm@548 3548 actions to greatly constrain the possible interpretations of an
rlm@548 3549 action.
rlm@548 3550
rlm@548 3551 - Created =EMPATH=, a program which uses empathic action
rlm@548 3552 recognition to recognize physical actions in a simple model
rlm@548 3553 involving segmented worm-like creatures.
rlm@548 3554
rlm@548 3555 - Created =CORTEX=, a comprehensive platform for embodied AI
rlm@548 3556 experiments. It is the base on which =EMPATH= is built.
rlm@517 3557
rlm@488 3558 #+BEGIN_LaTeX
rlm@548 3559 \clearpage
rlm@488 3560 \appendix
rlm@488 3561 #+END_LaTeX
rlm@517 3562
rlm@558 3563 * Appendix: =CORTEX= User Guide
rlm@488 3564
rlm@488 3565 Those who write a thesis should endeavor to make their code not only
rlm@517 3566 accessible, but actually usable, as a way to pay back the community
rlm@488 3567 that made the thesis possible in the first place. This thesis would
rlm@488 3568 not be possible without Free Software such as jMonkeyEngine3,
rlm@556 3569 Blender, clojure, =emacs=, =ffmpeg=, and many other tools. That is
rlm@556 3570 why I have included this user guide, in the hope that someone else
rlm@556 3571 might find =CORTEX= useful.
rlm@488 3572
rlm@488 3573 ** Obtaining =CORTEX=
rlm@488 3574
rlm@488 3575 You can get cortex from its mercurial repository at
rlm@488 3576 http://hg.bortreb.com/cortex. You may also download =CORTEX=
rlm@488 3577 releases at http://aurellem.org/cortex/releases/. As a condition of
rlm@488 3578 making this thesis, I have also provided Professor Winston the
rlm@488 3579 =CORTEX= source, and he knows how to run the demos and get started.
rlm@488 3580 You may also email me at =cortex@aurellem.org= and I may help where
rlm@488 3581 I can.
rlm@488 3582
rlm@488 3583 ** Running =CORTEX=
rlm@488 3584
rlm@488 3585 =CORTEX= comes with README and INSTALL files that will guide you
rlm@488 3586 through installation and running the test suite. In particular you
rlm@488 3587 should look at test =cortex.test= which contains test suites that
rlm@488 3588 run through all senses and multiple creatures.
rlm@488 3589
rlm@488 3590 ** Creating creatures
rlm@488 3591
rlm@488 3592 Creatures are created using /Blender/, a free 3D modeling program.
rlm@488 3593 You will need Blender version 2.6 when using the =CORTEX= included
rlm@517 3594 in this thesis. You create a =CORTEX= creature in a similar manner
rlm@488 3595 to modeling anything in Blender, except that you also create
rlm@488 3596 several trees of empty nodes which define the creature's senses.
rlm@488 3597
rlm@488 3598 *** Mass
rlm@488 3599
rlm@488 3600 To give an object mass in =CORTEX=, add a ``mass'' metadata label
rlm@488 3601 to the object with the mass in jMonkeyEngine units. Note that
rlm@488 3602 setting the mass to 0 causes the object to be immovable.
rlm@488 3603
rlm@488 3604 *** Joints
rlm@488 3605
rlm@488 3606 Joints are created by creating an empty node named =joints= and
rlm@488 3607 then creating any number of empty child nodes to represent your
rlm@488 3608 creature's joints. The joint will automatically connect the
rlm@488 3609 closest two physical objects. It will help to set the empty node's
rlm@488 3610 display mode to ``Arrows'' so that you can clearly see the
rlm@488 3611 direction of the axes.
rlm@488 3612
rlm@488 3613 Joint nodes should have the following metadata under the ``joint''
rlm@488 3614 label:
rlm@488 3615
rlm@488 3616 #+BEGIN_SRC clojure
rlm@540 3617 ;; ONE of the following, under the label "joint":
rlm@488 3618 {:type :point}
rlm@488 3619
rlm@488 3620 ;; OR
rlm@488 3621
rlm@488 3622 {:type :hinge
rlm@488 3623 :limit [<limit-low> <limit-high>]
rlm@488 3624 :axis (Vector3f. <x> <y> <z>)}
rlm@488 3625 ;;(:axis defaults to (Vector3f. 1 0 0) if not provided for hinge joints)
rlm@488 3626
rlm@488 3627 ;; OR
rlm@488 3628
rlm@488 3629 {:type :cone
rlm@488 3630 :limit-xz <lim-xz>
rlm@488 3631 :limit-xy <lim-xy>
rlm@562 3632 :twist <lim-twist>} ;(use XZY rotation mode in Blender!)
rlm@488 3633 #+END_SRC
rlm@488 3634
rlm@488 3635 *** Eyes
rlm@488 3636
rlm@488 3637 Eyes are created by creating an empty node named =eyes= and then
rlm@488 3638 creating any number of empty child nodes to represent your
rlm@488 3639 creature's eyes.
rlm@488 3640
rlm@488 3641 Eye nodes should have the following metadata under the ``eye''
rlm@488 3642 label:
rlm@488 3643
rlm@488 3644 #+BEGIN_SRC clojure
rlm@488 3645 {:red <red-retina-definition>
rlm@488 3646 :blue <blue-retina-definition>
rlm@488 3647 :green <green-retina-definition>
rlm@488 3648 :all <all-retina-definition>
rlm@488 3649 (<0xrrggbb> <custom-retina-image>)...
rlm@488 3650 }
rlm@488 3651 #+END_SRC
rlm@488 3652
rlm@488 3653 Any of the color channels may be omitted. You may also include
rlm@488 3654 your own color selectors, and in fact :red is equivalent to
rlm@488 3655 0xFF0000 and so forth. The eye will be placed at the same position
rlm@488 3656 as the empty node and will bind to the neatest physical object.
rlm@488 3657 The eye will point outward from the X-axis of the node, and ``up''
rlm@488 3658 will be in the direction of the X-axis of the node. It will help
rlm@488 3659 to set the empty node's display mode to ``Arrows'' so that you can
rlm@488 3660 clearly see the direction of the axes.
rlm@488 3661
rlm@517 3662 Each retina file should contain white pixels wherever you want to be
rlm@488 3663 sensitive to your chosen color. If you want the entire field of
rlm@488 3664 view, specify :all of 0xFFFFFF and a retinal map that is entirely
rlm@488 3665 white.
rlm@488 3666
rlm@488 3667 Here is a sample retinal map:
rlm@488 3668
rlm@488 3669 #+caption: An example retinal profile image. White pixels are
rlm@488 3670 #+caption: photo-sensitive elements. The distribution of white
rlm@488 3671 #+caption: pixels is denser in the middle and falls off at the
rlm@488 3672 #+caption: edges and is inspired by the human retina.
rlm@488 3673 #+name: retina
rlm@488 3674 #+ATTR_LaTeX: :width 7cm :placement [H]
rlm@488 3675 [[./images/retina-small.png]]
rlm@488 3676
rlm@488 3677 *** Hearing
rlm@488 3678
rlm@488 3679 Ears are created by creating an empty node named =ears= and then
rlm@488 3680 creating any number of empty child nodes to represent your
rlm@488 3681 creature's ears.
rlm@488 3682
rlm@488 3683 Ear nodes do not require any metadata.
rlm@488 3684
rlm@488 3685 The ear will bind to and follow the closest physical node.
rlm@488 3686
rlm@488 3687 *** Touch
rlm@488 3688
rlm@488 3689 Touch is handled similarly to mass. To make a particular object
rlm@488 3690 touch sensitive, add metadata of the following form under the
rlm@488 3691 object's ``touch'' metadata field:
rlm@488 3692
rlm@488 3693 #+BEGIN_EXAMPLE
rlm@488 3694 <touch-UV-map-file-name>
rlm@488 3695 #+END_EXAMPLE
rlm@488 3696
rlm@488 3697 You may also include an optional ``scale'' metadata number to
rlm@517 3698 specify the length of the touch feelers. The default is $0.1$,
rlm@488 3699 and this is generally sufficient.
rlm@488 3700
rlm@488 3701 The touch UV should contain white pixels for each touch sensor.
rlm@488 3702
rlm@488 3703 Here is an example touch-uv map that approximates a human finger,
rlm@488 3704 and its corresponding model.
rlm@488 3705
rlm@488 3706 #+caption: This is the tactile-sensor-profile for the upper segment
rlm@488 3707 #+caption: of a fingertip. It defines regions of high touch sensitivity
rlm@488 3708 #+caption: (where there are many white pixels) and regions of low
rlm@488 3709 #+caption: sensitivity (where white pixels are sparse).
rlm@488 3710 #+name: guide-fingertip-UV
rlm@488 3711 #+ATTR_LaTeX: :width 9cm :placement [H]
rlm@488 3712 [[./images/finger-UV.png]]
rlm@488 3713
rlm@488 3714 #+caption: The fingertip UV-image form above applied to a simple
rlm@488 3715 #+caption: model of a fingertip.
rlm@488 3716 #+name: guide-fingertip
rlm@488 3717 #+ATTR_LaTeX: :width 9cm :placement [H]
rlm@553 3718 [[./images/finger-1.png]]
rlm@488 3719
rlm@517 3720 *** Proprioception
rlm@488 3721
rlm@488 3722 Proprioception is tied to each joint node -- nothing special must
rlm@562 3723 be done in a Blender model to enable proprioception other than
rlm@488 3724 creating joint nodes.
rlm@488 3725
rlm@488 3726 *** Muscles
rlm@488 3727
rlm@488 3728 Muscles are created by creating an empty node named =muscles= and
rlm@488 3729 then creating any number of empty child nodes to represent your
rlm@488 3730 creature's muscles.
rlm@488 3731
rlm@488 3732
rlm@488 3733 Muscle nodes should have the following metadata under the
rlm@488 3734 ``muscle'' label:
rlm@488 3735
rlm@488 3736 #+BEGIN_EXAMPLE
rlm@488 3737 <muscle-profile-file-name>
rlm@488 3738 #+END_EXAMPLE
rlm@488 3739
rlm@488 3740 Muscles should also have a ``strength'' metadata entry describing
rlm@488 3741 the muscle's total strength at full activation.
rlm@488 3742
rlm@488 3743 Muscle profiles are simple images that contain the relative amount
rlm@488 3744 of muscle power in each simulated alpha motor neuron. The width of
rlm@488 3745 the image is the total size of the motor pool, and the redness of
rlm@488 3746 each neuron is the relative power of that motor pool.
rlm@488 3747
rlm@488 3748 While the profile image can have any dimensions, only the first
rlm@488 3749 line of pixels is used to define the muscle. Here is a sample
rlm@488 3750 muscle profile image that defines a human-like muscle.
rlm@488 3751
rlm@488 3752 #+caption: A muscle profile image that describes the strengths
rlm@488 3753 #+caption: of each motor neuron in a muscle. White is weakest
rlm@488 3754 #+caption: and dark red is strongest. This particular pattern
rlm@488 3755 #+caption: has weaker motor neurons at the beginning, just
rlm@488 3756 #+caption: like human muscle.
rlm@488 3757 #+name: muscle-recruit
rlm@488 3758 #+ATTR_LaTeX: :width 7cm :placement [H]
rlm@488 3759 [[./images/basic-muscle.png]]
rlm@488 3760
rlm@488 3761 Muscles twist the nearest physical object about the muscle node's
rlm@488 3762 Z-axis. I recommend using the ``Single Arrow'' display mode for
rlm@488 3763 muscles and using the right hand rule to determine which way the
rlm@488 3764 muscle will twist. To make a segment that can twist in multiple
rlm@488 3765 directions, create multiple, differently aligned muscles.
rlm@488 3766
rlm@488 3767 ** =CORTEX= API
rlm@488 3768
rlm@488 3769 These are the some functions exposed by =CORTEX= for creating
rlm@488 3770 worlds and simulating creatures. These are in addition to
rlm@488 3771 jMonkeyEngine3's extensive library, which is documented elsewhere.
rlm@488 3772
rlm@488 3773 *** Simulation
rlm@488 3774 - =(world root-node key-map setup-fn update-fn)= :: create
rlm@488 3775 a simulation.
rlm@488 3776 - /root-node/ :: a =com.jme3.scene.Node= object which
rlm@488 3777 contains all of the objects that should be in the
rlm@488 3778 simulation.
rlm@488 3779
rlm@488 3780 - /key-map/ :: a map from strings describing keys to
rlm@488 3781 functions that should be executed whenever that key is
rlm@488 3782 pressed. the functions should take a SimpleApplication
rlm@488 3783 object and a boolean value. The SimpleApplication is the
rlm@488 3784 current simulation that is running, and the boolean is true
rlm@488 3785 if the key is being pressed, and false if it is being
rlm@488 3786 released. As an example,
rlm@488 3787 #+BEGIN_SRC clojure
rlm@488 3788 {"key-j" (fn [game value] (if value (println "key j pressed")))}
rlm@488 3789 #+END_SRC
rlm@488 3790 is a valid key-map which will cause the simulation to print
rlm@488 3791 a message whenever the 'j' key on the keyboard is pressed.
rlm@488 3792
rlm@488 3793 - /setup-fn/ :: a function that takes a =SimpleApplication=
rlm@488 3794 object. It is called once when initializing the simulation.
rlm@488 3795 Use it to create things like lights, change the gravity,
rlm@488 3796 initialize debug nodes, etc.
rlm@488 3797
rlm@488 3798 - /update-fn/ :: this function takes a =SimpleApplication=
rlm@488 3799 object and a float and is called every frame of the
rlm@488 3800 simulation. The float tells how many seconds is has been
rlm@488 3801 since the last frame was rendered, according to whatever
rlm@488 3802 clock jme is currently using. The default is to use IsoTimer
rlm@488 3803 which will result in this value always being the same.
rlm@488 3804
rlm@488 3805 - =(position-camera world position rotation)= :: set the position
rlm@488 3806 of the simulation's main camera.
rlm@488 3807
rlm@488 3808 - =(enable-debug world)= :: turn on debug wireframes for each
rlm@488 3809 simulated object.
rlm@488 3810
rlm@488 3811 - =(set-gravity world gravity)= :: set the gravity of a running
rlm@488 3812 simulation.
rlm@488 3813
rlm@488 3814 - =(box length width height & {options})= :: create a box in the
rlm@488 3815 simulation. Options is a hash map specifying texture, mass,
rlm@488 3816 etc. Possible options are =:name=, =:color=, =:mass=,
rlm@488 3817 =:friction=, =:texture=, =:material=, =:position=,
rlm@488 3818 =:rotation=, =:shape=, and =:physical?=.
rlm@488 3819
rlm@488 3820 - =(sphere radius & {options})= :: create a sphere in the simulation.
rlm@488 3821 Options are the same as in =box=.
rlm@488 3822
rlm@488 3823 - =(load-blender-model file-name)= :: create a node structure
rlm@562 3824 representing the model described in a Blender file.
rlm@488 3825
rlm@488 3826 - =(light-up-everything world)= :: distribute a standard compliment
rlm@517 3827 of lights throughout the simulation. Should be adequate for most
rlm@488 3828 purposes.
rlm@488 3829
rlm@517 3830 - =(node-seq node)= :: return a recursive list of the node's
rlm@488 3831 children.
rlm@488 3832
rlm@488 3833 - =(nodify name children)= :: construct a node given a node-name and
rlm@488 3834 desired children.
rlm@488 3835
rlm@488 3836 - =(add-element world element)= :: add an object to a running world
rlm@488 3837 simulation.
rlm@488 3838
rlm@488 3839 - =(set-accuracy world accuracy)= :: change the accuracy of the
rlm@488 3840 world's physics simulator.
rlm@488 3841
rlm@488 3842 - =(asset-manager)= :: get an /AssetManager/, a jMonkeyEngine
rlm@488 3843 construct that is useful for loading textures and is required
rlm@488 3844 for smooth interaction with jMonkeyEngine library functions.
rlm@488 3845
rlm@540 3846 - =(load-bullet)= :: unpack native libraries and initialize the
rlm@540 3847 bullet physics subsystem. This function is required before
rlm@540 3848 other world building functions are called.
rlm@488 3849
rlm@488 3850 *** Creature Manipulation / Import
rlm@488 3851
rlm@488 3852 - =(body! creature)= :: give the creature a physical body.
rlm@488 3853
rlm@488 3854 - =(vision! creature)= :: give the creature a sense of vision.
rlm@488 3855 Returns a list of functions which will each, when called
rlm@488 3856 during a simulation, return the vision data for the channel of
rlm@488 3857 one of the eyes. The functions are ordered depending on the
rlm@488 3858 alphabetical order of the names of the eye nodes in the
rlm@562 3859 Blender file. The data returned by the functions is a vector
rlm@488 3860 containing the eye's /topology/, a vector of coordinates, and
rlm@488 3861 the eye's /data/, a vector of RGB values filtered by the eye's
rlm@488 3862 sensitivity.
rlm@488 3863
rlm@488 3864 - =(hearing! creature)= :: give the creature a sense of hearing.
rlm@488 3865 Returns a list of functions, one for each ear, that when
rlm@488 3866 called will return a frame's worth of hearing data for that
rlm@488 3867 ear. The functions are ordered depending on the alphabetical
rlm@562 3868 order of the names of the ear nodes in the Blender file. The
rlm@540 3869 data returned by the functions is an array of PCM (pulse code
rlm@540 3870 modulated) wav data.
rlm@488 3871
rlm@488 3872 - =(touch! creature)= :: give the creature a sense of touch. Returns
rlm@488 3873 a single function that must be called with the /root node/ of
rlm@488 3874 the world, and which will return a vector of /touch-data/
rlm@488 3875 one entry for each touch sensitive component, each entry of
rlm@488 3876 which contains a /topology/ that specifies the distribution of
rlm@488 3877 touch sensors, and the /data/, which is a vector of
rlm@488 3878 =[activation, length]= pairs for each touch hair.
rlm@488 3879
rlm@488 3880 - =(proprioception! creature)= :: give the creature the sense of
rlm@488 3881 proprioception. Returns a list of functions, one for each
rlm@488 3882 joint, that when called during a running simulation will
rlm@517 3883 report the =[heading, pitch, roll]= of the joint.
rlm@488 3884
rlm@488 3885 - =(movement! creature)= :: give the creature the power of movement.
rlm@488 3886 Creates a list of functions, one for each muscle, that when
rlm@488 3887 called with an integer, will set the recruitment of that
rlm@488 3888 muscle to that integer, and will report the current power
rlm@488 3889 being exerted by the muscle. Order of muscles is determined by
rlm@488 3890 the alphabetical sort order of the names of the muscle nodes.
rlm@488 3891
rlm@488 3892 *** Visualization/Debug
rlm@488 3893
rlm@488 3894 - =(view-vision)= :: create a function that when called with a list
rlm@488 3895 of visual data returned from the functions made by =vision!=,
rlm@488 3896 will display that visual data on the screen.
rlm@488 3897
rlm@488 3898 - =(view-hearing)= :: same as =view-vision= but for hearing.
rlm@488 3899
rlm@488 3900 - =(view-touch)= :: same as =view-vision= but for touch.
rlm@488 3901
rlm@488 3902 - =(view-proprioception)= :: same as =view-vision= but for
rlm@488 3903 proprioception.
rlm@488 3904
rlm@540 3905 - =(view-movement)= :: same as =view-vision= but for muscles.
rlm@488 3906
rlm@488 3907 - =(view anything)= :: =view= is a polymorphic function that allows
rlm@488 3908 you to inspect almost anything you could reasonably expect to
rlm@488 3909 be able to ``see'' in =CORTEX=.
rlm@488 3910
rlm@488 3911 - =(text anything)= :: =text= is a polymorphic function that allows
rlm@488 3912 you to convert practically anything into a text string.
rlm@488 3913
rlm@488 3914 - =(println-repl anything)= :: print messages to clojure's repl
rlm@488 3915 instead of the simulation's terminal window.
rlm@488 3916
rlm@488 3917 - =(mega-import-jme3)= :: for experimenting at the REPL. This
rlm@488 3918 function will import all jMonkeyEngine3 classes for immediate
rlm@488 3919 use.
rlm@488 3920
rlm@517 3921 - =(display-dilated-time world timer)= :: Shows the time as it is
rlm@488 3922 flowing in the simulation on a HUD display.