I am not sure if Yarp has seen an implementation as discussed above.
I'm currently writing a driver for the swissranger depth camera as
well and my current approach is:
- Define yarp::dev::IDepthCamera interface with
yarp::sig::ImageOf<yarp::sig::PixelMono16> > & pair) = 0;
that sends out synchronized frames in a single PortablePair packet.
- Write a network wrapper, ServerDepthCamera, that publishes those
- Write a class yarp::dev::DeviceSplitter (inspired by
yarp::dev::DevicePipe) that allows one to split up the PortablePair
into the two images, if so desired..
I'd be happy to hear about your suggestions (or Stefán's final depth
camera implementation) so that I don't re-invent the wheel :)
2008/6/6 Stefán Freyr Stefánsson <stefan@...>:
> On Wednesday 21 May 2008 16:55:07 Paul Fitzpatrick wrote:
>> Stefán Freyr Stefánsson wrote:
>> > Paul: if you could give an example of how the device driver interface for
>> > a multi_grabber device might look like (roughly) I'm sure that would help
>> > me understand things a bit better.
>> > So just to clear up what I could imagine causing me problems, let me take
>> > an example:
>> > The camera I'm working with has an "aquire" method that instructs it to
>> > grab a frame. When aquire is called, both of the images (intensity and
>> > distance) are written to a buffer. One of them needs to go to one port
>> > and the other one to another port. So as long as I can somehow call the
>> > aquire() method one time and then be guaranteed that getImage() is called
>> > for all defined streams (distance and intensity in my case) I'd be a
>> > happy camper! Or maybe this needs to be done in some other way?
>> I'm not sure what the multi_grabber one would look like - maybe we
>> should start a wiki page to develop a spec for it? It might be
>> something like:
>> int getTopIndex();
>> bool beginImageGroup();
>> bool getIndexedImage(int index, ImageOf<PixelRgb>& img);
>> bool endImageGroup();
>> with begin/end signalling when a set of getIndexedImage() calls are
>> expected to belong to the same external reality.
>> With the other proposal (using the "group" device) the device you write
>> would be responsible for setting the pace of acquisition, and two
>> grabber network wrappers would simply be blocking on two separate calls
>> to getImage(img) on two proxy objects. Perhaps a begin/end method could
>> be added to this proposal too...
>> I've started adding some notes about this thread on this page:
>> Feel free to add notes or scenarios to consider.
> After reading through the wiki page and with me being such a sucker for
> generic design I'm starting to like your "group device" implementation
> Currently I can't see any problem with the interface you propose on the wiki
> page, that is if I'm understanding it correctly. I'm not quite sure what you
> mean by that implementation needing "proxy objects" and since my C++ skills
> are very sub-prime I'm also wondering what the best way to typecast the
> sub-interfaces to its proper types to be able to use it in code without
> making the code completely dependant on the implementation. Maybe that is
> related to these proxy objects? One other thing I'm wondering is how easy it
> will then be to enable yarpdev to use this group device (starting up multiple
> ports etc.).
> But just to get it straight. The basic idea is that beginEvent() is called
> first and that could do the resource acquisition (in my case grab a frame)
> and then the sub interfaces would be queried (which in my case would be one
> sub-interface returning a distance image and another one returning the
> intensity image). Is that accurate?
> Finally I have some questions/comments:
> 1) Is it just me or is there a bit of a discrepancy in terms regarding
> devices. It seems that the following terms are used for the same concept:
> device (as in YARP device), driver (as in PolyDriver, DeviceDriver) and
> finally interface (as in getSubInterface(int)). Is there a distinction
> between these terms that I haven't spotted?
> 2) Why don't you make more use of templates in interfaces such as
> IFrameGrabberImage? Currently it is hard coded for ImageOf<PixelRgb>. Is
> there some technical problem involved? I ask because I would like to use it
> for my grayscale 16 bit images but that means that I have to duplicate the
> whole interface using my own PixelMono16 type.
> That's it from me for now.
> Regards, Stefan.
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> Robotcub-hackers mailing list