[Rock-dev] Fwd: RE: Avalon's Middleware
Jan Sliwka
sliwka at cmre.nato.int
Fri Aug 17 14:03:04 CEST 2012
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.
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.
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
o Add the dependency
· Change message_producer.orogen
o Configure 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
o The constructors (2), destructor
o updateHook
· 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)
o All the publishers can be created in the main function
o All the subscribers are associate a topic with a custom build function
which is called once a message appears on the topic
· Use
o rosrun [package_name] [node_name] for running just one Node at a time
o roslaunch [package] [filename.launch] for running all the system
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?
· Do you have a simulator?
· Do you have some sort of mission planner? A set of behaviors which
might be reused?
· Where is it possible to get the code and their documentation
Other questions:
As for the standard, I meant standards such as OMG (Object Management Group)
and so
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 <mailto:sliwka at cmre.nato.int> <sliwka at cmre.nato.int>
To:
'Matthias Goldhoorn' <mailto:matthias.goldhoorn at dfki.de>
<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; 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) 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 at 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
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.
****************************************************************************
******************
_______________________________________________
Rock-dev mailing list
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
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.
**********************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120817/2d529245/attachment-0001.htm
More information about the Rock-dev
mailing list