From: Toby C. <tco...@pl...> - 2008-06-28 22:35:56
|
Hi all, I can't help but notice that the functionality of Stage and Gazebo have a lot of overlap. Both now use opengl for rendering (different toolkits, but same basic tech). Both have code to provide sensing in the world model, and both have some sort of physics model and controllers. The major difference is of course in the physics layer. With Gazebo's PAL (physics abstraction layer) branch, would it be possible to effectively combine the two projects, make one simulator with gazebo and stage physics layers. If anything is possible here, it would probably be the versions after Stage 3 and gazebo 0.8, but thought I would float the idea and see what the feeling out there was. It is possible that I might be able to find a summer Intern to work on the initial stages of this (our summer is Nov->Feb), but only if there is interest amongst the developers as well. Toby P.S. I didnt cross post to the Gazebo list, if it is felt that it should be feel free to do so. -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Richard V. <va...@sf...> - 2008-06-29 01:20:47
|
Gz and Stg are very different, despite the similarities you mention. For example, Gz's OpenGL stuff is behind a scenegraph library, so there's not much in common in the application-level graphics code. I can see an advantage in a lightweight physics model for Gazebo, and also in a simplified Gz worldfile wrapper (probably requiring some restrictions on 3D geometry, like Stage). Maybe Stage code can be cannibalized towards that? It might be hard to splice them without adding a lot of complexity to both. The main advantage of Stage right now, if you can live without Gz's dynamics, real 3D and texture mapping, is the ease of runtime configuration (i.e. simple worldfile syntax), speed and scalability (O(1) models) and ease of building. Richard/ On Sat, Jun 28, 2008 at 3:36 PM, Toby Collett <tco...@pl...> wrote: > Hi all, > I can't help but notice that the functionality of Stage and Gazebo have a > lot of overlap. Both now use opengl for rendering (different toolkits, but > same basic tech). Both have code to provide sensing in the world model, and > both have some sort of physics model and controllers. The major difference > is of course in the physics layer. > > With Gazebo's PAL (physics abstraction layer) branch, would it be possible > to effectively combine the two projects, make one simulator with gazebo and > stage physics layers. If anything is possible here, it would probably be the > versions after Stage 3 and gazebo 0.8, but thought I would float the idea > and see what the feeling out there was. It is possible that I might be able > to find a summer Intern to work on the initial stages of this (our summer is > Nov->Feb), but only if there is interest amongst the developers as well. > > Toby > > P.S. I didnt cross post to the Gazebo list, if it is felt that it should be > feel free to do so. > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > -- Richard Vaughan Autonomy Lab / Computing Science / Simon Fraser University |
From: Reed H. <re...@mo...> - 2008-07-02 15:53:52
|
> The main advantage of Stage right now, if you can live without > Gz's dynamics, real 3D and texture mapping, is the ease of runtime > configuration (i.e. simple worldfile syntax), speed and scalability > (O(1) models) and ease of building. The most important things to me are speed and scalability, portability, and also usability. So when (if) I move to Stage 3, the main things I will be trying to do is to make sure it's usable with or without 3D hardware, on several platforms, and optionally without any kind of graphical layer (in fact, as a background daemon), and (in the no-gui option at least) can still run a hundred robots or so. I do think it makes sense to have two different things for two different tasks: Gazebo for physical simulation and full 3D, Stage for more simplified interaction and not full 3D (still based on a more or less planar universe). However, there is certainly overlap here and maybe they can share a "simulation kernel" ("engine") or something like that... or at least some utility libraries, perhaps share the same robot and world definition formats? (with each ignoring the parts that aren't relevant.) I suppose the two focuses could be modes of the same actual program, though (if it used plugins to avoid depending on lots of extra libraries like Ogre or ODE if they aren't going to be used), or compiled from the same source. Reed |
From: Richard V. <va...@sf...> - 2008-07-02 16:23:18
|
On Wed, Jul 2, 2008 at 8:53 AM, Reed Hedges <re...@mo...> wrote: > >> The main advantage of Stage right now, if you can live without >> Gz's dynamics, real 3D and texture mapping, is the ease of runtime >> configuration (i.e. simple worldfile syntax), speed and scalability >> (O(1) models) and ease of building. > > The most important things to me are speed and scalability, portability, and also > usability. > > So when (if) I move to Stage 3, the main things I will be trying to do is to > make sure it's usable with or without 3D hardware Probably not without, as it uses OpenGL extensively now. Runs like a dog on a MacBook Air but very nicely on my MacPook Pro. I plan to try it on a MacBook (a typical student PC) to see if it's reasonable. > on several platforms Everything except Windows right now, and hopefully Windows from 3.0.[small number > 0] if a maintaining volunteer emerges. , and > optionally without any kind of graphical layer yes > (in fact, as a background daemon), it doesn't provide any services to external processes unless plugged into Player > and (in the no-gui option at least) can still run a hundred robots or so. I reckon roughly 100 Pioneer + SICK or 1,000 little robots with sonar/IR in real time. > I do think it makes sense to have two different things for two different tasks: > Gazebo for physical simulation and full 3D, Stage for more simplified > interaction and not full 3D (still based on a more or less planar universe). > > However, there is certainly overlap here and maybe they can share a "simulation > kernel" ("engine") or something like that... or at least some utility libraries, > perhaps share the same robot and world definition formats? (with each ignoring > the parts that aren't relevant.) So they should simulate different things but share a simulation engine? That sounds tough. Also, though XML has some nice properties, human usability is not one of them. World files are intended to be edited by hand, and this is hard work in Gazebo, > I suppose the two focuses could be modes of the same actual program, though (if > it used plugins to avoid depending on lots of extra libraries like Ogre or ODE > if they aren't going to be used), or compiled from the same source. I still need a lot of convincing that this could be useful and not send the code complexity through the roof. Richard/ > > Reed > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Richard Vaughan Autonomy Lab / Computing Science / Simon Fraser University |
From: Reed H. <re...@mo...> - 2008-07-02 16:33:07
|
Richard Vaughan wrote: >> So when (if) I move to Stage 3, the main things I will be trying to do is to >> make sure it's usable with or without 3D hardware > > Probably not without, as it uses OpenGL extensively now. Runs like a > dog on a MacBook Air but very nicely on my MacPook Pro. I plan to try > it on a MacBook (a typical student PC) to see if it's reasonable. Hmm, really? Then I will have to plan on basically forking Stage (from 2), or writing an alternate graphics layer for Stage 3... > it doesn't provide any services to external processes unless plugged into Player > Right > So they should simulate different things but share a simulation > engine? I don't know anything about how Gazebo operations, but was guessing that there is some kind of infrastructure that does something similar as stage's model system and update loop. Maybe not useful as a shared thing though. > Also, though XML has some nice properties, > human usability is not one of them. World files are intended to be > edited by hand, and this is hard work in Gazebo, I would agree. A tool would be needed to edit them (could be built in). Reed |
From: Richard V. <va...@sf...> - 2008-07-02 16:57:44
|
On Wed, Jul 2, 2008 at 9:33 AM, Reed Hedges <re...@mo...> wrote: > Richard Vaughan wrote: >>> So when (if) I move to Stage 3, the main things I will be trying to do is to >>> make sure it's usable with or without 3D hardware >> >> Probably not without, as it uses OpenGL extensively now. Runs like a >> dog on a MacBook Air but very nicely on my MacPook Pro. I plan to try >> it on a MacBook (a typical student PC) to see if it's reasonable. > > Hmm, really? Then I will have to plan on basically forking Stage (from 2), or > writing an alternate graphics layer for Stage 3... > I am really unhappy with the Air performance. I profiled to see what was going on, and Stage spends its time in a thread that doesn't exist when running on the MB Pro - probably software rendering. Stage runs very fast on 5-year old graphics hardware, so any acceleration seems to be enough. A port to using FLTK's native drawing would be possible, but I don't know if it would perform any better. I decided that assuming modest acceleration is OK. We have only one machine in the lab without it - my fancy new laptop! Richard/ > >> it doesn't provide any services to external processes unless plugged into Player >> > > Right > > > >> So they should simulate different things but share a simulation >> engine? > > I don't know anything about how Gazebo operations, but was guessing that there > is some kind of infrastructure that does something similar as stage's model > system and update loop. Maybe not useful as a shared thing though. > > >> Also, though XML has some nice properties, >> human usability is not one of them. World files are intended to be >> edited by hand, and this is hard work in Gazebo, > > I would agree. A tool would be needed to edit them (could be built in). > > Reed > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Richard Vaughan Autonomy Lab / Computing Science / Simon Fraser University |
From: Toby C. <tco...@pl...> - 2008-07-02 20:19:55
|
My thought around merging some of the parts of stage/gazebo was particularly the sensing. There has been a lot of talk over the years about sensor noise, and no really good general solution for adding noise models, this is something that if done right could be reused in both stage and Gazebo. This thought then lead down the other similarities, although not as pronounced. I guess what I was thinking was something like splitting stage and gazebo into several libraries each that could be interchanged easily. My first guess for the layers would be. (1) A common core that does all the background work. (2) A physics simulation, just collisions for stage I think, ODE/PAL for gazebo version (3) A sensor module (this could be shared, or could have noiseless and advanced filters?) (4) A rendering module, optional to run headless, 2d and 3d versions etc There would need to be well defined interfaces for each of the subsystems, basically stage and gazebo would become a collection of plugins for a new simulation system. The nice thing about an approach like this is that stage and gazebo could continue to exist as is with a bit of refactoring to meet the defined interfaces as they are largely designed this way as it is. Of course it would not be worth undertaking if it didn't excite others :), maybe a summer of code project? Toby 2008/7/3 Richard Vaughan <va...@sf...>: > On Wed, Jul 2, 2008 at 9:33 AM, Reed Hedges <re...@mo...> wrote: > > Richard Vaughan wrote: > >>> So when (if) I move to Stage 3, the main things I will be trying to do > is to > >>> make sure it's usable with or without 3D hardware > >> > >> Probably not without, as it uses OpenGL extensively now. Runs like a > >> dog on a MacBook Air but very nicely on my MacPook Pro. I plan to try > >> it on a MacBook (a typical student PC) to see if it's reasonable. > > > > Hmm, really? Then I will have to plan on basically forking Stage (from > 2), or > > writing an alternate graphics layer for Stage 3... > > > > I am really unhappy with the Air performance. I profiled to see what > was going on, and Stage spends its time in a thread that doesn't exist > when running on the MB Pro - probably software rendering. > > Stage runs very fast on 5-year old graphics hardware, so any > acceleration seems to be enough. > > A port to using FLTK's native drawing would be possible, but I don't > know if it would perform any better. I decided that assuming modest > acceleration is OK. We have only one machine in the lab without it - > my fancy new laptop! > > Richard/ > > > > >> it doesn't provide any services to external processes unless plugged > into Player > >> > > > > Right > > > > > > > >> So they should simulate different things but share a simulation > >> engine? > > > > I don't know anything about how Gazebo operations, but was guessing that > there > > is some kind of infrastructure that does something similar as stage's > model > > system and update loop. Maybe not useful as a shared thing though. > > > > > >> Also, though XML has some nice properties, > >> human usability is not one of them. World files are intended to be > >> edited by hand, and this is hard work in Gazebo, > > > > I would agree. A tool would be needed to edit them (could be built in). > > > > Reed > > > > > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source project, > > along with a healthy diet, reduces your potential for chronic lameness > > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > > -- > Richard Vaughan > Autonomy Lab / Computing Science / Simon Fraser University > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Nate K. <nk...@us...> - 2008-07-10 15:57:54
|
Conceptually there are many parts of gazebo and stage that overlap. However, there is much less overlap once you look under the hood. Extensive work would be required to tie stage and gazebo together, and such a union might not be in the best interest of users and developers. Stage is at much more user-friendly and mature level than gazebo, and I have a feeling that merging the two would hinder development of both projects. That being said, there is no reason someone could develop sensor models that both stage and gazebo can use. For example, linking in a chunk of python code between sensor data generation and output to player would not be terribly difficult. -nate On Wed, Jul 2, 2008 at 1:20 PM, Toby Collett <tco...@pl...> wrote: > My thought around merging some of the parts of stage/gazebo was particularly > the sensing. There has been a lot of talk over the years about sensor noise, > and no really good general solution for adding noise models, this is > something that if done right could be reused in both stage and Gazebo. This > thought then lead down the other similarities, although not as pronounced. > > I guess what I was thinking was something like splitting stage and gazebo > into several libraries each that could be interchanged easily. My first > guess for the layers would be. > (1) A common core that does all the background work. > (2) A physics simulation, just collisions for stage I think, ODE/PAL for > gazebo version > (3) A sensor module (this could be shared, or could have noiseless and > advanced filters?) > (4) A rendering module, optional to run headless, 2d and 3d versions etc > > There would need to be well defined interfaces for each of the subsystems, > basically stage and gazebo would become a collection of plugins for a new > simulation system. The nice thing about an approach like this is that stage > and gazebo could continue to exist as is with a bit of refactoring to meet > the defined interfaces as they are largely designed this way as it is. > > Of course it would not be worth undertaking if it didn't excite others :), > maybe a summer of code project? > > Toby > > > 2008/7/3 Richard Vaughan <va...@sf...>: >> >> On Wed, Jul 2, 2008 at 9:33 AM, Reed Hedges <re...@mo...> wrote: >> > Richard Vaughan wrote: >> >>> So when (if) I move to Stage 3, the main things I will be trying to do >> >>> is to >> >>> make sure it's usable with or without 3D hardware >> >> >> >> Probably not without, as it uses OpenGL extensively now. Runs like a >> >> dog on a MacBook Air but very nicely on my MacPook Pro. I plan to try >> >> it on a MacBook (a typical student PC) to see if it's reasonable. >> > >> > Hmm, really? Then I will have to plan on basically forking Stage (from >> > 2), or >> > writing an alternate graphics layer for Stage 3... >> > >> >> I am really unhappy with the Air performance. I profiled to see what >> was going on, and Stage spends its time in a thread that doesn't exist >> when running on the MB Pro - probably software rendering. >> >> Stage runs very fast on 5-year old graphics hardware, so any >> acceleration seems to be enough. >> >> A port to using FLTK's native drawing would be possible, but I don't >> know if it would perform any better. I decided that assuming modest >> acceleration is OK. We have only one machine in the lab without it - >> my fancy new laptop! >> >> Richard/ >> >> > >> >> it doesn't provide any services to external processes unless plugged >> >> into Player >> >> >> > >> > Right >> > >> > >> > >> >> So they should simulate different things but share a simulation >> >> engine? >> > >> > I don't know anything about how Gazebo operations, but was guessing that >> > there >> > is some kind of infrastructure that does something similar as stage's >> > model >> > system and update loop. Maybe not useful as a shared thing though. >> > >> > >> >> Also, though XML has some nice properties, >> >> human usability is not one of them. World files are intended to be >> >> edited by hand, and this is hard work in Gazebo, >> > >> > I would agree. A tool would be needed to edit them (could be built in). >> > >> > Reed >> > >> > >> > >> > ------------------------------------------------------------------------- >> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> > Studies have shown that voting for your favorite open source project, >> > along with a healthy diet, reduces your potential for chronic lameness >> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> > _______________________________________________ >> > Playerstage-developers mailing list >> > Pla...@li... >> > https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > >> >> >> >> -- >> Richard Vaughan >> Autonomy Lab / Computing Science / Simon Fraser University >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > -- > This email is intended for the addressee only and may contain privileged > and/or confidential information > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > |