From: Brian G. <br...@ge...> - 2006-06-06 20:02:32
|
hi, Our recent overhaul of Player has given us the opportunity to do some new and interesting things. I'd like to know: what do you want? All ideas welcome, but I'm looking for relatively significant enhancements. More like new transport mechanisms and less like a driver for the latest laser range-finder. I'll assemble the responses into a prioritized wish list and post it at the project website. I'll also incorporate the items from the SFU wiki on ideas for a Google Summer of Code project. Here are a few ideas to get things going (feel free to comment on them): - New transport layers, getting away from the client-server model. Candidates include CORBA, ACE, Reid Simmons' IPC... - Standard implementations of multi-robot algorithms. Whereas now we have implementations of single-robot algorithms like AMCL and VFH, we could implement multi-robot SLAM, auction-based task allocation, etc. - Support for structured "client-to-client" communications. Right now, this is totally ad hoc, with everybody reinventing the wheel. We could take ideas from the old lifomcom driver and new relay driver to provide more fully-featured communication links among control programs (which, depending on the transport mechanism in use, will not necessarily be "clients") - Standard tasks to try in simulation, with instrumentation to provide automatic evaluation. Richard's going in this direction with the Zoo. brian. |
From: smog z. <sm...@gm...> - 2006-06-07 20:09:34
|
My personal wishlist : -> More people using/contributing to playerviewer3d :) -> Get sphinx2 libplayerc and c++ working (will work on this when i finish my other priorities). -> Investigate on the possibilites of using dbus for transport or just grab some ideas from it. -> Replace the gsl ugly code from player/pmap and replace it with http://itpp.sf.net so it becomes understandable (repeat after me: gsl sucks). -> Boost.org like review system for player code. To debug algorithms, tip o= n coding practices, healthy discussions, world domination, etc. --=20 Jo=E3o Xavier @ smogzer_at_gmail.com W3 http://miarn.cjb.net Institute for Systems and Robotics University of Coimbra |
From: Radu B. R. <ru...@cs...> - 2006-06-07 20:41:20
|
smog zer wrote: > -> Replace the gsl ugly code from player/pmap and replace it with > http://itpp.sf.net so it becomes understandable (repeat after me: gsl > sucks). Not trying to start a pro-cons discussion about GSL here, but why do you think it sucks? I used both GSL and IT++ (in combination with libDSP and FFTW), and GSL worked quite well. I do agree that it still needs work in certain areas, but for a lot of things it is quite neat. One could argue about the coding style, but ermm... that's different (personal preferences should be discussed separately ;) ). :) And for some reason, I always feel safer when I see software which comes directly from FSF. I am sick and tired to see tens to hundredths of glorious SF projects that rise up, promise some things, but then they simply die because the author finished his bsc/msc/phd thesis and decides that the project shouldn't be maintained anymore. :-/ FSF implies a certain...ermm, continuity for a project (at least for me). Let's not forget IT++ depends on a bunch of external libraries, which is neat if you're working on a PC but not that neat if you want to port everything to an embedded device for example. GSL can also work with FFTW or with other libs, but it also provides some (simpler) built-in algorithms that can do the trick. Anyway, you can reply to me privately in case this does not belongs here. I was just curious to know why you hate it so much. Maybe after you explain it to me I will see it too :) (I'm serious - no irony intended). Thanks, Radu. -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Paul O. <new...@ki...> - 2006-06-13 18:31:54
|
My personal wishlist : -> make player as much portable as it is possible -> use sdl as much as it is possible (for sound, joystick and multimedia hardware like that, timmings, threads, and so on, even we can think of new librtk that does not need gtk, it is not so hard to design widgets for sdl, each game has some nice menus and gui!) -> do not use sockets directly (CORBA seem to be the answer) -> scalability (should run on machines like sharp zaurus and multiprocessor machines) -> make passthrough and cameracompress and other 1.6.x useful devices work again! -> make it possible to have few version of player and libraries on one system Cheers, Paul On Tue, 6 Jun 2006, smog zer wrote: > My personal wishlist : > > -> More people using/contributing to playerviewer3d :) > > -> Get sphinx2 libplayerc and c++ working (will work on this when i finish > my other priorities). > > -> Investigate on the possibilites of using dbus for transport or just grab > some ideas from it. > > -> Replace the gsl ugly code from player/pmap and replace it with > http://itpp.sf.net so it becomes understandable (repeat after me: gsl > sucks). > > -> Boost.org like review system for player code. To debug algorithms, tip on > coding practices, healthy discussions, world domination, etc. > > -- > Jo?o Xavier > @ smogzer_at_gmail.com > W3 http://miarn.cjb.net > Institute for Systems and Robotics > University of Coimbra > |
From: Toby C. <tco...@pl...> - 2006-06-14 19:13:57
|
Hi, cameracompress should work again in 2.0.2 I think (if not it definately does in CVS HEAD) passthrough is no longer needed for driver 'require' options as you can now use the full address (server, port, interface, index) to subscribe directly between servers. A nicer way of handling multiple servers could be good in the client libs... you want CORBA and running on a zaurus? Having said that alternative transports is definately something a lot of people are interested in :) You should be able to run player 1.6 and 2.0 together I think, but I havent tried it myself and the .so's from 2.0.x as of about 2.0.2 should be able to be installed together (again I havent tried it so ...) Toby Paul Osmialowski wrote: > My personal wishlist : > -> make player as much portable as it is possible > -> use sdl as much as it is possible (for sound, joystick and > multimedia hardware like that, timmings, threads, and so on, even we can > think of new librtk that does not need gtk, it is not so hard to design > widgets for sdl, each game has some nice menus and gui!) > -> do not use sockets directly (CORBA seem to be the answer) > -> scalability (should run on machines like sharp zaurus and > multiprocessor machines) > -> make passthrough and cameracompress and other 1.6.x useful devices work > again! > -> make it possible to have few version of player and libraries on one > system > Cheers, > Paul > > On Tue, 6 Jun 2006, smog zer wrote: > >> My personal wishlist : >> >> -> More people using/contributing to playerviewer3d :) >> >> -> Get sphinx2 libplayerc and c++ working (will work on this when i finish >> my other priorities). >> >> -> Investigate on the possibilites of using dbus for transport or just grab >> some ideas from it. >> >> -> Replace the gsl ugly code from player/pmap and replace it with >> http://itpp.sf.net so it becomes understandable (repeat after me: gsl >> sucks). >> >> -> Boost.org like review system for player code. To debug algorithms, tip on >> coding practices, healthy discussions, world domination, etc. >> >> -- >> Jo?o Xavier >> @ smogzer_at_gmail.com >> W3 http://miarn.cjb.net >> Institute for Systems and Robotics >> University of Coimbra >> > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: Ales S. <ale...@fr...> - 2006-06-14 19:47:51
|
Hey, I just wrote a CORBA server for out ATRV-Mini robot... And it works like a charm.. I guess if you really wanted to use CORBA for Player you would have to start by defining interfaces (writing idl files) which would be big task.. But it would be worth to try. Cheers, Ales Toby Collett wrote: > Hi, > cameracompress should work again in 2.0.2 I think (if not it definately > does in CVS HEAD) > > passthrough is no longer needed for driver 'require' options as you can > now use the full address (server, port, interface, index) to subscribe > directly between servers. A nicer way of handling multiple servers could > be good in the client libs... > > you want CORBA and running on a zaurus? Having said that alternative > transports is definately something a lot of people are interested in :) > > You should be able to run player 1.6 and 2.0 together I think, but I > havent tried it myself and the .so's from 2.0.x as of about 2.0.2 should > be able to be installed together (again I havent tried it so ...) > > Toby > > > Paul Osmialowski wrote: > >> My personal wishlist : >> -> make player as much portable as it is possible >> -> use sdl as much as it is possible (for sound, joystick and >> multimedia hardware like that, timmings, threads, and so on, even we can >> think of new librtk that does not need gtk, it is not so hard to design >> widgets for sdl, each game has some nice menus and gui!) >> -> do not use sockets directly (CORBA seem to be the answer) >> -> scalability (should run on machines like sharp zaurus and >> multiprocessor machines) >> -> make passthrough and cameracompress and other 1.6.x useful devices work >> again! >> -> make it possible to have few version of player and libraries on one >> system >> Cheers, >> Paul >> >> On Tue, 6 Jun 2006, smog zer wrote: >> >> >>> My personal wishlist : >>> >>> -> More people using/contributing to playerviewer3d :) >>> >>> -> Get sphinx2 libplayerc and c++ working (will work on this when i finish >>> my other priorities). >>> >>> -> Investigate on the possibilites of using dbus for transport or just grab >>> some ideas from it. >>> >>> -> Replace the gsl ugly code from player/pmap and replace it with >>> http://itpp.sf.net so it becomes understandable (repeat after me: gsl >>> sucks). >>> >>> -> Boost.org like review system for player code. To debug algorithms, tip on >>> coding practices, healthy discussions, world domination, etc. >>> >>> -- >>> Jo?o Xavier >>> @ smogzer_at_gmail.com >>> W3 http://miarn.cjb.net >>> Institute for Systems and Robotics >>> University of Coimbra >>> >>> >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users >> >> > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > |
From: Paul O. <new...@ki...> - 2006-06-15 14:41:56
|
Toby Collett wrote: > passthrough is no longer needed for driver 'require' options as you can > now use the full address (server, port, interface, index) to subscribe > directly between servers. A nicer way of handling multiple servers could > be good in the client libs... We're using passthrough heavily at vlab.pjwstk.edu.pl to give access to robot devices that are behind the firewall. How can I implement that using 2.x? > > you want CORBA and running on a zaurus? Having said that alternative > transports is definately something a lot of people are interested in :) CORBA is too heavy? so let's look at SDL_net then... > > You should be able to run player 1.6 and 2.0 together I think, but I > havent tried it myself and the .so's from 2.0.x as of about 2.0.2 should > be able to be installed together (again I havent tried it so ...) I tried to have 1.6 and 2.0 together few months ago and as I remember, there was a problem with it, don't remember what. I guess the best solution is not to make system wide install whenever few versions must be in use. > > Paul Osmialowski wrote: > >>My personal wishlist : >>-> make player as much portable as it is possible >>-> use sdl as much as it is possible (for sound, joystick and >>multimedia hardware like that, timmings, threads, and so on, even we can >>think of new librtk that does not need gtk, it is not so hard to design >>widgets for sdl, each game has some nice menus and gui!) >>-> do not use sockets directly (CORBA seem to be the answer) >>-> scalability (should run on machines like sharp zaurus and >>multiprocessor machines) >>-> make passthrough and cameracompress and other 1.6.x useful devices work >>again! >>-> make it possible to have few version of player and libraries on one >>system >>Cheers, >>Paul >> >>On Tue, 6 Jun 2006, smog zer wrote: >> >> >>>My personal wishlist : >>> >>>-> More people using/contributing to playerviewer3d :) >>> >>>-> Get sphinx2 libplayerc and c++ working (will work on this when i finish >>>my other priorities). >>> >>>-> Investigate on the possibilites of using dbus for transport or just grab >>>some ideas from it. >>> >>>-> Replace the gsl ugly code from player/pmap and replace it with >>>http://itpp.sf.net so it becomes understandable (repeat after me: gsl >>>sucks). >>> >>>-> Boost.org like review system for player code. To debug algorithms, tip on >>>coding practices, healthy discussions, world domination, etc. >>> >>>-- >>>Jo?o Xavier >>>@ smogzer_at_gmail.com >>>W3 http://miarn.cjb.net >>>Institute for Systems and Robotics >>>University of Coimbra >>> >> >> >>_______________________________________________ >>Playerstage-users mailing list >>Pla...@li... >>https://lists.sourceforge.net/lists/listinfo/playerstage-users >> > > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Toby C. <tco...@pl...> - 2006-06-15 18:52:43
|
Paul Osmialowski wrote: > Toby Collett wrote: >> passthrough is no longer needed for driver 'require' options as you can >> now use the full address (server, port, interface, index) to subscribe >> directly between servers. A nicer way of handling multiple servers could >> be good in the client libs... > We're using passthrough heavily at vlab.pjwstk.edu.pl to give access to > robot devices that are behind the firewall. How can I implement that > using 2.x? That is a situation that I hadn't considered, For the moment I would recommend port forwarding, but I can see why passthrough could still be useful. Passthrough is something that should be relatively easy to implement, I just dont have the time at this moment. Why dont you post a feature request on sourceforge then it will not be forgotten. Toby >> you want CORBA and running on a zaurus? Having said that alternative >> transports is definately something a lot of people are interested in :) > CORBA is too heavy? so let's look at SDL_net then... >> You should be able to run player 1.6 and 2.0 together I think, but I >> havent tried it myself and the .so's from 2.0.x as of about 2.0.2 should >> be able to be installed together (again I havent tried it so ...) > I tried to have 1.6 and 2.0 together few months ago and as I remember, > there was a problem with it, don't remember what. I guess the best > solution is not to make system wide install whenever few versions must > be in use. > > >> Paul Osmialowski wrote: >> >>> My personal wishlist : >>> -> make player as much portable as it is possible >>> -> use sdl as much as it is possible (for sound, joystick and >>> multimedia hardware like that, timmings, threads, and so on, even we can >>> think of new librtk that does not need gtk, it is not so hard to design >>> widgets for sdl, each game has some nice menus and gui!) >>> -> do not use sockets directly (CORBA seem to be the answer) >>> -> scalability (should run on machines like sharp zaurus and >>> multiprocessor machines) >>> -> make passthrough and cameracompress and other 1.6.x useful devices work >>> again! >>> -> make it possible to have few version of player and libraries on one >>> system >>> Cheers, >>> Paul >>> >>> On Tue, 6 Jun 2006, smog zer wrote: >>> >>> >>>> My personal wishlist : >>>> >>>> -> More people using/contributing to playerviewer3d :) >>>> >>>> -> Get sphinx2 libplayerc and c++ working (will work on this when i finish >>>> my other priorities). >>>> >>>> -> Investigate on the possibilites of using dbus for transport or just grab >>>> some ideas from it. >>>> >>>> -> Replace the gsl ugly code from player/pmap and replace it with >>>> http://itpp.sf.net so it becomes understandable (repeat after me: gsl >>>> sucks). >>>> >>>> -> Boost.org like review system for player code. To debug algorithms, tip on >>>> coding practices, healthy discussions, world domination, etc. >>>> >>>> -- >>>> Jo?o Xavier >>>> @ smogzer_at_gmail.com >>>> W3 http://miarn.cjb.net >>>> Institute for Systems and Robotics >>>> University of Coimbra >>>> >>> >>> _______________________________________________ >>> Playerstage-users mailing list >>> Pla...@li... >>> https://lists.sourceforge.net/lists/listinfo/playerstage-users >>> >> >> >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: Reed H. <re...@mo...> - 2006-06-14 19:51:07
|
IMO a good alternative transport to TCP would be through a shared memory interface or local sockets (FIFOs). This would be useful for clients that are running on the same computer as the player server; in this situation using TCP just exacerbates kernel TCP overhead. Using shared memory or similar would also remove the neccesity to do much encoding of data. Another idea is for player to load client programs as plugins, and have the client "transport" functions hook in directly to Player or to a layer it provides as the "transport" for this purpose. Reed PS. Regarding using CORBA -- have you ever attempted to use Mobility? There's a reason why the rflex driver was created for Player! |
From: smog z. <sm...@gm...> - 2006-06-07 23:15:10
|
> On Tue, 6 June, 2006 9:57 pm, Geoffrey Biggs wrote: > > I also think that the ideas mentioned below of making player less > > "client-server" and more "distributed-control-network" is an important > > direction. I think we need to move away from the idea of an overall > > commanding client program doing all the management and more towards > > local autonomy, and maybe moving away from the client-server layout is > > one way to achieve this. > > Is the server/client architecture actually needed? Let me explain! I do > appearance-based vision, i.e. no feature extraction. This means that my > client needs to get raw images from the camera, which when sent over the > network (even localhost) between the server and my client, this introduce= s > impossible delays. At the moment, I can see two solutions: > > - not using player for the camera grabbing (my current solution as I had > the code from before using player); > - have my code not as a client but as a "driver" (or should that be a > service or something like that?), at least something that runs in the > server. > > Actually, the latter is probably the best way to do it, since as other di= d > put it, player is also a sensor system. Is that something that is alread= y > possible (I have to admit that I didn't look at that at all since I have > my own working solution now)? If it is possible, this also means that > player should contain some image processing functions that all vision > algorithms could use, and I would be more than happy to contribute to > that, even possibly give you some (not everything is relevant) of my code= . > > Cheers, > > Fred > > Player should use tcp over network and if client=3Dserver the transport should by default switch to ipc or shared memory. This would further simplify the simulation interfacing also. Another two subjects: algorithms and visualizations. Algorithms should be in a folder player/algorithms and every one should be a reusable base class. This means that when implementing an algorithm like vfh+++ one could inherit the base vfh class for code reuse. Another advantage would be that i could reuse the in playerviewer 3d that could use the algorithms directly from the algorithms api. A driver is not more than: a way to configure the algorithm and run it. About algorithm layout: * C code should be avoided as it makes programs have more lines than they should, and that diverges attention from the algorithm itself to coding details. * important variables should be visualizable(in window in opengl) all the way of the algorithm for debugging. * like is already done the driver encapsulates the init functions of the algorithm and the Main() calls the main functions one by one. * design of the class can take into account the following future possibilities: clock the time between operations for benchmarking/profiling; distributed processing ( robot already on the deadline for priority stuff so he sends part of the data to other host for processing); visualization of data; realtime discard of operations ( if part of the algorithm is not acomplishable and is not very important then discard it). Visualizations like the algorithms should also have a folder player/visualizations. In that folder would be code for visualization of the devices. Every one of them is a libtool library without any dependencies except for opengl/glu/gle (notice that i didn't use glut here to say it should be window system independent i.e. work in fltk, qt, glut, etc). This way they can be shared by all applications and somebody developing an algorithm can provide a visualization for it that does not bloat the algorithm code. Playerviewer 3d already is the equivalent of player for visualization so providing DRIVERS(a sequence of drawing functions to illustrate something) for visualization should be contributed to playerviewer 3d as it makes use of the versatile rtk3d library that allows for interactions, obj loading, window control, xml, etc. --=20 Jo=E3o Xavier @ smogzer_at_gmail.com W3 http://miarn.cjb.net Institute for Systems and Robotics University of Coimbra |
From: Geoffrey B. <g....@au...> - 2006-06-06 20:58:27
|
One that Toby and I have discussed is good support for talking to multiple player servers from a single client. We've found the current method of having to subscribe to each player server with an individual client object to be difficult to manage when you have many servers, each providing different services. This may not turn out to be a major change, but it is something that would be good to fix in a nice way. I also think that the ideas mentioned below of making player less "client-server" and more "distributed-control-network" is an important direction. I think we need to move away from the idea of an overall commanding client program doing all the management and more towards local autonomy, and maybe moving away from the client-server layout is one way to achieve this. Geoff Brian Gerkey wrote: > hi, > > Our recent overhaul of Player has given us the opportunity to do some > new and interesting things. I'd like to know: what do you want? > > All ideas welcome, but I'm looking for relatively significant > enhancements. More like new transport mechanisms and less like a > driver for the latest laser range-finder. > > I'll assemble the responses into a prioritized wish list and post it > at the project website. I'll also incorporate the items from the SFU > wiki on ideas for a Google Summer of Code project. > > Here are a few ideas to get things going (feel free to comment on them): > > - New transport layers, getting away from the client-server model. > Candidates include CORBA, ACE, Reid Simmons' IPC... > > - Standard implementations of multi-robot algorithms. Whereas now we > have implementations of single-robot algorithms like AMCL and VFH, we > could implement multi-robot SLAM, auction-based task allocation, etc. > > - Support for structured "client-to-client" communications. Right > now, this is totally ad hoc, with everybody reinventing the wheel. > We could take ideas from the old lifomcom driver and new relay driver > to provide more fully-featured communication links among control > programs (which, depending on the transport mechanism in use, will > not necessarily be "clients") > > - Standard tasks to try in simulation, with instrumentation to > provide automatic evaluation. Richard's going in this direction with > the Zoo. > > brian. -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Toby C. <tco...@pl...> - 2006-06-06 21:23:58
|
Other things on my list: - More work on service discovery - 3d poses for everything and a method of specifying the relationship between the geometry of devices (so you know the geometry of a camera will change when the pan tilt unit it is mounted on changes etc) These could actually be combined with the service repository storing the geometric configuration of units as well... - Player visualisation library Probably in openGL to get transparency, could be embedded in other apps such as playerv, IDE's, stage?, the various 3d vis projects (i.e. my ardev and the playerv3d project). This is something I may work on once my thesis is written...if time allows. - multi language driver support? - Windows support, native windows compiles of player core and client libraries and a subset of drivers. - Possibly splitting a player 'component' library from libplayerdrivers, this could give better identification to contributing developers for their specific components? Thats enough for now, Toby Geoffrey Biggs wrote: > One that Toby and I have discussed is good support for talking to > multiple player servers from a single client. We've found the current > method of having to subscribe to each player server with an individual > client object to be difficult to manage when you have many servers, each > providing different services. This may not turn out to be a major > change, but it is something that would be good to fix in a nice way. > > I also think that the ideas mentioned below of making player less > "client-server" and more "distributed-control-network" is an important > direction. I think we need to move away from the idea of an overall > commanding client program doing all the management and more towards > local autonomy, and maybe moving away from the client-server layout is > one way to achieve this. > > Geoff > > Brian Gerkey wrote: >> hi, >> >> Our recent overhaul of Player has given us the opportunity to do some >> new and interesting things. I'd like to know: what do you want? >> >> All ideas welcome, but I'm looking for relatively significant >> enhancements. More like new transport mechanisms and less like a >> driver for the latest laser range-finder. >> >> I'll assemble the responses into a prioritized wish list and post it >> at the project website. I'll also incorporate the items from the SFU >> wiki on ideas for a Google Summer of Code project. >> >> Here are a few ideas to get things going (feel free to comment on them): >> >> - New transport layers, getting away from the client-server model. >> Candidates include CORBA, ACE, Reid Simmons' IPC... >> >> - Standard implementations of multi-robot algorithms. Whereas now we >> have implementations of single-robot algorithms like AMCL and VFH, we >> could implement multi-robot SLAM, auction-based task allocation, etc. >> >> - Support for structured "client-to-client" communications. Right >> now, this is totally ad hoc, with everybody reinventing the wheel. >> We could take ideas from the old lifomcom driver and new relay driver >> to provide more fully-featured communication links among control >> programs (which, depending on the transport mechanism in use, will >> not necessarily be "clients") >> >> - Standard tasks to try in simulation, with instrumentation to >> provide automatic evaluation. Richard's going in this direction with >> the Zoo. >> >> brian. > |
From: Radu B. R. <ru...@cs...> - 2006-06-06 22:04:43
|
Heya, Geoffrey Biggs wrote: > One that Toby and I have discussed is good support for talking to > multiple player servers from a single client. We've found the current > method of having to subscribe to each player server with an individual > client object to be difficult to manage when you have many servers, each > providing different services. This may not turn out to be a major > change, but it is something that would be good to fix in a nice way. > > I also think that the ideas mentioned below of making player less > "client-server" and more "distributed-control-network" is an important > direction. I think we need to move away from the idea of an overall > commanding client program doing all the management and more towards > local autonomy, and maybe moving away from the client-server layout is > one way to achieve this. > One way of achieving that is to encapsulate your client programs using an agent development framework into software agents. It's pretty easy and it works quite well (I've done it some years ago for my diploma thesis). I am not sure if I would like Player to completely move in that direction (although if we can still keep the simple existing control mechanism, I'll be happy), but any add-ons would be neat of course. Brian, we already have a Simple Corba Framework developed here by one of our colleagues (Derik Schroeter - he is with Paul Newman at Oxford now) for the TumBot project. It's lightweight, stable and it works fine. It should be pretty easy to incorporate it as an add-on to the existing transport layer, provided that we have the right transition mechanisms in place. Once we have that, people could easily use it as an example for coding their own ICE, ACE, etc wrapper schemes. I would definitely want to see more in the multi-robot SLAM area (anyone attending the summer school in Oxford?). And yeah, client-to-client communication is something we should definitely do as fast as possible. I'll actually get into it pretty soon on -developers, as I will need it too in a distributed Wireless Sensor Network project. Other than that, probably improve what we already have, and maybe start working some more on the algorithmic part. There are plenty of proven mathematical (more or less) algorithms that we could implement. I once had a D* implementation handy in Java and was planning to start porting it to Player, but somehow I got into a different project at that time, and the whole thing just... died. And as Toby suggested in another e-mail, having some cool visualization software would be great! I am currently using VTK for a lot of things, but the overhead is a killer sometimes. We do have some smaller, lightweight, opengl libraries which we would gladly share and commit to Player if we get someone started on this project. Toby? :) That's it for now. Best, Radu. > Geoff > > Brian Gerkey wrote: > >> hi, >> >> Our recent overhaul of Player has given us the opportunity to do some >> new and interesting things. I'd like to know: what do you want? >> >> All ideas welcome, but I'm looking for relatively significant >> enhancements. More like new transport mechanisms and less like a >> driver for the latest laser range-finder. >> >> I'll assemble the responses into a prioritized wish list and post it >> at the project website. I'll also incorporate the items from the SFU >> wiki on ideas for a Google Summer of Code project. >> >> Here are a few ideas to get things going (feel free to comment on them): >> >> - New transport layers, getting away from the client-server model. >> Candidates include CORBA, ACE, Reid Simmons' IPC... >> >> - Standard implementations of multi-robot algorithms. Whereas now we >> have implementations of single-robot algorithms like AMCL and VFH, we >> could implement multi-robot SLAM, auction-based task allocation, etc. >> >> - Support for structured "client-to-client" communications. Right >> now, this is totally ad hoc, with everybody reinventing the wheel. >> We could take ideas from the old lifomcom driver and new relay driver >> to provide more fully-featured communication links among control >> programs (which, depending on the transport mechanism in use, will >> not necessarily be "clients") >> >> - Standard tasks to try in simulation, with instrumentation to >> provide automatic evaluation. Richard's going in this direction with >> the Zoo. >> >> brian. >> > > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Fred L. <ff...@ab...> - 2006-06-07 08:25:07
|
On Tue, 6 June, 2006 9:57 pm, Geoffrey Biggs wrote: > I also think that the ideas mentioned below of making player less > "client-server" and more "distributed-control-network" is an important > direction. I think we need to move away from the idea of an overall > commanding client program doing all the management and more towards > local autonomy, and maybe moving away from the client-server layout is > one way to achieve this. Is the server/client architecture actually needed? Let me explain! I do appearance-based vision, i.e. no feature extraction. This means that my client needs to get raw images from the camera, which when sent over the network (even localhost) between the server and my client, this introduces impossible delays. At the moment, I can see two solutions: - not using player for the camera grabbing (my current solution as I had the code from before using player); - have my code not as a client but as a "driver" (or should that be a service or something like that?), at least something that runs in the server. Actually, the latter is probably the best way to do it, since as other did put it, player is also a sensor system. Is that something that is already possible (I have to admit that I didn't look at that at all since I have my own working solution now)? If it is possible, this also means that player should contain some image processing functions that all vision algorithms could use, and I would be more than happy to contribute to that, even possibly give you some (not everything is relevant) of my code. Cheers, Fred |
From: Jose M. P. <jm...@gs...> - 2006-06-07 11:09:54
|
Hi, I do agree with Fred, speeding up the raw image flow "to the client" is interesting for our research too. If that flow were good enough (acceptable throughput, acceptable delay) I could migrate our vision based applications for robot navigation to work with Player. Brad's local transport mechanism sounds good. Congratulations for player 2.x! JoseMaria On Wed, 2006-06-07 at 09:24 +0100, Fred Labrosse wrote: > Is the server/client architecture actually needed? Let me explain! I do > appearance-based vision, i.e. no feature extraction. This means that my > client needs to get raw images from the camera, which when sent over the > network (even localhost) between the server and my client, this introduces > impossible delays. At the moment, I can see two solutions: > > - not using player for the camera grabbing (my current solution as I had > the code from before using player); > - have my code not as a client but as a "driver" (or should that be a > service or something like that?), at least something that runs in the > server. -- http://gsyc.escet.urjc.es/jmplaza Universidad Rey Juan Carlos |
From: Toby C. <tco...@pl...> - 2006-06-07 19:46:42
|
At the moment there are a couple of vision examples running as driver, in particular the CMVision and ARToolkitPlus drivers. When the driver is run on the same server as the camera driver there data is never transferred over a network connection, when this is not possible (a web cam on a robot with low CPU) it can be transparently switched to a network connection. While there is a little overhead in doing this, it shouldnt be too excessive. You will have to evaluate for individual cases... With image processing there will always be some techniques where every CPU cycle counts and you will always have to manage the whole pipeline directly, for the less intensive approaches running as a player driver should be suitable... Toby Jose Maria Can~as Plaza wrote: > Hi, > > I do agree with Fred, speeding up the raw image flow "to the client" is > interesting for our research too. If that flow were good enough > (acceptable throughput, acceptable delay) I could migrate our vision > based applications for robot navigation to work with Player. Brad's > local transport mechanism sounds good. > > Congratulations for player 2.x! > > JoseMaria > > On Wed, 2006-06-07 at 09:24 +0100, Fred Labrosse wrote: >> Is the server/client architecture actually needed? Let me explain! I do >> appearance-based vision, i.e. no feature extraction. This means that my >> client needs to get raw images from the camera, which when sent over the >> network (even localhost) between the server and my client, this introduces >> impossible delays. At the moment, I can see two solutions: >> >> - not using player for the camera grabbing (my current solution as I had >> the code from before using player); >> - have my code not as a client but as a "driver" (or should that be a >> service or something like that?), at least something that runs in the >> server. > |
From: Radu B. R. <ru...@cs...> - 2006-06-07 09:41:15
|
Fred, you raised a very important point in this discussion. Actually, with the major overhaul in Player 2, it is now possible to drop the client-server architecture, and simply wrap against certain libraries (you will need libplayercore and libplayerdrivers for your application - for instance). I think that what Brian was suggesting is that different people have different needs, so the best way to make everybody happy is to have a lightweight modular architecture, on top of which we can build other more "complex" things (I wouldn't call TCP/IP complex, but CORBA almost gets there). In my opinion, we shouldn't drop any of the existing transport or communication mechanisms, but rather add new ones, and, when necessary adapt the current ones to allow the existence of the new ones. Makes sense? Cheers, Radu. Fred Labrosse wrote: > On Tue, 6 June, 2006 9:57 pm, Geoffrey Biggs wrote: > >> I also think that the ideas mentioned below of making player less >> "client-server" and more "distributed-control-network" is an important >> direction. I think we need to move away from the idea of an overall >> commanding client program doing all the management and more towards >> local autonomy, and maybe moving away from the client-server layout is >> one way to achieve this. >> > > Is the server/client architecture actually needed? Let me explain! I do > appearance-based vision, i.e. no feature extraction. This means that my > client needs to get raw images from the camera, which when sent over the > network (even localhost) between the server and my client, this introduces > impossible delays. At the moment, I can see two solutions: > > - not using player for the camera grabbing (my current solution as I had > the code from before using player); > - have my code not as a client but as a "driver" (or should that be a > service or something like that?), at least something that runs in the > server. > > Actually, the latter is probably the best way to do it, since as other did > put it, player is also a sensor system. Is that something that is already > possible (I have to admit that I didn't look at that at all since I have > my own working solution now)? If it is possible, this also means that > player should contain some image processing functions that all vision > algorithms could use, and I would be more than happy to contribute to > that, even possibly give you some (not everything is relevant) of my code. > > Cheers, > > Fred > > > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Brad K. <bkr...@et...> - 2006-06-07 10:12:22
|
Radu Bogdan Rusu wrote: > Fred, you raised a very important point in this discussion. Actually, > with the major overhaul in Player 2, it is now possible to drop the > client-server architecture, and simply wrap against certain libraries > (you will need libplayercore and libplayerdrivers for your application - > for instance). I've been thinking about what it would take to implement this for a while now. It would be quite nice if we could insert a "libplayerlocal" transport mechanism that we could just link the c libraries against. I think it would be a better approach than trying to just link to libplayercore/drivers in client code. We do quite a bit of stuff on the local machine and use Player as a standard way to access the hardware. It would be great if we could speed things up a bit by removing the TCP layer(or even better selectively enable one or the other). Along these lines, other transport mechanisms like those mentioned before could be implemented. This would allow users to pick and choose the model that best suits them. Best regards, Brad |
From: Mirko B. <mir...@ie...> - 2006-06-07 11:10:25
|
but, as for the distributed control approach, isn't some kind of integration with jini already here? at least I read it on some papers (the teambotica one, to be precise) bye Mirko Bordignon - University of Padova, Italy mirko[dot]bordignon[at]ieee[dot]org Il giorno 07/giu/06, alle ore 11:41, Radu Bogdan Rusu ha scritto: > Fred, you raised a very important point in this discussion. Actually, > with the major overhaul in Player 2, it is now possible to drop the > client-server architecture, and simply wrap against certain libraries > (you will need libplayercore and libplayerdrivers for your > application - > for instance). > > I think that what Brian was suggesting is that different people have > different needs, so the best way to make everybody happy is to have a > lightweight modular architecture, on top of which we can build other > more "complex" things (I wouldn't call TCP/IP complex, but CORBA > almost > gets there). > > In my opinion, we shouldn't drop any of the existing transport or > communication mechanisms, but rather add new ones, and, when necessary > adapt the current ones to allow the existence of the new ones. > Makes sense? > > Cheers, > Radu. > > Fred Labrosse wrote: >> On Tue, 6 June, 2006 9:57 pm, Geoffrey Biggs wrote: >> >>> I also think that the ideas mentioned below of making player less >>> "client-server" and more "distributed-control-network" is an >>> important >>> direction. I think we need to move away from the idea of an overall >>> commanding client program doing all the management and more towards >>> local autonomy, and maybe moving away from the client-server >>> layout is >>> one way to achieve this. >>> >> >> Is the server/client architecture actually needed? Let me >> explain! I do >> appearance-based vision, i.e. no feature extraction. This means >> that my >> client needs to get raw images from the camera, which when sent >> over the >> network (even localhost) between the server and my client, this >> introduces >> impossible delays. At the moment, I can see two solutions: >> >> - not using player for the camera grabbing (my current solution as >> I had >> the code from before using player); >> - have my code not as a client but as a "driver" (or should that be a >> service or something like that?), at least something that runs in the >> server. >> >> Actually, the latter is probably the best way to do it, since as >> other did >> put it, player is also a sensor system. Is that something that is >> already >> possible (I have to admit that I didn't look at that at all since >> I have >> my own working solution now)? If it is possible, this also means >> that >> player should contain some image processing functions that all vision >> algorithms could use, and I would be more than happy to contribute to >> that, even possibly give you some (not everything is relevant) of >> my code. >> >> Cheers, >> >> Fred >> >> >> >> >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users >> > > -- > | Radu Bogdan Rusu | http://rbrusu.com/ > | http://www9.cs.tum.edu/people/rusu/ > | Intelligent Autonomous Systems > | Technische Universitaet Muenchen > > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Kurt K. <konolige@AI.SRI.COM> - 2006-06-06 21:02:36
|
How about a Windows implementation, at least of the client libs? Cheers --Kurt Brian Gerkey wrote: > hi, > > Our recent overhaul of Player has given us the opportunity to do some > new and interesting things. I'd like to know: what do you want? > > All ideas welcome, but I'm looking for relatively significant > enhancements. More like new transport mechanisms and less like a > driver for the latest laser range-finder. > > I'll assemble the responses into a prioritized wish list and post it > at the project website. I'll also incorporate the items from the SFU > wiki on ideas for a Google Summer of Code project. > > Here are a few ideas to get things going (feel free to comment on them): > > - New transport layers, getting away from the client-server model. > Candidates include CORBA, ACE, Reid Simmons' IPC... > > - Standard implementations of multi-robot algorithms. Whereas now we > have implementations of single-robot algorithms like AMCL and VFH, we > could implement multi-robot SLAM, auction-based task allocation, etc. > > - Support for structured "client-to-client" communications. Right > now, this is totally ad hoc, with everybody reinventing the wheel. > We could take ideas from the old lifomcom driver and new relay driver > to provide more fully-featured communication links among control > programs (which, depending on the transport mechanism in use, will > not necessarily be "clients") > > - Standard tasks to try in simulation, with instrumentation to > provide automatic evaluation. Richard's going in this direction with > the Zoo. > > brian. > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: Radu B. R. <ru...@cs...> - 2006-06-06 21:47:27
|
The Javaclient *should* already work ;) Not that I tried it lately or anything. Best, Radu. Kurt Konolige wrote: > How about a Windows implementation, at least of the client libs? > > Cheers --Kurt > > Brian Gerkey wrote: > >> hi, >> >> Our recent overhaul of Player has given us the opportunity to do some >> new and interesting things. I'd like to know: what do you want? >> >> All ideas welcome, but I'm looking for relatively significant >> enhancements. More like new transport mechanisms and less like a >> driver for the latest laser range-finder. >> >> I'll assemble the responses into a prioritized wish list and post it >> at the project website. I'll also incorporate the items from the SFU >> wiki on ideas for a Google Summer of Code project. >> >> Here are a few ideas to get things going (feel free to comment on them): >> >> - New transport layers, getting away from the client-server model. >> Candidates include CORBA, ACE, Reid Simmons' IPC... >> >> - Standard implementations of multi-robot algorithms. Whereas now we >> have implementations of single-robot algorithms like AMCL and VFH, we >> could implement multi-robot SLAM, auction-based task allocation, etc. >> >> - Support for structured "client-to-client" communications. Right >> now, this is totally ad hoc, with everybody reinventing the wheel. >> We could take ideas from the old lifomcom driver and new relay driver >> to provide more fully-featured communication links among control >> programs (which, depending on the transport mechanism in use, will >> not necessarily be "clients") >> >> - Standard tasks to try in simulation, with instrumentation to >> provide automatic evaluation. Richard's going in this direction with >> the Zoo. >> >> brian. >> >> >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users >> >> > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Shawn L. <la...@cs...> - 2006-06-06 22:48:43
|
I think the javaClient has some flaws and bugs in it yet, but I do believe that a "better" javaClient might have some interest to the community. Radu Bogdan Rusu wrote: > The Javaclient *should* already work ;) Not that I tried it lately or > anything. > > Best, > Radu. > > Kurt Konolige wrote: >> How about a Windows implementation, at least of the client libs? |
From: Radu B. R. <ru...@cs...> - 2006-06-07 07:47:39
|
I am more than happy to accept any patches or contributions you might have! :) Best, Radu. Shawn Lavelle wrote: > I think the javaClient has some flaws and bugs in it yet, but I do > believe that a "better" javaClient might have some interest to the > community. > > > Radu Bogdan Rusu wrote: > >> The Javaclient *should* already work ;) Not that I tried it lately or >> anything. >> >> Best, >> Radu. >> >> Kurt Konolige wrote: >> >>> How about a Windows implementation, at least of the client libs? >>> > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Mirko B. <mir...@ie...> - 2006-06-07 00:30:23
|
hi, as others said, I'd say service discovery; then I think some infrastructural redesign -or, meanwhile, a simple extension- could better address interoperation with simpler wireless sensor networks (I think about TinyOS related stuff), btw, isn't Player dubbed as a "Free Software that enables research in robot and sensor systems" ;-) ? the following excerpt made me think about it, although incorporating part of the zigbee stack is surely something more kernel/os related 4. Code for a Linux-based 802.15.4 access point. A Telos Mote plugged into a Linux PC acts as an 802.15.4 access point and routes packets to the Internet. (from http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2005- August/000767.html) maybe it's just because my instructor makes us work with bots and motes in the lab, but I think p/s should address the thing more clearly, even if it's already possible (with the proper os hacking and player driver development) to work out something (in fact I'm lobbying for p/s in the lab PCs as a mean to interface not only with the robots but with the sensor nodes too...) cheers Mirko Bordignon - University of Padova, Italy mirko[dot]bordignon[at]ieee[dot]org Il giorno 06/giu/06, alle ore 22:03, Brian Gerkey ha scritto: > hi, > > Our recent overhaul of Player has given us the opportunity to do some > new and interesting things. I'd like to know: what do you want? > > All ideas welcome, but I'm looking for relatively significant > enhancements. More like new transport mechanisms and less like a > driver for the latest laser range-finder. > > I'll assemble the responses into a prioritized wish list and post it > at the project website. I'll also incorporate the items from the SFU > wiki on ideas for a Google Summer of Code project. > > Here are a few ideas to get things going (feel free to comment on > them): > > - New transport layers, getting away from the client-server model. > Candidates include CORBA, ACE, Reid Simmons' IPC... > > - Standard implementations of multi-robot algorithms. Whereas now we > have implementations of single-robot algorithms like AMCL and VFH, we > could implement multi-robot SLAM, auction-based task allocation, etc. > > - Support for structured "client-to-client" communications. Right > now, this is totally ad hoc, with everybody reinventing the wheel. > We could take ideas from the old lifomcom driver and new relay driver > to provide more fully-featured communication links among control > programs (which, depending on the transport mechanism in use, will > not necessarily be "clients") > > - Standard tasks to try in simulation, with instrumentation to > provide automatic evaluation. Richard's going in this direction with > the Zoo. > > brian. > > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Radu B. R. <ru...@cs...> - 2006-06-07 07:46:41
|
You might want to check the CVS repository, as I committed working interfaces and code for mica2,mica2dot,rcore,particles,m1,m1-mini and m300 (check the wsn and rfid interfaces). I also have some automatic feature extraction plugin using PCA, ICA, Wavelets, Fourier (with the possibility to use the output of one as the input of another) and then combining them to calculate classical features like mean, variance, power spectrum, etc. This one is not committed yet though, as we lack a proper interface for that. I am currently using opaque in my own projects. Best, Radu. Mirko Bordignon wrote: > hi, > > as others said, I'd say service discovery; then I think some > infrastructural redesign -or, meanwhile, a simple extension- could > better address interoperation with simpler wireless sensor networks (I > think about TinyOS related stuff), > btw, isn't Player dubbed as a "Free Software that enables research in > robot and sensor systems" ;-) ? > > the following excerpt made me think about it, although incorporating > part of the zigbee stack is surely something more kernel/os related > > 4. Code for a Linux-based 802.15.4 access point. A Telos Mote plugged > into a Linux PC acts as an 802.15.4 access point and routes packets to > the Internet. > (from > http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2005-August/000767.html) > > > maybe it's just because my instructor makes us work with bots and > motes in the lab, but I think p/s should address the thing more > clearly, even if it's already possible (with the proper os hacking and > player driver development) to work out something > (in fact I'm lobbying for p/s in the lab PCs as a mean to interface > not only with the robots but with the sensor nodes too...) > > cheers > > Mirko Bordignon - University of Padova, Italy > > mirko[dot]bordignon[at]ieee[dot]org > > > > Il giorno 06/giu/06, alle ore 22:03, Brian Gerkey ha scritto: > >> hi, >> >> Our recent overhaul of Player has given us the opportunity to do some >> new and interesting things. I'd like to know: what do you want? >> >> All ideas welcome, but I'm looking for relatively significant >> enhancements. More like new transport mechanisms and less like a >> driver for the latest laser range-finder. >> >> I'll assemble the responses into a prioritized wish list and post it >> at the project website. I'll also incorporate the items from the SFU >> wiki on ideas for a Google Summer of Code project. >> >> Here are a few ideas to get things going (feel free to comment on them): >> >> - New transport layers, getting away from the client-server model. >> Candidates include CORBA, ACE, Reid Simmons' IPC... >> >> - Standard implementations of multi-robot algorithms. Whereas now we >> have implementations of single-robot algorithms like AMCL and VFH, we >> could implement multi-robot SLAM, auction-based task allocation, etc. >> >> - Support for structured "client-to-client" communications. Right >> now, this is totally ad hoc, with everybody reinventing the wheel. >> We could take ideas from the old lifomcom driver and new relay driver >> to provide more fully-featured communication links among control >> programs (which, depending on the transport mechanism in use, will >> not necessarily be "clients") >> >> - Standard tasks to try in simulation, with instrumentation to >> provide automatic evaluation. Richard's going in this direction with >> the Zoo. >> >> brian. >> >> >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > ------------------------------------------------------------------------ > > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |