Dear All,
I have been thinking about the open question of having a tool to simulate the robots.
First of all, we should consider that a simulation has three main components:
1) 3D visualization
2) dynamic calculation
3) collision detection (to be coupled with dynamic calculation).
I know that Herman was suggesting to use Blender, but I personally believe that we are converting something that was not intended for robotics into something different (which might take a long time to be accomplished professionally).
I would like to know the opinion of the community of Orocos about a different approach: to JOIN FORCES with other projects with similar goals: OpenHRP3 and/or OpenRAVE.
I have excluded other simulators such as Gazebo, which looks less mature and not very active in the development.
Both the simulation softwares seem very modular: OpenRAVE is based on plug-ins which can be changed by the user (so you are not obliged to use just a single visualizer, dynamic solver or collision detection) and OpenHRP3, as well, separates the three elements in different server clients who communicate through CORBA (OmniORB actually:) ).
My question is: why don't we adopt one of this projects as standard visualization/simulation environment for Orocos? In the same way that we expect that people use Orocos instead of re-inventing the wheel, we should reuse the work of other groups!!! (i.e. be coherent..)
Of course, the following elements must be compatible with the Orocos philosophy:
A) licensing should be open-source but compatible with commercial applications.
B) the software should be modular: we do not want any algorithm in the simulation package such as navigation/manipulation/etc
C) it would be nice to keep small the number of dependencies which are not in common with Orocos to reduce the troubles of the users...
I am looking forward for your feedback.
Davide
OpenRave, OpenHRP3, or...
On Wednesday 25 February 2009 13:35:53 faconti [..] ... wrote:
> Dear All,
>
> I have been thinking about the open question of having a tool to simulate
> the robots.
As a user, I'm very in favour of such tools. The best visualisation we have
now is the ReportingComponent + kst, which is a necessary tool for data port
analysis, but not for anything more.
The reality is that as a developer, I can't (because of time budget)
coordinate the effort around the integration of these tools with the RTT. Just
like I don't get involved much in the OpenCV or KDL discussions.
So please don't wait for my approval or comments on these topics, I'll gladly
take the RTT side of things in the integration story, but you guys need to
pull this as a whole.
Peter
OpenRave, OpenHRP3, or...
On Wednesday, February 25, 2009, at 01:02PM, "Davide Faconti" <faconti [..] ...> wrote:
>1) the community NEEDS _as_soon_as_possible_ to have some kind of
>simulation/visualizer. This would make Orocos much more popular and it
>would help to get more community involved into the development of the
>project.
>Please note that I am trying to talk for a larger of final users than
>ourselves (actually I do have my own simulator integrated already with
>Orocos).
Orocos is supposed to be a framework that easily allows integration of many other tools (including visualizers). I would think that providing better and more examples of how to plugin to existing visualizers would be more palatable to the masses, and to the minds behind the project. This then doesn't limit the options for end users.
>2) OpenRave already has video export and I don't think that the
>robotic community needs so much the rendering engine of Blender: they
>want to test if their robot can move and how it moves! This does not
>means that people will not like what Blender can offer, I just think
>that it is not urgent to have it. (But I must admit that keyframing
>would be very nice !!)
I disagree. We regularly need high-fidelity rendering of robots and other objects in the scene, and need a proper rendering engine to do this. It isn't just a debugging tool - in past jobs we've used high-fidelity simulations of robot scenarios to produce marketing-quality videos.
Stephen
OpenRave, OpenHRP3, or...
On Wed, 25 Feb 2009, faconti [..] ... wrote:
> I have been thinking about the open question of having a tool to simulate
> the robots. First of all, we should consider that a simulation has three
> main components:
>
> 1) 3D visualization
> 2) dynamic calculation
> 3) collision detection (to be coupled with dynamic calculation).
>
> I know that Herman was suggesting to use Blender, but I personally
> believe that we are converting something that was not intended for
> robotics into something different (which might take a long time to be
> accomplished professionally).
It has a lot of manpower behind it, _and_ it works closely with the Bullet
project <http://www.bulletphysics.com/Bullet/wordpress /> which is used by
Sony for its PS3 game support.
> I would like to know the opinion of the community of Orocos about a
> different approach: to JOIN FORCES with other projects with similar
> goals: OpenHRP3 and/or OpenRAVE.
OpenHRP3 makes software available but is not open source projects: I have
never been able to discuss things with developers on a mailinglist for
example...
OpenRAVE is better in that respect, but it is reinventing the 3D graphics
wheels...
> I have excluded other simulators such as Gazebo, which looks less mature
> and not very active in the development.
>
> Both the simulation softwares seem very modular: OpenRAVE is based on
> plug-ins which can be changed by the user (so you are not obliged to use
> just a single visualizer, dynamic solver or collision detection) and
> OpenHRP3, as well, separates the three elements in different server
> clients who communicate through CORBA (OmniORB actually:) ).
>
> My question is: why don't we adopt one of this projects as standard
> visualization/simulation environment for Orocos?
Because I don't believe that their vision is not long-term and
application-independent enough.
But the core idea of orocos is that it is (and wants to stay) fully
decoupled from other complementary projects, while working on
interoperability. So, each of these projects could be made to work with
orocos, and/or the other way around, without having them becoming a part of
Orocos (or the other way around).
> In the same way that we
> expect that people use Orocos instead of re-inventing the wheel, we
> should reuse the work of other groups!!! (i.e. be coherent..)
> Of course, the following elements must be compatible with the Orocos philosophy:
>
> A) licensing should be open-source but compatible with commercial applications.
That's okay for the ones you mention.
> B) the software should be modular: we do not want any algorithm in the simulation package such as navigation/manipulation/etc
Okay too.
> C) it would be nice to keep small the number of dependencies which are
> not in common with Orocos to reduce the troubles of the users...
Okay too.
But my "vision" remark remains an important "D)"... :-)
Herman
> I am looking forward for your feedback.
>
> Davide
>
OpenRave, OpenHRP3, or...
It has a lot of manpower behind it, _and_ it works closely with the Bullet project
This is interesting. Is there any timeframe for the first release?
OpenHRP3 makes software available but is not open source projects: I have never been able to discuss things with developers on a mailinglist for example...
This is a serious drawback!
OpenRAVE is better in that respect, but it is reinventing the 3D graphics wheels...
I am not sure that I get what you means. Apparently it is using the Coin3D engine and it is not reinventing anything. It is also very welcome that 3D visualization is a plug-in, so your are not obliged to use it if you don't like their double-license.
Because I don't believe that their vision is not long-term and application-independent enough.
But the core idea of orocos is that it is (and wants to stay) fully decoupled from other complementary projects, while working on interoperability. So, each of these projects could be made to work with orocos, and/or the other way around, without having them becoming a part of Orocos (or the other way around).
The two projects can become complementary in the same way that BFL is complementary to RTT: you can have just 1 of them of you can make work them together...
About being application-independent, I should admit that I don't like that OpenRAVE integrates kinematic solvers and path planning in its inner structure... should be ask them for a more decoupled framework or may be shall be fork?
OpenRave, OpenHRP3, or...
On Wed, 25 Feb 2009, faconti [..] ... wrote:
>
> It has a lot of manpower behind it, _and_ it works closely with the Bullet project <http://www.bulletphysics.com/Bullet/wordpress /> which is used by Sony for its PS3 game support.
>
>
> This is interesting. Is there any timeframe for the first release?
Probably, but I don't follow this evolution closely. Mainly because it
involves the alternative approach to dynamic simulation, that is the
"Impulse based method" <http://en.wikipedia.org/wiki/Physics_engine>, while
I am more interested in the minimal parameter closed-form approach.
>
> OpenHRP3 makes software available but is not open source projects: I have never been able to discuss things with developers on a mailinglist for example...
>
> This is a serious drawback!
>
>
> OpenRAVE is better in that respect, but it is reinventing the 3D graphics wheels...
>
> I am not sure that I get what you means. Apparently it is using the
> Coin3D engine and it is not reinventing anything. It is also very welcome
> that 3D visualization is a plug-in, so your are not obliged to use it if
> you don't like their double-license.
What I mean is that there is a _long_ way between being able to show a 3D
figure on screen to a software package that has useful tools around that:
key framing, video and still rendering, interpolation curves, material
texturing, etc.
>
> Because I don't believe that their vision is not long-term and application-independent enough.
> But the core idea of orocos is that it is (and wants to stay) fully decoupled from other complementary projects, while working on interoperability. So, each of these projects could be made to work with orocos, and/or the other way around, without having them becoming a part of Orocos (or the other way around).
>
>
> The two projects can become complementary in the same way that BFL is complementary to RTT: you can have just 1 of them of you can make work them together...
Yes, but interoperability requires cooperation from _both_ sides! For
example, providing language- and platform neutral interfaces, that are as
small as possible. That's though, also from the Orocos point of view, and
that is certainly something where collaboration with other projects would
help _a lot_ :-) The important thing is to find someone from these other
projects who wants to discuss with us, try out some Orocos concepts and
code, etc.
> About being application-independent, I should admit that I don't like
> that OpenRAVE integrates kinematic solvers and path planning in its inner
> structure... should be ask them for a more decoupled framework or may be
> shall be fork?
The "F" word! :-) Forking is absolutely the last thing to do, because that
reduces the critical mass even further... But unfortunately that's what I
see happening all the time, especially in the "communication middleware"
arena. 3D simulation is becoming a "worthy" contender... :-(
In summary: cooperation, yes! But that will only work with committed people
at the other side. For the Blender-Orocos interoperability, for example, I
have hired a Blender developer part time, and we know already that it will
be very hard and a lot of work. (Also LAAS in France is hiring a Blender
developer.)
A remark: "end users" such as your company, or Willow Garage etc, are the
best stakeholders to drive the interoperability issues, since (i) you have
most the gain from it, and (ii) you know best where interoperability is
failing, and why. So, please, go ahead with your quest for inter-project
cooperation! You have my full (but critical) support :-)
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
OpenRave, OpenHRP3, or...
>> I am not sure that I get what you means. Apparently it is using the
>> Coin3D engine and it is not reinventing anything. It is also very welcome
>> that 3D visualization is a plug-in, so your are not obliged to use it if
>> you don't like their double-license.
>
> What I mean is that there is a _long_ way between being able to show a 3D
> figure on screen to a software package that has useful tools around that:
> key framing, video and still rendering, interpolation curves, material
> texturing, etc.
>
I see what you mean, but there is something that you should consider:
1) the community NEEDS _as_soon_as_possible_ to have some kind of
simulation/visualizer. This would make Orocos much more popular and it
would help to get more community involved into the development of the
project.
Please note that I am trying to talk for a larger of final users than
ourselves (actually I do have my own simulator integrated already with
Orocos).
2) OpenRave already has video export and I don't think that the
robotic community needs so much the rendering engine of Blender: they
want to test if their robot can move and how it moves! This does not
means that people will not like what Blender can offer, I just think
that it is not urgent to have it. (But I must admit that keyframing
would be very nice !!)
> Yes, but interoperability requires cooperation from _both_ sides! For
> example, providing language- and platform neutral interfaces, that are as
> small as possible. That's though, also from the Orocos point of view, and
> that is certainly something where collaboration with other projects would
> help _a lot_ :-) The important thing is to find someone from these other
> projects who wants to discuss with us, try out some Orocos concepts and
> code, etc.
I agree! Actually, by next e-mail will be sent to people of the
OpenRave project.
> A remark: "end users" such as your company, or Willow Garage etc, are the
> best stakeholders to drive the interoperability issues, since (i) you have
> most the gain from it, and (ii) you know best where interoperability is
> failing, and why. So, please, go ahead with your quest for inter-project
> cooperation! You have my full (but critical) support :-)
>
I am looking forward for your critical support :D
Davide
OpenRave, OpenHRP3, or...
On Wed, 25 Feb 2009, S Roderick wrote:
> On Wednesday, February 25, 2009, at 01:02PM, "Davide Faconti" <faconti [..] ...> wrote:
>
>> 1) the community NEEDS _as_soon_as_possible_ to have some kind of
>> simulation/visualizer. This would make Orocos much more popular and it
>> would help to get more community involved into the development of the
>> project.
>> Please note that I am trying to talk for a larger of final users than
>> ourselves (actually I do have my own simulator integrated already with
>> Orocos).
>
> Orocos is supposed to be a framework that easily allows integration of
> many other tools (including visualizers). I would think that providing
> better and more examples of how to plugin to existing visualizers would
> be more palatable to the masses, and to the minds behind the project.
> This then doesn't limit the options for end users.
I agree! And I am looking for internship students or similar man power to
take care of this... Let me know if one of your students could be tempted
into spending his/her down-under winter in Leuven!
Herman
>> 2) OpenRave already has video export and I don't think that the
>> robotic community needs so much the rendering engine of Blender: they
>> want to test if their robot can move and how it moves! This does not
>> means that people will not like what Blender can offer, I just think
>> that it is not urgent to have it. (But I must admit that keyframing
>> would be very nice !!)
>
> I disagree. We regularly need high-fidelity rendering of robots and other
> objects in the scene, and need a proper rendering engine to do this. It
> isn't just a debugging tool - in past jobs we've used high-fidelity
> simulations of robot scenarios to produce marketing-quality videos.
>
> Stephen
>
OpenRave, OpenHRP3, or...
On Wed, 25 Feb 2009, Davide Faconti wrote:
>>> I am not sure that I get what you means. Apparently it is using the
>>> Coin3D engine and it is not reinventing anything. It is also very welcome
>>> that 3D visualization is a plug-in, so your are not obliged to use it if
>>> you don't like their double-license.
>>
>> What I mean is that there is a _long_ way between being able to show a 3D
>> figure on screen to a software package that has useful tools around that:
>> key framing, video and still rendering, interpolation curves, material
>> texturing, etc.
>>
>
> I see what you mean, but there is something that you should consider:
>
> 1) the community NEEDS _as_soon_as_possible_ to have some kind of
> simulation/visualizer.
Of course, and Blender can do the job! We have made already dozens of
visualisation with it, by a simple coupling at the joint angle level: an
Orocos reporting TaskContext makes TCP packets that contain join angles,
and a Python script in Blender reads them in and makes a robot model move.
> This would make Orocos much more popular and it
> would help to get more community involved into the development of the
> project.
I fully agree. That was my personal motivation behind my advocacy for
Blender :-)
> Please note that I am trying to talk for a larger of final users than
> ourselves (actually I do have my own simulator integrated already with
> Orocos).
>
> 2) OpenRave already has video export and I don't think that the
> robotic community needs so much the rendering engine of Blender: they
> want to test if their robot can move and how it moves! This does not
> means that people will not like what Blender can offer, I just think
> that it is not urgent to have it. (But I must admit that keyframing
> would be very nice !!)
I have seen it so many times (in open source or in commercial software):
people start a new project because the existing ones are (i) not _exactly_
doing what they want, and (ii) are doing "too much we don't need". Before
they know it they are (i) struggling to get their own thing do _exactly_
what they want, and (ii) re-invent the things they were not needing
before...
So, I think only the project with the largest community, the most
ambitious roadmap, and the best infrastructure for interoperability should
be supported. And until you or someone else convinces me of the opposite
with hard facts, Blender wins hands down on all three items. Especially
taking into account their current refactoring towards 2.50:
<http://www.blender.org/development/current-projects/blender-25-project />
I read so many things that will improve modularity, customizability without
compromising interoperability, and openness to other projects...
Herman
>> Yes, but interoperability requires cooperation from _both_ sides! For
>> example, providing language- and platform neutral interfaces, that are as
>> small as possible. That's though, also from the Orocos point of view, and
>> that is certainly something where collaboration with other projects would
>> help _a lot_ :-) The important thing is to find someone from these other
>> projects who wants to discuss with us, try out some Orocos concepts and
>> code, etc.
>
> I agree! Actually, by next e-mail will be sent to people of the
> OpenRave project.
>
>> A remark: "end users" such as your company, or Willow Garage etc, are the
>> best stakeholders to drive the interoperability issues, since (i) you have
>> most the gain from it, and (ii) you know best where interoperability is
>> failing, and why. So, please, go ahead with your quest for inter-project
>> cooperation! You have my full (but critical) support :-)
>>
>
> I am looking forward for your critical support :D
>
>
> Davide
>