Coder ROS2 Build Error (colcon) with Custom ROS2 Message

I have a custom ROS2 message that am integrating into a Matlab function that is getting deployed on a remote Linux maching using Coder. During the 'colcon build' step of the Coder execution, I am getting the error:

error: cannot convert 'struct_T*' to 'const uavrt_interfaces_PulseStruct_T*'

82 | MATLABROS2Publisher_publish(pulsePub.PublisherHelper, &pulseMsg);

| ^~~~~~~~~

| |

| struct_T*

The rest of the terminal output after this is at the bottom of this message. My minimally functional Matlab function is below. The error is associated the C++ line of code that corresponds to the send(pulsePub,pulseMsg) line in my Matlab function. It seems to be upset about the type of pulseMsg, but that variable is defined as a ros2message earlier in my code. Below, I have also include the custom ROS2 message definition for Pulse.msg. I have also included the commands I use for using Coder. What is frustrating is that was working a few weeks ago and I can't seem to figure out what changed to cause colcon to error out.

MATLAB Function:

function [] = uavrt_detection_debug()

 %#codegen

% ROS2 Setup
ros2Enable = true; %Hard coded switch so that can be ROS2 can be turned off for testing/debugging
if ros2Enable
    fprintf("Preparing ROS2 Node and Messages...")
    node = ros2node("detector",0);
    pulsePub = ros2publisher(node,"/pulse","uavrt_interfaces/Pulse");
    pulseMsg = ros2message(pulsePub);
    fprintf("complete.\n")
end
pulseCount = 1;
ID = num2str(564321);
for i = 1:5
    %Set pulseMsg parameters for sending
    pulseMsg.detector_id        = char(ID);
    pulseMsg.frequency          = 1;
    pulseMsg.start_time.sec             = int32(1);
    pulseMsg.start_time.nanosec         = uint32(1);
    pulseMsg.end_time.sec               = int32(1);
    pulseMsg.end_time.nanosec           = uint32(1);
    pulseMsg.predict_next_start.sec     = int32(1);
    pulseMsg.predict_next_start.nanosec = uint32(1);
    pulseMsg.predict_next_end.sec       = int32(1);
    pulseMsg.predict_next_end.nanosec   = uint32(1);
    pulseMsg.snr                = 100;
    pulseMsg.dft_real           = 2;
    pulseMsg.dft_imag           = 3;
    pulseMsg.group_ind          = uint16(3);
    pulseMsg.group_SNR          = 123;
    pulseMsg.detection_status   = true;
    pulseMsg.confirmed_status   = false;
    send(pulsePub,pulseMsg)
    pulseCount = pulseCount+1;
    pause(1);
    fprintf('Transmitted a pulse...\n')
end
fprintf('Complete.\n')

end

The ROS2 Pulse.msg Definition:

# This is our custom message for pulses

string detector_id
float64 frequency
builtin_interfaces/Time start_time
builtin_interfaces/Time end_time
builtin_interfaces/Time predict_next_start
builtin_interfaces/Time predict_next_end
float64 snr
float64 snr_per_sample
float64 psd_sn
float64 psd_n
float64 dft_real
float64 dft_imag
uint16 group_ind
float64 group_snr
bool detection_status
bool confirmed_status

 

Code Generation Commands:

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'; % IP Address of target machine
cfg.Hardware.RemoteDeviceUsername = 'XXXXXXX'; % Login credentials of target machine
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)';
cfg.RuntimeChecks = true;%Disable for final deployments.
codegen uavrt_detection_debug -args {} -config cfg

The error is that shows up in the Matlab Terminal:

/home/dasl/uavrt_ws/src/uavrt_detection_debug/src/uavrt_detection_debug.cpp:82:59: error: cannot convert 'struct_T*' to 'const uavrt_interfaces_PulseStruct_T*'

82 | MATLABROS2Publisher_publish(pulsePub.PublisherHelper, &pulseMsg);

| ^~~~~~~~~

| |

| struct_T*

/home/dasl/uavrt_ws/src/uavrt_detection_debug/include/uavrt_detection_debug/mlros2_pub.h:15:65: note: in definition of macro 'MATLABROS2Publisher_publish'

15 | #define MATLABROS2Publisher_publish(obj,structPtr) obj->publish(structPtr)

| ^~~~~~~~~

/home/dasl/uavrt_ws/src/uavrt_detection_debug/include/uavrt_detection_debug/mlros2_pub.h:50:37: note: initializing argument 1 of 'void MATLABROS2Publisher<MsgType, StructType>::publish(const StructType*) [with MsgType = uavrt_interfaces::msg::Pulse_<std::allocator<void> >; StructType = uavrt_interfaces_PulseStruct_T]'

50 | void publish(const StructType *msgStructPtr) {

| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~

make[2]: *** [CMakeFiles/uavrt_detection_debug.dir/build.make:144: CMakeFiles/uavrt_detection_debug.dir/src/uavrt_detection_debug.cpp.o] Error 1

make[2]: *** Waiting for unfinished jobs....

make[1]: *** [CMakeFiles/Makefile2:81: CMakeFiles/uavrt_detection_debug.dir/all] Error 2

make: *** [Makefile:144: all] Error 2

---

Failed <<< uavrt_detection_debug [8.34s, exited with code 2]

Summary: 1 package finished [10.4s]

1 package failed: uavrt_detection_debug

1 package had stderr output: uavrt_detection_debug

??? The following error occurred during deployment to your hardware board:

Build unsuccessful for model 'uavrt_detection_debug'. Check the build log in the diagnostics viewer for error

messages.

Answer 1

[Karthik Reddy Vennapureddy]

Hi Michael,

Thank you for providing the custom message definition and necessary scripts to reproduce the issue. I have investigated this and found that there is issue in MATLAB Function: uavrt_detection_debug(). Please change the following line

pulseMsg.group_SNR = 123;

to

pulseMsg.group_snr = 123;

As ros2message is a MATLAB struct, it just appends any new field (group_SNR) to existing struct containing a field (group_snr) and uses the default values. Here, in the custom message definition, there is field group_snr but no such field group_SNR, which is the root cause leading to the build failure.

Let us know, if you still face issues after doing the suggested change.

Thanks,

Karthik Reddy

[Michael]

Karthik,

That was the problem. Thanks! A simple case error. I am now past that error, but when I go back to my main program (the expanded verion of the simple uavrt_detection_debug() case above), the code generation is successful to the point of colcon build, but when it gets to the build colcon build stage it fails because of a makefile error that I can't seem to figure out because there is very little diagnostic information in the error. Here is what I am seeing at the end of the sterr.log file within my uavrt_ws/log/build_<timestamp>/uavrt_detection.

:

:

warnings that I can ignore

:

:

make[2]: *** [CMakeFiles/uavrt_detection.dir/build.make:1106: CMakeFiles/uavrt_detection.dir/src/ros2node.cpp.o] Error 1

make[2]: *** Waiting for unfinished jobs....

make[1]: *** [CMakeFiles/Makefile2:81: CMakeFiles/uavrt_detection.dir/all] Error 2

make: *** [Makefile:144: all] Error 2

Do you have any idea what this error is related to? I have attached a zip of the CMakeFiles directory from within uavrt_ws/build/uavrt_detection. I did get in a look at the CMakeFiles/uavrt_detection.dir/src/ directory. that seems to be causeing the first error. I am seeing a lot of .o files, but not ros2node.cpp.o. It seems to be missing, which is likely the cause of the error. How might fix this?

[Karthik Reddy Vennapureddy]

Hi Michael,

Could you attach the latest build_log "stdout_sterr.log" file from ~/uavrt_ws/log/build_<timestamp>/uavrt_detection directory

Thanks,

Karthik Reddy

[Michael]

Here it is. Thanks. I had to change the file extension to .txt because Matlab Answers didn't like .log files for attachments.

[Karthik Reddy Vennapureddy]

Hi Michael,

The error in the log is as follows:

/home/dasl/uavrt_ws/src/uavrt_detection/src/ros2node.cpp:25:21: error: 'getGlobalNodeHandle' was not declared in this scope; did you mean 'MATLAB::getGlobalNodeHandle'? 25 | obj->NodeHandle = getGlobalNodeHandle; | ^~~~~~~~~~~~~~~~~~~

This issue is addressed and fix is already available in R2022a_update3. It's a minor bug fix, you can change the following:

1. edit ros.internal.codegen.ros2node
2. Go to constructor of the class
3. change

obj.NodeHandle = coder.opaque('rclcpp::Node::SharedPtr','getGlobalNodeHandle','HeaderFile','mlros2_node.h');

to

obj.NodeHandle = coder.opaque('rclcpp::Node::SharedPtr','HeaderFile','mlros2_node.h');

4. Regenerate the code

Thanks,

Karthik Reddy

[Michael]

Okay. This is good to know. I haven't tried this your solution with R2022a because I thought it might be a bug and installed R2022b while I was waiting for you to responds. Unfortunately, that install broke my ability to use custom ros2 messages, which means I can't check this solution. I have a separate question posted about that issue now here: https://www.mathworks.com/matlabcentral/answers/1836538-ros2genmsg-error-when-updating-to-r2022b

[Michael]

Okay - now that the custom message is resolved - I'm back to this issue. I am getting the same error using R2022b. I see

/home/dasl/uavrt_ws/src/uavrt_detection/src/ros2node.cpp: In member function 'coder::ros2node* coder::ros2node::init()':

/home/dasl/uavrt_ws/src/uavrt_detection/src/ros2node.cpp:24:21: error: 'getGlobalNodeHandle' was not declared in this scope; did you mean 'MATLAB::getGlobalNodeHandle'?

24 | obj->NodeHandle = getGlobalNodeHandle;

| ^~~~~~~~~~~~~~~~~~~

| MATLAB::getGlobalNodeHandle

In my stdout_stderr.log file for this build.

@Karthik Reddy Vennapureddy As you instructed, I edited ros.internal.codegen.ros2node on my Mac and it now is working. Can you please let me know why, if this was addressed in R2022a_update3 it is still an issue for me in my newly installed R2022b? I am afraid the next time I go do a fresh install of Matlab I'm going to run into this same issue.

[Michael]

@Karthik Reddy Vennapureddy Any update on why this might still be happening on R2022b when it was supposed to be fixed in R2022a? Thanks.

[Karthik Reddy Vennapureddy]

Hi Michael,

This issue is addressed as part of R2022b_update4 and R2022a_update3. Could you please update your MATLAB R2022b to update4. Note that, this fix is available in R2023a as well.

Thanks,

Karthik Reddy