Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732016-06-08T12:17:41ZOpen Source Collaboration Platform
Redmine Tasks #2559 (New): Scope renaminghttps://code.cor-lab.de/issues/25592016-06-08T12:17:41ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deTasks #2479 (New): Bag as bus server crashes in case client is closedhttps://code.cor-lab.de/issues/24792015-12-11T12:37:58ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>I have seen this several times in case I terminate a bus client:<br /><pre>
jwienke@cinnabar ~ [1]> /media/local_data/jwienke/sensor-fusion/bin/rsbag play --loop=t /vol/toolkit/tutorial-sensor-fusion-with-rsb/data/tutorial_datafusion.tide socket:
2015-12-09T18:02:17.672763+01:00 40.42 % 326 [ 0, 808]
Error processing entry #<EVENT /kinect2/ #(10 6 10 2 8 ...) (850) E3E058D2> from
#<REPLAY-BAG-CONNECTION (2) {1015A7E2F3}> during replay according to strategy #<RECORDED-TIMING [0, *[ {1015A74F03}>.
Caused by:
> Couldn't write to #<SB-SYS:FD-STREAM for "socket 127.0.0.1:55555, peer: 127.0.0.1:53256" {100CB814F3}>: Broken pipe
<WARN> [13:36:24] [Worker for #<BUS-CONNECTION open #(127 0 0 1):53256>] rsb.transport.socket bus-connection.lisp (%make-error-policy bus-connection-error-policy) -
When #<BUS-CONNECTION closing: :RECEIVE ADDRESS?:PORT?> executed error
policy, error closing connection:
Couldn't write to #<SB-SYS:FD-STREAM
for "socket 127.0.0.1:55555, peer: 127.0.0.1:53256"
{100CB814F3}>:
Broken pipe
jwienke@cinnabar ~ [1]> /media/local_data/jwienke/sensor-fusion/bin/rsbag play --version
/media/local_data/jwienke/sensor-fusion/bin/rsbag play version 0.13.42-g6f687b5
SBCL version 1.2.15
RSB version 0.13.89-gac01044
RSBAG version 0.13.41-gda486e6
RSBAG-TIDELOG version 0.13.41-gda486e6
</pre></p> Enhancement #2376 (New): Allow to deduplicate participants in introspection exporthttps://code.cor-lab.de/issues/23762015-08-31T11:34:37ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>When using <code>bag introspect</code> it would be nice if one could specify something like primary keys for the different elements in the introspection tree so that e.g. participants of the same type and scope, but different IDs could be deduplicated.</p> Tasks #2216 (New): Consider using git subtrees instead of submoduleshttps://code.cor-lab.de/issues/22162015-04-02T12:51:44ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>We can all agree, that our submodule setup sucks.</p>
<p>We discussed and rejected gitslave: <a class="external" href="https://projects.cor-lab.org/projects/corcse/wiki/GitSlave">https://projects.cor-lab.org/projects/corcse/wiki/GitSlave</a></p>
<p>Nicolas Hafner suggests git subtrees, which I (jmoringe) did not know about. We should probably look into that possibility.<br /><a class="external" href="http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/">http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/</a></p> Feature #2138 (New): Allow constructing scopes from a list of component strings (potentially sing...https://code.cor-lab.de/issues/21382014-12-17T13:13:52ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Java</li>
<li>C++</li>
<li>Python</li>
</ul> Feature #1870 (New): Allow (optional) parallel method callshttps://code.cor-lab.de/issues/18702014-05-08T12:36:06ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Johannes will commit patches containing a short-term workaround for C++ and Java</li>
</ul> Feature #1769 (New): Store start and end timestamp of recordinghttps://code.cor-lab.de/issues/17692014-02-14T11:41:13ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>As opposed to timestamps of first/last recorded events.</p> Bug #1665 (New): Support common installations (to simlify cross compiliation)https://code.cor-lab.de/issues/16652013-12-03T10:46:15ZS. Herbrechtsmeiersherbrec@cit-ec.uni-bielefeld.de
<p>The current rsb projects contains many functions which are only needed for the local deployment. As most of this functions are not optional they don't allow a common installation and make the installation unusable in cross compiler environments. The main reason is that cmake and pkg-config files are not relocatable because they contain full paths from the installation or build time.</p>
<p>In common installation the following should not be needed: <br />- Add the release version to project and library names (example: rsb0.9 in rst-converters0.9.pc)<br />- Decode the so version in pkg-config files (example: librsb.so.0.9 in rsb.pc)<br />- Use so files instead of <del>l{libname} in pkg-config files (example: ${libdir}/librsb.so.0.9 in rsb.pc)<br /></del> Set full paths in cmake files (example: RSC_DIR in RSBConfig.cmake)</p>
<p>Additionally cmake files should save the dependency projects and use FIND_PACKAGE to detect the paths.</p> Tasks #1365 (New): Participant-wise configurationhttps://code.cor-lab.de/issues/13652013-01-28T16:38:23ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>With the availability of plugins it becomes more important to configure individual participants, as plugins can easily result in converter ambiguities. The following was the solution discussed today:</p>
<ol>
<li>Give names to participants (client have to do this when creating participants) to identify them in the configuration mechanism
<ul>
<li>Names will be logical names</li>
<li>TODO:
<ul>
<li>Are names always required? -> Otherwise it might be impossible to configure some participants if the programmer forgot to give names to them</li>
<li>Do names need to be unique (at least within each process) or are they treated like tags?
<ul>
<li>If they are not unique, it might be that the developer chose a grouping of participants with a single tag, which turns out to be an over-generalization and recompiling will be necessary to disambiguate them</li>
<li>If the are unique, composing multiple RSB libraries in a single binary might lead to name clashes. Some kind of scoping will be necessary.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>Add participant-wise configuration options based on separate files
<ul>
<li>A new section will be added to the options, where each key corresponds to the aforementioned participant names/tag and the values dispatch to separate configuration files using the usual configuration syntax. Like this, each named participant can be equipped with additional configuration options which override the defaults. The additional files are so far called "profiles" </li>
<li>If a named participant is not included in the <code>rsb.conf</code>, it will use the process-wide defaults.</li>
<li>If filenames are just a basename, the usual cascade for finding config files will be used, absolute files are also supported</li>
</ul>
</li>
<li>Add an info tool which explains which configuration property is caused by which source to make it easier to debug configuration errors (see <a href="https://code.cor-lab.de/issues/1458" class="issue tracker-4 status-2 priority-4 priority-default child" title="Implement configuration inspector tool (In Progress)">#1458</a>).</li>
</ol>
<p>Like this, extension packages like for the iCub can install profiles in the system and the user only has to dispatch to them in the config.</p> Enhancement #1123 (New): Improve documentation for debian package installation wrt spread transporthttps://code.cor-lab.de/issues/11232012-08-03T10:43:45ZC. Emmerichcemmeric@cor-lab.de
<p>After installing rsb0.7 and rsbcpptools0.7 with debian packages, rsb throws a runtime error:<br /><pre>
terminate called after throwing an instance of 'rsc::patterns::NoSuchImpl'
what(): no implementation of interface `rsb::transport::InPushConnector' found for specified key `spread'
Aborted
</pre></p>
<p>Note: I do not remember this issue occuring when I installed rsb0.7 manually...</p> Bug #923 (New): Computation of channel format is a horrible hackhttps://code.cor-lab.de/issues/9232012-03-04T16:11:47ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<ul>
<li>Specific to Protocol Buffer serialization</li>
<li>Can cause severe slowdowns during channel creation</li>
<li>Does not handle unavailable payload IDLs properly</li>
<li>Compatibility of computed format and actually recorded events is not verified</li>
<li>Output format sucks
<ul>
<li>Parsing is very fragile due to <code>:</code> serparator</li>
<li>Interaction of type-dependencies, filenames and imports sucks</li>
<li>Format is not fully machine-readable at this point</li>
</ul></li>
</ul> Feature #875 (In Progress): Newer tool versions should be able to write files in format understan...https://code.cor-lab.de/issues/8752012-02-14T12:40:20ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deTasks #597 (New): Evaluate whether we want to move to Github once Spread is extractedhttps://code.cor-lab.de/issues/5972011-09-30T11:58:32ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Besides general considerations, we need to check how this would go together with redmine.</p> Tasks #524 (In Progress): Which timestamps should be set based on recorded information?https://code.cor-lab.de/issues/5242011-08-26T21:24:57ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>Out of create, send, receive and deliver, which timestamps should be recorded and later restored when replaying events?</p>
<p>One use-case reported by Johannes:</p>
<blockquote>
<p>If one channel in a tide file is assumed to be the absolute reference for all other activities, all timestamps should be relative to the first event of that special stream. The first event there should have timestamp 0.</p>
</blockquote> Feature #471 (New): Support for RPC clients which do not require a running server parthttps://code.cor-lab.de/issues/4712011-08-04T15:17:20ZL. Schillingmannlschilli@techfak.uni-bielefeld.de
<p>It should be simple to code a rpc client which is able to handle different states of the rpc server availability:</p>
<ul>
<li>reconnect if server disappears and reappears</li>
<li>detect server availability</li>
<li>wait for server to appear (with timeout)</li>
</ul>