search

orocos-toolchain / ocl

Orocos Component Library
Other
16 stars 33 forks source link

ReporterComponent failes to decompose ROS data types. #67

Open disRecord opened 6 years ago

disRecord commented 6 years ago

When I tried to log sensor_msg::JointState port with OCL::ReportingComponent I got following output:

TimeStamp file_player.out_joints_fixed.header.seq file_player.out_joints_fixed.header.stamp.sec file_player.out_joints_fixed.header.stamp.nsec file_player.out_joints_fixed.header.frame_id[0] file_player.out_joints_fixed.name.0.0 file_player.out_joints_fixed.name.0.1 file_player.out_joints_fixed.name.0.2 file_player.out_joints_fixed.name.0.3 file_player.out_joints_fixed.name.0.4 file_player.out_joints_fixed.name.0.5 file_player.out_joints_fixed.position.0 file_player.out_joints_fixed.velocity.0 file_player.out_joints_fixed.effort.0
 0.013426   0  0 0    s e r v o 1  0.775381  -1.0239  0.0556217
 0.0225068   0  0 0    s e r v o 1  0.725693  -1.09675  0.0527346
 ...

It is clearly not desired output, especially if servo name can change its length. In the longer session I saw signs of pointer corruption (garbage in name field), but I was unable to quickly reproduce this effect.

It seems the problem is somewhere inside this function: memberDecompose

disRecord commented 6 years ago

I suggest following walkaround: https://github.com/orocos-toolchain/ocl/pull/68 .

meyerj commented 6 years ago

Thanks, I merged the proposed workaround to toolchain-2.9.

Should we keep this issue open until we might find a better solution that either fixes memberDecomposition for ROS types or boosts the performance of decomposeType?

disRecord commented 6 years ago

I positively do not understand how those decomposition functions work so I can only suggest this workaround. But I think the issue should be left open for some time in case someone decides to provide a better solution. Anyway it is not high priority task.