Remote ROS2 Coder Deployment: 'libmwnetworkdevice.dyld does not exist'

I am trying to set up a remote deployment of a ROS2 Node to my Linux machine from my Mac, where I am doing my development. I had this previous workflow working well where I would enter the commands below to compile/deploy my node.

cfg = coder.config('exe');
cfg.Hardware = coder.hardware('Robot Operating System 2 (ROS 2)');
cfg.Hardware.BuildAction = 'Build and load';
cfg.Hardware.RemoteDeviceAddress = 'xxx.xxx.xxx.xxx';
cfg.Hardware.RemoteDeviceUsername = 'xxxxxxx';
cfg.Hardware.RemoteDevicePassword = 'xxxxxxx';
cfg.Hardware.DeployTo = 'Remote Device';
cfg.Hardware.ROS2Folder = '/opt/ros/galactic';
cfg.Hardware.ROS2Workspace = '~/uavrt_ws';
cfg.HardwareImplementation.ProdHWDeviceType = 'Intel->x86-64 (Linux 64)';
%Tried adding line below but that didn't help
%cfg.CustomLibrary = '/Applications/MATLAB_R2022b.app/bin/maci64/libmwnetworkdevice.dylib';
cfg.RuntimeChecks = true;%Disable for final deployments.
codegen uavrt_detection -args {} -config cfg

After a few months of doing other work I came back and tried this process again, but I am now getting the following output at the Matlab terminal:

------------------------------------------------------------------------

File 'libmwnetworkdevice.dylib' does not exist.

------------------------------------------------------------------------

??? Build error: C++ compiler produced errors. See the Build Log for further details.

More information

Code generation failed: View Error Report

I think this is a problem on the Mac side. I have tried setting the DYLD_LIBRARY_PATH with:

setenv("DYLD_LIBRARY_PATH",'/Applications/MATLAB_R2022b.app/bin/maci64:/Applications/MATLAB_R2022b.app/sys/os/maci64')

but that didn't resolve the issue. When I click on 'View Error Report' and click on the 'Build Logs' tab, the only line there is: File 'libmwnetworkdevice.dylib' does not exist.

How might I get around this issue? Thanks.

Answer 1

[Michael]

I upgraded to R2023a prerelease, and this issue resolved. This may have been a bug in R2022b...