Hello!
Me and my team have been using SpectacularAI with an OAK-D W camera, using data fusion with GNSS with a lot of success, but we have run into an issue recently.
We have decided to move the GNSS antenna away from the camera to reduce electrical interference, but we have not been able to assign a value to the config.imuToGnss config option. Without it, there is very significant drift, likely due to discrepancies in data fusion.
When we try to use the vio_gnss.py example with the imuToGnss option enabled (line 73 uncommented), we get the following error:
Traceback (most recent call last):
File "/opt/depthai/spectacular_ai/sdk-examples/python/oak/vio_gnss.py", line 73, in <module>
config.imuToGnss = spectacularAI.Vector3d(0.0, 0.0, 0.0)
RuntimeError: Unable to load a custom holder type from a default-holder instance
The same happens when we try to assign a spectacularAI.Vector3f, a Python list or a Python tuple.
Our best guess is that there is a mistake in the type definition for Python bindings, preventing any valid value from being assigned.
This issue occurs on the latest 1.36.0 version of the SDK, but it also has appeared on many previous versions we have tried.
We are hoping this issue won't be difficult to resolve and are happy to provide any extra information necessary!
Hello! Me and my team have been using SpectacularAI with an OAK-D W camera, using data fusion with GNSS with a lot of success, but we have run into an issue recently. We have decided to move the GNSS antenna away from the camera to reduce electrical interference, but we have not been able to assign a value to the
config.imuToGnss
config option. Without it, there is very significant drift, likely due to discrepancies in data fusion.When we try to use the
vio_gnss.py
example with theimuToGnss
option enabled (line 73 uncommented), we get the following error:The same happens when we try to assign a
spectacularAI.Vector3f
, a Python list or a Python tuple.Our best guess is that there is a mistake in the type definition for Python bindings, preventing any valid value from being assigned. This issue occurs on the latest 1.36.0 version of the SDK, but it also has appeared on many previous versions we have tried.
We are hoping this issue won't be difficult to resolve and are happy to provide any extra information necessary!