I really like the stereo matching system and integration with Octomap in the default SLAM.dunk stack, but the SLAM system is sub-par, so I would like to replace it with our own hardware-accelerated VIO. I really don’t want to use a different Octomap implementation over the optimized Parrot one, just replace its pose source for the map construction.
Is it possible to do this? The internal Kalamos API seems very untransparent/closed and unsuitable for development.
The kalamos::OccupancyDataPoint seems to be constructed internally. Without being able to modify it, I don’t see how I can achieve what I wrote about (providing my own pose data for octomap construction. I could just rewrite the whole pipeline on my own, that’s not the issue, but since Parrot has done a good job of the overall implementation, it makes sense to expose some more stuff for the developer so that more code can be reused.
I understand that you’re only supporting ROS, but it’s just a wrapper around kalamos-context, and is very limited in what it can do without atleast some basic implementation/modification/access details for kalamos-context.
My intention was to disable the underlying SLAM system and occupancy grid manager such that I can run my own. After compiling the node and starting it instead of the system node however, SLAM and occupancy still seem to run (high CPU load) and the node log shows this on stop :
[ INFO] [1489216967.461305568]: stop capture
@tba Any pointers on how I can get this slimmed down properly and stop it from running everything I don’t need?