failed to add kinbody after reloading the environment with pqp collision checker

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

failed to add kinbody after reloading the environment with pqp collision checker

Huan Liu
Hi Rosen,
I keep getting the following error as I add a kinbody after reloading the environment with pqp collision checker.
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
RuntimeError: unidentifiable C++ exception

Let me try to describe the problem more clearly:
0) I have the following two classes: ORTest and ORTest1:
class ORTest:
   def __init__(self,env,target):
       self.env = env
       self.target = target

class ORTest1:
   def __init__(self,env,target):
       self.env = env
       self.target = target
       collision_checker = self.env.CreateCollisionChecker('pqp')
       collision_checker.SetCollisionOptions(CollisionOptions.Distance|CollisionOptions.Contacts)
       self.env.SetCollisionChecker(collision_checker)

1) open a python interpretor in the terminal
2) copy and paste the following line to initialize the environment, add a robot and an object,  initialize ORTest

from bug import *;env=Environment();env.SetViewer('qtcoin');env.Reset();robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest(env,target)

3) copy and paste the following line to reset the environment, reload the source file containing the two classes, add a robot and an object, initialize ORTest

env.Reset();import bug;reload(bug);from bug import *;robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest(env,target)

So far so good. This time let's switch to ORTest1

1) open a python interpretor in the terminal
2) copy and paste the following line to initialize the environment, add a robot and an object, initialize ORTest1

from bug import *;env=Environment();env.SetViewer('qtcoin');env.Reset();robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest1(env,target)

3) copy and paste the following line to reset the environment, reload the source file containing the two classes, add a robot and an object

env.Reset();import bug;reload(bug);from bug import *;robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest1(env,target)

Here we get the error message:
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
RuntimeError: unidentifiable C++ exception

As we can see that the robot gets added, but as soon as we get to add the kinbody, we get an error. The only difference between the two classes is that ORTest1 changes the collision checker to pqp. Attached is the problematic code.

The reason why I encounter this bug is because I want to debug the source while staying in the interpreter and keeping the last camera angle. I can totally avoid such issue by restarting every time. Please let me know if there's a better way of debugging code. Thanks!

Huan


Here's the problematic code:


#!/usr/bin/env python
# bug.py

from openravepy import *
from numpy import *

class ORTest:
   def __init__(self,env,target):
       self.env = env
       self.target = target

class ORTest1:
   def __init__(self,env,target):
       self.env = env
       self.target = target
       collision_checker = self.env.CreateCollisionChecker('pqp')
       collision_checker.SetCollisionOptions(CollisionOptions.Distance|CollisionOptions.Contacts)
       self.env.SetCollisionChecker(collision_checker)

'''
from bug import *;env=Environment();env.SetViewer('qtcoin');env.Reset();robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest(env,target)

env.Reset();import bug;reload(bug);from bug import *;robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest(env,target)

from bug import *;env=Environment();env.SetViewer('qtcoin');env.Reset();robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest1(env,target)

env.Reset();import bug;reload(bug);from bug import *;robot = env.ReadRobotXMLFile('robots/pr2-beta-static.robot.xml');env.AddRobot(robot);target=env.ReadKinBodyXMLFile('data/mug2.kinbody.xml');env.AddKinBody(target);O_T_Target = mat([[1,0,0,1],[0,1,0,0],[0,0,1,1],[0,0,0,1]]);target.SetTransform(array(O_T_Target));ot=ORTest1(env,target)

'''
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users

bug.py (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

"Other" sensor type

Nick Hillier
Hi all,

Can we add a "ST_Other" sensor type to the enum in rave/sensor.h so that
we have a type to assign to sensor definitions that we write custom
plugins for? Or should we be using the "ST_Invalid" type for custom
sensor types that we know OpenRAVE won't handle the data for natively?

I am writing an INS sensor plugin to publish some ROS messages for our
platforms, I'm sure there will be others.

Nick


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: "Other" sensor type

Rosen Diankov
Administrator
hi nick,

One of the advantages of putting all the sensor geometry and data
definitions in the header file is that others will be able to
understand and use the sensor messages. As soon as you start putting
custom sensors, people will start having different definitions of what
a  camera and a laser is, and then compatibility will break.

Therefore, if you have an idea for a new sensor type, please post it
on this users lists so we can discuss it, and eventually it will
become part of the openrave.

rosen,

2010/9/28 Nick Hillier <[hidden email]>:

> Hi all,
>
> Can we add a "ST_Other" sensor type to the enum in rave/sensor.h so that
> we have a type to assign to sensor definitions that we write custom
> plugins for? Or should we be using the "ST_Invalid" type for custom
> sensor types that we know OpenRAVE won't handle the data for natively?
>
> I am writing an INS sensor plugin to publish some ROS messages for our
> platforms, I'm sure there will be others.
>
> Nick
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: "Other" sensor type

Rosen Diankov
Administrator
Hi Nick,

You make several very excellent points. Currently, I think it is
better to have a huge list of all sensor types. However, that doesn't
mean you are only restricted to only the parameters defined in the
header files. If you'll notice the basesensors plugin, it defines
several new parameters for flash lidar. This sensor is encoded as a
basic laser type, and its extra parameters are hidden from the
openrave API (ie they are in the basesensors definition), however it
still notifies users of the basic data type without requiring them to
compile new code to use the new laser.

In fact, I argue that after nailing down all basic types of sensor
geometry and data, the same sensor could offer multiple modalities of
sensing data. For example, the SR4000 gives range data and image data.

I agree that extending sensor definitions for plugin developers could
be made easier, but I would really like to see how far we can push the
static basic data types before going onto a special "custom" message.
Once a "custom" sensor is introduced, everyone who wants to put custom
data will ignore the base definitions, and create their own sensor,
which others will not be able to read. After using ROS for 2 years,
this is exactly the problem that has happened and has caused a lot of
incompatibility headaches.

Anyway, please describe the INS sensor's geometry and data output.
Because it is both a GPS and an inertial sensor, perhaps it is worth
implementing the multiple sensor geometry/types.

rosen,

2010/9/28 Nick Hillier <[hidden email]>:

> Thanks Rosen,
>
> Whilst I agree in principal, I suspect that you are going to end up with
> a huge list of sensors that only a select few (or probably only one)
> user is interested in. At the moment I'm really just after something
> that the default openrave_sensors ROS publisher will just skip over
> rather than filling my screen with "failed to output..." messages, so I
> can create my own publisher plugin.
>
> I'm currently implementing a plugin for an INS - a hybrid GPS, Inertial
> navigation sensor. The effort in this sensor alone is significant -
> there are various GPS support message types, status fields, varying
> levels of solution fix etc.
>
> Further compounding the issue for us, is that most users here do not use
> OpenRAVE as a planning environment, but rather an easily extensible
> simulation tool, due to the nice plug-in architecture.  We are looking
> at implementing a variety of different laser and radar scanners that do
> not play well with the standard laser message interfaces in OpenRAVE
> (published under ROS as pointcloud2 type), due to various probabilistic
> sensor models with multiple echo return widths etc.
>
> We also have users interested in using OpenRAVE's simple interfaces to
> prototype sensors, just to see how their data processing algorithms
> might perform on mobile platforms, for example hyperspectral imaging
> sensors simulated by defining "material properties" in the environment
> representation and using ray traces and look-up tables to compute the
> return data.
>
> Regards,
> Nick
>
> On Tue, 2010-09-28 at 16:12 +1000, Rosen Diankov wrote:
>> hi nick,
>>
>> One of the advantages of putting all the sensor geometry and data
>> definitions in the header file is that others will be able to
>> understand and use the sensor messages. As soon as you start putting
>> custom sensors, people will start having different definitions of what
>> a  camera and a laser is, and then compatibility will break.
>>
>> Therefore, if you have an idea for a new sensor type, please post it
>> on this users lists so we can discuss it, and eventually it will
>> become part of the openrave.
>>
>> rosen,
>>
>> 2010/9/28 Nick Hillier <[hidden email]>:
>> > Hi all,
>> >
>> > Can we add a "ST_Other" sensor type to the enum in rave/sensor.h so that
>> > we have a type to assign to sensor definitions that we write custom
>> > plugins for? Or should we be using the "ST_Invalid" type for custom
>> > sensor types that we know OpenRAVE won't handle the data for natively?
>> >
>> > I am writing an INS sensor plugin to publish some ROS messages for our
>> > platforms, I'm sure there will be others.
>> >
>> > Nick
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Start uncovering the many advantages of virtual appliances
>> > and start using them to simplify application deployment and
>> > accelerate your shift to cloud computing.
>> > http://p.sf.net/sfu/novell-sfdev2dev
>> > _______________________________________________
>> > Openrave-users mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/openrave-users
>> >
>
>
>

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: "Other" sensor type

Nick Hillier
Thanks Rosen,

I am making a Trac ticket with the description of the data fields for an
INS.

In the mean time... 3 more things

1) Can you update the ROS sensor publisher to only print the unsupported
sensor message once, rather than at every iteration? I've just commented
it out locally for our own use until we can use something that fits into
the OpenRAVE architecture better, but for other users that may fall into
this trap in the future, it would be nice not to flood their screen with
errors.

2) I've been looking at the flash lidar plugin as you suggested. It
reports data in the form of the LaserSensorData type which basically
gives a long 1D array of the data based on an indexing which increments
based on a column-major format (i.e. the first lot of data corresponds
to the first column of the scan, the second column of data is then
appended to the first etc).

This is nice in that it re-uses the existing LaserSensorData type, which
makes it accessible within the python interface without any additional
hooks etc. However, the user doesn't know the data format (i.e. row or
column major) without looking at your plugin implementation. This is
just a minor usability issue and for the sake of code maintenance, it's
probably not worth the hassle of addressing, but does raise the sort of
usability issues that might arise in more complicated sensor
implementations.

3) My real question though is: how would you combine two standard data
types into one sensor? e.g. the image data of the SR4000 as well as the
range data? there is only one argument to the GetSensorData() function,
so how would one sensor return two data types (here a LaserSensorData
type and a CameraSensorData type)? I ask this because an INS would
return multiple IMU data sets, GPS data, covariance data etc.

Thanks again for your help,
Nick



On Tue, 2010-09-28 at 20:34 +1000, Rosen Diankov wrote:

> Hi Nick,
>
> You make several very excellent points. Currently, I think it is
> better to have a huge list of all sensor types. However, that doesn't
> mean you are only restricted to only the parameters defined in the
> header files. If you'll notice the basesensors plugin, it defines
> several new parameters for flash lidar. This sensor is encoded as a
> basic laser type, and its extra parameters are hidden from the
> openrave API (ie they are in the basesensors definition), however it
> still notifies users of the basic data type without requiring them to
> compile new code to use the new laser.
>
> In fact, I argue that after nailing down all basic types of sensor
> geometry and data, the same sensor could offer multiple modalities of
> sensing data. For example, the SR4000 gives range data and image data.
>
> I agree that extending sensor definitions for plugin developers could
> be made easier, but I would really like to see how far we can push the
> static basic data types before going onto a special "custom" message.
> Once a "custom" sensor is introduced, everyone who wants to put custom
> data will ignore the base definitions, and create their own sensor,
> which others will not be able to read. After using ROS for 2 years,
> this is exactly the problem that has happened and has caused a lot of
> incompatibility headaches.
>
> Anyway, please describe the INS sensor's geometry and data output.
> Because it is both a GPS and an inertial sensor, perhaps it is worth
> implementing the multiple sensor geometry/types.
>
> rosen,
>
> 2010/9/28 Nick Hillier <[hidden email]>:
> > Thanks Rosen,
> >
> > Whilst I agree in principal, I suspect that you are going to end up with
> > a huge list of sensors that only a select few (or probably only one)
> > user is interested in. At the moment I'm really just after something
> > that the default openrave_sensors ROS publisher will just skip over
> > rather than filling my screen with "failed to output..." messages, so I
> > can create my own publisher plugin.
> >
> > I'm currently implementing a plugin for an INS - a hybrid GPS, Inertial
> > navigation sensor. The effort in this sensor alone is significant -
> > there are various GPS support message types, status fields, varying
> > levels of solution fix etc.
> >
> > Further compounding the issue for us, is that most users here do not use
> > OpenRAVE as a planning environment, but rather an easily extensible
> > simulation tool, due to the nice plug-in architecture.  We are looking
> > at implementing a variety of different laser and radar scanners that do
> > not play well with the standard laser message interfaces in OpenRAVE
> > (published under ROS as pointcloud2 type), due to various probabilistic
> > sensor models with multiple echo return widths etc.
> >
> > We also have users interested in using OpenRAVE's simple interfaces to
> > prototype sensors, just to see how their data processing algorithms
> > might perform on mobile platforms, for example hyperspectral imaging
> > sensors simulated by defining "material properties" in the environment
> > representation and using ray traces and look-up tables to compute the
> > return data.
> >
> > Regards,
> > Nick
> >
> > On Tue, 2010-09-28 at 16:12 +1000, Rosen Diankov wrote:
> >> hi nick,
> >>
> >> One of the advantages of putting all the sensor geometry and data
> >> definitions in the header file is that others will be able to
> >> understand and use the sensor messages. As soon as you start putting
> >> custom sensors, people will start having different definitions of what
> >> a  camera and a laser is, and then compatibility will break.
> >>
> >> Therefore, if you have an idea for a new sensor type, please post it
> >> on this users lists so we can discuss it, and eventually it will
> >> become part of the openrave.
> >>
> >> rosen,
> >>
> >> 2010/9/28 Nick Hillier <[hidden email]>:
> >> > Hi all,
> >> >
> >> > Can we add a "ST_Other" sensor type to the enum in rave/sensor.h so that
> >> > we have a type to assign to sensor definitions that we write custom
> >> > plugins for? Or should we be using the "ST_Invalid" type for custom
> >> > sensor types that we know OpenRAVE won't handle the data for natively?
> >> >
> >> > I am writing an INS sensor plugin to publish some ROS messages for our
> >> > platforms, I'm sure there will be others.
> >> >
> >> > Nick
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Start uncovering the many advantages of virtual appliances
> >> > and start using them to simplify application deployment and
> >> > accelerate your shift to cloud computing.
> >> > http://p.sf.net/sfu/novell-sfdev2dev
> >> > _______________________________________________
> >> > Openrave-users mailing list
> >> > [hidden email]
> >> > https://lists.sourceforge.net/lists/listinfo/openrave-users
> >> >
> >
> >
> >



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|

Re: "Other" sensor type

Rosen Diankov
Administrator
hi nick,

thanks for the ticket!

http://sourceforge.net/apps/trac/openrave/ticket/70

1) The rossensorpublisher is fixed as you suggested (jsk-ros-pkg r698)

2) Actually the goal was never to show the 2D structure of the laser
data. I'm not sure how important that is... but if you think this is
vital information, then we could comment that field more

3) The SensorBase class will have to change to accommodate for this,
this will most likely happen by quering if a sensor supports a
particular type, and then return the data/geometry only for that
particular type. For example the new declarations could be:

SensorGeometryPtr GetSensorGeometry(SensorType);

SensorDataPtr CreateSensorData(SensorType);

bool Supports(SensorType);

rosen,


2010/9/29 Nick Hillier <[hidden email]>:

> Thanks Rosen,
>
> I am making a Trac ticket with the description of the data fields for an
> INS.
>
> In the mean time... 3 more things
>
> 1) Can you update the ROS sensor publisher to only print the unsupported
> sensor message once, rather than at every iteration? I've just commented
> it out locally for our own use until we can use something that fits into
> the OpenRAVE architecture better, but for other users that may fall into
> this trap in the future, it would be nice not to flood their screen with
> errors.
>
> 2) I've been looking at the flash lidar plugin as you suggested. It
> reports data in the form of the LaserSensorData type which basically
> gives a long 1D array of the data based on an indexing which increments
> based on a column-major format (i.e. the first lot of data corresponds
> to the first column of the scan, the second column of data is then
> appended to the first etc).
>
> This is nice in that it re-uses the existing LaserSensorData type, which
> makes it accessible within the python interface without any additional
> hooks etc. However, the user doesn't know the data format (i.e. row or
> column major) without looking at your plugin implementation. This is
> just a minor usability issue and for the sake of code maintenance, it's
> probably not worth the hassle of addressing, but does raise the sort of
> usability issues that might arise in more complicated sensor
> implementations.
>
> 3) My real question though is: how would you combine two standard data
> types into one sensor? e.g. the image data of the SR4000 as well as the
> range data? there is only one argument to the GetSensorData() function,
> so how would one sensor return two data types (here a LaserSensorData
> type and a CameraSensorData type)? I ask this because an INS would
> return multiple IMU data sets, GPS data, covariance data etc.
>
> Thanks again for your help,
> Nick
>
>
>
> On Tue, 2010-09-28 at 20:34 +1000, Rosen Diankov wrote:
>> Hi Nick,
>>
>> You make several very excellent points. Currently, I think it is
>> better to have a huge list of all sensor types. However, that doesn't
>> mean you are only restricted to only the parameters defined in the
>> header files. If you'll notice the basesensors plugin, it defines
>> several new parameters for flash lidar. This sensor is encoded as a
>> basic laser type, and its extra parameters are hidden from the
>> openrave API (ie they are in the basesensors definition), however it
>> still notifies users of the basic data type without requiring them to
>> compile new code to use the new laser.
>>
>> In fact, I argue that after nailing down all basic types of sensor
>> geometry and data, the same sensor could offer multiple modalities of
>> sensing data. For example, the SR4000 gives range data and image data.
>>
>> I agree that extending sensor definitions for plugin developers could
>> be made easier, but I would really like to see how far we can push the
>> static basic data types before going onto a special "custom" message.
>> Once a "custom" sensor is introduced, everyone who wants to put custom
>> data will ignore the base definitions, and create their own sensor,
>> which others will not be able to read. After using ROS for 2 years,
>> this is exactly the problem that has happened and has caused a lot of
>> incompatibility headaches.
>>
>> Anyway, please describe the INS sensor's geometry and data output.
>> Because it is both a GPS and an inertial sensor, perhaps it is worth
>> implementing the multiple sensor geometry/types.
>>
>> rosen,
>>
>> 2010/9/28 Nick Hillier <[hidden email]>:
>> > Thanks Rosen,
>> >
>> > Whilst I agree in principal, I suspect that you are going to end up with
>> > a huge list of sensors that only a select few (or probably only one)
>> > user is interested in. At the moment I'm really just after something
>> > that the default openrave_sensors ROS publisher will just skip over
>> > rather than filling my screen with "failed to output..." messages, so I
>> > can create my own publisher plugin.
>> >
>> > I'm currently implementing a plugin for an INS - a hybrid GPS, Inertial
>> > navigation sensor. The effort in this sensor alone is significant -
>> > there are various GPS support message types, status fields, varying
>> > levels of solution fix etc.
>> >
>> > Further compounding the issue for us, is that most users here do not use
>> > OpenRAVE as a planning environment, but rather an easily extensible
>> > simulation tool, due to the nice plug-in architecture.  We are looking
>> > at implementing a variety of different laser and radar scanners that do
>> > not play well with the standard laser message interfaces in OpenRAVE
>> > (published under ROS as pointcloud2 type), due to various probabilistic
>> > sensor models with multiple echo return widths etc.
>> >
>> > We also have users interested in using OpenRAVE's simple interfaces to
>> > prototype sensors, just to see how their data processing algorithms
>> > might perform on mobile platforms, for example hyperspectral imaging
>> > sensors simulated by defining "material properties" in the environment
>> > representation and using ray traces and look-up tables to compute the
>> > return data.
>> >
>> > Regards,
>> > Nick
>> >
>> > On Tue, 2010-09-28 at 16:12 +1000, Rosen Diankov wrote:
>> >> hi nick,
>> >>
>> >> One of the advantages of putting all the sensor geometry and data
>> >> definitions in the header file is that others will be able to
>> >> understand and use the sensor messages. As soon as you start putting
>> >> custom sensors, people will start having different definitions of what
>> >> a  camera and a laser is, and then compatibility will break.
>> >>
>> >> Therefore, if you have an idea for a new sensor type, please post it
>> >> on this users lists so we can discuss it, and eventually it will
>> >> become part of the openrave.
>> >>
>> >> rosen,
>> >>
>> >> 2010/9/28 Nick Hillier <[hidden email]>:
>> >> > Hi all,
>> >> >
>> >> > Can we add a "ST_Other" sensor type to the enum in rave/sensor.h so that
>> >> > we have a type to assign to sensor definitions that we write custom
>> >> > plugins for? Or should we be using the "ST_Invalid" type for custom
>> >> > sensor types that we know OpenRAVE won't handle the data for natively?
>> >> >
>> >> > I am writing an INS sensor plugin to publish some ROS messages for our
>> >> > platforms, I'm sure there will be others.
>> >> >
>> >> > Nick
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Start uncovering the many advantages of virtual appliances
>> >> > and start using them to simplify application deployment and
>> >> > accelerate your shift to cloud computing.
>> >> > http://p.sf.net/sfu/novell-sfdev2dev
>> >> > _______________________________________________
>> >> > Openrave-users mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/openrave-users
>> >> >
>> >
>> >
>> >
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Openrave-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openrave-users
>

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users