Help save net neutrality! Learn more.

## playerstage-users

 [Playerstage-users] vfh coordinate system From: Stefan Stiene - 2007-05-15 14:05:14 ```Hi, what is the coordinate system of the vfh driver? If I get turnrate 30 is this 30 degree clockwise from the robots heading direction? The vfh driver gets odometry data from the under lying position2d device. Then it computes: float Desired_Angle = (90 + atan2((goal_y - this->odom_pose[1]), (goal_x - this->odom_pose[0])) * 180 / M_PI - this->odom_pose[2]); while (Desired_Angle > 360.0) Desired_Angle -= 360.0; while (Desired_Angle < 0) Desired_Angle += 360.0; what is the coordinate system from odom_pose[2] (the robot orientation). >From the formula it looks like the oriantation has to be in degree. Is it between -180 and 180 or 0 and 360? Best Stefan ```
 Re: [Playerstage-users] vfh coordinate system From: Jack O'Quin - 2007-05-15 15:16:02 ```On 5/15/07, Stefan Stiene wrote: > Hi, > what is the coordinate system of the vfh driver? > If I get turnrate 30 is this 30 degree clockwise from the robots heading > direction? > > The vfh driver gets odometry data from the under lying position2d > device. Then it computes: > > float Desired_Angle = (90 + atan2((goal_y - this->odom_pose[1]), > (goal_x - this->odom_pose[0])) > * 180 / M_PI - this->odom_pose[2]); > > while (Desired_Angle > 360.0) > Desired_Angle -= 360.0; > while (Desired_Angle < 0) > Desired_Angle += 360.0; > > what is the coordinate system from odom_pose[2] (the robot orientation). > >From the formula it looks like the oriantation has to be in degree. Is > it between -180 and 180 or 0 and 360? That code is very confusing. I believe VFH uses a strange ego-centric coordinate system in degrees with a heading of 90 deg being straight ahead. That lines up with the hard-coded 180-degree laser ranges. These headings seem to be normalized in different ways in different parts of the code. Sometimes it's [0..360], sometimes [-180..180]. Very confusing. The sign seems to follow the standard player convention: positive is to the left (counter-clockwise). -- joq ```
 Re: [Playerstage-users] vfh coordinate system From: Stefan Stiene - 2007-05-15 15:49:49 ```Thanks for the quick answer. We combined two laser scanner to a 360° laser scanner. Now we want to do obstacle avoidance using this scanner. I use the playerviewer3d to show me the primary vfh histogram. And it seems like the vfh driver works with the 360° scanner. I can see large histogram values if the robot gets neer to obstacles. I push ground truth odometry data to the vfh driver using the standard player convention for the robot orientation. However I always get turnrate 40 and the robot is driving in a never ending circle. Any Ideas Stefan Jack O'Quin schrieb: > On 5/15/07, Stefan Stiene wrote: > >> Hi, >> what is the coordinate system of the vfh driver? >> If I get turnrate 30 is this 30 degree clockwise from the robots heading >> direction? >> >> The vfh driver gets odometry data from the under lying position2d >> device. Then it computes: >> >> float Desired_Angle = (90 + atan2((goal_y - this->odom_pose[1]), >> (goal_x - this->odom_pose[0])) >> * 180 / M_PI - this->odom_pose[2]); >> >> while (Desired_Angle > 360.0) >> Desired_Angle -= 360.0; >> while (Desired_Angle < 0) >> Desired_Angle += 360.0; >> >> what is the coordinate system from odom_pose[2] (the robot orientation). >> >From the formula it looks like the oriantation has to be in degree. Is >> it between -180 and 180 or 0 and 360? >> > > That code is very confusing. I believe VFH uses a strange ego-centric > coordinate system in degrees with a heading of 90 deg being straight > ahead. That lines up with the hard-coded 180-degree laser ranges. > > These headings seem to be normalized in different ways in different > parts of the code. Sometimes it's [0..360], sometimes [-180..180]. > Very confusing. The sign seems to follow the standard player > convention: positive is to the left (counter-clockwise). > ```
 Re: [Playerstage-users] vfh coordinate system From: Jack O'Quin - 2007-05-15 16:03:10 ```On 5/15/07, Stefan Stiene wrote: > Thanks for the quick answer. > We combined two laser scanner to a 360=B0 laser scanner. Now we want to d= o > obstacle avoidance using this scanner. I use the playerviewer3d to show > me the primary vfh histogram. And it seems like the vfh driver works > with the 360=B0 scanner. I can see large histogram values if the robot > gets neer to obstacles. I push ground truth odometry data to the vfh > driver using the standard player convention for the robot orientation. > However I always get turnrate 40 and the robot is driving in a never > ending circle. No. I asked about 360-degree laser support in VFH several months ago. Brian replied that the 180-degree logic is deeply imbedded in the algorithm. It sounds like a difficult job. He said he'd accept a patch to fix the problem. :-) You might take a look at the new nd driver. It implements nearness diagram navigation with an interface compatible with VFH. --=20 joq ```
 Re: [Playerstage-users] vfh coordinate system From: Stefan Stiene - 2007-05-16 08:38:27 ```Jack O'Quin schrieb: > On 5/15/07, Stefan Stiene wrote: >> Thanks for the quick answer. >> We combined two laser scanner to a 360° laser scanner. Now we want to do >> obstacle avoidance using this scanner. I use the playerviewer3d to show >> me the primary vfh histogram. And it seems like the vfh driver works >> with the 360° scanner. I can see large histogram values if the robot >> gets neer to obstacles. I push ground truth odometry data to the vfh >> driver using the standard player convention for the robot orientation. >> However I always get turnrate 40 and the robot is driving in a never >> ending circle. > > No. > > I asked about 360-degree laser support in VFH several months ago. > Brian replied that the 180-degree logic is deeply imbedded in the > algorithm. It sounds like a difficult job. > > He said he'd accept a patch to fix the problem. :-) > > You might take a look at the new nd driver. It implements nearness > diagram navigation with an interface compatible with VFH. I looked at the nd driver. The description says, that the driver is only for non holonomic robots. In nd_plugin.h there is the possibility to set the nd method for holonomic robots. If I want to use nd with a holonomic robot, is this->NDparametros.holonomic = 0 (nd_plugin line 982) all I have to change? Or is the skid steered robot kinematic deeply integrated into in the nd_plugin file? Best Stefan ```
 Re: [Playerstage-users] vfh coordinate system From: Brian Gerkey - 2007-05-16 15:58:12 ```On May 16, 2007, at 1:38 AM, Stefan Stiene wrote: >> >> I asked about 360-degree laser support in VFH several months ago. >> Brian replied that the 180-degree logic is deeply imbedded in the >> algorithm. It sounds like a difficult job. To clarify, the laser aperture is not part of the VFH *algorithm*, but just our implementation of it. The algorithm can easily handle a 360-degree range sensor. The problem is that there is some funny indexing in our code that assumes 180-degree scans. >> He said he'd accept a patch to fix the problem. :-) And the offer still stands :) > I looked at the nd driver. The description says, that the driver is > only > for non holonomic robots. In nd_plugin.h there is the possibility > to set > the nd method for holonomic robots. > If I want to use nd with a holonomic robot, is > this->NDparametros.holonomic = 0 (nd_plugin line 982) > all I have to change? Or is the skid steered robot kinematic deeply > integrated into in the nd_plugin file? The non-holonomic / diff-drive assumption is hardcoded into nd_plugin.cc, but the core nd library can handle a holonomic robot (though I've never tried it). It should not be that hard to modify nd_plugin.cc to expose this functionality. However, if your robot is roughly circular, VFH will probably give better / faster behavior. brian. ```
 Re: [Playerstage-users] vfh coordinate system From: - 2007-05-18 10:38:46 ```Hi, why don't change all collision avoidance driver to a holonomic model. The collision avoidance driver computes direction and speed drive commans and pass them to an under lying kinematic model driver. This driver computes the specific drive commands from speed and direction for holonomous, diff-drive, ackerman steered, ... robots. For example. The vfh driver figures out, that the robot has to drive backwards to escape. It passes this direction to the under lying kinematic model driver. If this driver has a holonomic kinematic the robot drives direct in this direction. If it implements a diff-drive model the driver computes a turn on place drive command. The kinematic model driver gets the robot geometry, the driving model and hardware access from a under lying robotmodel driver. Using this configuration all robots can use the same vfh,nd,... driver. And new robot drivers don't have to reimplement the robots kinematic model (if it is a standard one). Best stefan > > On May 16, 2007, at 1:38 AM, Stefan Stiene wrote: > >>> >>> I asked about 360-degree laser support in VFH several months ago. >>> Brian replied that the 180-degree logic is deeply imbedded in the >>> algorithm. It sounds like a difficult job. > > To clarify, the laser aperture is not part of the VFH *algorithm*, > but just our implementation of it. The algorithm can easily handle a > 360-degree range sensor. The problem is that there is some funny > indexing in our code that assumes 180-degree scans. > >>> He said he'd accept a patch to fix the problem. :-) > > And the offer still stands :) > >> I looked at the nd driver. The description says, that the driver is >> only >> for non holonomic robots. In nd_plugin.h there is the possibility >> to set >> the nd method for holonomic robots. >> If I want to use nd with a holonomic robot, is >> this->NDparametros.holonomic = 0 (nd_plugin line 982) >> all I have to change? Or is the skid steered robot kinematic deeply >> integrated into in the nd_plugin file? > > The non-holonomic / diff-drive assumption is hardcoded into > nd_plugin.cc, but the core nd library can handle a holonomic robot > (though I've never tried it). It should not be that hard to modify > nd_plugin.cc to expose this functionality. > > However, if your robot is roughly circular, VFH will probably give > better / faster behavior. > > brian. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Playerstage-users mailing list > Playerstage-users@... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > ```
 Re: [Playerstage-users] vfh coordinate system From: Brian Gerkey - 2007-05-22 16:29:53 ```On May 18, 2007, at 4:38 AM, sstiene@... wrote: > why don't change all collision avoidance driver to a holonomic > model. The > collision avoidance driver computes direction and speed drive > commans and > pass them to an under lying kinematic model driver. This driver > computes > the specific drive commands from speed and direction for holonomous, > diff-drive, ackerman steered, ... robots. For example. > > The vfh driver figures out, that the robot has to drive backwards to > escape. It passes this direction to the under lying kinematic model > driver. If this driver has a holonomic kinematic the robot drives > direct > in this direction. If it implements a diff-drive model the driver > computes > a turn on place drive command. > The kinematic model driver gets the robot geometry, the driving > model and > hardware access from a under lying robotmodel driver. > > Using this configuration all robots can use the same vfh,nd,... > driver. > And new robot drivers don't have to reimplement the robots > kinematic model > (if it is a standard one). Sounds like a great idea, though it will require a bit of work. Can you put together a proposal interface for communicating between navigation drivers and kinematic-specific controllers? brian. ```