wolf merge requestshttps://gitlab.iri.upc.edu/mobile_robotics/wolf_projects/wolf_lib/wolf/-/merge_requests2019-05-09T13:01:09+02:00https://gitlab.iri.upc.edu/mobile_robotics/wolf_projects/wolf_lib/wolf/-/merge_requests/272Problem notification lists API2019-05-09T13:01:09+02:00Joan Vallvé Navarrojvallve@iri.upc.eduProblem notification lists APIAfter merging !261, for some reasons related with the mutex in problem, the old accessors for the notification maps `getStateBlockNotificationMap()` and `getFactorNotificationMap()` were removed. The were replaced by the new `consumeStat...After merging !261, for some reasons related with the mutex in problem, the old accessors for the notification maps `getStateBlockNotificationMap()` and `getFactorNotificationMap()` were removed. The were replaced by the new `consumeStateBlockNotificationMap()` and `consumeFactorNotificationMap()` that returns them via copy, so, the map is emptied after calling them.
The tests were adapted to these new functions, but I think it can be misleading, mostly for new tests (notifications emptied before being updated to the solver...).
In this MR I propose to keep `Problem::consumeStateBlockNotificationMap()` and `Problem::consumeFactorNotificationMap()` protected. Then, `SolverManager` has been added as a `friend` to allow it to call these functions.
For testing, new public functions are provided (that does not alter the maps in `Problem`):
* **`SizeStd getStateBlockNotificationMapSize() const`**: Returns the size of the map of state block notification.
* **`bool getStateBlockNotification(const StateBlockPtr& sb_ptr, Notification& notif) const`**: Returns if the state block has been notified, and the notification via parameter.
* **`SizeStd getFactorNotificationMapSize() const`**: Returns the size of the map of factor notification.
* **`bool getFactorNotification(const FactorBasePtr& sb_ptr, Notification& notif) const`**: Returns if the factor has been notified, and the notification via parameter.Multi-threadinghttps://gitlab.iri.upc.edu/mobile_robotics/wolf_projects/wolf_lib/wolf/-/merge_requests/261Added mutexs in problem2019-05-06T10:00:18+02:00Joan Vallvé Navarrojvallve@iri.upc.eduAdded mutexs in problemImplementing issue #190
Two of the protected attributes (both `std::map`: `state_block_nofitication_map_` and `factor_nofitication_map_`) had `getXXX()` functions that returned via reference. They have been changed to `consumeXXX()` th...Implementing issue #190
Two of the protected attributes (both `std::map`: `state_block_nofitication_map_` and `factor_nofitication_map_`) had `getXXX()` functions that returned via reference. They have been changed to `consumeXXX()` that returns them via `std::move` so, emptying them after the call.
In the process, I identified that the list `Problem::state_block_list_` became useless some time ago. It was removed and all the associated machinery.Multi-threadingJoan Vallvé Navarrojvallve@iri.upc.eduJoan Vallvé Navarrojvallve@iri.upc.eduhttps://gitlab.iri.upc.edu/mobile_robotics/wolf_projects/wolf_lib/wolf/-/merge_requests/259Multi-threading patch2019-04-09T12:34:02+02:00Joan Vallvé Navarrojvallve@iri.upc.eduMulti-threading patchAs explained in #188, some of the wolf ros nodes use different threads for each sensor callback and the call to `solve()` as well. Consequently, it rarely crashes due to some asserts in `SolverManager::update()`.
They are there to guar...As explained in #188, some of the wolf ros nodes use different threads for each sensor callback and the call to `solve()` as well. Consequently, it rarely crashes due to some asserts in `SolverManager::update()`.
They are there to guarantee that all notified factors have been updated and that all state blocks in the problem are registered. However, with this multithreading scheme, a new factor or state block is sometimes added during the `update()` execution.
This MR comments two asserts and adds a `continue` to avoid a third case which would produce an error. However, **this is just a patch**, we should discuss adding some mutex for some `Problem` attributes or whatever.. to deal with multi-threading.Multi-threadingJoan Vallvé Navarrojvallve@iri.upc.eduJoan Vallvé Navarrojvallve@iri.upc.edu