[Rock-dev] Fwd: RE: Avalon's Middleware

Wed Aug 22 17:58:49 CEST 2012

On 17.08.2012 14:03, Jan Sliwka wrote:
>
> Hello all,
>
> Thank you for your response. I didn't know that the project was so 
> young. So it is normal that the documentation is very technical. I 
> would like to give my opinion for the project since I find it 
> interesting. An input from third party might also be valuable. I am 
> sorry if I say some wrong things due to the misunderstandings of the 
> Rock framework.
>
Hey Jan, any kind of feedback is more than welcome, so thanks!
>
> I would like first to talk about the context. You know, you're facing 
> the famous ROS and my question would be: what are the points in which 
> you are equal and those where you surpass ROS.
>
> I would say that first; your strong point might be the AUV world. 
> Currently, there are very few components related to the AUV in ROS. I 
> think the second strong point is the use of Orocos which enable better 
> control of the application (more suitable for fine control when 
> resources are lacking). However, the cost of better control is higher 
> complexity.
>
Regarding ROS IMO we are (still) on a complementary level, however 
without being to elaborate some of the differentiators:
  - Rock's main driver is architecturing systems and targeting a 
potentially large collection of components which requires advanced 
management tools
  - Rock provides tools for complex system management see 
http://rock-robotics.org/stable/documentation/system/index.html
  - Rock is is therefore more strict and relies on a component-model to 
allow to build up the tooling (also to foster reuse -> strict separation 
of framework and drivers)
  - Rock is using the Orocos component model and thus allows for 
real-time execution capability
  - Connections are modelled, so system designers can control where data 
goes (not the component)

> As for complexity, you have maybe been victims of your own engineering 
> strength. You can handle high complexity and so you make complex 
> systems. Now to compare Ros and Rock.
>
> If I understood correctly. To create a component using Rock you need:
>
> ·Use rock-create-orogen
>
> ·Change manifest.xml
>
> oAdd the dependency
>
> ·Change message_producer.orogen
>
> oConfigure the component
>
> ·add you(r) component to the build system by adding the package to 
> autproj/manifest's layout section
>
> ·amake
>
> ·Change Task.hpp, Task.cpp
>
> oThe constructors (2), destructor
>
> oupdateHook
>
> ·amake
>
> ·Change orocos.rb
>
> ·ruby start.rb
>
> Creating a configurable component is not trivial (I mean not hard but 
> once there are more than 5 place to modify it becomes ... not trivial).
>
> As for connecting the components, I would say that it is clear and 
> easy. I think what should be specified in your approach is that you 
> spend time building components but then, their usage becomes very easy 
> and professional. You should maybe focus on that point so that people 
> can sacrifice some of their time to build components.
>
> Ok. Now for ROS you need
>
> ·$ roscreate-pkg [package_name] [depend1] [depend2] [depend3]
>
> ·Check manifest.xml or edit if needed
>
> ·rosdep install [package]
>
> ·rosmake [package]
>
> ·run ROS: roscore
>
> ·Change Task.hpp and Task.cpp (The interconnections can be defined here)
>
> oAll the publishers can be created in the main function
>
> oAll the subscribers are associate a topic with a custom build 
> function which is called once a message appears on the topic
>
> ·Use
>
> orosrun [package_name] [node_name] for running just one Node at a time
>
> oroslaunch [package] [filename.launch] for running all the system
>
Comparing ROCK and ROS setup I assume you actually want to stress the 
'required modification' part, i.e. improving steps to integrate into the 
build system and such?!

> ROS runs a parameter server which you can initialize using a ".yaml" 
> file. The parameters are accessible through the functions 
> "setParam/getParam. The difference with Rock is that the server is 
> centralized but you handle one config per component which is maybe 
> better.
>
> The components are naturally connected through topic names. The 
> connection graph can be even remapped using ROS remapping capability. 
> However, this is not necessarily good since the connection graph is 
> not necessarily defined in a single file.  In the case of Rock all the 
> interconnections are visible in the same file.
>
> I personally find ROS more ergonomic but Rock having more potential.
>
> To be honest I still didn't use Rock but it is the impression I have 
> from reading the documentation.
>
> I have some questions with regards to the modules you offer:
>
> ·What is the list of communication devices you handle: 
> Serial/I2C/CAN/Bluetooth?
>
Best check online:
http://rock-robotics.org/stable/pkg/index.html
and type in 'drivers'

> ·Do you have a simulator?
>
We have use a custom simulator in our institute, however you can easily 
attach your own, when using Rock.
>
> ·Do you have some sort of mission planner? A set of behaviors which 
> might be reused?
>
Not a planner but a plan manager: 'Roby' - which is used as 'supervision':
http://rock-robotics.org/stable/api/tools/roby/index.html

Currently, there is no collection of behaviours publicly available.
>
> ·Where is it possible to get the code and their documentation
>
  Rock packages are hosted on gitorious.org
>
> Other questions:
>
> As for the standard, I meant standards such as OMG (Object Management 
> Group) and so...
>
e.g. CORBA is used, or FIPA standards, and otherwise we start out with 
convention(s) as already mentioned

Hope that helps, best

Thomas
>
> Sorry for that long mail, I hope I could contribute to the project,
>
> Best regards,
>
> Jan SLIWKA
>
> Dr. Ing. at CMRE (formerly NURC)
>
> *From:*Thomas Roehr [mailto:thomas.roehr at dfki.de]
> *Sent:* Thursday, August 16, 2012 8:14 PM
> *To:* sliwka at cmre.nato.int
> *Cc:* rock-dev at dfki.de
> *Subject:* Re: [Rock-dev] Fwd: RE: Avalon's Middleware
>
> On 14.08.2012 12:48, Matthias Goldhoorn wrote:
>
> Hello together,
>
> I think i move this to the ML, because i still couldn't answer all 
> questions.
> Maybe one of the more-active developers could take over (or extend) 
> the "core" questions below?
>
> Greetings,
> Matthias
>
>
> -------- Original Message --------
>
> *Subject: *
>
> 	
>
> RE: Avalon's Middleware
>
> *Date: *
>
> 	
>
> Tue, 14 Aug 2012 12:15:34 +0200
>
> *From: *
>
> 	
>
> Jan Sliwka <sliwka at cmre.nato.int> <mailto:sliwka at cmre.nato.int>
>
> *To: *
>
> 	
>
> 'Matthias Goldhoorn' <matthias.goldhoorn at dfki.de> 
> <mailto:matthias.goldhoorn at dfki.de>
>
> I am searching for an (new) comm-framework for our particular project which
> could become THE framework for all the nurc vehicles in general.
> In order to do so, as you said, I am collecting information for a
> state-of-the-art report. If you have access to report like this, I'd
> appreciate to have it.
> I took a look into rock and orocos. I think the documentation and tutorials
> you provide on your webpage is well structured and complete but in my
> opinion they are hard to follow for someone who wants to know about rock
> without necessarily having it installed on the computer and as a consequence
> not able to test the lines of code you provide. Maybe you could add a small
> paragraph to your webpage about how rock works in a simplified (short!!!)
>
> Ack -  now on our todo list
>
>   
> version with lots of diagrams (like it is the case for the orocos doc but
> maybe even simpler...), what a user needs to know (ruby, c++), provide
> templates for users to fill with code... you should maybe not assume that
> people know or should know orocos (since orocos is another sea of code if
> you know what I mean). Or maybe it is impossible to separate orocos and
> rock?...I mean making a full abstraction out of it.
>
> Orocos-related software represents a large part of the Rock-Toolchain. 
> However, (as one example)
> due to the strict separation between driver development and framework 
> you can always use our drivers independently of the given
> framework.
>
>   
> What I like in your framework is the real-time aspect of orocos and the
> tools you provide (little bit like ROS but more AUV oriented).
> I have some questions.
>
>
>
>   
> Question: do you provide a pdf version of the documentation for rock like
> for orocos?
>
> no (t yet)
>
>   
> Question: are the tools you provide tested and reliable? Is rock used by a
> university or other institute other than DFKI?
>
> Using our release strategy from master->next->stable we try to 
> maintain stability and reliability, and most packages come along with 
> unit tests.
> We have seen Rock's toolchain and generated components working 
> reliably in our projects, which is one of the reasons for our first 
> release.
>
> Clearly, the main application base for now has been us at DFKI (in 
> different projects), and some partners.
> Since the first release has been only a couple of months ago and some 
> people/institute there might be still some unknown early adopters.
>
>   
> Question: is it possible to use rock without knowing how to use orocos while
> keeping the real-time aspect of the execution.
>
> Components in Rock are Orocos components - thus working with these 
> components (with real-time or not) does require a general 
> understanding of Orocos components and their working. The provided 
> tooling by Rock facilitates your task to build and manage single 
> components and (complex) networks of components and thus you don't 
> have to dive too deep.
>
>
>   
> Question: can you use the statecharts (based on orocos statecharts) using
> rock only?
>
> short version: statechart integration does not exist
>
> long version:
> generating components via Rock (i.e. using oroGen) allows you easily 
> specify custom states of your component: 'Extending the state machine' 
> http://rock-robotics.org/stable/documentation/orogen/task_states.html
>
> Once you start building complex component networks an integration into 
> the supervision component (Roby -> 
> http://rock-robotics.org/stable/documentation/system/index.html) 
> exits. This integration relies on a mapping of the task state 
> transitions to events.
>
>
>   
> Question: does rock/orocos comply to a specific standard
>
> What kind of standard do you refer to?
> Generally, we try to push 'standardization' and rely on (common) 
> conventions, yet
> if you refer to DIN, ISO or similar official type of standard: not for 
> the Rock part.
>
> http://rock.opendfki.de/wiki/WikiStart/Standards
>
>
>   
> Question: what is the license of rock/orocos (It is GPLv2 I think but
> correct me if I am mistaken)
>
> LGPL for most of the libraries, individual packages might differ though
>
> Best
> Thomas
>
>   
> That's all for now, I am sorry to ask those questions but orocos is a good
> but complex tool and I find simplifying it (using rock) a good idea.
> Looking forward to your answer,
> And greetings from sunny Italy ;) (viva the air conditioning)
> Jan
>   
> -----Original Message-----
> From: Matthias Goldhoorn [mailto:matthias.goldhoorn at dfki.de]
> Sent: Tuesday, August 14, 2012 9:14 AM
> To: Jan Sliwka
> Subject: Re: Avalon's Middleware
>   
> how's going,
>   
> did you already take a look into "rock"?, got problems or is something
> unclear?
>   
> Are you searching for an (new) comm-framework for the nurc vehicles in
> general, or do you only collecting information for an state-of-the-art
> report?
>   
> Greetings from sunny Bremen.
> Matthias
>   
>   
>   
> On 09.08.2012 10:00, Jan Sliwka wrote:
> >  Thanks a lot!!!
> >  
> >  -----Original Message-----
> >  From: Matthias Goldhoorn [mailto:matthias.goldhoorn at dfki.de]
> >  Sent: Thursday, August 09, 2012 8:26 AM
> >  To: Jan Sliwka
> >  Cc:sliwka at cmre.nato.int  <mailto:sliwka at cmre.nato.int>;malgorzata.goldhoorn at dfki.de  <mailto:malgorzata.goldhoorn at dfki.de>
> >  Subject: Re: Avalon's Middleware
> >  
> >  Am 08.08.2012 16:49, schrieb Jan Sliwka:
> >>  Hi Matthias,
> >>  I now work on middlewares for underwater robots at the NURC. I
> >>  remember you were developing one in DFKI but I forgot the name.
> >>  Could you give me some references and links where I can find more
> >>  information about it?
> >>  Say hello from me to Malgosia,
> >>  thanks,
> >>  Jan
> >  Hi Jan, nice to hear from you.
> >  Greetings of course back from Malgosia.
> >  
> >  So regarding the "Middleware" or communication framework.
> >  
> >  The Framework is called Rock-Robotics (www.rock-robotics.org  <http://www.rock-robotics.org>) it's an
> >  layer ontop of Orocos-RTT Tollchain.
> >  You can have RealTimeSupport but you not enforced to add an RTT Kernel.
> >  Rock proides a lot of typical driver like for the BlueView Sonar,
> >  Several Tritech devices and other stuff.
> >  
> >  http://rock-robotics.org/stable/pkg/index.html  (search for driver for
> e.G.).
> >  The Repositorys of the drivers (more or less all) are located on spacegit:
> >  
> >  http://gitorious.org/rock-drivers
> >  
> >  These drivers are (on this layer) Framework-Independently written so
> >  that they can be used also on other frameworks or even simple
> >  programs, the build simply as an library that can be used everywhere.
> >  
> >  If yourneed any other information about rock or the capabilities, we
> >  are providing an mailinglist that's queite friendly and active. Since
> >  i'm also an rock-developer i got these mails too. But if you like you
> >  could contact me private too ;).
> >  
> >  Conrats's for you NURC Contract i aos thougt about sending an CV to
> >  the nurc in the future.
> >  
> >  Freetings from Cold northern Germany,
> >  Matthias
> >  
> >  
> >  
> >  
> >  **********************************************************************
> >  ************************
> >  *** PRIVILEGED AND CONFIDENTIAL ***
> >  
> >  Centre for Maritime Research and Experimentation (CMRE, formerly NURC)
> >  
> >  The information contained in this e-mail message (including any
> >  attached files) is intended for the use of the addressee(s) only and is
> privileged information.
> >  The information should neither be posted to the Internet, nor
> >  published in any other public domain, without the express permission
> >  of the sender. If you are not the intended recipient(s) or the
> >  recipient's representative, you are hereby notified that any use,
> >  disclosure, copying or distribution of this communication is
> >  prohibited. If you have received this communication in error please
> >  notify us immediately atpostmaster at cmre.nato.int  <mailto:postmaster at cmre.nato.int>  and remove this message
> from your system.
> >  **********************************************************************
> >  ************************
>   
>   
> --
>    Dipl.-Inf. Matthias Goldhoorn
>    Unterwasserrobotik
>   
>    Hauptanschrift Standort Bremen:
>    DFKI GmbH
>    Robotics Innovation Center
>    Robert-Hooke-Straße 5
>    28359 Bremen, Germany
>   
>    Phone: +49 (0)421 178 45-4193
>    Fax:   +49 (0)421 178 45-4150
>    E-Mail:robotik at dfki.de  <mailto:robotik at dfki.de>
>   
>    Weitere Informationen:http://www.dfki.de/robotik
>    -----------------------------------------------------------------------
>    Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>    Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>    Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>    (Vorsitzender) Dr. Walter Olthoff
>    Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>    Amtsgericht Kaiserslautern, HRB 2313
>    Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>    USt-Id.Nr.:    DE 148646973
>    Steuernummer:  19/673/0060/3
>   
>   
>   
>   
> **********************************************************************************************
> *** PRIVILEGED AND CONFIDENTIAL ***
>   
> Centre for Maritime Research and Experimentation (CMRE, formerly NURC)
>   
> The information contained in this e-mail message (including any attached files)
> is intended for the use of the addressee(s) only and is privileged information.
> The information should neither be posted to the Internet, nor published in any
> other public domain, without the express permission of the sender. If you are
> not the intended recipient(s) or the recipient's representative, you are hereby
> notified that any use, disclosure, copying or distribution of this communication
> is prohibited. If you have received this communication in error please notify us
> immediately atpostmaster at cmre.nato.int  <mailto:postmaster at cmre.nato.int>  and remove this message from
> your system.
> **********************************************************************************************
>
>
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de  <mailto:Rock-dev at dfki.de>
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
>
>
> -- 
> Thomas Röhr (M.Sc.)
> Space Robotics
>   
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>   
> Phone: +49 (0)421 178-454151
> Fax:   +49 (0)421 178-454150
> E-Mail:robotik at dfki.de  <mailto:robotik at dfki.de>
>   
> Weitere Informationen:http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.:    DE 148646973
> Steuernummer:  19/673/0060/3
> -----------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
> /*** PRIVILEGED AND CONFIDENTIAL ***
>
> Centre for Maritime Research and Experimentation (CMRE, formerly NURC)
>
> The information contained in this e-mail message (including any 
> attached files)
> is intended for the use of the addressee(s) only and is privileged 
> information.
> The information should neither be posted to the Internet, nor 
> published in any
> other public domain, without the express permission of the sender. If 
> you are
> not the intended recipient(s) or the recipient's representative, you 
> are hereby
> notified that any use, disclosure, copying or distribution of this 
> communication
> is prohibited. If you have received this communication in error please 
> notify us
> immediately at postmaster at cmre.nato.int and remove this message from
> your system. /
> ------------------------------------------------------------------------


-- 
Thomas Röhr (M.Sc.)
Space Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454151
Fax:   +49 (0)421 178-454150
E-Mail:robotik at dfki.de

Weitere Informationen:http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120822/d425d678/attachment-0001.htm