Use random generator from C++11 instead of from Boost in module sample_consensus

[SunBlack]

Separation from #2956 due to the need to adapt tests.

[SergioRAgostinho]

I had a first look over it and it looks fine. To give a better feedback into the changes in the numerical values of the unit tests I need to actually dive into the problem, read into the actual model estimation process, plotting data, etc... Sunday at best :/

[taketwo]

Here is a visualization of the cone data:

The cone was "manually fitted", it's parameters are:

• apex: 0.0, 0.1, 1.0
• axis: 0, 1, 0
• angle: 20 degrees, which is approximately 0.34905 radians

This matches the expected values in the test. For some reason, only three out of seven parameters are checked, so I'd say we should add checks for the rest as well.

[SergioRAgostinho]

I'm going to pick up everything related to random in the next days. Let's rebase this one and let it run.

[SergioRAgostinho]

Despite the fact the unit tests are passing here, there at least 5 failing in my local environment when I checkout this branch.

[stale]

This pull request has been automatically marked as stale because it hasn't had
any activity in the past 60 days. Commenting or adding a new commit to the
pull request will revert this.

Come back whenever you have time. We look forward to your contribution.

[stale]

This pull request has been automatically marked as stale because it hasn't had
any activity in the past 60 days. Commenting or adding a new commit to the
pull request will revert this.

Come back whenever you have time. We look forward to your contribution.

[stale]

Marking this as stale due to 30 days of inactivity. Commenting or adding a new commit to the pull request will revert this.

[kunaltyagi]

There's some cleanup in this PR compared to master. I'd prefer if someone could just get that separated and merged whenever they have the time.

Regarding boost -> stdlib generator, as Morween pointed out, that might be the cause of difference in results. The generators API has been standardized, not their (input, output), so the same seed on different platforms can give different results with stdlib. In view of that, I'd recommend throwing away the work done/planned to remove boost generators. On the other hand, PRNG generators are standardized better, and boost PRNG can be replaced by stdlib PRNGs

[stale]

Marking this as stale due to 30 days of inactivity. Commenting or adding a new commit to the pull request will revert this.

[rurban]

There is no boost::mt19937 anymore, replaced by std:mt19937. see the failing gh actions on macOS Ventura 13.
So this should be rebased and merged sooner or later

[mvieth]

There is no boost::mt19937 anymore, replaced by std:mt19937. see the failing gh actions on macOS Ventura 13. So this should be rebased and merged sooner or later

boost::mt19937 definitely still exists in Boost 1.86.0: https://www.boost.org/doc/libs/1_86_0/doc/html/doxygen/headers/mersenne__twister_8hpp_1a313d63e0721b6a6bba3a1be507e9e6a2.html macOS Ventura 13 currently fails because PCL needs to include some additional Boost headers (that have been transitively included by other Boost headers in previous Boost versions). I already created a pull request to add the includes and make PCL compatible with Boost 1.86.0.

[rurban]

Oh, I see. thanks