Robotics Service Bus

h1. Meetings 2011-09-22

h2. Cause Vectors (Johannes)

* Causes

** Transitive closure?

** List vs. set

* Provide event ids independently of sending?

** Ingo: ids in active memory (which become available only after sending) have been inconvenient 

* Keep origin and sequence number as attributes of events? Slightly in favor

h2. RSBag Demo and Update (Jan)

* Usage of @bag-record@, @bag-info@, @bag-play@

* IDL retrieval

** Converter registration could make IDL available via RPC

** Include hash derived from IDL in each message

*** Verify IDL compatibility

*** Potential disadvantage: overhead

*** Retrieval of definition could be solved via reverse hash -> definition resolution service

*** Compatible IDL changes would be hard to do

** HTTP downloads

** RPC service that distributes IDLs

*** Central IDL services with registration method

*** Per-node/informer service

* Replay strategies?

* Flow-control?

** Should not be handled in rsbag tools

h2. Recording Discussion (Ingo)

h3. Multi-file storage schemes

Ingo's mail:

> wir sind jetzt auch bei der Umstellung des Logging für unsere Demos, und dabei sind mir ein paar Dinge aufgefallen, die ich als Defizite des aktuellen TIDE-Formats sehen würde (und die übrigens auch für rosbag gelten). Ich würde daraus Änderungen am TIDE-Format ableiten. Hier aber erstmal die Erläuterung.

>

> Kurz gesagt: Ich halte es inzwischen für ungünstig, zum Loggen eine einzige Datei zu verwenden. Wenn man aber mehrere Dateien verwendet, ändert sich Einiges an den Abwägungen.

>

> Eine entsprechende Überlegung hatte ich schon vor längerer Zeit angestellt, als mir das "dirfile"-Format des getdata-Projektes über den Weg lief, siehe: http://getdata.sourceforge.net/ Damals schien es mir aber keinen konkreten Grund zu geben, der dafür sprach, und es hat ein paar Nachteile beim Transport, und dirfile selbst ist jetzt auch nicht gerade das, was wir wollten. Wir haben das also erstmal nicht gemacht.

>

> Der Grund warum ich meine Ansicht da geändert habe ist einfach: Für manche Datentypen gibt es bereits etablierte und bessere Formate. Man kann das mischen, aber dann verliert man an dieser Stelle den kompletten Support für existente Werkzeuge. Es ist absehbar, dass man an irgendeinem Zeitpunkt das sowieso "exportieren" müsste, und dann wäre es vermutlich besser, man hätte es gleich so erfasst.

>

> Ein Anwendungsfall ist z.B. das Speichern von Video-Daten: Wenn ich nicht komprimiert speichere, kann ich das ohne Weiteres in ein TIDE-Logfile schreiben. Wenn ich aber schon beim Schreiben komprimieren will, dann ist es erstens von den Tools her sehr viel einfacher, das in eine getrennte Datei zu schreiben, und außerdem auch besser für die Weiterverarbeitung, das Schneiden, etc. Auch beim Loggen von XML-Dateien ist es z.B. ganz praktisch, die eine große Datei mit Namespaces einzubetten, weil man dann Standard-Werkzeuge drauf ansetzen kann.

>

> Man braucht trotzdem weiter einen Container für alles das, wofür es kein etabliertes Format gibt, aber wenn man sowieso mehrere Dateien verwendet, dann kann man diesen Container einfacher gestalten, und z.B. Meta-Daten getrennt ablegen, vielleicht sogar als XML (muss dann ja nicht mehr so oft manipuliert werden).

>

> Man will natürlich das ganze trotzdem als ein Konglomerat behandeln können, aber mit geeigneten Werkzeugen (z.B. MP4BOX für Video-Daten) ist das ja auch dann möglich, wenn mehrere Dateien vorliegen.

>

> Es würde mich sehr interessieren, was ihr von diesen Überlegungen haltet. Je nach dem, wie euer Feedback ist, würde ich dann eine Überarbeitung von TIDE anstoßen.

* Data in multi-file storage scheme

** Video/Audio

*** Could be stored in native formats (mpeg, mp3, ...)

*** Advantages: tool support, compression

*** Disadvantages: timestamps may be harder to obtain, meta-data has to be associated via external files

** XML

*** Advantages: tool support (but: would also  be available in TIDE-based recording if we had @bag-cat@)

** Meta-data

*** Additional file(s) for whole directory

*** Store(s) channel information

*** Store(s) associated timestamps and meta-data for native data files

*** Store(s) indexing information

* Implementation

** Commandline tool orchestrates multi-source recording

*** RSB source

*** Camera sources

*** Microphone sources

*** ROS source

** Commandline tool or client library for data access

*** Would provide timestamp-based alignment of multimodal data

*** Would abstract access methods (e.g. video container, TIDE-files, ...)

h3. Program Names

> Unfortunately, "rsblog" isn't better either ;-)

> 

> May "stream-log", contracted to "slog", might be something. That also 

> describes very well what is required to wade through this data ;-)

_not discussed_