rtt_dot_service feedback

I've run this service again for our euRobotics 'simulation' deployment (see
attachment)

- Maybe instead of the connection name, we could indicate the connection
type instead. With the words 'buffer[size]' or 'data' for example. The long
names impair readability and don't give any extra information.
- Readability might improve if the arrows leaving an output port or entering
an input port would originate from the same point. I have no idea to do
this.. drawing another 'icon' which represents a port would not guarantee
that the port icon stays close to the component in the drawing.
- We might need another service to display peer connections. I don't think
its readable to show both.
- Ports of services are not done yet..? We could show services which have
ports as ovals as well, but again, these could be relocated far away by the
drawing algorithm.

Anyway, very usable as it is... and independent of ROS :-)

Peter

AttachmentSize
euRobotics.png117.85 KB

rtt_dot_service feedback

2011/10/4 Peter Soetens <peter [..] ...>

> I've run this service again for our euRobotics 'simulation' deployment (see
> attachment)
>
> - Maybe instead of the connection name, we could indicate the connection
> type instead. With the words 'buffer[size]' or 'data' for example. The long
> names impair readability and don't give any extra information.
> - Readability might improve if the arrows leaving an output port or
> entering an input port would originate from the same point. I have no idea
> to do this.. drawing another 'icon' which represents a port would not
> guarantee that the port icon stays close to the component in the drawing.
> - We might need another service to display peer connections. I don't think
> its readable to show both.
> - Ports of services are not done yet..? We could show services which have
> ports as ovals as well, but again, these could be relocated far away by the
> drawing algorithm.
>
> Anyway, very usable as it is... and independent of ROS :-)
>
> Peter
>

FYI, here is a screen for a more connected scheme. Sorry for the size of the
screen I can't do better for having the hole scheme.

>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

rtt_dot_service feedback

On Monday 17 October 2011 02:11:21 Willy Lambert wrote:
> 2011/10/4 Peter Soetens <peter [..] ...>
>
> > I've run this service again for our euRobotics 'simulation' deployment
> > (see attachment)
> >
> > - Maybe instead of the connection name, we could indicate the connection
> > type instead. With the words 'buffer[size]' or 'data' for example. The
> > long names impair readability and don't give any extra information.
> > - Readability might improve if the arrows leaving an output port or
> > entering an input port would originate from the same point. I have no
> > idea to do this.. drawing another 'icon' which represents a port would
> > not guarantee that the port icon stays close to the component in the
> > drawing. - We might need another service to display peer connections. I
> > don't think its readable to show both.
> > - Ports of services are not done yet..? We could show services which have
> > ports as ovals as well, but again, these could be relocated far away by
> > the drawing algorithm.
> >
> > Anyway, very usable as it is... and independent of ROS :-)
> >
> > Peter
>
> FYI, here is a screen for a more connected scheme. Sorry for the size of
> the screen I can't do better for having the hole scheme.

This shows again what composition of components is useful for as well...
providing clear overview of the system from the top level.

Peter

rtt_dot_service feedback

On Oct 17, 2011, at 05:40 , Peter Soetens wrote:

> On Monday 17 October 2011 02:11:21 Willy Lambert wrote:
>> 2011/10/4 Peter Soetens <peter [..] ...>
>>
>>> I've run this service again for our euRobotics 'simulation' deployment
>>> (see attachment)
>>>
>>> - Maybe instead of the connection name, we could indicate the connection
>>> type instead. With the words 'buffer[size]' or 'data' for example. The
>>> long names impair readability and don't give any extra information.
>>> - Readability might improve if the arrows leaving an output port or
>>> entering an input port would originate from the same point. I have no
>>> idea to do this.. drawing another 'icon' which represents a port would
>>> not guarantee that the port icon stays close to the component in the
>>> drawing. - We might need another service to display peer connections. I
>>> don't think its readable to show both.
>>> - Ports of services are not done yet..? We could show services which have
>>> ports as ovals as well, but again, these could be relocated far away by
>>> the drawing algorithm.
>>>
>>> Anyway, very usable as it is... and independent of ROS :-)
>>>
>>> Peter
>>
>> FYI, here is a screen for a more connected scheme. Sorry for the size of
>> the screen I can't do better for having the hole scheme.
>
> This shows again what composition of components is useful for as well...
> providing clear overview of the system from the top level.

Agreed completely! The ability to hierarchically compose/decompose a large system is one of the main benefits of component composition. This directly affects scalability.
S

rtt_dot_service feedback

On Mon, 17 Oct 2011, S Roderick wrote:

> On Oct 17, 2011, at 05:40 , Peter Soetens wrote:
>
>> On Monday 17 October 2011 02:11:21 Willy Lambert wrote:
>>> 2011/10/4 Peter Soetens <peter [..] ...>
>>>
>>>> I've run this service again for our euRobotics 'simulation' deployment
>>>> (see attachment)
>>>>
>>>> - Maybe instead of the connection name, we could indicate the connection
>>>> type instead. With the words 'buffer[size]' or 'data' for example. The
>>>> long names impair readability and don't give any extra information.
>>>> - Readability might improve if the arrows leaving an output port or
>>>> entering an input port would originate from the same point. I have no
>>>> idea to do this.. drawing another 'icon' which represents a port would
>>>> not guarantee that the port icon stays close to the component in the
>>>> drawing. - We might need another service to display peer connections. I
>>>> don't think its readable to show both.
>>>> - Ports of services are not done yet..? We could show services which have
>>>> ports as ovals as well, but again, these could be relocated far away by
>>>> the drawing algorithm.
>>>>
>>>> Anyway, very usable as it is... and independent of ROS :-)
>>>>
>>>> Peter
>>>
>>> FYI, here is a screen for a more connected scheme. Sorry for the size of
>>> the screen I can't do better for having the hole scheme.
>>
>> This shows again what composition of components is useful for as well...
>> providing clear overview of the system from the top level.
>
> Agreed completely! The ability to hierarchically compose/decompose a large system is one of the main benefits of component composition. This directly affects scalability.

Good to read that some of the major contributors to Orocos agree on this
need for introducing the primitive concept of "composition" into RTT! I
am looking forward to the patches that will make this happen... :-)

> S

Herman

rtt_dot_service feedback

2011/10/17 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>

> On Mon, 17 Oct 2011, S Roderick wrote:
>
> > On Oct 17, 2011, at 05:40 , Peter Soetens wrote:
> >
> >> On Monday 17 October 2011 02:11:21 Willy Lambert wrote:
> >>> 2011/10/4 Peter Soetens <peter [..] ...>
> >>>
> >>>> I've run this service again for our euRobotics 'simulation' deployment
> >>>> (see attachment)
> >>>>
> >>>> - Maybe instead of the connection name, we could indicate the
> connection
> >>>> type instead. With the words 'buffer[size]' or 'data' for example. The
> >>>> long names impair readability and don't give any extra information.
> >>>> - Readability might improve if the arrows leaving an output port or
> >>>> entering an input port would originate from the same point. I have no
> >>>> idea to do this.. drawing another 'icon' which represents a port would
> >>>> not guarantee that the port icon stays close to the component in the
> >>>> drawing. - We might need another service to display peer connections.
> I
> >>>> don't think its readable to show both.
> >>>> - Ports of services are not done yet..? We could show services which
> have
> >>>> ports as ovals as well, but again, these could be relocated far away
> by
> >>>> the drawing algorithm.
> >>>>
> >>>> Anyway, very usable as it is... and independent of ROS :-)
> >>>>
> >>>> Peter
> >>>
> >>> FYI, here is a screen for a more connected scheme. Sorry for the size
> of
> >>> the screen I can't do better for having the hole scheme.
> >>
> >> This shows again what composition of components is useful for as well...
> >> providing clear overview of the system from the top level.
> >
> > Agreed completely! The ability to hierarchically compose/decompose a
> large system is one of the main benefits of component composition. This
> directly affects scalability.
>
> Good to read that some of the major contributors to Orocos agree on this
> need for introducing the primitive concept of "composition" into RTT! I
> am looking forward to the patches that will make this happen... :-)
>

+1. Has there already been work on this ? It has been one of my first miss
in Orocos. Is there difficulties there ? Or is it a developper-time problem
?

>
> > S
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

rtt_dot_service feedback

On Oct 17, 2011, at 07:10 , Herman Bruyninckx wrote:

> On Mon, 17 Oct 2011, S Roderick wrote:
>
>> On Oct 17, 2011, at 05:40 , Peter Soetens wrote:
>>
>>> On Monday 17 October 2011 02:11:21 Willy Lambert wrote:
>>>> 2011/10/4 Peter Soetens <peter [..] ...>
>>>>
>>>>> I've run this service again for our euRobotics 'simulation' deployment
>>>>> (see attachment)
>>>>>
>>>>> - Maybe instead of the connection name, we could indicate the connection
>>>>> type instead. With the words 'buffer[size]' or 'data' for example. The
>>>>> long names impair readability and don't give any extra information.
>>>>> - Readability might improve if the arrows leaving an output port or
>>>>> entering an input port would originate from the same point. I have no
>>>>> idea to do this.. drawing another 'icon' which represents a port would
>>>>> not guarantee that the port icon stays close to the component in the
>>>>> drawing. - We might need another service to display peer connections. I
>>>>> don't think its readable to show both.
>>>>> - Ports of services are not done yet..? We could show services which have
>>>>> ports as ovals as well, but again, these could be relocated far away by
>>>>> the drawing algorithm.
>>>>>
>>>>> Anyway, very usable as it is... and independent of ROS :-)
>>>>>
>>>>> Peter
>>>>
>>>> FYI, here is a screen for a more connected scheme. Sorry for the size of
>>>> the screen I can't do better for having the hole scheme.
>>>
>>> This shows again what composition of components is useful for as well...
>>> providing clear overview of the system from the top level.
>>
>> Agreed completely! The ability to hierarchically compose/decompose a large system is one of the main benefits of component composition. This directly affects scalability.
>
> Good to read that some of the major contributors to Orocos agree on this
> need for introducing the primitive concept of "composition" into RTT! I
> am looking forward to the patches that will make this happen... :-)

Come on, Herman! You know I like to go blind trying staring at a graph of our 60+ component systems ... ;-)

rtt_dot_service feedback

2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>

>
>
> 2011/10/5 Steven Bellens <steven [dot] bellens [..] ...>
>
>> 2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>:
>> >
>> >
>> > 2011/10/5 Peter Soetens <peter [..] ...>
>> >>
>> >> On Tue, Oct 4, 2011 at 11:35 PM, Steven Bellens
>> >> <steven [dot] bellens [..] ...> wrote:
>> >>>
>> >>> 2011/10/4 Peter Soetens <peter [..] ...>:
>> >>> > I've run this service again for our euRobotics 'simulation'
>> deployment
>> >>> > (see
>> >>> > attachment)
>> >>> > - Maybe instead of the connection name, we could indicate the
>> >>> > connection
>> >>> > type instead. With the words 'buffer[size]' or 'data' for example.
>> The
>> >>> > long
>> >>> > names impair readability and don't give any extra information.
>> >>>
>> >>> Agree, tried to implement it but didn't test is extensively though.
>> >>
>> >> Bugfix for this in attachment :-)
>> >>
>> >>>
>> >>> > - Readability might improve if the arrows leaving an output port or
>> >>> > entering
>> >>> > an input port would originate from the same point. I have no idea to
>> do
>> >>> > this.. drawing another 'icon' which represents a port would not
>> >>> > guarantee
>> >>> > that the port icon stays close to the component in the drawing.
>> >>>
>> >>> Pretty easy, edges accept a tailport and headport argument, which you
>> >>> can set to any direction (n,e,s,w,ne, etc..). Done.
>> >>
>> >> It doesn't group them by port.
>> >>
>> >>>
>> >>> > - We might need another service to display peer connections. I don't
>> >>> > think
>> >>> > its readable to show both.
>> >>>
>> >>> We might be able to display peers with the same contour colors maybe?
>> >>
>> >> I don't see how this could work.
>> >>
>> >>>
>> >>> > - Ports of services are not done yet..? We could show services which
>> >>> > have
>> >>> > ports as ovals as well, but again, these could be relocated far away
>> by
>> >>> > the
>> >>> > drawing algorithm.
>> >>>
>> >>> DOT has subgraphs, but I never worked with those either. Might offer a
>> >>> solution for this problem.
>> >>>
>> >>> > Anyway, very usable as it is... and independent of ROS :-)
>> >>>
>> >>> Now start using it :)
>> >>
>> >> :-)
>> >> Peter
>> >>
>> >
>> > I tried this on a little example, it works fine here. I love it. I'll
>> try
>> > this on a hudge example as soon as my app is working under xenomai ;)
>> > It is a must have for the default Orocos installation, and more, I would
>> put
>> > it by default in the deployer.
>> > The only suggestion for now would be to enlarge the size of "Component"
>> > drawing if it is possible. Cause in a heavily connected application
>> you'll
>> > need some space to connect ports and it would be more readable if you
>> can
>> > find components easily
>>
>> I've put the dot syntax arguments as properties for drawing
>> components, connections and channels - so you can play with it
>> yourself to get the graph you like most.
>> If anyone wants to implement service ports as well, feel free to send
>> patches - I don't have any more time for it in the near future myself.
>>
>>
> Great I have big bubles now ;)
>
>
Is it possible to modify those properties from Lua ?
I tried this :
Deployer:provides("dot"):getProperty("comp_args"):set("style=filled,width=5,height=3.5")

and this
print(Deployer:provides("dot"))

which prints :
Service: dot
Subservices:
Operations: generate, getOwnerName
Ports:

so I wonder if Lua know how to get a property in a servcie ?

>
>
>> Steven
>>
>> >
>> >>
>> >>
>> >> --
>> >> Orocos-Dev mailing list
>> >> Orocos-Dev [..] ...
>> >> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>> >>
>> >
>> >
>>
>
>

rtt_dot_service feedback

Hi Willy,

On Wed, Oct 12, 2011 at 06:13:19PM +0200, Willy Lambert wrote:
> 2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>
>
>
>
> 2011/10/5 Steven Bellens <steven [dot] bellens [..] ...>
>
> 2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>:
...

> I've put the dot syntax arguments as properties for drawing
> components, connections and channels - so you can play with it
> yourself to get the graph you like most.
> If anyone wants to implement service ports as well, feel free to send
> patches - I don't have any more time for it in the near future myself.
>
>
>
> Great I have big bubles now ;)
>
>
>
> Is it possible to modify those properties from Lua ?
> I tried this :
> Deployer:provides("dot"):getProperty("comp_args"):set("style=filled,width=
> 5,height=3.5")
>
> and this
> print(Deployer:provides("dot"))
>
> which prints :
> Service: dot
> Subservices:
> Operations: generate, getOwnerName
> Ports:
>
> so I wonder if Lua know how to get a property in a servcie ?

I have not added property (and port) service access yet, but its
trivial and high on the todo list...

Markus

rtt_dot_service feedback

2011/10/12 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>

> Hi Willy,
>
> On Wed, Oct 12, 2011 at 06:13:19PM +0200, Willy Lambert wrote:
> > 2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>
> >
> >
> >
> > 2011/10/5 Steven Bellens <steven [dot] bellens [..] ...>
> >
> > 2011/10/5 Willy Lambert <lambert [dot] willy [..] ...>:
> ...
>
> > I've put the dot syntax arguments as properties for drawing
> > components, connections and channels - so you can play with it
> > yourself to get the graph you like most.
> > If anyone wants to implement service ports as well, feel free to
> send
> > patches - I don't have any more time for it in the near future
> myself.
> >
> >
> >
> > Great I have big bubles now ;)
> >
> >
> >
> > Is it possible to modify those properties from Lua ?
> > I tried this :
> >
> Deployer:provides("dot"):getProperty("comp_args"):set("style=filled,width=
> > 5,height=3.5")
> >
> > and this
> > print(Deployer:provides("dot"))
> >
> > which prints :
> > Service: dot
> > Subservices:
> > Operations: generate, getOwnerName
> > Ports:
> >
> > so I wonder if Lua know how to get a property in a servcie ?
>
> I have not added property (and port) service access yet, but its
> trivial and high on the todo list...
>

Ok, I found a workaround. Let me know as soon as it is available

>
> Markus
>