wiki:VirtualHumanLoader

Specifying the configuration of your Virtual Human

Every application has different requirements for the Virtual Human. Gesture repertoire, body graphics, using speech engine or not using speech engine, which voice, etcetera. We have made an XML format to specify in detail what should and should not be initialized for your virtual human.

main idea: you can specify Embodiments and Engines. Each Embodiment offers an interface to display expressions and behaviors: skeleton control for animation, MPEG4 control for a face embodiment,motor control for a robot embodiment, etcetera. An Engine specializes in displaying specific behavior types (e.g., head and hand gestures) on one or more of the Embodiments. In an Asap Virtual Human Loader file you specify the various embodiments and engines, and connect the embodiments to the right engines.

General structure

A loader he file consists of 3 sections, that must appear in that order.

<AsapVirtualHuman>

   Subsection: Specification of parsing, scheduling, pipes, ports, and adapters

   Subsection: Specification of Embodiments, Engines, and other loaders

   Subsection: Re-routing of BML to Engines (overriding defaults)

</AsapVirtualHuman>

Parsing, scheduling, pipes, ports, and adapters

In this section, you first configure the parser, then the scheduler, and then you add any other pipes and adapters.

Example of first parser and scheduler configuration:

    <BMLParser>
      <BMLAttributeExtension class="asap.bml.ext.bmlb.BMLBBMLBehaviorAttributes"/>
      <BMLAttributeExtension class="asap.bml.ext.bmlt.BMLTBMLBehaviorAttributes"/>
    </BMLParser>
	
    <BMLScheduler>
      <SchedulingHandler class="asap.realizer.scheduler.BMLBandTSchedulingHandler" schedulingStrategy="asap.realizer.scheduler.SortedSmartBodySchedulingStrategy"/>
    </BMLScheduler>

Log pipe

  • Module: in Asap core
  • Allows you to log all incoming requests and outgoing feedback messages to an Slf4j channel.
  • Configurable: the logger name for requests and for feedback.
    <PipeLoader id="..." loader="asap.realizerembodiments.LogPipeLoader">
            <Log requestlog="..."  feedbacklog="..."/> 
    </PipeLoader>
    

ActiveMQPipe

  • Module: org=HMI name=!HMIActiveMQPipe
  • Connects your realizer seamlessly to the !ActiveMQ network, through the asap.bml.request and asap.bml.feedback channels.
  • No configuration settings; connects to !ActiveMQ on localhost, default port.
    <PipeLoader id="..." loader="hmi.activemq.bmlpipe.ActiveMQPipeLoader"/>
    

TCPIP Server

  • Module: in Asap core
  • Connects your realizer to TCPIP socket for receiving BML requests; feedback is sent out through the feedback socket.
  • Configuration settings: the ports used for feedback and requests.
    <ServerAdapter requestport="..." feedbackport="..."/>
    

Using Multiple pipes

Multiple pipes may be used in sequence, e.g.

    <PipeLoader id="pipe" loader="asap.ipaacaadapters.loader.IpaacaToBMLRealizerAdapterLoader"/>
    <PipeLoader id="visualizerpipe" loader="asap.bmlflowvisualizer.loader.AsapBMLFlowVisualizerPortLoader"/>

This has the effect of hooking up Ipaaca middleware BML sending to a visualization pipe that visualizes bml progress which is in turn connected to AsapRealizer.

Loaders

GUI for BML Realizer

  • Module: in Asap core
  • A GUI for sending BML to the Virtual Human, for inspecting warnings and progress feedback, etcetera. This embodiment is also used by various engines to add more controls, such as a dropdown for changing voices.
  • Configuration settings; .
    <Loader id="..." loader="asap.realizerembodiments.JFrameEmbodiment">
        <BmlUI demoscriptresources="..."/> <!-- Add a input box for directly sending BML to the VH. if demoscriptresources is not set, use the default set of demo scripts -->
        <FeedbackUI/> <!-- Add 3 tab panels for inspecting the feedback returned by the Realizer -->
        <ServerUI/> <!-- Add a GUI for starting and stopping the TCPIP server adapter. Requires a TCPIP server to be configured earlier. -->
    </Loader>
    

Rerouting of BML to Engines

At the end of the file, you can override all default routings. Each type of Engine generally claims a default set of behaviors, but sometimes you want to send, e.g., face behaviors to a AsapPictureEngine instead of to the AsapFaceEngine, etcetera.

Each route consists of a fully qualified classname of the behavior, and the id of the engine that should be responsible for that behavior type.

<BMLRouting>
    <Route behaviourclass="saiba.bml.core.FaceBehaviour" engineid="..."/>
</BMLRouting>

User contributions

This page still requires a lot more documentation. Please ask specific questions below.

Discussion

Your feedback is welcome.