Troubleshooting

See also

Support
If this page doesn’t help

Wire-schema is not Known

See also

IDL-related Commandline Options
Commandline Options for loading Data Type Definitions

Problem

I tried to record events with wire schema rst.kinematics.JointAngles using bag-record. This does not seem to work - at least bag-record reports:

WARNING:
    Payload serialization format for wire schema :|.rst.kinematics.JointAngles|
    is not known. Channel format will only describe outer event serialization;
    not inner payload serialization.

Solution

bag-record should record all events despite the warning but the resulting log file will not contain information about the types of the recorded event payloads and will thus not be self-describing. bag-record usually tries to make all recorded log files self-describing. That is the reason for the warning.

For recording and replaying events, bag-record and bag-play do not require this additional information. Did you try to replay the recorded data?

If you want to avoid the warning and/or store the type information in the log file to make it self-describing, you can add commandline options to load the respective data type definitions:

bag-record -IPATH-TO-RST/proto/stable/ -lPATH-TO-RST/proto/stable/rst/kinematics/JointAngles.proto

Missing Spread Library

Problem

Calling any of the bag-* tools, the following happens:

$ bag-cat my-log-file.tide
WARNING:
  Failed to load Spread library: Unable to load any of the alternatives:
  ("libspread-without-signal-blocking.so" "libspread.so" "libspread.so.2"
   "libspread.so.2.0" "libspread.so.1").
  Did you set LD_LIBRARY_PATH?
  Spread transport will now be disabled.
[execution continues, but Spread transport does not work]

Solution

Place one of the mentioned Spread libraries (typically libspread.so.2.0) on the system library search path or set LD_LIBRARY_PATH appropriately.

Illegal Spread

Problem

We would like also to know how to record with bag-record. We have tried:

$ bag-record -o test.tide                         \
             'spread://remote:4803/nao/vision/0'  \
             'spread://remote:4803/nao/vision/1'  \
             'spread://remote:4803/nao/audio/all'

with no success: ILLEGAL SPREAD.

Solution

Most likely, there is no Spread daemon running on host remote (or not on port 4803).

bag-record Exits during Recording

Problem

When recording with bag-record using the Spread transport, bag-record exist after a short amount of time with an error like:

Error receiving: CONNECTION-CLOSED

Solution

This problem occurs because more data is sent to bag-record than it can receive and/or write to disk. Although this problem should be much less common in recent versions (>= 0.9) of bag-record, it can still happen with large volumes of data or problematic Spread configurations.

There several options to mitigate the problem:

  1. When the data which should be recorded is sent to several scopes, separate bag-record processes can be created for these scopes - maybe even on different machines.
  2. The socket-based transport is sometimes faster than the Spread transport.
  3. An unmodified Spread daemon sometimes delivers events slower than necessary, which can lead to the problem described above. We provide a patched Spread Debian package in the CoR-Lab package repository.

Empty Log-files after Recording

Problem

After recording with bag-record, there are no events in my log files (according to bag-info).

Solution

We suggest the following procedure to investigate the problem:

digraph empty_file {
fontname=Arial
fontsize=11
node [fontsize=11,fontname=Arial]
edge [fontsize=11,fontname=Arial]

info [label="bag-info broken.tide",shape=box]
info_decision [label="displays events?",shape="diamond"]
noevents [label="no events (according to bag-info)",shape=box]
filesize [label="check filesize",shape=diamond]
forgetit [label="forget it; nothing has been recorded",shape=box]
forgetit_decision [label="want to fix it?",shape=diamond]
info_reindex [label="bag-info --on-error continue",shape=box]
info_reindex_decision [label="displays events?",shape=diamond]
merge_reindex [label="bag-merge --on-error continue -o repaired.tide broken.tide",shape=box]
contactus [label="contact us",shape=box]

info -> info_decision
info_decision -> noevents [label="no"]
info_decision -> contactus [label="yes (what is the problem, then?)"]
noevents -> filesize
filesize -> forgetit [label="<= 22 byte"]
forgetit -> forgetit_decision
forgetit_decision -> contactus [label="yes"]
forgetit_decision -> forgetit [label="no"]
filesize -> info_reindex [label="> 22 byte"]
info_reindex -> info_reindex_decision
info_reindex_decision -> contactus [label="still no events"]
info_reindex_decision -> merge_reindex [label="yes, displays events"]
}

Adjust Timestamps during Replay

See also

Adjusting Timestamps during Replay
Description in the bag-play manual page

Problem

Is it possible to have bag-play use a playback strategy like recorded-timing but to adapt the create timestamps of the data to correspond to the current system time and not the recorded original creation time?

Solution

This can be achieved by calling bag-play like this:

$ bag-play --replay-strategy 'recorded-timing :adjustments ((:create :now))' ...

Replay without Gaps

Problem

Replaying a log file with “gaps” (i.e. periods of time during which no events were sent) for testing purposes is inconvenient and takes longer than necessary because of the gaps. Is it possible to skip over these gaps while otherwise retaining the original timing?

Solution

This can be achieved by calling bag-play like this:

$ bag-play --replay-strategy 'recorded-timing :max-delay .1' ...

:max-delay .1 limits the maximum delay between adjacent events to 100 milliseconds without changing the playback timing for shorter delays.