From: Alexei M. <al...@ca...> - 2008-02-16 14:33:57
|
Date: Sat, 16 Feb 2008 19:05:19 +0900 From: Jordi <mu...@gm...> Subject: Re: [Playerstage-developers] GearBox: a new approach to making robot software reusable Hi Jordi, thanks for the comments. I'm one of the Gearbox admins. let me try to answer your questions. > - If all the submitted libraries are independent between them, wouldn't that > mean a lot of code replication? Lots of drivers will be similar, etc. Libraries in Gearbox can in fact depend on each other. You can make your library depend on another one of yours or somebody else's. Absolutely no restrictions here. We've tried to make sure that inter-dependencies are easy to encode. CMake does a lot of the hard work out of the box and we've added a few macros to reduce the dependency checks to just a few lines. take a look at this build system tutorial if interested: http://gearbox.sourceforge.net/gbx_doc_buildsys.html Yes, there could be duplication. Standardization is not our objective. there have been many, many attempts in robotics to standardize frameworks, communication, ontologies, data types, etc. None of them have left a mark. So if we don't want to set standards and don't want to create a new framework, then what? We think that the biggest "bang for the buck" can be achieved by bringing about a set of libraries which: a) work -- we hope to achieve this "novelty" through peer review and wider reuse b) can be glued together in a variety of ways -- by requiring that they do not link to any particular glue code. These 2 objectives are challenging enough and it is far from certain that it will be a success. adding the objective of standardization to the mix would add to the challenge substantially and therefore reduce the chances of success. Having said that I do hope that some degree of commonality will emerge organically for two reasons: 1) having 1 or 2 working and reusable implementations of a particular driver or algorithm would discourage people from writing another 7 or 8 half-working implementations (the situation today) 2) placing multiple implementations side-by-side into the same distribution would make functional overlap obvious and some developers may decide to join efforts. Some of course will not, but in that case I doubt that any standardization committee could convince them anyway. > - Gearbox is intended to be used by frameworks or by people programming > robots. If the later, how it is any different use it from using any other > framework? right on the money! it is NOT meant to be a framework. submission of framework-like code is discouraged. what exactly is a "framework" is hard to define and can be quite subjective. our working definition is "the code which is used for composing pre-existing modules into a system". in most cases the classification is obvious, where not, we'll leave the decision to a public discussion on the mailing list. who's the user? -- a very good question. we think of frameworks as the direct "users" of Gearbox. the end user trying to build a system using the framework of choice will of course benefit at the end. our immediate focus is on the developers of the existing frameworks. that's why we sent the announcement to the devel list. :) > - All the implementations will be C++? (may not be an issue anyway) No official restrictions or even suggestions. choice of the programming language is listed as one of the freedoms: http://gearbox.sourceforge.net/gbx_doc_principles.html#gbx_doc_principles_freedoms Practically, there're limitations imposed by the choice of CMake for the build system. C, C++, Java are all easily accommodated. > - Couldn't third party developers take care of retired code of other > developers? Or simply improve the code if the license is open? All the normal open-source rules and practices apply. The original author chooses the license and and is in control of the copyright and the direction in which the source is headed. > Great idea anyway. cheers, alex makarenko |
From: Jordi <mu...@gm...> - 2008-02-16 15:42:48
|
I agree with you in everything but in one thing. In my short programming experience related code and even unrelated tends to (with enough time and resources) becomes libraries of common utilities and code using them. Even with more time and resources it tends to become frameworks. For instance, I guess lasers are sufficiently similar between them that frameworks tend to have common function between laser drivers. In this case, it makes me think of 3 issues: - Current frameworks' code may be pretty tied to its own libraries of common functions implemented once and used by several. - The code of GearBox will tend to create libraries of common code (by itself or moved from frameworks). This will make new developers think Gearbox is a framework as any other. Possibly making them choose another. - The lack of enforcement by Gearbox on how the code is made (regarding libraries) can become a situation where most of a particular driver type is using a library agreed by those developers, other 2 drivers used other that came from a framework and another goes by it own. It may not happen as I am saying but I think it is not at all unlikely. Summary: The "let's make libraries" path leads to just another robotic framework but "Let's libraries emerge or no (freedom)" can lead to a difficult life for developers and chaos. I love robotics and I love opensource. We really need a de-facto standard project where to put our efforts. I'd love you to see your success. I hope the above comments can help somewhat. BTW, have you thought about robotics simulators? It is out of the scope of your project? cheers On Feb 16, 2008 11:34 PM, Alexei Makarenko <al...@ca...> wrote: > Date: Sat, 16 Feb 2008 19:05:19 +0900 > From: Jordi <mu...@gm...> > Subject: Re: [Playerstage-developers] GearBox: a new approach to > making robot software reusable > > Hi Jordi, thanks for the comments. I'm one of the Gearbox admins. let me > try to answer your questions. > > > - If all the submitted libraries are independent between them, wouldn't > that > > mean a lot of code replication? Lots of drivers will be similar, etc. > > Libraries in Gearbox can in fact depend on each other. You can make your > library depend on another one of yours or somebody else's. Absolutely no > restrictions here. > > We've tried to make sure that inter-dependencies are easy to encode. CMake > does a lot of the hard work out of the box and we've added a few macros to > reduce the dependency checks to just a few lines. take a look at this build > system tutorial if interested: > http://gearbox.sourceforge.net/gbx_doc_buildsys.html > > Yes, there could be duplication. Standardization is not our objective. > there have been many, many attempts in robotics to standardize frameworks, > communication, ontologies, data types, etc. None of them have left a mark. > > So if we don't want to set standards and don't want to create a new > framework, then what? > > We think that the biggest "bang for the buck" can be achieved by bringing > about a set of libraries which: > a) work -- we hope to achieve this "novelty" through peer review and > wider reuse > b) can be glued together in a variety of ways -- by requiring that they do > not link to any particular glue code. > > These 2 objectives are challenging enough and it is far from certain that > it will be a success. adding the objective of standardization to the mix > would add to the challenge substantially and therefore reduce the chances of > success. > > Having said that I do hope that some degree of commonality will emerge > organically for two reasons: > 1) having 1 or 2 working and reusable implementations of a particular > driver or algorithm would discourage people from writing another 7 or 8 > half-working implementations (the situation today) > 2) placing multiple implementations side-by-side into the same > distribution would make functional overlap obvious and some developers > may decide to join efforts. Some of course will not, but in that case I > doubt that any standardization committee could convince them anyway. > > > - Gearbox is intended to be used by frameworks or by people programming > > robots. If the later, how it is any different use it from using any > other > > framework? > > right on the money! it is NOT meant to be a framework. submission of > framework-like code is discouraged. what exactly is a "framework" is hard to > define and can be quite subjective. our working definition is "the code > which is used for composing pre-existing modules into a system". in most > cases the classification is obvious, where not, we'll leave the decision to > a public discussion on the mailing list. > > who's the user? -- a very good question. we think of frameworks as the > direct "users" of Gearbox. the end user trying to build a system using the > framework of choice will of course benefit at the end. > > our immediate focus is on the developers of the existing frameworks. > that's why we sent the announcement to the devel list. :) > > > - All the implementations will be C++? (may not be an issue anyway) > > No official restrictions or even suggestions. choice of the programming > language is listed as one of the freedoms: > > http://gearbox.sourceforge.net/gbx_doc_principles.html#gbx_doc_principles_freedoms > > Practically, there're limitations imposed by the choice of CMake for the > build system. C, C++, Java are all easily accommodated. > > > - Couldn't third party developers take care of retired code of other > > developers? Or simply improve the code if the license is open? > > All the normal open-source rules and practices apply. The original author > chooses the license and and is in control of the copyright and the direction > in which the source is headed. > > > Great idea anyway. > > cheers, > alex makarenko > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org |