## Re: [Playerstage-users] driving in reverse?

 Re: [Playerstage-users] driving in reverse? From: Jack O'Quin - 2006-12-19 22:14:42 ```On 12/19/06, Brian Gerkey wrote: > On Dec 15, 2006, at 9:00 PM, Jack O'Quin wrote: > > Is there any way to extend VFH to handle something like that? > > Yes, but it would require quite a bit of work. The underlying VFH > code strictly assumes 180-degree sensing in all of its indexing. > This is something we've been working around for a long time, so I'd > happily accept a patch that makes our vfh driver more flexible. Sounds very tricky to get right. I'll take a look at it. Maybe there is some ugly workaround like reversing VFH's view of the world when travelling in reverse, so that backwards is forwards and the rear-scanning laser ranges are the ones it uses. (Obviously, I have no idea what I am talking about here.) :-) > Note that the VFH algorithm is fundamentally a 2-D navigation > technique, so there's not much point in giving it pointcloud3d data. > Instead, I would pre-process the 3d laser data into a 2-D scan that > gives, for examples, the shortest range at each bearing (you could > offer an optional 'laser' interface on your driver for the Velodyne). I had figured on creating some kind of 2d mapping. Is it allowed for a laser interface to return 360-degree data? Can a player_laser_data_t return min_angle and max_angle of +pi and -pi? -- joq ```

 [Playerstage-users] driving in reverse? From: Jack O'Quin - 2006-12-07 23:41:13 ```I am trying to figure out the best way to represent driving in reverse for a player-controller vehicle. The vehicle is a car, which needs to learn how to make 3-point turns, etc. The computer can shift the transmission into reverse. How do other projects handle this in player? The obvious solution is sending a negative vel.px in the PLAYER_POSITION2D_CMD_VEL request, or a negative velocity with PLAYER_POSITION2D_CMD_CAR. Will other existing player code handle this correctly? (stage, gazebo, vfh, laser, amcl, pointcloud3d, etc.) Is there a better approach? -- joq ```
 Re: [Playerstage-users] driving in reverse? From: Brian Gerkey - 2006-12-15 21:29:18 ```On Dec 7, 2006, at 3:41 PM, Jack O'Quin wrote: > I am trying to figure out the best way to represent driving in > reverse for a player-controller vehicle. The vehicle is a car, > which needs to learn how to make 3-point turns, etc. The > computer can shift the transmission into reverse. > > How do other projects handle this in player? > > The obvious solution is sending a negative vel.px in the > PLAYER_POSITION2D_CMD_VEL request, or a negative > velocity with PLAYER_POSITION2D_CMD_CAR. Yep, negative translational velocity will do the trick, with either CMD_VEL or CMD_CAR (though not many drivers support CMD_CAR). > Will other existing player code handle this correctly? > (stage, gazebo, vfh, laser, amcl, pointcloud3d, etc.) VFH won't drive backward, because it assumes you have a forward- pointing sensor, and it can't see behind itself. brian. ```
 Re: [Playerstage-users] driving in reverse? From: Jack O'Quin - 2006-12-16 05:00:52 ```On 12/15/06, Brian Gerkey wrote: > > On Dec 7, 2006, at 3:41 PM, Jack O'Quin wrote: > > > I am trying to figure out the best way to represent driving in > > reverse for a player-controller vehicle. The vehicle is a car, > > which needs to learn how to make 3-point turns, etc. The > > computer can shift the transmission into reverse. > > > > How do other projects handle this in player? > > > > The obvious solution is sending a negative vel.px in the > > PLAYER_POSITION2D_CMD_VEL request, or a negative > > velocity with PLAYER_POSITION2D_CMD_CAR. > > Yep, negative translational velocity will do the trick, with either > CMD_VEL or CMD_CAR (though not many drivers support CMD_CAR). > > > Will other existing player code handle this correctly? > > (stage, gazebo, vfh, laser, amcl, pointcloud3d, etc.) > > VFH won't drive backward, because it assumes you have a forward- > pointing sensor, and it can't see behind itself. OK, thanks. That's about what I figured. We're still working on the sensors. The plan is to install 360-degree coverage. Maybe using pointcloud3d. We've tested the new Velodyne 3d laser. Is there any way to extend VFH to handle something like that? -- joq ```
 Re: [Playerstage-users] driving in reverse? From: Brian Gerkey - 2006-12-19 17:00:42 ```On Dec 15, 2006, at 9:00 PM, Jack O'Quin wrote: > On 12/15/06, Brian Gerkey wrote: >> >> VFH won't drive backward, because it assumes you have a forward- >> pointing sensor, and it can't see behind itself. > > OK, thanks. > > That's about what I figured. We're still working on the sensors. The > plan is to install 360-degree coverage. Maybe using pointcloud3d. > We've tested the new Velodyne 3d laser. > > Is there any way to extend VFH to handle something like that? Yes, but it would require quite a bit of work. The underlying VFH code strictly assumes 180-degree sensing in all of its indexing. This is something we've been working around for a long time, so I'd happily accept a patch that makes our vfh driver more flexible. Note that the VFH algorithm is fundamentally a 2-D navigation technique, so there's not much point in giving it pointcloud3d data. Instead, I would pre-process the 3d laser data into a 2-D scan that gives, for examples, the shortest range at each bearing (you could offer an optional 'laser' interface on your driver for the Velodyne). brian. ```
 Re: [Playerstage-users] driving in reverse? From: Jack O'Quin - 2006-12-19 22:14:42 ```On 12/19/06, Brian Gerkey wrote: > On Dec 15, 2006, at 9:00 PM, Jack O'Quin wrote: > > Is there any way to extend VFH to handle something like that? > > Yes, but it would require quite a bit of work. The underlying VFH > code strictly assumes 180-degree sensing in all of its indexing. > This is something we've been working around for a long time, so I'd > happily accept a patch that makes our vfh driver more flexible. Sounds very tricky to get right. I'll take a look at it. Maybe there is some ugly workaround like reversing VFH's view of the world when travelling in reverse, so that backwards is forwards and the rear-scanning laser ranges are the ones it uses. (Obviously, I have no idea what I am talking about here.) :-) > Note that the VFH algorithm is fundamentally a 2-D navigation > technique, so there's not much point in giving it pointcloud3d data. > Instead, I would pre-process the 3d laser data into a 2-D scan that > gives, for examples, the shortest range at each bearing (you could > offer an optional 'laser' interface on your driver for the Velodyne). I had figured on creating some kind of 2d mapping. Is it allowed for a laser interface to return 360-degree data? Can a player_laser_data_t return min_angle and max_angle of +pi and -pi? -- joq ```
 Re: [Playerstage-users] driving in reverse? From: Brian Gerkey - 2006-12-19 22:19:31 ```On Dec 19, 2006, at 2:14 PM, Jack O'Quin wrote: > On 12/19/06, Brian Gerkey wrote: > >> Note that the VFH algorithm is fundamentally a 2-D navigation >> technique, so there's not much point in giving it pointcloud3d data. >> Instead, I would pre-process the 3d laser data into a 2-D scan that >> gives, for examples, the shortest range at each bearing (you could >> offer an optional 'laser' interface on your driver for the Velodyne). > > I had figured on creating some kind of 2d mapping. Is it allowed for > a laser interface to return 360-degree data? Can a > player_laser_data_t > return min_angle and max_angle of +pi and -pi? Sure, that's no problem. brian. ```