The current situation is that we build deployments at compile time. They are declared in orogen, and orogen generates binaries from them. It has served us well, but has quite a bit of limitations:

  • creating new deployments has a significant cost
  • you cannot "just use" a component in e.g. a GUI to process images. You first have to create a deployment for it (or use the default deployment)
  • synchronous processing could be done in a multiprocess way, but that's not the simplest

This TODO item lays down a plan to be able to create deployments at runtime

For the sake of completeness, I must mention that we could use the OCL deployer. I personally don't like that solution because the deployer is really used as a deployer in RTT/OCL as a way to get a script interface, NOT because it should be a component. Moreover, it is actually a pain to extend (just look at the code) and integrating all functionality I'd like to have is going to be hard (e.g. control over the transports).


The structure of the deployment library is really to provide the following services:

  • load a task class from a task library (part of the discovery is already done by orogen, the loading / plugin part is provided by RTT)
  • allow to create a new task of said class
  • allow to assign an activity to it
  • allow to register it on name services (CORBA / avahi) with an arbitrary name (does not necessarily have to be the same than the task name)
  • allow to setup the transport(s) (can set scheduler and priority of the CORBA dispatcher for instance)

Overall, it would be a pretty thin Ruby binding on top of the existing RTT API (no intermediate library necessary). On the Ruby side, we already have the API for the specification (oroGen). Would need to extend it slightly (e.g. for name service registration and transport setup)

Last modified 7 years ago Last modified on 12/01/14 22:06:32