Hi all,
I am designing two components which I would like to like with a system state (the output of Task1 is a system state input in Task2).
This system state is composed of several components: a 3D position, a 3D orientation, and a 3D acceleration.
What is the best practise in this case? Make 9 different 1D ports, or create a new data type (with the typekit)?
Thanks,
Antoine.
Multiple dimensions ports:
"...which I would like to LINK with a system state...", not to "like" as written
Multiple dimensions ports: best practise
Hi Antoine,
2015-08-31 6:47 GMT+02:00 <antoine [dot] rennuit [..] ...>:
> Hi all,
>
> I am designing two components which I would like to like with a system state
> (the output of Task1 is a system state input in Task2).
>
> This system state is composed of several components: a 3D position, a 3D
> orientation, and a 3D acceleration.
>
> What is the best practise in this case? Make 9 different 1D ports, or create
> a new data type (with the typekit)?
There is no "best solution", but few guidelines which I would consider
to take a decision on that.
The main criteria is the follow: in your application, is the data
synchronous or not? That is, will you update all the system state at
once (thus sending/receiving all the data, synchronously), or you may
update only one part of it?
In the first case, I would go for a compact solution ( one port, one
compound datatype).
Instead, If part of the state gets an update to an higher frequency
wrt the rest, split in multiple ports is a better option, IMHO.
On the other hand, creating a new typekit will slightly afffect the
"portability" of your component - that is, if you aim to distribuite
or reuse it, the relative typekit should be provided too. In addition,
you could consider if the whole state is always incoming from the same
component, or (in the future) data is coming from different
sources/components.
As side note, you can obtain the same "asynchronous" behavior in one
port only case - you update only the data that is actually changed.
>From the behaviour point of view is exactly the same, but it is not
performance-wise.
HTH,
- Enea
> Thanks,
>
> Antoine.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Multiple dimensions ports: best practise
Hello Enea, this does make sense, thanks for the tip!
Multiple dimensions ports: best practise
On Mon, Aug 31, 2015 at 6:47 AM, <antoine [dot] rennuit [..] ...>
wrote:
> Hi all,
>
>
Hey Antoine,
> I am designing two components which I would like to like with a system
> state
> (the output of Task1 is a system state input in Task2).
>
> This system state is composed of several components: a 3D position, a 3D
> orientation, and a 3D acceleration.
>
> What is the best practise in this case? Make 9 different 1D ports, or
> create
> a new data type (with the typekit)?
>
>From the standpoint of system resource usage, less ports is better. So
unless your application strictly requires it, I would avoid the 9-port
alternative.
Three vector ports (pos, vel,acc) is a good compromise as you don't have to
develop a new typekit.
If it makes sense to your application, and you don't mind setting up a
typekit, consider a single data structure. If readings are all taken at the
same time, you could also consider adding a timestamp that downstream
components might find useful.
Cheers,
Adolfo.
> Thanks,
>
> Antoine.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Multiple dimensions ports: best practise
Hello Adolfo,
When you say "Three vector ports (pos, vel,acc) is a good compromise as you don't have to develop a new typekit" is this because you mean to use data of type vector<double> which is already built-in?
Also when you write "you could also consider adding a timestamp that downstream components might find useful", you mean it is useful for non-periodic data generation or you also see a use case for this timestamp in case of periodic data?
Thanks,
Antoine.