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

[Janosch Machowinski]

There is one big problem with this approach :

Timestameped< Probabilistic<RigidBodyState> >  !=
Probabilistic< Timestamped<RigidBodyState> >

So one needs to be very careful which types go on the ports.
Greetings
     Janosch


Am 10.04.2015 um 11:53 schrieb 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
>>
>


-- 
  Dipl. Inf. Janosch Machowinski
  SAR- & Sicherheitsrobotik

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-6614
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  jmachowinski at informatik.uni-bremen.de

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