Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732015-04-23T15:44:40ZOpen Source Collaboration Platform
Redmine Tasks #2233 (In Progress): Wait for confirmation when joining Spread groupshttps://code.cor-lab.de/issues/22332015-04-23T15:44:40ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>When joining a Spread group, the operation cannot be assumed to have completed before the corresponding membership message has been received from the Spread daemon. As a consequence, events that a certain Spread connection must receive, cannot be sent before the connection in question received its membership message.</p>
<p>When this reasoning and our experimental implementation of a suitable waiting logic appear sound, we have to implement that logic for all languages (and create sub-issues).</p> Enhancement #2149 (Feedback): Provide simple API to programmatically set preferred convertershttps://code.cor-lab.de/issues/21492015-01-04T06:57:44ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>Currently converters can only be configured via the RSC config system. <br />Preferred converters are filtered out in rsb::ParticipantConfig::Transport::handleOption.</p>
<p>As usually the programm needs to specifiy its required converters (rather than the system), there should be an easy mechanism to specify preferred converters on that level.<br />I suggest to add methods addConverter(wireschema, datatype) and addConverters(ConverterNames)</p> Enhancement #2066 (Feedback): added WireSchemaFilter + FilterCombinationhttps://code.cor-lab.de/issues/20662014-10-24T10:04:07ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>WireSchemaFilter acts as a type filter, but could be applied before conversion<br />FilterCombination allows to combine several filters in AND (match all) or OR (match any) fashion</p> Enhancement #2041 (Feedback): merge URI spec into ParticipantConfighttps://code.cor-lab.de/issues/20412014-10-06T21:17:18ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>provide utilities to parse rsb-URIs (see <a class="external" href="http://docs.cor-lab.de//rsb-manual/trunk/html/specification-uris.html">http://docs.cor-lab.de//rsb-manual/trunk/html/specification-uris.html</a>)</p>
<p>provide thin uri class, full-fledged class might become part of boost: <a class="external" href="https://github.com/cpp-netlib/uri">https://github.com/cpp-netlib/uri</a></p>
<p>provide ParticipantConfig ParticipantConfig::merge (const uri&) to merges uri-parameters of existing ParticipantConfig<br />- uri parameters, if available, overwrite existing parameters<br />- new transport is added if neccessary</p>
<p>provide ParticipantConfig ParticipantConfig::replace (const uri&): as merge, but disable (or remove?) other transports</p>
<p>raises std::invalid_argument on failures:<br />- invalid URI syntax<br />- host/port given, but no transport specified</p> Enhancement #1831 (Feedback): Provide introspection functionality as shared object (as opposed to...https://code.cor-lab.de/issues/18312014-04-01T14:40:48ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
Questions to consider:
<ul>
<li>How should the shared object be exported on the CMake-level?
<ul>
<li>Probably similar to converter plugins in <a href="https://code.cor-lab.de/projects/rst" class="project">Robotics Systems Types</a></li>
<li>However, we probably do not want CMake components since they make everything more complicated</li>
<li>Probably add a <code>RSB_INTROSPECTION_LIBS</code> variable and export it in <code>rsb-config.cmake</code></li>
</ul>
</li>
<li>How should the initialization and cleanup be performed when the introspection shared object is used?</li>
<li>What happens if a client programs links against the introspection shared object and then loads the plugin?</li>
</ul> Feature #1767 (Feedback): Export default plugin folderhttps://code.cor-lab.de/issues/17672014-02-13T16:38:09ZAnonymous
<p>There is some kind of <em>default plugin folder</em> (currently <code>lib/rsbx.x/plugins</code>), where several downstream projects install their plugins (e.g. rst converters, rsb-spread, ...) for convenience. Up to now the downstream projects construct this path by hand.</p>
<p>I suggest that we export e.g. a <code>RSB_DEFAULT_PLUGIN_PATH</code> via cmake config for downstream projects to use. Does that make sense?</p> Enhancement #1757 (In Progress): Add intermediate results to request-reply patternhttps://code.cor-lab.de/issues/17572014-02-10T10:28:55ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Allow RPC methods to provide intermediate results during processing using asynchronous communication.</p> Tasks #1415 (In Progress): Document writing converters in manualhttps://code.cor-lab.de/issues/14152013-02-14T13:28:20ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>There is some material <a href="https://code.cor-lab.de/projects/rsb/wiki/Writing_Converters" class="wiki-page">Writing Converters</a> and <a href="https://code.cor-lab.de/projects/rsb/wiki/ProtocolBufferConverter" class="wiki-page">ProtocolBufferConverter</a>.</p> Tasks #1227 (Feedback): Add a CMake macro for RSB pluginshttps://code.cor-lab.de/issues/12272012-11-05T17:47:35ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>The <code>CMakeLists.txt</code> files of the currently existing plugins are very similar.</p>
<p>I suspect we could provide a CMake macro which performs 90 % of the work for most plugin projects.</p>
<p>If we decide to do this, it should be mentioned in the manual.</p> Feature #1149 (Feedback): Allow checking if handlers are registered in Listenerhttps://code.cor-lab.de/issues/11492012-08-24T15:00:38ZM. Meiermmeier@techfak.uni-bielefeld.de
<p>For our migration to rsb we need some sort of functionality provided by the <code>rsb::Listener</code> which allows us to check if there are any handlers registered. In earlier version we used the <code>std::set<HandlerPtr></code> in <code>rsb::Listener::Impl</code> which has been removed recently (<a href="https://code.cor-lab.de/projects/rsb/repository/rsb-cpp/revisions/de636d5533afee40af3b2a2ecee4db6c8325597c" class="changeset" title="Removed unused member variable in src/rsb/Listener.cpp * src/rsb/Listener.cpp: removed unused mem...">rsb-cpp|de636d55</a>). So we would like to have at least some kind of <code>bool hasHandlers()</code> available.</p> Feature #1139 (In Progress): Reference documentation in error reportshttps://code.cor-lab.de/issues/11392012-08-15T14:06:58ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>It would be nice to refer users to suitable documentation when certain errors are encountered.</p>
<p>This has been suggested before (see <a href="https://code.cor-lab.de/issues/967" class="issue tracker-5 status-3 priority-4 priority-default closed" title="Error message for missing transports is uninformative (Resolved)">#967</a>).</p>
<p>There are examples in other middlewares:<br /><pre>
6.210 [ Warning][DeploymentComponent::configureComponents] The protocol with id 3 did not register a fall-back handler for unknown types!
6.210 [ Warning][DeploymentComponent::configureComponents] triggered by: unknown_t which does not have a transport.
6.210 [ ERROR ][DeploymentComponent::configureComponents] Could not create transport stream for port FRIState with transport id 3
6.210 [ ERROR ][DeploymentComponent::configureComponents] No such transport registered. Check your policy.transport settings or add the transport for type /tFriIntfState
</pre></p>
<p>A more generic approach than the above would be attaching references as data structures to exceptions. The information could then be printed in way suiting the situation at hand. Here is an example of such a feature being implemented as a mixin class for exception classes:<br /><pre>
The bounding indices 1 and 2 are bad for a sequence of length 0.
[Condition of type SB-KERNEL:BOUNDING-INDICES-BAD-ERROR]
See also:
Common Lisp Hyperspec, _bounding index designator_ [:glossary]
Common Lisp Hyperspec, _SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR_ [:issue]
</pre><br />Where the <code>_..._</code> parts are hyperlinks.</p>
Where could this be used?
<ul>
<li>Incompatible payload type vs. informer type => "polymorphic informer" (<a href="/projects/rsb/repository/rsb-manual/revisions/20f6d6bc/entry/troubleshooting.rst#L215" class="source">source:rsb-manual|troubleshooting.rst@20f6d6bc#L215</a>)</li>
</ul> Enhancement #551 (Feedback): Language-specific configurationhttps://code.cor-lab.de/issues/5512011-09-07T08:09:08ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>We already have things like<br /><pre>
[transport.spread.converter.cpp]
bool = bool
image = IplImage
</pre><br />in the current configuration scheme.</p>
<p>With the introduction of more technical tunable parameters (e.g. <a href="https://code.cor-lab.de/issues/548" class="issue tracker-5 status-3 priority-4 priority-default closed parent" title="Threadless RSB (Resolved)">#548</a>, <a href="https://code.cor-lab.de/issues/550" class="issue tracker-2 status-3 priority-4 priority-default closed child" title="Selection of Receiving Strategy (Resolved)">#550</a>, <a href="https://code.cor-lab.de/issues/551" class="issue tracker-5 status-4 priority-5 priority-high3" title="Language-specific configuration (Feedback)">#551</a>), it seems unlikely that a single configuration file can be used to configure all language implementation simultaneously.</p>
Two solutions come to mind:
<ul>
<li>In addition to <code>rsb.conf</code>, have language-specific configuration file like <code>rsb-cpp.conf</code> that take precedence over the generic one</li>
<li>Extend the approach mentioned above and introduce language-specific options like <code>eventprocessing.receivingstrategy.cpp</code></li>
</ul> Enhancement #477 (Feedback): Test / Reconsider Distributed Logginghttps://code.cor-lab.de/issues/4772011-08-05T16:37:34ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<ul>
<li>Is this part of RSB functionality?</li>
<li>Part of an additional library?</li>
<li>Which logging frameworks to support?</li>
<li>What is the common format (so far it was log4j's XML format)</li>
</ul> Tasks #432 (Feedback): Logo Designhttps://code.cor-lab.de/issues/4322011-07-20T14:40:17ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Florian made me think about this one...</p>
<p>He chose <a href="http://www.rsb4.de/images/stories/Standardbilder/rsb-Fahne.jpg" class="external">this picture</a> as an icon for RSB in the toolkit...</p>
<p>If we stick to the name RSB, I could imagine a number of Bender-like robot marching with RSB flags... But probably that would be too militaristic theme as Bender surely is a bad guy...</p>
<p>We need a meeting on this. ;-)</p> Feature #340 (Feedback): Implement Distributed Namingservicehttps://code.cor-lab.de/issues/3402011-05-30T09:51:10ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>For introspection in an RSB system comprised by multiple transports, a nameservice implementation is needed.</p>
<p>In contrast to ROS, YARP, XCF, a distributed nameservice is required.</p>
<p>Implementation could be based on:</p>
<ul>
<li>UPNP (btw: could enable DLNA-based use cases...)</li>
<li>Multicast-DNS (check compatibity)</li>
<li>ROS Master (at least evaluate it?)</li>
</ul>
<p>Check relation to model-layer.</p>