search

autonohm / ohm_tsd_slam

SLAM approach based on truncated signed distance transform
21 stars 25 forks source link

Bug with 360 degree scans #19

Open max-kuzmin opened 6 years ago

max-kuzmin commented 6 years ago

Some laser rangefinders cast rays on 360 degree and publish messages with angle_min=0 and angle_max=6.28. But algorithm only uses rays from 0 to 3.14. Other rays drop in function obvious::SensorPolar2D::backProject()

Possible fix without modifying Obvious sources is to check angle_min in functions ThreadLocalize::init and ThreadLocalize::eventLoop. And then rotate ranges vector

std::rotate(ranges.begin(), ranges.begin() + (int)round(M_PI / inc), ranges.end());
philko4711 commented 6 years ago

Hi, could you please post your launch file here. The slam has been tested successfully with 360° scanners. It loads automatically all parameters from the ros message.

max-kuzmin commented 6 years ago

I think that this is mostly problem of Obviously. ThreadLocalize correctly creates obvious::SensorPolar2D object from scan messages. I use Turtlebot3 model inside simulator Gazebo. In my case laser rays have angles from 0 to 2*Pi. And at the step of integrating it into grid method obvious::SensorPolar2D::backProject() drops all rays that not between angle_min and Pi. Even in comments to obvious::SensorPolar2D said that _phiLowerBound should be less than 0. Taking into account the fact that the algorithm normalizes inverted scan messages (parameter ThreadLocalize::_reverseScan) it also will be better to normalize rays angles to interval [-Pi; Pi] as I wrote above.

philko4711 commented 6 years ago

Hi, Im pretty sure, that the obviously lib remained unchanged regarding these classes. We have used an RPLidar and a high resolution 360° laser scanner. The 3D version of this lib has been tested with a velodyne 32 laser scanner. I promise to look into that. The SLAM and the obvision lib will be refactored in the near future.