From: Stefan S. <ss...@uo...> - 2007-05-08 09:57:18
|
Hi, I want to send the different Histograms, speed and turnrate of the vfh driver to a visualization client. If i use the opaque interface there is the problem, that I have to convert a float array to an uint8_t array and I have to encode the resolution of the scan and compute the point in 2d space from the histogram values,... . All these problems doesn't occur if I use the laser interface. But these can be a bit confusing if the vfh client supports a laser interface and answers to GET CONF and GET GEOM messages for this laser interface, because the semantic of the laser interface is no longer a laser. I hope I made the problem clear. Any Ideas which is the best solution. Stefan |
From: Jack O'Q. <jac...@gm...> - 2007-05-08 14:01:21
|
On 5/8/07, Stefan Stiene <ss...@uo...> wrote: > Hi, > I want to send the different Histograms, speed and turnrate of the vfh > driver to a visualization client. If i use the opaque interface there is > the problem, that I have to convert a float array to an uint8_t array > and I have to encode the resolution of the scan and compute the point in > 2d space from the histogram values,... . All these problems doesn't > occur if I use the laser interface. But these can be a bit confusing if > the vfh client supports a laser interface and answers to GET CONF and > GET GEOM messages for this laser interface, because the semantic of the > laser interface is no longer a laser. I hope I made the problem clear. > > Any Ideas which is the best solution. Opaque is probably easiest if you don't need to support clients running on multiple architectures. As long as you can ignore the word-size, endian, and other XDR issues, it's simple. Just memcopy() an arbitrary struct into the opaque data array, setting the data count appropriately. Player will deliver the bits, you'll have to unpack them yourself on the other end. Maybe some future release (2.1??) will support user-defined interfaces. That would be wonderful. Meanwhile, we have opaque. -- joq |
From: Geoffrey B. <g....@au...> - 2007-05-11 23:09:06
|
I have several ideas for supporting user-defined interfaces, and would love to get them done for 2.1. However, as we are planning on releasing 2.1 as soon as possible, there probably isn't time to get such an important change as fully tested as is necessary before the release. Look for user-defined interface support in 2.2, or CVS before then if you like living on the (potentially broken) edge. Geoff Jack O'Quin wrote: > Maybe some future release (2.1??) will support user-defined > interfaces. That would be wonderful. Meanwhile, we have > opaque. -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Jack O'Q. <jac...@gm...> - 2007-05-12 04:45:46
|
On 5/11/07, Geoffrey Biggs <g....@au...> wrote: > I have several ideas for supporting user-defined interfaces, and would > love to get them done for 2.1. However, as we are planning on releasing > 2.1 as soon as possible, there probably isn't time to get such an > important change as fully tested as is necessary before the release. > Look for user-defined interface support in 2.2, or CVS before then if > you like living on the (potentially broken) edge. Sounds good. I need stable interfaces for the project I am working on right now. We are using a fairly recent CVS version of the 2-0-patches at the moment, almost the same as the new release 2.0.4. That is working fine at the moment, with several bug fixes that have all been included in that release. Later, I would be happy to experiment with new interface definitions, especially if the client and driver API's could remain almost the same. -- joq |