Eike

I think OSX dependencies need to be removed in MAVGCL/build.xml, e.g. https://github.com/ecmnet/MAVGCL/blob/2c5ad24bbc0ed75386c909e9490c9d9081da2d04/MAVGCL/build.xml#L20 which point to a maven installation.

mavcom needs to be build separately

@Jaeyoung-Lim Here you are.

Thank you very much.

Thanks for reporting. It seems that the upload to GitHub damages the binary dmg.

Any solution or workaround to this? I experience a similar issue on OSX and Ubuntu using version 1.5.7. Grabbing stops after some minutes at `imgFrame = queue.getImgFrame(); imgFrame.getData().asByteBuffer().get(imageData);` with this...

@saudet Unfortunately not - I see that in this case neither registering nor GC takes place. Python and C++ DepthAI examples work. `Debug: Loading class org.bytedeco.javacpp.BytePointer Stack trace (most recent...

@saudet I tried using the -Xrs option as well as the environment variable settings as described in the document above. Both with no success.

@saudet Tried that also in different ways - even doing it step by step closing all objects immediately does not work. `Debug: Registering org.bytedeco.depthai.ImgFrame[address=0x600002f58f18,position=0,limit=0,capacity=0,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0x60000389dcf0,deallocatorAddress=0x136d5a850]] Debug: Registering org.bytedeco.depthai.RawBuffer[address=0x600000889cc8,position=0,limit=0,capacity=0,deallocator=org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0x60000389fc50,deallocatorAddress=0x136d13d50]] Debug: Releasing org.bytedeco.javacpp.Pointer$NativeDeallocator[ownerAddress=0x60000389dcf0,deallocatorAddress=0x136d5a850]...

An additional observation: Grabbing lives longer (up to 3 mins), when closing each object immediately and using PointerScope enclosing all statements.