annotate thesis/cortex.org @ 511:07c3feb32df3

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