IEEE Robotics & Automation Magazine - September 2018 - 67

compiler supports the widely used Robot Operating System
(ROS) Universal Robot Definition Format (URDF). Additionally, because of the difficulty of writing URDF by hand,
we also introduce a new, compact scene file syntax (see Figure 3).
Compiling scenes offers several performance and administrative advantages:
● Compiled scenes are fast to load, because the OS directly
maps into memory the included mesh data (via mmap),
eliminating runtime parsing and processing.
● Compiled scenes reduce memory use compared to runtime parsing when multiple OS processes operate on
the same scene, because the memory-mapped scene
graphs in different processes share physical memory.
● Compiled scenes are easy to distribute to other machines,
e.g., a cluster, which may lack scene sources, utilities, or
support libraries. Only the executable or shared library is
required to load the compiled scene, reducing potential
runtime dependencies.
● Compiled scenes avoid the need to include large parsing
libraries, e.g., an XML parser, in real-time processes and
reduce the dynamic allocations necessary to load scenes.
● Multiple compiled scenes can be flexibly composed both
statically ahead of time and dynamically at runtime,
improving overall scene construction efficiency when
some portions of the scene are fixed and others changing.
For example, we can precompile the scene for the robot,
which remains constant based on the robot's mechanical
design. However, the locations of objects on a table may
change frequently, so we can compose the precompiled
robot scene with the separate or dynamically generated
scene for these objects.
The scene graph data structure and scene compiler provide the necessary geometric support for TMP and plan
execution.
TMP
Our TMP implementation follows the overall structure of
Figure 2, based on the algorithm of [1] and [2]. In the task
layer, we use an incremental, constraint-based task planner. In

Scene
File
COLLADA,
STL, etc.
URDF

Scene File
Parser
Blender

OBJ

Wavefront
Parser
URDF
Parser

the motion layer, we include a variety of sampling-based
motion planners through the Open Motion Planning Library
[9]. The key to achieving generality in our planner is the
selection of abstractions. Our task languages can model arbitrary, finite-state task domains, and our scene graphs can
model arbitrary, rigid-body robots and environments.
We relate the task and motion domains by defining a
domain semantics (see Figure 4). The domain semantics
define the conversion of the scene graph to a task state and
define functions to refine high-level task actions by computing the corresponding motion plans. Concretely, the domain
semantics in TMKit are functions written in Python or Common Lisp. Figure 5 includes an example of a task state computed from a scene graph, and Figure 3 contains an example
of a refinement function in the domain semantics for pickand-place manipulation. The same semantics definition may
be used across multiple scenes or problem instances. Changes to the task domain, e.g., new actions, do require updating
the domain semantics but require no changes to the planner
itself. By abstracting TM interaction to these separate
domain semantics definitions, our planning system generalizes across domains.
Output and Execution
The immediate output of our system is a TM plan describing
the sequence of task actions and corresponding motion plans.
We benchmark the performance and scalability of the overall
approach in [1] and [2]. Figure 3 shows a fragment of such a
plan for the table-setting example, represented using a plaintext, line-based file format that is human-readable and can be
efficiently parsed. Each line indicates either a task action, the
joints moved during a motion plan, a waypoint in a motion
plan, or a reparenting operation, e.g., picking or placing an
object by changing an edge in the scene graph from the table
to the hand or vice versa. The resulting file defines the interleaving of task actions and motion plans.
Then, we execute the TM plan by interpolating the given
motion plans and performing the indicated reparentings to
grasp and release objects. There are numerous methods to

C Code
Generator

GCC

scene.so

∪

aarxc

POV-Ray
Generator

POV-Ray

scene.png

Robot

Compile

Load

Baxter

14.0 s

0.33 ms

UR10

11.7 s

0.17 ms

Jaco

15.6 s

0.20 ms

(b)

(a)

Figure 6. The scene graph compiler aarxc. (a) A compiler block diagram. The compiler includes parsers for scene files, Wavefront
Object (OBJ) meshes, and ROS URDF files. It uses the Blender 3-D modeling program to convert a variety of meshes to the
conventional Wavefront OBJ format. The compiler translates the loaded scene graph to optimized C code for later fast loading and realtime execution. It can also translate scene graphs to input for the POV-Ray raytracer for high-quality visualization. (b) Compile times-
including mesh processing, code generation, and C compilation-and load times for common robots, using Blender 2.77 and GCC 4.9.2
on an Intel Core i7-4790. Example plans and planning times are presented in Figure 3 and Figure 8 [1], [2].

september 2018

IEEE ROBOTICS & AUTOMATION MAGAZINE

IEEE Robotics & Automation Magazine - September 2018

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - September 2018