Juraj Oršulić

Results 39 comments of Juraj Oršulić

Looking forward to your rfc :-) I think you can rely on Cartographer's constraint builder for closing loops and solving the kidnapped robot problem, and use a simple "nearest within...

+1. Is this still considered to be added?

It looks like when parsing the cons list of hex numbers in the aggregated offer, multiple hex numbers somehow get improperly concatenated: SyntaxError: invalid hex at 1: 0xa402643c844ad9048d4a6f9c724077254fa5e1355b7afb06088de4f92ad489a6e9045811e8797a49157ca20510bac62f3e985c5f94fbbfd3d8fbed99886750820000000000008a84**0x**f94821c0703b8484dcfba68b1a678002efbe97dc058b8ffb9f26723d34c449b5e9045811e8797a49157ca20510bac62f3e985c5f94fbbfd3d8fbed99886750820000000000008aac**0x**305b....

Cross referencing the question on LaTeX Stack Exchange: https://tex.stackexchange.com/questions/621084/higher-overlay-specs-break-movie15s-includemovie

I tried out your PR and it helped with wild pose divergences indoors (VLP-16). They still happen (especially in confined spaces), but less often.

Indeed, thank you :) Yup, this implementation trusts the IMU too little. It only uses the gyro/accelerometer to unwarp the point cloud, even though the IMU provides a stable pitch/roll...

@KitKat7 can you PTAL at [this line](https://github.com/laboshinl/loam_velodyne/blob/a4c364a677647f2a35831439032dc5a58378b3fd/src/lib/BasicLaserOdometry.cpp#L502)? Do you think that the transform should be scaled according to scan time (`s = (1.f / _scanPeriod) * (pointOri.intensity - int(pointOri.intensity))` like...

Hmmm, are you sure it's just scaling? The angle inside the sines/cosines a couple of lines below is also multiplied by `s`. If the costs `d` (inside `coeff.intensity`) are calculated...

@tungdanganh You need to use "transposeInPlace()". https://eigen.tuxfamily.org/dox/group__TutorialMatrixArithmetic.html

@dmiklic you can maybe take a look at this.