I know I already asked once, but things have evolved and I would like to
ask again.
At the same time that we migrate to RTT2 and the updated toolchain, we
also publish some (hopefully, most of) our software. We decided to call
the project the Robot construction kit (or rock).
We will use a separate webspace at rock-robotics.org to hold the
documentation, and probably a wiki (that's left to be decided). However,
there is the matter of the mailing list.
Given the low bandwidth of orocos-users, I would rather use it for Rock
as well, and have a separate rock-dev mailing list for the development
(which, I hope, will become higher-bandwidth). I don't see the point,
right now, of completely splitting the communities.
However, as I am definitely am not the owner of the ML(s), I feel
compelled to ask ;-)
Using orocos-dev and orocos-users for a separate project ?
On Thursday 25 November 2010 19:16:26 Sylvain Joyeux wrote:
> I know I already asked once, but things have evolved and I would like to
> ask again.
>
> At the same time that we migrate to RTT2 and the updated toolchain, we
> also publish some (hopefully, most of) our software. We decided to call
> the project the Robot construction kit (or rock).
>
> We will use a separate webspace at rock-robotics.org to hold the
> documentation, and probably a wiki (that's left to be decided). However,
> there is the matter of the mailing list.
>
> Given the low bandwidth of orocos-users, I would rather use it for Rock
> as well, and have a separate rock-dev mailing list for the development
> (which, I hope, will become higher-bandwidth). I don't see the point,
> right now, of completely splitting the communities.
>
> However, as I am definitely am not the owner of the ML(s), I feel
> compelled to ask ;-)
To get the picture clear: you're in the process of renaming 'orocos-dfki' to
'rock-robotics' ?
Since rock-users are orocos-users at the same time, I don't see a problem.
*The* problem I see for the future is to communicate a clear workflow. Where
should new users start ? Trying a ruby model/deployment ? Create a C++
component + deployer ? Use the ROS package tree layout ? Or is there an
'Orocos for ROS' users and an 'Orocos for ROCK' users workflow ? Does ROCK
work on Windows ?
I don't want to spent time in battles between 'the best' workflow. I do believe
that there is a good argument for any of these. So this question is more about
how to lead the user to the tool that solves his problem best. I was thinking
of creating the 'RTT' cheat-sheet with a similar workflow as oroGen. Maybe we
need a similar document for the big picture...
Peter
PS: The link on the main page of 'orocos.rb' to running/index.html should
point to runtime/index.html . This link error has been there for a while...
Using orocos-dev and orocos-users for a separate project ?
> To get the picture clear: you're in the process of renaming 'orocos-dfki' to
> 'rock-robotics' ?
That's correct.
> Since rock-users are orocos-users at the same time, I don't see a problem.
>
> *The* problem I see for the future is to communicate a clear workflow. Where
> should new users start ? Trying a ruby model/deployment ? Create a C++
> component + deployer ? Use the ROS package tree layout ? Or is there an
> 'Orocos for ROS' users and an 'Orocos for ROCK' users workflow ? Does ROCK
> work on Windows ?
It is 'rock', not ROCK (sorry, I really don't like reading uppercase, I
always have the impression that the word is screaming at me :P).
And yes, there will be an orocos for ros workflow and an orocos for rock
workflow. And a "C++ component + deployer" workflow.
Note that the C++ component + typegen + deployer workflow could kind-of
work with orocos.rb. Or even the supervision layer up to a certain point
(i.e. management + monitoring, only the automated dataflow network
generation requires orogen specs). Just not high in my priority list, so
someone would have to contribute that.
Rock does has been demonstrated to work on windows as a proof of
concept, but it is not maintained / not streamlined. I.e. don't expect a
"install rock on windows" page anytime soon. However, I do want to get a
streamlined experience on macosx since some people here start to use
autoproj and are on OSX.
> I don't want to spent time in battles between 'the best' workflow. I do believe
> that there is a good argument for any of these. So this question is more about
> how to lead the user to the tool that solves his problem best. I was thinking
> of creating the 'RTT' cheat-sheet with a similar workflow as oroGen. Maybe we
> need a similar document for the big picture...
From my POV, it is a matter of application. If someone comes to me with
an indoor, dual-arm manipulator that he needs to integrate, I would
point him to ros. Some people at dfki have exactly done that.
If he comes because he needs some algorithms but has its own integration
framework and/or its own build system, I would also point him to rock.
Because that's a design constraint on rock: algorithms in
non-orocos-specific libraries and using a standard cmake + pkgconfig
workflow.
If he comes to me with an underwater vehicle or with a field robotics
application, I would tell him to have a look at rock.
If he is doing research in DSLs and architecture, I would also point him
to rock, but I am obviously biased.
Finally, if someone tells me that he is in the "I write my C++
components myself", the only argument I personally accept as valid is
legacy. I don't see the point of writing boilerplate code manually. And
not have decent logging and replay tooling. And and and ...
> PS: The link on the main page of 'orocos.rb' to running/index.html should
> point to runtime/index.html . This link error has been there for a while...
Ah ... thanks. Fixed now
Sylvain