[Rock-dev] Apropos base/orogen/interfaces

[Matthias Goldhoorn]

On 14.05.2013 08:49, Jakob Schwendner wrote:
> On 05/13/2013 05:17 PM, Sylvain Joyeux wrote:
>> I have a strong feeling against base/orogen/interfaces. This is actually
>> why it is still stuck on master, as
>>
>> My problem is that:
>>    - the properties that are defined in the interfaces make only sense on
>> one or two devices. They are not generic, and therefore the 'interface'
>> is actually half broken (setting a property on task X is not guaranteed
>> to actually produce something). This is already a problem we have with
>> the camera interface.
>>    - the value in having a common base class just to define one or two
>> ports is IMO very limited
>>
>> So ... I'd like to hear the other side of the story ;-)
>>
> The rational for the interfaces was to have a way of making sure that
> devices of the same kind use the same types to transport their data, and
> also use the same name for the ports. We've discussed this with a few
> people from the rock-dev (you weren't there) a while ago. The reason was
> that I wanted to implement tasks that simulate a specific device. I
> think we had a few options on the table for this. One of them using
> interfaces through the inheritance mechanism of orogen. I seem to
> remember that we opted for this because it was implemented. I can't
> remember the alternatives, but I think they involved more work. I
> personally don't have a strong oppinion for or against the interfaces. I
> just looked at the code, and I am note sure I can share your observation
> that the interfaces are broken at this point. Yes, the Servo interface
> is not really an interface, but actually contains the sweep
> functionality. And yes again, the LaserScanner has some properties that
> may not be implemented for some devices. One easy way to fix this, is to
> move it out of the interface and into the actual device. Then we could
> say only things that have to be implemented by all the derived devices
> go into the interface.
> I guess from a syskit perspective interfaces may not be so important
> since you do the modelling of the functionality on a different level.
> For the scripts I think they make life a little easier since the
> simulated and real devices really have the same signature.

I have currently the problem that i cleanup the mars-interfaces for this 
i created an orogen MarsPlugin class.
All depending tasks need to inherit this class, since double 
inheritation is not possible (currently) in orogen i got an unsolvable 
problem with the interfaces, because i can't simply inherit both...

I'm note sure too what's the best way to define "device-interfaces", 
even not sure if this is really needed. Functionality can be in an 
normal interface class generalized. And for the port names, hmh, maybe 
some code-review before we allow packages to go into "rock"?. Or we 
define some guidelines for often-use drivers?

I don't like the problem with unused properties too...

I can spend the work for the simulation side to review out "result".
I vote for simply "not using interfaces but make sure port/propery names 
are the same."

Other ideas?

Matthias




>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev


-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4193
  Zentrale: +49 421 178 45-6550
  Fax:      +49 421 178 45-4150
  E-Mail:   matthias.goldhoorn at uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik