Version 30 (modified by welberge, 5 years ago) (diff)


Interpreting Feedback

AsapRealizer uses   BML 1.0 feedback to indicate progress on the behavior it is executing and predictions on the timing of to be executed behavior. Special attributes are introduced in BMLA to specify (predicted) POSIX timestamps of behavior (=number of milliseconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970).

Parsing feedback


Parsing can be done with  OpenBMLParser, or using the BMLAFeedbackParser (in Asap/AsapBML) that wraps it (providing easier access to BMLA specific attributes):

BMLFeedback fb = BMLAFeedbackParser.parseFeedback(feedbackString);
if (fb instanceof BMLABlockProgressFeedback)
    BMLABlockProgressFeedback bpf = (BMLABlockProgressFeedback) fb;
else if(fb instanceof BMLASyncPointProgressFeedback)
    BMLASyncPointProgressFeedback spf = (BMLASyncPointProgressFeedback) fb;
else if(fb instanceof BMLAPredictionFeedback)
     BMLAPredictionFeedback pf = (BMLAPredictionFeedback) fb;
else if(fb instanceof BMLWarningFeedback)
     BMLWarningFeedback wf = (BMLWarningFeedback) fb;

Interpreting timestamps, POSIX time, local time and global time

Timestamps for feedback messages are given in local time (since the start of the BML block), global time (seconds since the start of AsapRealizer), and POSIX time. The timestamps in local and global time are more precise (obtained with System.nanoTime()), but are not not related to any other notion of system or wall-clock time. There is also no garantee that these times match timestamps obtained through System.nanoTime() called from another JVM. Timestamps in POSIX-time are less precise (obtained with System.currentTimeMillis()). The resolution of the POSIX timestamps is OS-dependent, in Windows it is 10ms, in other OSes it's typically better. Local time and global times are given in seconds, POSIX time in milliseconds.

Interpreting the status of a BML block

  • IN_PREP: start state
  • PENDING: scheduling finished, preplanned
  • LURKING: scheduling finished
  • IN_EXEC: block is running
  • SUBSIDING: all behavior in the block are done or in the relax state
  • DONE: successfully executed
  • REVOKED: interrupted before running
  • INTERRUPTING: the block is currently gracefully being interrupted (TO IMPLEMENT)
  • INTERRUPTED: interrupted during execution, all gracefull interruptions finished
  • FAILED: AsapRealizer could not realize this block

Feedback obtained from a single BML block, in order

  1. Before scheduling: predictionFeedback for block, takes into account composition/appendAfter attributes, provides block start prediction.
  2. After scheduling: predictionFeedback for block+behaviors provides block start and end time prediction, internal timing of behaviors in the block, timing based on e.g. rest posture.
  3. At block start: blockProgress, block start feedback
  4. Directly after block start (unless the block ends instantly (the block is empty or all containing behavior fails to be scheduled)): predictionFeedback for block+behaviors, provides block start and end time prediction, internal timing of behaviors in the block, timing based on e.g. start posture.
  5. During execution:
    1. syncPointProgress feedback for syncpoints of all behaviors in the block
    2. predictionFeedback whenever timing predictions change (e.g. through anticipator time changes, bottom-up adaptations, parametervaluechanges that affect timing) [TO IMPLEMENT!]
  6. At end: blockProgress, block end feedback