[Rock-dev] How to add Uncertaincies - was: Inheritance in base/types - the natural way to go?

[Steffen Planthaber]

Hi,

Renamed the Topic

Am 10.04.2015 um 11:12 schrieb Javier Hidalgo Carrió:
> On 10.04.2015 09:47, Steffen Planthaber wrote:

>> - Use Templates for Extensions? +1
> It depends on the type. I don't see a problem for Timestamp but I am not
> fully sure for Uncertainties since the propagation of the Uncertainty
> fully depends on the data type (no linearities on the propagation).
> Nevertheless, I guess it can be done using an Abstract class and the
> child class should implement the method.

Thats right. But having the Uncertainties as extra types like 
PositionUncertainty, RotationUncertainty could make is possible to 
combine these in a child class for Transfoms (and also to send them alone).

The Question is, on which level we could apply the "uncertain" template, 
is it on top of the final type (like RigidBodyState), or should the 
basic types the RBS is composed of get Uncertainty.

Actually i think second, as accessing the data could be nicer 
rbs.position.uncertainty is nicer to use than having rbs.position and 
rbs.position_uncertainty.

>
> Regarding std::pair,  I would guess typelib cannot handle multiple
> inheritance. Otherwise, NamedVector would be implemented in this manner.
>
> Regarding the Timestamped:
> Shall we still keep the Time.hpp class. What would happen in case
> someone just want to send a Time-stamp through a port? Was there a pull
> request for the Template class "Timestamped" to have a look?

Sadly no, it was before we had that structure and as i said is pushed it 
directly...

Sending the TimeStamp is sending a base::Time.
The template class is used to combine two types into a new one. It 
inhertits the one type and adds the other one as variable.


>> - Autoconvert extended and base types? -1
> +1 I will say this will be the main advantage of the subtype polymorphism.
Well should the dev be aware of the difference to prevent errors or not...

>> - Generic Metadata in types? +1
> Do you have an example for that?

No, it is the generic idea, that rock could support "appending" 
additional types to what is send via a port, like telling on orogen 
level, that a port sends a combination of two (or more) types in one 
single update, like a base::Position and a base::PositionUncertainty.

But we would have to think about the pros and cons on this and also if 
this is possible at all.

Steffen


>
>> Kind regards,
>>
>> Steffen
> I am afraid you brought a wider discussion than I originally meant with
> this email. Perhaps it is the right timing to discuss the topic...
>
> Regards,
>
> Javier.
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>


-- 
  Steffen Planthaber
  Weltraumrobotik

  Besuchsadresse der Nebengeschäftstelle:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Postadresse der Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4125
  Zentrale: +49 421 178 45-0
  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   Steffen.Planthaber 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
  -----------------------------------------------------------------------