Open afrixs opened 11 months ago
Thanks for the report. I've confirmed this is an issue with the following process on rolling today.
I ran two talker nodes:
ros2 run demo_nodes_cpp talker --ros-args -r chatter:=chatter1
ros2 run demo_nodes_cpp talker --ros-args -r chatter:=chatter2
I then recorded a bag with ros2 bag record --all
$ ros2 bag info rosbag2_2024_02_16-00_42_25/
Files: rosbag2_2024_02_16-00_42_25_0.mcap
Bag size: 23.2 KiB
Storage id: mcap
ROS Distro: rolling
Duration: 4.99s
Start: Feb 16 2024 00:42:25.111 (1708069345.111)
End: Feb 16 2024 00:42:29.210 (1708069349.210)
Messages: 43
Topic information: Topic: /chatter2 | Type: std_msgs/msg/String | Count: 4 | Serialization Format: cdr
Topic: /chatter1 | Type: std_msgs/msg/String | Count: 4 | Serialization Format: cdr
Topic: /events/write_split | Type: rosbag2_interfaces/msg/WriteSplitEvent | Count: 0 | Serialization Format: cdr
Topic: /parameter_events | Type: rcl_interfaces/msg/ParameterEvent | Count: 0 | Serialization Format: cdr
Topic: /rosout | Type: rcl_interfaces/msg/Log | Count: 35 | Serialization Format: cdr
By default in rolling
, the storage type for bags is mcap
, but LoadFromBag
hard codes the type as sqlite3
.
Thus, trying again with specifying a sqlite3 type:
ros2 bag record --all -s sqlite3
And, finally the test code:
TEST(RosbagHandling, multipleTopics)
{
std::string pathToBag = "/home/ryan/Dev/rosbag2_2024_02_16-00_50_47";
string topic = "chatter1";
GridMap gridMapOut;
rcpputils::fs::path dir(pathToBag);
EXPECT_TRUE(GridMapRosConverter::loadFromBag(pathToBag, topic, gridMapOut));
}
I got this result from colcon test
:
2: [ RUN ] RosbagHandling.multipleTopics
2: [INFO] [1708069934.957041361] [rosbag2_storage]: Opened database '/home/ryan/Dev/rosbag2_2024_02_16-00_50_47/rosbag2_2024_02_16-00_50_47_0.db3' for READ_ONLY.
2:
2: >>> [rcutils|error_handling.c:108] rcutils_set_error_state()
2: This error state is being overwritten:
2:
2: 'Handle's typesupport identifier (rosidl_typesupport_cpp) is not supported by this library, at ./src/type_support_dispatch.hpp:111'
2:
2: with this new error message:
2:
2: 'Fast CDR exception deserializing message of type grid_map_msgs::msg::dds_::GridMap_., at ./src/type_support_common.cpp:118'
2:
2: rcutils_reset_error() should be called after error handling to avoid this.
2: <<<
I've tried determining where it's throwing, but the tutorial I wrote for debugging tests with gdb doesn't isolate it.
But, you can instead just run gdb build/grid_map_ros/grid_map_ros-test
>>> catch throw
>>> run
>>> bt
Thus, it's failing to deserialize, probably because it's the wrong type. This may be a different bug than you saw, but that's obviously wrong and should be fixed.
serialization.deserialize_message(&extracted_serialized_msg, &extracted_gridmap_msg);
I haven't used the rosbag API's, so it may take me a bit to get familiar with it. Anyone is welcome to issue a patch. For some reason, even though building in debug mode, I can't inspect locals.
This reference doesn't help much for getting symbols. https://stackoverflow.com/questions/26581066/how-to-get-backtrace-information-from-exception-in-googletest
I also tried using VSCode to debug grid_map_ros
, but had no luck. Here's the config which has the same issue about no symbols in GridMapRosCoverter.cpp. VSCode ignores breakpoints in there.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/build/grid_map_ros/grid_map_ros-test",
"args": [],
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
}
]
}
I guess that
topic
parameter was meant to be used, e.g.could be added here