Error when use bounded planes plugin
ruffsl opened this issue · 4 comments
When using the bounded planes plugin, an error occurs when retrieving added plane landmarks:
omnimapper/src/plugins/bounded_plane_plugin.cpp
Lines 323 to 327 in f215e35
[omnimapper_ros_node-1] Meas Boundary Map: Boundary Point: -0.099607 -0.045571 0.994434
[omnimapper_ros_node-1] Meas Boundary Map: Boundary Point: -0.098161 -0.045652 0.996211
[omnimapper_ros_node-1] Meas Boundary Map: Boundary Point: -0.096732 -0.047371 0.998222
[omnimapper_ros_node-1] Meas Boundary Map: Boundary Point: -0.096754 -0.049009 0.998450
[omnimapper_ros_node-1] BoundedPlanePlugin: Creating new plane 8070450532247928832: 0.769868 -0.097762 -0.630671 0.699390
[omnimapper_ros_node-1] Adding new symbol: p0
[omnimapper_ros_node-1] terminate called after throwing an instance of 'gtsam::ValuesIncorrectType'
[omnimapper_ros_node-1] what(): Attempting to retrieve value with key "p0", type stored in Values is N10omnimapper13BoundedPlane3IN3pcl12PointXYZRGBAEEE but requested type was N10omnimapper13BoundedPlane3IN3pcl12PointXYZRGBAEEE
The last line is particularly strange as the mangled types are printed using the same string.
Stacktrace:
__GI_raise 0x00007fb4c71eae97
__GI_abort 0x00007fb4c71ec801
<unknown> 0x00007fb4c7841957
<unknown> 0x00007fb4c7847ae6
std::terminate() 0x00007fb4c7847b21
std::rethrow_exception(std::__exception_ptr::exception_ptr) 0x00007fb4c7847ada
<unknown> 0x00007fb4c7b5fd0c
<unknown> 0x00007fb4c7b64e9b
<unknown> 0x00007fb4c7b61790
gtsam::NonlinearFactorGraph::linearize(gtsam::Values const&) const 0x00007fb4c84c1f8c
gtsam::ISAM2::update(gtsam::NonlinearFactorGraph const&, gtsam::Values const&, gtsam::ISAM2UpdateParams const&) 0x00007fb4c848dbc4
gtsam::ISAM2::update(gtsam::NonlinearFactorGraph const&, gtsam::Values const&, std::vector<unsigned long, tbb::tbb_allocator<unsigned long> > const&, boost::optional<gtsam::FastMap<unsigned long, int> > const&, boost::optional<gtsam::FastList<unsigned long> > const&, boost::optional<gtsam::FastList<unsigned long> > const&, bool) 0x00007fb4c848a67c
omnimapper::OmniMapperBase::optimize omnimapper_base.cpp:467
omnimapper::OmniMapperBase::spinOnce omnimapper_base.cpp:657
omnimapper::OmniMapperBase::spin omnimapper_base.cpp:640
boost::_mfi::mf0<void, omnimapper::OmniMapperBase>::operator() mem_fn_template.hpp:49
boost::_bi::list1<boost::_bi::value<omnimapper::OmniMapperBase*> >::operator()<boost::_mfi::mf0<void, omnimapper::OmniMapperBase>, boost::_bi::list0> bind.hpp:259
boost::_bi::bind_t<void, boost::_mfi::mf0<void, omnimapper::OmniMapperBase>, boost::_bi::list1<boost::_bi::value<omnimapper::OmniMapperBase*> > >::operator() bind.hpp:1294
boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, omnimapper::OmniMapperBase>, boost::_bi::list1<boost::_bi::value<omnimapper::OmniMapperBase*> > > >::run thread.hpp:116
<unknown> 0x00007fb4c7d8bbcd
start_thread 0x00007fb4c99806db
clone 0x00007fb4c72cd88f
omnimapper/src/omnimapper_base.cpp
Lines 469 to 470 in f215e35
It'd be nice to have a cleaner stacktrace to work with, but #25 inhibits building against debug gtsam.
My guess is that it has something to do with an API change in gtsam::Value class, that omnimappers derived DerivedValue class isn't accounting for:
Related:
Reading into the ValuesIncorrectType class, it looks like the values are just compared using the typeid call, the used to throw the error if the two are not equivalent:
From the stdio above, we can see the member function name for the two std::type_info references pint out equivalently, so we can check with type_info definition to see what else might be used to define uniqueness.
From peeking at the std C++ lib for std:type_info class, we can see the operator== has three variants for different targets:
- one where uniqueness must uses the
_namevalue - one where some more extensive string comparison over the
_name - and the last where address comparisons are sufficient
At fist I was thinking the hash member function for std::type_info could be returning different digests for instanced being compared, but it doesn't seem like the comparison operator even considers the hash. Does any one know how to find what flags are used when building releases for gcc on debian? That might tell us if the comparisons are deviating by address, given the _name values look the same.
As discussed offline, @xingyc15 will migrate the following gtsam::Value class derivatives:
omnimapper/include/omnimapper/plane.h
Line 54 in 7aaec77
from the previous custom DerivedValue class:
to the GenericValue class now natively supported in GTSAM:
Upon closer inspection of the current Value hear in GTSAM, it seems that Value types should no longer derive from Value or DerivedValue (or GenericValue for that matter), and use type traits instead:
This is described in the tucked away migration guide for GTSAM 3.X to 4.0 in the old bitbucket repo:
@xingyc15 , could you please migrate Plane, BoundedPlane3 types to use the gtsam traits instead?