From: Radu B. R. <ru...@cs...> - 2006-07-05 16:30:18
|
Hellos, Would it be possible to add a DATA mode to the graphics3d interface ? I am writing a driver that would really make use of that. Basically I need something that can return player_point_3d as data. Together with the ACCEPT/IGNORE/REPLACE patch (Brian, Toby - see e-mail), it should be pretty neat to ignore data packets from graphics3d in case they are not needed. Thanks, R. -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Radu B. R. <ru...@cs...> - 2006-07-09 14:22:19
Attachments:
functiontable.c.patch
player.h.patch
|
Ok, here's a patch that would allow DATA packets to be sent by a driver who makes use of graphics3d. I also believe that boosting the number of points from 64 to 1024 is an important move. Any reasons not to incorporate this asap? I would like to commit some drivers for building 3d laser maps soon. :) PS. I also put the patch up at SF. Thanks, R. Radu Bogdan Rusu wrote: > Hellos, > > Would it be possible to add a DATA mode to the graphics3d interface ? I am writing a > driver that would really make use of that. Basically I need something that can return > player_point_3d as data. > > Together with the ACCEPT/IGNORE/REPLACE patch (Brian, Toby - see e-mail), it should be > pretty neat to ignore data packets from graphics3d in case they are not needed. > > > Thanks, > R. > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Toby C. <tco...@pl...> - 2006-07-09 23:00:32
|
Hi, what is the purpose of the data packet, in my mind the graphics3d interface was a consumer of commands rather than a producer of packets (i.e. its responsible for rendering the point sets...) Could be its just too soon after waking up... Toby Radu Bogdan Rusu wrote: > Ok, here's a patch that would allow DATA packets to be sent by a driver > who makes use of graphics3d. I also believe that boosting the number of > points from 64 to 1024 is an important move. > > Any reasons not to incorporate this asap? I would like to commit some > drivers for building 3d laser maps soon. :) > > PS. I also put the patch up at SF. > Thanks, > R. > > Radu Bogdan Rusu wrote: >> Hellos, >> >> Would it be possible to add a DATA mode to the graphics3d interface ? >> I am writing a driver that would really make use of that. Basically I >> need something that can return player_point_3d as data. >> >> Together with the ACCEPT/IGNORE/REPLACE patch (Brian, Toby - see >> e-mail), it should be pretty neat to ignore data packets from >> graphics3d in case they are not needed. >> >> >> Thanks, >> R. >> > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Radu B. R. <ru...@cs...> - 2006-07-10 06:30:46
|
Toby Collett wrote: > Hi, > what is the purpose of the data packet, in my mind the graphics3d > interface was a consumer of commands rather than a producer of packets > (i.e. its responsible for rendering the point sets...) > > Could be its just too soon after waking up... :) No problem, I know the feeling. So, I wrote an e-mail on 23/06 ("wish list but also maybe more immediate plans") about the inability of representing 3d point clouds in Player. We are/will be building 3D maps from laser (and stereo) data, and naturally, I would feel much better if these drivers were in the repository so that other people can use them. Right now, I am looking at something that spits out arrays of X,Y,Z and Graphics3D seems like a good candidate. I was already thinking when I sent the e-mail yesterday, that I wouldn't mind a player_3dmap interface, which could be even more specific for these kinds of tasks. I have no problem maintaining it. Also, would there be an issue that an interface happens to have data packets too, but they are only used by some drivers ? I mean, if a driver doesn't publish anything, Player won't put anything on the wire, right? And since we're talking about the "wish list", what about true dynamic arrays (without a PLAYER_MAX limit) and other transport mechanisms ? The sooner we talk about it (easier to put it on the table here, than one just wasting time going through the code and trying to understand), the sooner I could get some students working on it. ;) Thanks, R. > > Toby > > Radu Bogdan Rusu wrote: >> Ok, here's a patch that would allow DATA packets to be sent by a driver >> who makes use of graphics3d. I also believe that boosting the number of >> points from 64 to 1024 is an important move. >> >> Any reasons not to incorporate this asap? I would like to commit some >> drivers for building 3d laser maps soon. :) >> >> PS. I also put the patch up at SF. >> Thanks, >> R. >> >> Radu Bogdan Rusu wrote: >>> Hellos, >>> >>> Would it be possible to add a DATA mode to the graphics3d interface ? >>> I am writing a driver that would really make use of that. Basically I >>> need something that can return player_point_3d as data. >>> >>> Together with the ACCEPT/IGNORE/REPLACE patch (Brian, Toby - see >>> e-mail), it should be pretty neat to ignore data packets from >>> graphics3d in case they are not needed. >>> >>> >>> Thanks, >>> R. >>> >> -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Toby C. <tco...@pl...> - 2006-07-10 10:22:05
|
Hi, I suspect that a separate interface for the point clouds might better for clarity rather than reusing the graphics 3d, it help maintain clarity of the interfaces. Possibly a 'pointmap' interface. My personal feeling is that all new interfaces added to player should be '3d' where possible (and where it makes sense) 2d drivers/clients can ignore the z component and the small data overhead is nothing compared to the pain of maintaining 2d and 3d versions of everything. There is no issue having some drivers provide data and other not, or even different drivers supporting different data outputs within an interface within limits. There is now the ability to report capabilities for drivers and all new drivers should do this (and we are happy to have patches adding capability reporting to other drivers...) Dynamic arrays must be the number one request at the moment (someone correct me if I get this wrong)...This is already dealt with in the transport so its only in the drivers and client libs that these limits are used. The problem is if we want to maintain C compatibility we cant have nice classes with constructors and destructors... This means either the user needs to allocate and deallocate all their own memory, or we need create and destroy methods for every structure... The latter is probably the 'standard' way to do it in terms of the kernel API's etc, and we could probably autogenerate these a la Brians xdr python scripts etc. but it would make the drivers and clients a little more verbose... The disadvantage of this is we need to change every driver again, and we still havent finished the last few straglers from the player 2.0 move... well theres my 2 cents (which ends up about 1 cent with the exchange rates) Toby Radu Bogdan Rusu wrote: > > Toby Collett wrote: >> Hi, >> what is the purpose of the data packet, in my mind the graphics3d >> interface was a consumer of commands rather than a producer of packets >> (i.e. its responsible for rendering the point sets...) >> >> Could be its just too soon after waking up... > > > :) No problem, I know the feeling. > > So, I wrote an e-mail on 23/06 ("wish list but also maybe more immediate plans") about the > inability of representing 3d point clouds in Player. We are/will be building 3D maps from > laser (and stereo) data, and naturally, I would feel much better if these drivers were in > the repository so that other people can use them. > > Right now, I am looking at something that spits out arrays of X,Y,Z and Graphics3D seems > like a good candidate. I was already thinking when I sent the e-mail yesterday, that I > wouldn't mind a player_3dmap interface, which could be even more specific for these kinds > of tasks. I have no problem maintaining it. > > Also, would there be an issue that an interface happens to have data packets too, but they > are only used by some drivers ? I mean, if a driver doesn't publish anything, Player won't > put anything on the wire, right? > > And since we're talking about the "wish list", what about true dynamic arrays (without a > PLAYER_MAX limit) and other transport mechanisms ? The sooner we talk about it (easier to > put it on the table here, than one just wasting time going through the code and trying to > understand), the sooner I could get some students working on it. ;) > > Thanks, > R. > >> Toby >> >> Radu Bogdan Rusu wrote: >>> Ok, here's a patch that would allow DATA packets to be sent by a driver >>> who makes use of graphics3d. I also believe that boosting the number of >>> points from 64 to 1024 is an important move. >>> >>> Any reasons not to incorporate this asap? I would like to commit some >>> drivers for building 3d laser maps soon. :) >>> >>> PS. I also put the patch up at SF. >>> Thanks, >>> R. >>> >>> Radu Bogdan Rusu wrote: >>>> Hellos, >>>> >>>> Would it be possible to add a DATA mode to the graphics3d interface ? >>>> I am writing a driver that would really make use of that. Basically I >>>> need something that can return player_point_3d as data. >>>> >>>> Together with the ACCEPT/IGNORE/REPLACE patch (Brian, Toby - see >>>> e-mail), it should be pretty neat to ignore data packets from >>>> graphics3d in case they are not needed. >>>> >>>> >>>> Thanks, >>>> R. >>>> > |
From: Geoffrey B. <g....@au...> - 2006-07-10 11:03:10
|
Based on your previous email and this one, you essentially want an interface for scanners that return ranges in three dimensions rather than a line in two dimensions. Is that correct? If that's the case, a far better idea than trying to make the graphics3d interface do something it isn't intended for (and so creating confusion about the name) is for us to design a new, properly 3D generic ranger device interface sorted. This should work just as well for an array of sonar/IR sensors, a standard laser scanner, a 3D laser scanner, and various other forms of scanners. It isn't an issue for an interface to have data packets that aren't often used, but it's an issue if they don't make sense for the interface's intended purpose, as that leads to confusion and overly complicated interfaces doing more than they should. I think it's much better to create a new interface when supporting a new device type. It's about time Player supported 3D scanners properly. Now seems like a good time to get going on designing the necessary interface. So I'll kick it off. Firstly, a generic ranger interface would be nice to abstract away the differences between sonar, laser and IR sensors. This is something Toby and I have been contemplating as a good idea for a while. Data - ranges[dynamic array would be nice] - scan poses[] - resolution of the array (2d to allow x and y res?) Commands Requests - Geom: pose (3d!), some kind of dimensions of the array? - Power Wow, that's smaller than I expected. Anyway, then the laser, sonar, ir interfaces can be designed to provide the specific functionality for each (like intensities, control of scan rates, etc). If people don't like the idea of a generic interface, then we should at least provide a laser3d interface. Same as the laser one, but make everything 3d, and allow for 2d arrays of scans. Tiredly hoping something useful comes of this, Geoff Radu Bogdan Rusu wrote: > So, I wrote an e-mail on 23/06 ("wish list but also maybe more immediate plans") about the > inability of representing 3d point clouds in Player. We are/will be building 3D maps from > laser (and stereo) data, and naturally, I would feel much better if these drivers were in > the repository so that other people can use them. > > Right now, I am looking at something that spits out arrays of X,Y,Z and Graphics3D seems > like a good candidate. I was already thinking when I sent the e-mail yesterday, that I > wouldn't mind a player_3dmap interface, which could be even more specific for these kinds > of tasks. I have no problem maintaining it. > > Also, would there be an issue that an interface happens to have data packets too, but they > are only used by some drivers ? I mean, if a driver doesn't publish anything, Player won't > put anything on the wire, right? -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Raymond S. <rsh...@ra...> - 2006-07-10 12:19:56
|
>Radu wrote: ><snip> >Right now, I am looking at something that spits out arrays of X,Y,Z and >Graphics3D seems >like a good candidate. I was already thinking when I sent the e-mail >yesterday, that I >wouldn't mind a player_3dmap interface, which could be even more specific >for these kinds >of tasks. I have no problem maintaining it. > >Also, would there be an issue that an interface happens to have data >packets too, but they >are only used by some drivers ? I mean, if a driver doesn't publish >anything, Player won't >put anything on the wire, right? > >And since we're talking about the "wish list", what about true dynamic >arrays (without a >PLAYER_MAX limit) and other transport mechanisms ? The sooner we talk >about it (easier to >put it on the table here, than one just wasting time going through the >code and trying to >understand), the sooner I could get some students working on it. ;) ><snip> Trying to handle variable sized things (pointclouds and other 'composite' data structures) was one thing we could really make use of in Player (we've resorted to Ice/Orca when we've had to do that sorta thing) ... great to see a growing push to make Player capable of this :-) Geoff wrote: <snip> >Firstly, a generic ranger interface would be nice to abstract away the >differences between sonar, laser and IR sensors. This is something Toby >and I have been contemplating as a good idea for a while. > >Data >- ranges[dynamic array would be nice] >- scan poses[] >- resolution of the array (2d to allow x and y res?) <snip> I realise I'm rather a novice when it comes to P/S but if I could add my $0.02AUD worth, one issue we've found with treating the range sensor effectively as a 2D imager that provides range instead of intensity (I think that's what you're getting at right? Correct me if I'm wrong!) is that often you don't get a nice rectangular set of data - especially if you're doing a lot of sanity checks at the driver level and the actual 3D data is quite sparse (such as the case with stereo vision for instance), if you've got data from several range imagers (or the one range imager in several positions) or you've got a range sensor that might use a different co-ordinate system (a laser rotating about the roll axis will give you a circular set of data for instance - you could treat it as rectangular and take the vertical co-ordinate as angle but you may then end up with convention issues). A second potential issue is that we've found it very useful to fuse data from several imagers at the robot end so that we're guaranteed everything is in sync. For instance we've got a range, thermal and colour imager all pointing in the one direction ... another example would be when you're doing stereo and you've got both range and colour. From our experience it might be useful to have a more general pointcloud (rather than effective a "range image") ... maybe something which has the following: - Range sensor pose (or poses if it's a combination from several imagers or several positions?) - Number of data points - Type of data points - Datapoints[] In this case Datapoints would carry variable dimensional data and consist of the usual [X, Y, Z] tuple as well as none or more of [R, G, B], [Reflectance, Intensity], [Temperature], [PoseIndex] and so-on (one alternative would be to have a Datapoints[] array which would have [X, Y, Z] then additional arrays to carry the other dimensions) ... the question is, how much would THIS break things architecturally? :-) Cheers! - Raymond |
From: Brian G. <br...@ge...> - 2006-07-11 00:30:54
|
On Jul 9, 2006, at 11:30 PM, Radu Bogdan Rusu wrote: > Right now, I am looking at something that spits out arrays of X,Y,Z > and Graphics3D seems > like a good candidate. I was already thinking when I sent the e- > mail yesterday, that I > wouldn't mind a player_3dmap interface, which could be even more > specific for these kinds > of tasks. I have no problem maintaining it. I agree with Toby and Geoff that a new interface is warranted here. It's tempting to reuse an existing interface, but when the new use is quite different from the original intent of the interface, confusion is sure to follow. > And since we're talking about the "wish list", what about true > dynamic arrays (without a > PLAYER_MAX limit) and other transport mechanisms ? The sooner we > talk about it (easier to > put it on the table here, than one just wasting time going through > the code and trying to > understand), the sooner I could get some students working on it. ;) Historically, those limits were there because all messages were fixed size, even when sent on the wire. When we moved to XDR-encoding, the messages became dynamically-sized on the wire. However, they're still passed at max-size going in and out of drivers (and clients). Doing it like this simplifies the messaging API, because I can pass you a pointer to a fixed-size struct, and you can easily access its member fields directly. People are starting to chafe at these limits, so the question is how best get away from them. One way would be to keep the fundamental definition of the messages as C structs, but specify arrays as pointers (with an auxiliary size field), instead of sized arrays. The structs would still be fixed- size and could, for example, be safely declared on the stack. As Toby has pointed out, you would have to explicitly manage the memory pointed to by the structs. We could hide some of this in the transport layer(s), but drivers and clients would end up doing some memory management. An alternative would be to drop C structs as the definition language for Player messages, and move to a "modern" interface definition language. I've never tried one, but I imagine that the IDLs used by CORBA systems must be flexible enough to do what we want. The question there is how much overhead is involved in using the IDL, and how easy it is to access IDL-defined structures in various languages (importantly, C). I'm very interested in implementing a peer-to-peer transport (possibly ICE, which many have mentioned recently) in the near future, and I'd like to roll this variable-sized message change in at the same time. Another thing to think about is how we can distribute the interface definitions. Right now everything is defined in player.h, which makes the addition of new interfaces somewhat cumbersome. I've gotten close to a plugin-interface setup, but we're still missing some functionality to make this easy to do. CARMEN does something interesting here, which is for each module to provide a library that packs, unpacks, and provides accessor functions for all messages that the module produces. So if you want to read messages from the 'laser' module, you link your program against the 'laser_interface' library. Of course, by distributing the interface definitions to this degree, there's no way to guarantee (or effectively encourage) multiple drivers/modules to adhere to a common interface. Comments, thoughts? brian. |
From: Radu B. R. <ru...@cs...> - 2006-07-11 19:21:11
|
Okay then. Time to make a new interface! :) I think it would be safe to begin with: #define PLAYER_3DPOINTCLOUD_MAX_POINTS ... (what would be an appropriate value here?) #define PLAYER_3DPOINTCLOUD_DATA_STATE 1 typedef struct player_3dpointcloud_data { uint32_t points_count; player_point_3d_t points[PLAYER_3DPOINTCLOUD_MAX_POINTS]; uint32_t points_colors_count; player_color_t colors[PLAYER_3DPOINTCLOUD_MAX_POINTS]; } player_3dpointcloud_data_t; #define PLAYER_3DPOINTCLOUD_GET_GEOM_REQ 1 typedef struct player_3dpointcloud_geom { player_pose3d_t pose; // or, as Raymond suggested in a previous e-mail (with PLAYER_3DPOINTCLOUD_MAX_POSES // defined earlier somewhere): // // uint32_t poses_count; // player_pose3d_t poses[PLAYER_3DPOINTCLOUD_MAX_POSES]; } Please feel free to commend, fix or add additional structures/definitions. Brian Gerkey wrote: > On Jul 9, 2006, at 11:30 PM, Radu Bogdan Rusu wrote: > >> Right now, I am looking at something that spits out arrays of X,Y,Z >> and Graphics3D seems >> like a good candidate. I was already thinking when I sent the e- >> mail yesterday, that I >> wouldn't mind a player_3dmap interface, which could be even more >> specific for these kinds >> of tasks. I have no problem maintaining it. > > I agree with Toby and Geoff that a new interface is warranted here. > It's tempting to reuse an existing interface, but when the new use is > quite different from the original intent of the interface, confusion > is sure to follow. PS. Brian, you can remove the graphics3d patch from SF then. Thanks. Best, R. -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Geoffrey B. <g....@au...> - 2006-07-12 21:12:37
|
Is there anything else that this interface should be doing? Rather than just an interface to a big bunch of points, should we consider information about devices that produce such data? Eg resolution, pose of the device that's producing the data, etc. Geoff Radu Bogdan Rusu wrote: > Okay then. Time to make a new interface! :) > > I think it would be safe to begin with: > #define PLAYER_3DPOINTCLOUD_MAX_POINTS ... (what would be an appropriate value here?) > #define PLAYER_3DPOINTCLOUD_DATA_STATE 1 > typedef struct player_3dpointcloud_data > { > uint32_t points_count; > player_point_3d_t points[PLAYER_3DPOINTCLOUD_MAX_POINTS]; > uint32_t points_colors_count; > player_color_t colors[PLAYER_3DPOINTCLOUD_MAX_POINTS]; > } player_3dpointcloud_data_t; > > #define PLAYER_3DPOINTCLOUD_GET_GEOM_REQ 1 > typedef struct player_3dpointcloud_geom > { > player_pose3d_t pose; > // or, as Raymond suggested in a previous e-mail (with PLAYER_3DPOINTCLOUD_MAX_POSES > // defined earlier somewhere): > // > // uint32_t poses_count; > // player_pose3d_t poses[PLAYER_3DPOINTCLOUD_MAX_POSES]; > } > > Please feel free to commend, fix or add additional structures/definitions. -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Radu B. R. <ru...@cs...> - 2006-07-12 08:18:30
|
So it looks like there are two separate things, which could be "solved" through a single, but more major modification. Unfortunately it seems that the array problem is related to the possibility of having a C-compatible framework. Drop C, and you already get access to vectors/dynamic arrays. Keep C, drivers+clients must take care of memory management. I think one of the most powerful features of Player is its "language independence", meaning that we have a bunch of very different programming languages that it can be used from. I wouldn't like this to die. I have colleagues who have been using Player/Gazebo with LISP for years now, and their results are impressive. On the other hand, it seems that by switching to an IDL like ICE, you still get the possibility of using it from at least C++, Java and Python (I am not mentioning PHP since we don't have a client for Player yet, and the other two languages supported by ICE are evil anyway). Keeping two versions of Player is out of the question. It would complicate things way too much. So the goal would be to keep the current TCP/UDP transport mechanism (libplayertcp+xdr) and add a libplayerice near it, so that the user could switch between the two transport mechanisms. Maybe, just maybe, we could keep two separate lists of "supported languages/platforms", one based on the standard TCP/UDP/XDR mechanism, and another based on ICE, meaning that for instance we would still have Ada, LISP, etc clients for libplayertcp/xdr, but only C++/Java/Python would be supported for libplayerice. It might sound "cruel", but I think it's reasonable. I guess not too many people would like to code CORBA/ICE/ACE/etc wrappers in LISP anyway. I guess the only issue is... what happens to plain C? A lot of other platforms ran away from it, and are either 100% C++, or hybrid, by making use of IDLs such as ICE. I would like to see a better way of defining interfaces, as Brian mentioned, but I am also a fan of the already imposed standards too. I guess the possibility of serializing your own objects or defining your own data structures in a true manner, through the usage of an opaque interface would still be the best way to go for people who need "obscure" definitions. The most important move for me personally, would be to get rid of the "static" limits, since I don't think we can keep on boosting them up forever. Even with the newly proposed 3dpointcloud (or whatever its name is going to be at the end) interface, it will be hard to decide on an upper limit. Feel free to correct me if I'm wrong. Best, R. Brian Gerkey wrote: > On Jul 9, 2006, at 11:30 PM, Radu Bogdan Rusu wrote: >> And since we're talking about the "wish list", what about true >> dynamic arrays (without a >> PLAYER_MAX limit) and other transport mechanisms ? The sooner we >> talk about it (easier to >> put it on the table here, than one just wasting time going through >> the code and trying to >> understand), the sooner I could get some students working on it. ;) > > Historically, those limits were there because all messages were fixed > size, even when sent on the wire. When we moved to XDR-encoding, the > messages became dynamically-sized on the wire. However, they're > still passed at max-size going in and out of drivers (and clients). > Doing it like this simplifies the messaging API, because I can pass > you a pointer to a fixed-size struct, and you can easily access its > member fields directly. > > People are starting to chafe at these limits, so the question is how > best get away from them. > > One way would be to keep the fundamental definition of the messages > as C structs, but specify arrays as pointers (with an auxiliary size > field), instead of sized arrays. The structs would still be fixed- > size and could, for example, be safely declared on the stack. As > Toby has pointed out, you would have to explicitly manage the memory > pointed to by the structs. We could hide some of this in the > transport layer(s), but drivers and clients would end up doing some > memory management. > > An alternative would be to drop C structs as the definition language > for Player messages, and move to a "modern" interface definition > language. I've never tried one, but I imagine that the IDLs used by > CORBA systems must be flexible enough to do what we want. The > question there is how much overhead is involved in using the IDL, and > how easy it is to access IDL-defined structures in various languages > (importantly, C). > > I'm very interested in implementing a peer-to-peer transport > (possibly ICE, which many have mentioned recently) in the near > future, and I'd like to roll this variable-sized message change in at > the same time. > > Another thing to think about is how we can distribute the interface > definitions. Right now everything is defined in player.h, which > makes the addition of new interfaces somewhat cumbersome. I've > gotten close to a plugin-interface setup, but we're still missing > some functionality to make this easy to do. CARMEN does something > interesting here, which is for each module to provide a library that > packs, unpacks, and provides accessor functions for all messages that > the module produces. So if you want to read messages from the > 'laser' module, you link your program against the 'laser_interface' > library. Of course, by distributing the interface definitions to > this degree, there's no way to guarantee (or effectively encourage) > multiple drivers/modules to adhere to a common interface. > > Comments, thoughts? > > brian. > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Toby C. <tco...@pl...> - 2006-07-12 20:44:49
|
Hi, Having slept on the dynamic array issue a couple of things have occurred to me: 1) as previously mentioned, the static limits are features of the drivers and clients alone, not the transport layer 2) The server is already c++ only so there is no issue here with creating classes to wrap the structures (and therefore handle the arrays) 3) So the c client is the only area where changing will require manual memory management, and this should be able to be wrapper up in the proxies. so... We should be able to move to dynamic length arrays without affecting any client applications, and we should be able to simply the driver updates with some wrapper classes around the raw structures. At the same time we could implement Brians pluggable interfaces, which should be kept separate from pluggable drivers to encourage reuse of the interfaces... If people agree with this the question becomes who has time to carry this all out, and are we aiming to incorperate this in 2.1 or somewhere further down the track (and can we add the queue autopointers while we are breaking everything else :) Toby Radu Bogdan Rusu wrote: > So it looks like there are two separate things, which could be "solved" through a single, > but more major modification. > > Unfortunately it seems that the array problem is related to the possibility of having a > C-compatible framework. Drop C, and you already get access to vectors/dynamic arrays. Keep > C, drivers+clients must take care of memory management. > > I think one of the most powerful features of Player is its "language independence", > meaning that we have a bunch of very different programming languages that it can be used > from. I wouldn't like this to die. I have colleagues who have been using Player/Gazebo > with LISP for years now, and their results are impressive. > > On the other hand, it seems that by switching to an IDL like ICE, you still get the > possibility of using it from at least C++, Java and Python (I am not mentioning PHP since > we don't have a client for Player yet, and the other two languages supported by ICE are > evil anyway). > > Keeping two versions of Player is out of the question. It would complicate things way too > much. > > So the goal would be to keep the current TCP/UDP transport mechanism (libplayertcp+xdr) > and add a libplayerice near it, so that the user could switch between the two transport > mechanisms. Maybe, just maybe, we could keep two separate lists of "supported > languages/platforms", one based on the standard TCP/UDP/XDR mechanism, and another based > on ICE, meaning that for instance we would still have Ada, LISP, etc clients for > libplayertcp/xdr, but only C++/Java/Python would be supported for libplayerice. It might > sound "cruel", but I think it's reasonable. I guess not too many people would like to code > CORBA/ICE/ACE/etc wrappers in LISP anyway. > > I guess the only issue is... what happens to plain C? A lot of other platforms ran away > from it, and are either 100% C++, or hybrid, by making use of IDLs such as ICE. > > I would like to see a better way of defining interfaces, as Brian mentioned, but I am also > a fan of the already imposed standards too. I guess the possibility of serializing your > own objects or defining your own data structures in a true manner, through the usage of an > opaque interface would still be the best way to go for people who need "obscure" definitions. > > The most important move for me personally, would be to get rid of the "static" limits, > since I don't think we can keep on boosting them up forever. Even with the newly proposed > 3dpointcloud (or whatever its name is going to be at the end) interface, it will be hard > to decide on an upper limit. > > Feel free to correct me if I'm wrong. > > Best, > R. > > Brian Gerkey wrote: >> On Jul 9, 2006, at 11:30 PM, Radu Bogdan Rusu wrote: >>> And since we're talking about the "wish list", what about true >>> dynamic arrays (without a >>> PLAYER_MAX limit) and other transport mechanisms ? The sooner we >>> talk about it (easier to >>> put it on the table here, than one just wasting time going through >>> the code and trying to >>> understand), the sooner I could get some students working on it. ;) >> Historically, those limits were there because all messages were fixed >> size, even when sent on the wire. When we moved to XDR-encoding, the >> messages became dynamically-sized on the wire. However, they're >> still passed at max-size going in and out of drivers (and clients). >> Doing it like this simplifies the messaging API, because I can pass >> you a pointer to a fixed-size struct, and you can easily access its >> member fields directly. >> >> People are starting to chafe at these limits, so the question is how >> best get away from them. >> >> One way would be to keep the fundamental definition of the messages >> as C structs, but specify arrays as pointers (with an auxiliary size >> field), instead of sized arrays. The structs would still be fixed- >> size and could, for example, be safely declared on the stack. As >> Toby has pointed out, you would have to explicitly manage the memory >> pointed to by the structs. We could hide some of this in the >> transport layer(s), but drivers and clients would end up doing some >> memory management. >> >> An alternative would be to drop C structs as the definition language >> for Player messages, and move to a "modern" interface definition >> language. I've never tried one, but I imagine that the IDLs used by >> CORBA systems must be flexible enough to do what we want. The >> question there is how much overhead is involved in using the IDL, and >> how easy it is to access IDL-defined structures in various languages >> (importantly, C). >> >> I'm very interested in implementing a peer-to-peer transport >> (possibly ICE, which many have mentioned recently) in the near >> future, and I'd like to roll this variable-sized message change in at >> the same time. >> >> Another thing to think about is how we can distribute the interface >> definitions. Right now everything is defined in player.h, which >> makes the addition of new interfaces somewhat cumbersome. I've >> gotten close to a plugin-interface setup, but we're still missing >> some functionality to make this easy to do. CARMEN does something >> interesting here, which is for each module to provide a library that >> packs, unpacks, and provides accessor functions for all messages that >> the module produces. So if you want to read messages from the >> 'laser' module, you link your program against the 'laser_interface' >> library. Of course, by distributing the interface definitions to >> this degree, there's no way to guarantee (or effectively encourage) >> multiple drivers/modules to adhere to a common interface. >> >> Comments, thoughts? >> >> brian. >> > |
From: Raymond S. <rsh...@ra...> - 2006-07-13 06:19:33
|
Hi all, I hope people don't mind me making a few suggestions ... again I make the point that whilst I've played a bit with moving 3D data around I'm not too familiar with conventions in the Player server so take with a suitably sized grain of salt. Geoff wrote: > Is there anything else that this interface should be doing? Rather than > just an interface to a big bunch of points, should we consider > information about devices that produce such data? Eg resolution, pose of > the device that's producing the data, etc. I think it might be useful for provisions for a variety of point-specific data to be included as well as sensor specific ... perhaps what Radu suggested could be extended somewhat? If everything is now in variable sized vectors we could have something like this (no attempt made to get it syntactically correct): typedef struct player_3dpointcloud_data { uint16_t sensor_count; vector <player_3dpointcloud_sensor_params_t> sensor_params; uint32_t points_count; vector <player_point_3d_t> points; vector <uint16_t> sensor_id; <== if you have only 1 sensor, you could leave this zero length (and assume the lone element of sensor_params is it) vector <player_color_t> color; vector <double> intensity; (... and so-on) } player_3dpointcloud_data_t; Sensor specific stuff could then be stored in: typedef struct player_3dpointcloud_sensor_params { player_pose3d_t pose; (some resolution type) resolution; (some enumeration type) sensortype; (some other enumeration type) sensorstate; vector <player_point_3d_t> boundingvolume; <=== not necessarily rectangular (... and so-on) } player_3dpointcloud_sensor_params_t; You'd have a constraint that apart from sensor_params, all of the vectors in player_3dpointcloud_data_t were either points_count in length or zero length if not available (points_count is actually redundant, maybe the length of points could be the controlling length and any other vector with a non-zero length different from points could be treated as invalid?). Perhaps we could then have some "standard" set of data elements (the ... and so-on bit) and if your sensor doesn't have them, simply leave the vector as zero-length ... here are some that we've used before in our pointclouds: [r, g, b] <== uint8s [intensity, reflectance] <== uint32s [temperature] <== double [flag] <== int enum of landmark, victim, focus, background, etc. [type] <== int enum of initialised, filtered, unfiltered, junk, matching_landmark, etc. [(un)certainty] <== double As long as each of these was a fixed size we'd probably be pretty safe ... and because we could have them as zero length, you could have a pile of these with minimal overhead if they weren't actually used. This would also preserve transparency in the sense that clients don't need to change if the sensor changed (3D data from a rotating laser will look the same as from a range imager which would look the same as data from an MRI scanner with the exception of the distribution of points) - unless the sensor was missing data that the client needed. If you wanted to include resolution (actually I think it might be more useful to specify some bounding volume - comparing resolutions across sensor types gets tricky - is resolution 2D or 3D? Polar or cartesian? Foveated/variable or fixed?) one could include it inside player_3dpointcloud_sensor_params_t (which would also include pose, bounding volume, type, etc.) ... this might be particularly useful where the data is preprocessed (because of the volumes of data generated, you'd want to merge/cull/filter as close to the sensor as possible) - you might specify the type of preprocessing in the sensor params (and clients which don't care could ignore it). I'm sure I've broken a pile of Player conventions in this suggestion ... heh ... Toby wrote: <snip> > If people agree with this the question becomes who has time to carry > this all out, and are we aiming to incorperate this in 2.1 or somewhere > further down the track (and can we add the queue autopointers while we > are breaking everything else :) Whilst we're breaking things, could I make another quick suggestion? :-D One thing that would be very nice (and complement pointclouds) is on-the-fly lossless compression (bzip comes to mind). CameraCompress has been doing it as a passthrough for lossy (jpeg) compression but would it be worth putting an (optional) lossless compression layer, maybe at (or just before) the transport level rather than at the driver level? We've found that pointclouds can compress down very well depending on the sensor used but other things (like certain cameras that you don't want to compress with lossy compression) could benefit ... </$0.02> - Raymond |
From: Brian G. <br...@ge...> - 2006-07-25 17:14:06
|
Have we reached a consensus on this interface? Anybody care to submit a new draft for inclusion in player.h? brian. On Jul 12, 2006, at 11:19 PM, Raymond Sheh wrote: > Hi all, > > > I hope people don't mind me making a few suggestions ... again I > make the > point that whilst I've played a bit with moving 3D data around I'm > not too > familiar with conventions in the Player server so take with a suitably > sized grain of salt. > > > Geoff wrote: >> Is there anything else that this interface should be doing? Rather >> than >> just an interface to a big bunch of points, should we consider >> information about devices that produce such data? Eg resolution, >> pose of >> the device that's producing the data, etc. > > I think it might be useful for provisions for a variety of point- > specific > data to be included as well as sensor specific ... perhaps what Radu > suggested could be extended somewhat? If everything is now in variable > sized vectors we could have something like this (no attempt made to > get it > syntactically correct): > > typedef struct player_3dpointcloud_data > { > > uint16_t sensor_count; > vector <player_3dpointcloud_sensor_params_t> sensor_params; > > uint32_t points_count; > vector <player_point_3d_t> points; > vector <uint16_t> sensor_id; <== if you have only 1 sensor, you > could leave this zero length (and assume the lone element of > sensor_params > is it) > vector <player_color_t> color; > vector <double> intensity; > (... and so-on) > > } player_3dpointcloud_data_t; > > > Sensor specific stuff could then be stored in: > > typedef struct player_3dpointcloud_sensor_params > { > player_pose3d_t pose; > (some resolution type) resolution; > (some enumeration type) sensortype; > (some other enumeration type) sensorstate; > vector <player_point_3d_t> boundingvolume; <=== not necessarily > rectangular > (... and so-on) > } player_3dpointcloud_sensor_params_t; > > > You'd have a constraint that apart from sensor_params, all of the > vectors > in player_3dpointcloud_data_t were either points_count in length or > zero > length if not available (points_count is actually redundant, maybe the > length of points could be the controlling length and any other > vector with > a non-zero length different from points could be treated as invalid?). > Perhaps we could then have some "standard" set of data elements > (the ... > and so-on bit) and if your sensor doesn't have them, simply leave the > vector as zero-length ... here are some that we've used before in our > pointclouds: > [r, g, b] <== uint8s > [intensity, reflectance] <== uint32s > [temperature] <== double > [flag] <== int enum of landmark, victim, focus, background, etc. > [type] <== int enum of initialised, filtered, unfiltered, junk, > matching_landmark, etc. > [(un)certainty] <== double > > As long as each of these was a fixed size we'd probably be pretty > safe ... > and because we could have them as zero length, you could have a > pile of > these with minimal overhead if they weren't actually used. This > would also > preserve transparency in the sense that clients don't need to > change if the > sensor changed (3D data from a rotating laser will look the same as > from a > range imager which would look the same as data from an MRI scanner > with the > exception of the distribution of points) - unless the sensor was > missing > data that the client needed. > > If you wanted to include resolution (actually I think it might be more > useful to specify some bounding volume - comparing resolutions across > sensor types gets tricky - is resolution 2D or 3D? Polar or cartesian? > Foveated/variable or fixed?) one could include it inside > player_3dpointcloud_sensor_params_t (which would also include pose, > bounding volume, type, etc.) ... this might be particularly useful > where > the data is preprocessed (because of the volumes of data generated, > you'd > want to merge/cull/filter as close to the sensor as possible) - you > might > specify the type of preprocessing in the sensor params (and clients > which > don't care could ignore it). > > > I'm sure I've broken a pile of Player conventions in this > suggestion ... > heh ... > > > > Toby wrote: > <snip> >> If people agree with this the question becomes who has time to carry >> this all out, and are we aiming to incorperate this in 2.1 or >> somewhere >> further down the track (and can we add the queue autopointers >> while we >> are breaking everything else :) > > Whilst we're breaking things, could I make another quick > suggestion? :-D > > One thing that would be very nice (and complement pointclouds) is > on-the-fly lossless compression (bzip comes to mind). > CameraCompress has > been doing it as a passthrough for lossy (jpeg) compression but > would it be > worth putting an (optional) lossless compression layer, maybe at > (or just > before) the transport level rather than at the driver level? We've > found > that pointclouds can compress down very well depending on the > sensor used > but other things (like certain cameras that you don't want to > compress with > lossy compression) could benefit ... > > > > </$0.02> > > > - Raymond > > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Radu B. R. <ru...@cs...> - 2006-07-25 20:55:56
|
I was going to do it early next week, probably after another chat with Raymond. I am currently on the road, so internet access is kind of intermittent. Best, R. On Tue, Jul 25, 2006 at 10:14:04AM -0700, Brian Gerkey wrote: > Have we reached a consensus on this interface? Anybody care to > submit a new draft for inclusion in player.h? > > brian. > > On Jul 12, 2006, at 11:19 PM, Raymond Sheh wrote: > > > Hi all, > > > > > > I hope people don't mind me making a few suggestions ... again I > > make the > > point that whilst I've played a bit with moving 3D data around I'm > > not too > > familiar with conventions in the Player server so take with a suitably > > sized grain of salt. > > > > > > Geoff wrote: > >> Is there anything else that this interface should be doing? Rather > >> than > >> just an interface to a big bunch of points, should we consider > >> information about devices that produce such data? Eg resolution, > >> pose of > >> the device that's producing the data, etc. > > > > I think it might be useful for provisions for a variety of point- > > specific > > data to be included as well as sensor specific ... perhaps what Radu > > suggested could be extended somewhat? If everything is now in variable > > sized vectors we could have something like this (no attempt made to > > get it > > syntactically correct): > > > > typedef struct player_3dpointcloud_data > > { > > > > uint16_t sensor_count; > > vector <player_3dpointcloud_sensor_params_t> sensor_params; > > > > uint32_t points_count; > > vector <player_point_3d_t> points; > > vector <uint16_t> sensor_id; <== if you have only 1 sensor, you > > could leave this zero length (and assume the lone element of > > sensor_params > > is it) > > vector <player_color_t> color; > > vector <double> intensity; > > (... and so-on) > > > > } player_3dpointcloud_data_t; > > > > > > Sensor specific stuff could then be stored in: > > > > typedef struct player_3dpointcloud_sensor_params > > { > > player_pose3d_t pose; > > (some resolution type) resolution; > > (some enumeration type) sensortype; > > (some other enumeration type) sensorstate; > > vector <player_point_3d_t> boundingvolume; <=== not necessarily > > rectangular > > (... and so-on) > > } player_3dpointcloud_sensor_params_t; > > > > > > You'd have a constraint that apart from sensor_params, all of the > > vectors > > in player_3dpointcloud_data_t were either points_count in length or > > zero > > length if not available (points_count is actually redundant, maybe the > > length of points could be the controlling length and any other > > vector with > > a non-zero length different from points could be treated as invalid?). > > Perhaps we could then have some "standard" set of data elements > > (the ... > > and so-on bit) and if your sensor doesn't have them, simply leave the > > vector as zero-length ... here are some that we've used before in our > > pointclouds: > > [r, g, b] <== uint8s > > [intensity, reflectance] <== uint32s > > [temperature] <== double > > [flag] <== int enum of landmark, victim, focus, background, etc. > > [type] <== int enum of initialised, filtered, unfiltered, junk, > > matching_landmark, etc. > > [(un)certainty] <== double > > > > As long as each of these was a fixed size we'd probably be pretty > > safe ... > > and because we could have them as zero length, you could have a > > pile of > > these with minimal overhead if they weren't actually used. This > > would also > > preserve transparency in the sense that clients don't need to > > change if the > > sensor changed (3D data from a rotating laser will look the same as > > from a > > range imager which would look the same as data from an MRI scanner > > with the > > exception of the distribution of points) - unless the sensor was > > missing > > data that the client needed. > > > > If you wanted to include resolution (actually I think it might be more > > useful to specify some bounding volume - comparing resolutions across > > sensor types gets tricky - is resolution 2D or 3D? Polar or cartesian? > > Foveated/variable or fixed?) one could include it inside > > player_3dpointcloud_sensor_params_t (which would also include pose, > > bounding volume, type, etc.) ... this might be particularly useful > > where > > the data is preprocessed (because of the volumes of data generated, > > you'd > > want to merge/cull/filter as close to the sensor as possible) - you > > might > > specify the type of preprocessing in the sensor params (and clients > > which > > don't care could ignore it). > > > > > > I'm sure I've broken a pile of Player conventions in this > > suggestion ... > > heh ... > > > > > > > > Toby wrote: > > <snip> > >> If people agree with this the question becomes who has time to carry > >> this all out, and are we aiming to incorperate this in 2.1 or > >> somewhere > >> further down the track (and can we add the queue autopointers > >> while we > >> are breaking everything else :) > > > > Whilst we're breaking things, could I make another quick > > suggestion? :-D > > > > One thing that would be very nice (and complement pointclouds) is > > on-the-fly lossless compression (bzip comes to mind). > > CameraCompress has > > been doing it as a passthrough for lossy (jpeg) compression but > > would it be > > worth putting an (optional) lossless compression layer, maybe at > > (or just > > before) the transport level rather than at the driver level? We've > > found > > that pointclouds can compress down very well depending on the > > sensor used > > but other things (like certain cameras that you don't want to > > compress with > > lossy compression) could benefit ... > > > > > > > > </$0.02> > > > > > > - Raymond > > -- | Radu Bogdan Rusu | http://rbrusu.com | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Radu B. R. <ru...@cs...> - 2006-08-02 06:45:05
|
We settled on the following, just to get it started: /** Data subtype: Get cloud */ #define PLAYER_3DPOINTCLOUD_DATA_STATE 1 /** Request/reply subtype: get configuration */ #define PLAYER_3DPOINTCLOUD_REQ_GET_CONFIG 1 /** @brief Data: Get cloud (@ref PLAYER_3DPOINTCLOUD_DATA_STATE) The basic 3dcloudpoint data packet. */ typedef struct player_3dpointcloud { uint32_t points_count; player_point_3d_t points[PLAYER_3DPOINTCLOUD_MAX_POINTS]; uint32_t points_colors_count; player_color_t colors[PLAYER_3DPOINTCLOUD_MAX_POINTS]; } player_3dpointcloud_t; /** @brief Request/reply: Get cloud properties. The cloud configuration (resolution, aperture, etc) can be queried by sending a null @ref PLAYER_LASER_REQ_GET_CONFIG request. The current configuration will be returned in the response. */ typedef struct player_3dpointcloud_config { /** The device's pose. */ player_pose3d_t pose; /** Angular horizontal resolution [rad]. */ float resolution_h; /** Angular vertical resolution [rad]. */ float resolution_v; /** Start and end angles for X [rad]. */ float minx_angle; /** Start and end angles for X [rad]. */ float maxx_angle; /** Start and end angles for Y [rad]. */ float miny_angle; /** Start and end angles for Y [rad]. */ float maxy_angle; /** Maximum range [m]. */ float max_range; } player_3dpointcloud_config_t; I am not sure about PLAYER_3DPOINTCLOUD_MAX_POINTS, but until we get rid of the static limits, I propose to set it to something huge. Compression also comes to mind. As soon as we have it in, I'll commit a test driver. Cheers, Radu. Radu Bogdan Rusu wrote: > I was going to do it early next week, probably after another chat with > Raymond. I am currently on the road, so internet access is kind of > intermittent. > > Best, > R. > > On Tue, Jul 25, 2006 at 10:14:04AM -0700, Brian Gerkey wrote: >> Have we reached a consensus on this interface? Anybody care to >> submit a new draft for inclusion in player.h? >> >> brian. >> >> On Jul 12, 2006, at 11:19 PM, Raymond Sheh wrote: >> >>> Hi all, >>> >>> >>> I hope people don't mind me making a few suggestions ... again I >>> make the >>> point that whilst I've played a bit with moving 3D data around I'm >>> not too >>> familiar with conventions in the Player server so take with a suitably >>> sized grain of salt. >>> >>> >>> Geoff wrote: >>>> Is there anything else that this interface should be doing? Rather >>>> than >>>> just an interface to a big bunch of points, should we consider >>>> information about devices that produce such data? Eg resolution, >>>> pose of >>>> the device that's producing the data, etc. >>> I think it might be useful for provisions for a variety of point- >>> specific >>> data to be included as well as sensor specific ... perhaps what Radu >>> suggested could be extended somewhat? If everything is now in variable >>> sized vectors we could have something like this (no attempt made to >>> get it >>> syntactically correct): >>> >>> typedef struct player_3dpointcloud_data >>> { >>> >>> uint16_t sensor_count; >>> vector <player_3dpointcloud_sensor_params_t> sensor_params; >>> >>> uint32_t points_count; >>> vector <player_point_3d_t> points; >>> vector <uint16_t> sensor_id; <== if you have only 1 sensor, you >>> could leave this zero length (and assume the lone element of >>> sensor_params >>> is it) >>> vector <player_color_t> color; >>> vector <double> intensity; >>> (... and so-on) >>> >>> } player_3dpointcloud_data_t; >>> >>> >>> Sensor specific stuff could then be stored in: >>> >>> typedef struct player_3dpointcloud_sensor_params >>> { >>> player_pose3d_t pose; >>> (some resolution type) resolution; >>> (some enumeration type) sensortype; >>> (some other enumeration type) sensorstate; >>> vector <player_point_3d_t> boundingvolume; <=== not necessarily >>> rectangular >>> (... and so-on) >>> } player_3dpointcloud_sensor_params_t; >>> >>> >>> You'd have a constraint that apart from sensor_params, all of the >>> vectors >>> in player_3dpointcloud_data_t were either points_count in length or >>> zero >>> length if not available (points_count is actually redundant, maybe the >>> length of points could be the controlling length and any other >>> vector with >>> a non-zero length different from points could be treated as invalid?). >>> Perhaps we could then have some "standard" set of data elements >>> (the ... >>> and so-on bit) and if your sensor doesn't have them, simply leave the >>> vector as zero-length ... here are some that we've used before in our >>> pointclouds: >>> [r, g, b] <== uint8s >>> [intensity, reflectance] <== uint32s >>> [temperature] <== double >>> [flag] <== int enum of landmark, victim, focus, background, etc. >>> [type] <== int enum of initialised, filtered, unfiltered, junk, >>> matching_landmark, etc. >>> [(un)certainty] <== double >>> >>> As long as each of these was a fixed size we'd probably be pretty >>> safe ... >>> and because we could have them as zero length, you could have a >>> pile of >>> these with minimal overhead if they weren't actually used. This >>> would also >>> preserve transparency in the sense that clients don't need to >>> change if the >>> sensor changed (3D data from a rotating laser will look the same as >>> from a >>> range imager which would look the same as data from an MRI scanner >>> with the >>> exception of the distribution of points) - unless the sensor was >>> missing >>> data that the client needed. >>> >>> If you wanted to include resolution (actually I think it might be more >>> useful to specify some bounding volume - comparing resolutions across >>> sensor types gets tricky - is resolution 2D or 3D? Polar or cartesian? >>> Foveated/variable or fixed?) one could include it inside >>> player_3dpointcloud_sensor_params_t (which would also include pose, >>> bounding volume, type, etc.) ... this might be particularly useful >>> where >>> the data is preprocessed (because of the volumes of data generated, >>> you'd >>> want to merge/cull/filter as close to the sensor as possible) - you >>> might >>> specify the type of preprocessing in the sensor params (and clients >>> which >>> don't care could ignore it). >>> >>> >>> I'm sure I've broken a pile of Player conventions in this >>> suggestion ... >>> heh ... >>> >>> >>> >>> Toby wrote: >>> <snip> >>>> If people agree with this the question becomes who has time to carry >>>> this all out, and are we aiming to incorperate this in 2.1 or >>>> somewhere >>>> further down the track (and can we add the queue autopointers >>>> while we >>>> are breaking everything else :) >>> Whilst we're breaking things, could I make another quick >>> suggestion? :-D >>> >>> One thing that would be very nice (and complement pointclouds) is >>> on-the-fly lossless compression (bzip comes to mind). >>> CameraCompress has >>> been doing it as a passthrough for lossy (jpeg) compression but >>> would it be >>> worth putting an (optional) lossless compression layer, maybe at >>> (or just >>> before) the transport level rather than at the driver level? We've >>> found >>> that pointclouds can compress down very well depending on the >>> sensor used >>> but other things (like certain cameras that you don't want to >>> compress with >>> lossy compression) could benefit ... >>> >>> >>> >>> </$0.02> >>> >>> >>> - Raymond >>> > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Raymond S. <rs...@cs...> - 2006-08-02 15:00:04
|
Hi all, Cool, we've got a starting point! I've just got a couple of minor changes to suggest ... - change angles to [min|max][h|v]_angle (to standardise on h and v for horizontal and vertical view frustum angles so we don't get confused with x and y co-ordinates) - remove points_colors_count (because we'd assume that each entry in the colors array directly corresponds to the same entry in the points array) - include range resolution (but should it be called something like resolution_range to make it consistent with the angles or range_res to match the laser equivalent?) - Wouldn't you want to send a null PLAYER_3DPOINTCLOUD_REQ_GET_CONFIG request (rather than a PLAYER_LASER request)? - Would we want to have some enumeration in the config to specify the type of the sensor (stereo, rolling/tilting/panning laser, range imager, etc.)? I've made the changes below. A few things to point out that may be worth further thought ... - I think is that whilst we have min and max angles like on the laser, unlike the laser there would be no assumption on the ordering of the data ... if it's coming from a 3D image sensor (SwissRanger for instance) it might well be in image order (upper left to lower right) but I'm presuming that in general it won't be because of points culling, etc. - The config structure assumes a point-based 3D sensor (camera, moving laser, etc.) so things like viewing frustum angle and range resolution actually have meaning ... I can't think of any sensor, apart from perhaps a medical imaging sensor (CAT/MRI style scanner) that would provide a 3D pointcloud without going through a single point, certainly nothing that you're likely to have on a robot ... can anyone think of any such sensor that might need to be considered? - The meaning of horizontal and vertical resolution may not always be comparable between sensors, especially if sensor or driver level point culling is being done (eg. stereo vision) or if the sensor isn't cartesian (eg. a laser rangefinder rolling about its forward-pointing axis). - Likewise the meaning of The other thing is that this would be a stand-in until variable sized structures become available ... there could be a pile of things that could be added once that happens, here are a few I can think of ... - Multiple configs (for pointclouds that come from more than one origin) - An extra array for polygonal relationships (similar to how a ply file works) - Additional data per pixel such as certainty, flags, etc. - this might be rolled into some variable sized generic data field? ================ /** Data subtype: Get cloud */ #define PLAYER_3DPOINTCLOUD_DATA_STATE 1 /** Request/reply subtype: get configuration */ #define PLAYER_3DPOINTCLOUD_REQ_GET_CONFIG 1 /** @brief Data: Get cloud (@ref PLAYER_3DPOINTCLOUD_DATA_STATE) The basic 3dcloudpoint data packet. */ typedef struct player_3dpointcloud { uint32_t points_count; player_point_3d_t points[PLAYER_3DPOINTCLOUD_MAX_POINTS]; player_color_t colors[PLAYER_3DPOINTCLOUD_MAX_POINTS]; } player_3dpointcloud_t; /** @brief Request/reply: Get cloud properties. The cloud configuration (resolution, aperture, etc) can be queried by sending a null @ref PLAYER_3DPOINTCLOUD_REQ_GET_CONFIG request. The current configuration will be returned in the response. */ typedef struct player_3dpointcloud_config { /** The device's pose. */ player_pose3d_t pose; /** Angular horizontal resolution [rad]. */ float resolution_h; /** Angular vertical resolution [rad]. */ float resolution_v; /** Start and end angles for horizontal viewing frustum [rad]. */ float minh_angle; /** Start and end angles for horizontal viewing frustum [rad]. */ float maxh_angle; /** Start and end angles for vertical viewing frustum [rad]. */ float minv_angle; /** Start and end angles for vertical viewing frustum [rad]. */ float maxv_angle; /** Maximum sensor range [m]. */ float max_range; /** Sensor range resolution [m]. */ float resolution_range } player_3dpointcloud_config_t; ================ What do people think? Cheers! - Raymond Radu Bogdan Rusu wrote: > We settled on the following, just to get it started: > > /** Data subtype: Get cloud */ > #define PLAYER_3DPOINTCLOUD_DATA_STATE 1 > /** Request/reply subtype: get configuration */ > #define PLAYER_3DPOINTCLOUD_REQ_GET_CONFIG 1 > > /** @brief Data: Get cloud (@ref PLAYER_3DPOINTCLOUD_DATA_STATE) > The basic 3dcloudpoint data packet. */ > typedef struct player_3dpointcloud > { > uint32_t points_count; > player_point_3d_t points[PLAYER_3DPOINTCLOUD_MAX_POINTS]; > uint32_t points_colors_count; > player_color_t colors[PLAYER_3DPOINTCLOUD_MAX_POINTS]; > } player_3dpointcloud_t; > > /** @brief Request/reply: Get cloud properties. > > The cloud configuration (resolution, aperture, etc) can be queried by > sending a null @ref PLAYER_LASER_REQ_GET_CONFIG request. The > current configuration will be returned in the response. */ > typedef struct player_3dpointcloud_config > { > /** The device's pose. */ > player_pose3d_t pose; > /** Angular horizontal resolution [rad]. */ > float resolution_h; > /** Angular vertical resolution [rad]. */ > float resolution_v; > /** Start and end angles for X [rad]. */ > float minx_angle; > /** Start and end angles for X [rad]. */ > float maxx_angle; > /** Start and end angles for Y [rad]. */ > float miny_angle; > /** Start and end angles for Y [rad]. */ > float maxy_angle; > /** Maximum range [m]. */ > float max_range; > } player_3dpointcloud_config_t; > > I am not sure about PLAYER_3DPOINTCLOUD_MAX_POINTS, but until we get rid of the static > limits, I propose to set it to something huge. Compression also comes to mind. > > As soon as we have it in, I'll commit a test driver. > > Cheers, > Radu. > > Radu Bogdan Rusu wrote: > >> I was going to do it early next week, probably after another chat with >> Raymond. I am currently on the road, so internet access is kind of >> intermittent. >> >> Best, >> R. >> >> On Tue, Jul 25, 2006 at 10:14:04AM -0700, Brian Gerkey wrote: >> >>> Have we reached a consensus on this interface? Anybody care to >>> submit a new draft for inclusion in player.h? >>> >>> brian. >>> >>> On Jul 12, 2006, at 11:19 PM, Raymond Sheh wrote: >>> >>> >>>> Hi all, >>>> >>>> >>>> I hope people don't mind me making a few suggestions ... again I >>>> make the >>>> point that whilst I've played a bit with moving 3D data around I'm >>>> not too >>>> familiar with conventions in the Player server so take with a suitably >>>> sized grain of salt. >>>> >>>> >>>> Geoff wrote: >>>> >>>>> Is there anything else that this interface should be doing? Rather >>>>> than >>>>> just an interface to a big bunch of points, should we consider >>>>> information about devices that produce such data? Eg resolution, >>>>> pose of >>>>> the device that's producing the data, etc. >>>>> >>>> I think it might be useful for provisions for a variety of point- >>>> specific >>>> data to be included as well as sensor specific ... perhaps what Radu >>>> suggested could be extended somewhat? If everything is now in variable >>>> sized vectors we could have something like this (no attempt made to >>>> get it >>>> syntactically correct): >>>> >>>> typedef struct player_3dpointcloud_data >>>> { >>>> >>>> uint16_t sensor_count; >>>> vector <player_3dpointcloud_sensor_params_t> sensor_params; >>>> >>>> uint32_t points_count; >>>> vector <player_point_3d_t> points; >>>> vector <uint16_t> sensor_id; <== if you have only 1 sensor, you >>>> could leave this zero length (and assume the lone element of >>>> sensor_params >>>> is it) >>>> vector <player_color_t> color; >>>> vector <double> intensity; >>>> (... and so-on) >>>> >>>> } player_3dpointcloud_data_t; >>>> >>>> >>>> Sensor specific stuff could then be stored in: >>>> >>>> typedef struct player_3dpointcloud_sensor_params >>>> { >>>> player_pose3d_t pose; >>>> (some resolution type) resolution; >>>> (some enumeration type) sensortype; >>>> (some other enumeration type) sensorstate; >>>> vector <player_point_3d_t> boundingvolume; <=== not necessarily >>>> rectangular >>>> (... and so-on) >>>> } player_3dpointcloud_sensor_params_t; >>>> >>>> >>>> You'd have a constraint that apart from sensor_params, all of the >>>> vectors >>>> in player_3dpointcloud_data_t were either points_count in length or >>>> zero >>>> length if not available (points_count is actually redundant, maybe the >>>> length of points could be the controlling length and any other >>>> vector with >>>> a non-zero length different from points could be treated as invalid?). >>>> Perhaps we could then have some "standard" set of data elements >>>> (the ... >>>> and so-on bit) and if your sensor doesn't have them, simply leave the >>>> vector as zero-length ... here are some that we've used before in our >>>> pointclouds: >>>> [r, g, b] <== uint8s >>>> [intensity, reflectance] <== uint32s >>>> [temperature] <== double >>>> [flag] <== int enum of landmark, victim, focus, background, etc. >>>> [type] <== int enum of initialised, filtered, unfiltered, junk, >>>> matching_landmark, etc. >>>> [(un)certainty] <== double >>>> >>>> As long as each of these was a fixed size we'd probably be pretty >>>> safe ... >>>> and because we could have them as zero length, you could have a >>>> pile of >>>> these with minimal overhead if they weren't actually used. This >>>> would also >>>> preserve transparency in the sense that clients don't need to >>>> change if the >>>> sensor changed (3D data from a rotating laser will look the same as >>>> from a >>>> range imager which would look the same as data from an MRI scanner >>>> with the >>>> exception of the distribution of points) - unless the sensor was >>>> missing >>>> data that the client needed. >>>> >>>> If you wanted to include resolution (actually I think it might be more >>>> useful to specify some bounding volume - comparing resolutions across >>>> sensor types gets tricky - is resolution 2D or 3D? Polar or cartesian? >>>> Foveated/variable or fixed?) one could include it inside >>>> player_3dpointcloud_sensor_params_t (which would also include pose, >>>> bounding volume, type, etc.) ... this might be particularly useful >>>> where >>>> the data is preprocessed (because of the volumes of data generated, >>>> you'd >>>> want to merge/cull/filter as close to the sensor as possible) - you >>>> might >>>> specify the type of preprocessing in the sensor params (and clients >>>> which >>>> don't care could ignore it). >>>> >>>> >>>> I'm sure I've broken a pile of Player conventions in this >>>> suggestion ... >>>> heh ... >>>> >>>> >>>> >>>> Toby wrote: >>>> <snip> >>>> >>>>> If people agree with this the question becomes who has time to carry >>>>> this all out, and are we aiming to incorperate this in 2.1 or >>>>> somewhere >>>>> further down the track (and can we add the queue autopointers >>>>> while we >>>>> are breaking everything else :) >>>>> >>>> Whilst we're breaking things, could I make another quick >>>> suggestion? :-D >>>> >>>> One thing that would be very nice (and complement pointclouds) is >>>> on-the-fly lossless compression (bzip comes to mind). >>>> CameraCompress has >>>> been doing it as a passthrough for lossy (jpeg) compression but >>>> would it be >>>> worth putting an (optional) lossless compression layer, maybe at >>>> (or just >>>> before) the transport level rather than at the driver level? We've >>>> found >>>> that pointclouds can compress down very well depending on the >>>> sensor used >>>> but other things (like certain cameras that you don't want to >>>> compress with >>>> lossy compression) could benefit ... >>>> >>>> >>>> >>>> </$0.02> >>>> >>>> >>>> - Raymond >>>> >>>> > > |
From: Radu B. R. <ru...@cs...> - 2006-08-02 15:11:52
|
Raymond Sheh wrote: > ================ > /** Data subtype: Get cloud */ > > #define PLAYER_3DPOINTCLOUD_DATA_STATE 1 > /** Request/reply subtype: get configuration */ > #define PLAYER_3DPOINTCLOUD_REQ_GET_CONFIG 1 > > /** @brief Data: Get cloud (@ref PLAYER_3DPOINTCLOUD_DATA_STATE) > The basic 3dcloudpoint data packet. */ > typedef struct player_3dpointcloud > { > uint32_t points_count; > player_point_3d_t points[PLAYER_3DPOINTCLOUD_MAX_POINTS]; > player_color_t colors[PLAYER_3DPOINTCLOUD_MAX_POINTS]; > } player_3dpointcloud_t; > > /** @brief Request/reply: Get cloud properties. > > The cloud configuration (resolution, aperture, etc) can be queried by > sending a null @ref PLAYER_3DPOINTCLOUD_REQ_GET_CONFIG request. The > current configuration will be returned in the response. */ > typedef struct player_3dpointcloud_config > { > /** The device's pose. */ > player_pose3d_t pose; > /** Angular horizontal resolution [rad]. */ > float resolution_h; > /** Angular vertical resolution [rad]. */ > float resolution_v; > /** Start and end angles for horizontal viewing frustum [rad]. */ > float minh_angle; > /** Start and end angles for horizontal viewing frustum [rad]. */ > float maxh_angle; > /** Start and end angles for vertical viewing frustum [rad]. */ > float minv_angle; > /** Start and end angles for vertical viewing frustum [rad]. */ > float maxv_angle; > /** Maximum sensor range [m]. */ > float max_range; > /** Sensor range resolution [m]. */ > float resolution_range > } player_3dpointcloud_config_t; > > ================ > > > > What do people think? Looks better. I stay corrected and concur! :) Radu. -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Radu B. R. <ru...@cs...> - 2006-08-02 15:14:50
|
Ah, one small thing. Radu Bogdan Rusu wrote: >> /** Sensor range resolution [m]. */ >> float resolution_range >> } player_3dpointcloud_config_t; float resolution_range; Either we go with resolution on all interfaces, or resolution_range or res_range. The current laser interface has resolution. (it doesn't have anything to do with the laser interface, I know, but it would be nice to have unified attribute names) > Looks better. I stay corrected and concur! :) stay/stand. > > Radu. -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |
From: Raymond S. <rs...@cs...> - 2006-08-02 15:25:07
|
Radu Bogdan Rusu wrote: > Ah, one small thing. > > Radu Bogdan Rusu wrote: > >>> /** Sensor range resolution [m]. */ >>> float resolution_range >>> } player_3dpointcloud_config_t; >>> > > float resolution_range; > > Either we go with resolution on all interfaces, or resolution_range or res_range. The > current laser interface has resolution. (it doesn't have anything to do with the laser > interface, I know, but it would be nice to have unified attribute names) > As I understand it, "resolution" on the laser refers to scan (angular) resolution (what we're calling resolution_h and resolution_v) ... from my reading of the docs, the range resolution is referred to as "res_range". Cheers! - Raymond |
From: Geoffrey B. <g....@au...> - 2006-08-02 21:12:12
|
Raymond Sheh wrote: > - remove points_colors_count (because we'd assume that each entry in the > colors array directly corresponds to the same entry in the points array) Isn't that needed for XDR to know how big the array is? > - The config structure assumes a point-based 3D sensor (camera, moving > laser, etc.) so things like viewing frustum angle and range resolution > actually have meaning ... I can't think of any sensor, apart from > perhaps a medical imaging sensor (CAT/MRI style scanner) that would > provide a 3D pointcloud without going through a single point, certainly > nothing that you're likely to have on a robot ... can anyone think of > any such sensor that might need to be considered? My memory may be wrong here, but I thought that the rescue robot displayed at ACRA last year had a 2D range sensor array that could be represented with this interface but wouldn't have all all data going through a single point. Geoff -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Raymond S. <rs...@cs...> - 2006-08-02 21:17:32
|
Geoffrey Biggs wrote: > Raymond Sheh wrote: > >> - remove points_colors_count (because we'd assume that each entry in the >> colors array directly corresponds to the same entry in the points array) >> > > Isn't that needed for XDR to know how big the array is? > I guess my point was that points_colors_count and points_count would always be identical (because you can't have a color entry without a point entry). I guess it's possible for points_count to be something and points_colors_count to be zero if you have points without color ... I'm not sure you could ever have points_colors_count as something other than points_count and zero because if so, you wouldn't be able to get a match between a color and a point. > >> - The config structure assumes a point-based 3D sensor (camera, moving >> laser, etc.) so things like viewing frustum angle and range resolution >> actually have meaning ... I can't think of any sensor, apart from >> perhaps a medical imaging sensor (CAT/MRI style scanner) that would >> provide a 3D pointcloud without going through a single point, certainly >> nothing that you're likely to have on a robot ... can anyone think of >> any such sensor that might need to be considered? >> > > My memory may be wrong here, but I thought that the rescue robot > displayed at ACRA last year had a 2D range sensor array that could be > represented with this interface but wouldn't have all all data going > through a single point. > If you're referring to CASTER, it carries a CSEM SwissRanger SR-2 range imager, which is effectively a camera where each pixel measures time-of-flight and gives you a range measurement ... so in terms of geometry it's like a camera with a single focal point and a standard viewing frustum (44x42 degrees if I recall correctly) ... I guess this would be very similar to basically any 3D sensor that's likely to be deployed on a robot right? A rotating laser would be the same (although I guess you could rotate it about an axis different to its mirror so you'd need to have the pose of both the horizontal and vertical deflections), as would a stereo head (you'd have a virtual focal point centered at one of the actual focal points or in between depending on your algorithm). Cheers! - Raymond |
From: Toby C. <tco...@pl...> - 2006-08-02 22:20:56
|
Geoff's XDR point was an implementation comment, the XDR implementation *requires* a count for each array otherwise it cant pack and unpack the data automatically. The only way around two counts is one count and a point structure with several values. Toby Raymond Sheh wrote: > Geoffrey Biggs wrote: > >> Raymond Sheh wrote: >> >> >>> - remove points_colors_count (because we'd assume that each entry in the >>> colors array directly corresponds to the same entry in the points array) >>> >>> >> Isn't that needed for XDR to know how big the array is? >> >> > I guess my point was that points_colors_count and points_count would > always be identical (because you can't have a color entry without a > point entry). I guess it's possible for points_count to be something and > points_colors_count to be zero if you have points without color ... I'm > not sure you could ever have points_colors_count as something other than > points_count and zero because if so, you wouldn't be able to get a match > between a color and a point. > > >> >> >>> - The config structure assumes a point-based 3D sensor (camera, moving >>> laser, etc.) so things like viewing frustum angle and range resolution >>> actually have meaning ... I can't think of any sensor, apart from >>> perhaps a medical imaging sensor (CAT/MRI style scanner) that would >>> provide a 3D pointcloud without going through a single point, certainly >>> nothing that you're likely to have on a robot ... can anyone think of >>> any such sensor that might need to be considered? >>> >>> >> My memory may be wrong here, but I thought that the rescue robot >> displayed at ACRA last year had a 2D range sensor array that could be >> represented with this interface but wouldn't have all all data going >> through a single point. >> >> > If you're referring to CASTER, it carries a CSEM SwissRanger SR-2 range > imager, which is effectively a camera where each pixel measures > time-of-flight and gives you a range measurement ... so in terms of > geometry it's like a camera with a single focal point and a standard > viewing frustum (44x42 degrees if I recall correctly) ... I guess this > would be very similar to basically any 3D sensor that's likely to be > deployed on a robot right? A rotating laser would be the same (although > I guess you could rotate it about an axis different to its mirror so > you'd need to have the pose of both the horizontal and vertical > deflections), as would a stereo head (you'd have a virtual focal point > centered at one of the actual focal points or in between depending on > your algorithm). > > Cheers! > > - Raymond > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > |
From: Brian G. <br...@ge...> - 2006-08-03 20:36:30
|
On Aug 2, 2006, at 3:21 PM, Toby Collett wrote: > Geoff's XDR point was an implementation comment, the XDR > implementation > *requires* a count for each array otherwise it cant pack and unpack > the > data automatically. The only way around two counts is one count and a > point structure with several values. Indeed. It's a limitation of the parser that I wrote to process <player.h> and produce XDR marshaling functions. An array 'foo' will be variable-length only if you have an accompanying integer field 'foo_count' declared earlier in the structure. Otherwise, it will be transmitted fixed-length (XDR calls these vectors) at its maximum size. brian. |
From: Raymond S. <rs...@cs...> - 2006-08-03 22:46:27
|
Brian Gerkey wrote: > On Aug 2, 2006, at 3:21 PM, Toby Collett wrote: > > >> Geoff's XDR point was an implementation comment, the XDR >> implementation >> *requires* a count for each array otherwise it cant pack and unpack >> the >> data automatically. The only way around two counts is one count and a >> point structure with several values. >> > > Indeed. It's a limitation of the parser that I wrote to process > <player.h> and produce XDR marshaling functions. An array 'foo' will > be variable-length only if you have an accompanying integer field > 'foo_count' declared earlier in the structure. Otherwise, it will be > transmitted fixed-length (XDR calls these vectors) at its maximum size. > Ah OK that makes sense ... So what do people feel will be the lesser of two "potential evils"? Having two counters that should be in step or having a new datatype that would contain both an existing 3D point and a colour? Actually that brings up another question I've been wondering about ... say a new datatype was created for each entry in this vector (so it'd contain a 3D point and a colour). Can XDR handle this new datatype itself containing variable length data? Cheers! - Raymond |