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

[Sylvain Joyeux]

Hello Jan. Thanks for the feedback and the interest in the project !

On 08/17/2012 02:03 PM, Jan Sliwka wrote:
>
> 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.
>
http://www.rock-robotics.org/stable/documentation/about/index.html
http://www.rock-robotics.org/stable/documentation/about/others.html

> 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.
>
On that front, it might be of interest for you that we are currently 
helping MARUM to run a new AUV (and in the future, all their systems) 
using Rock. The drivers and control software will be released as open 
source.

[snip new module creation examples]
In practice, component creation is a process that will take 2% of the 
overall development time. It is, as you point out, very important to 
attract new users (and we are interested in comments on how to improve 
it), but has very little effect on the overall development times.
>
> 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.
>
You also have access to parameters directly on the components through 
the property interface (for e.g. change parameters at runtime).
>
> 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 would also add: the developer of a node can anytime add a new topic. 
If not careful (or -- in case of reusing nodes, if he/she does not know 
about your system), the new topic name might clash with an existing one 
and boom. Additionally, having explicit connections allows to disconnect 
dataflow and reconnect it. The first one is important for safety 
reasons, as one can isolate a rogue component from the rest of the 
system. The second one is the cornerstone of behaviour switching in Rock 
(we switch behaviours by starting/stopping new components and rewiring 
the connections).
>
> 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?
>
Depends on what you mean by "handle".

The base class for all our device drivers can handle serial and 
bluetooth (since bluetooth is seen as a network device on linux). There 
is a dedicated CAN component for CAN devices. On top of that, for 
underwater systems, we have drivers for the schilling DTS.

> ·Do you have a simulator?
>
As Thomas mentioned, we have our own simulator that just got released as 
open source. However, while it kind-a works for underwater applications, 
it is not ideal. We did look pretty hard for a good open source 
underwater simulator, but never found one. Would you have any pointer in 
that respect ?

-- 
Sylvain Joyeux (Dr.Ing.)
Senior Researcher

Space & Security Robotics
Underwater Robotics

!!! Achtung, neue Telefonnummer!!!

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

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-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
-----------------------------------------------------------------------

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20120914/a0dce468/attachment.htm