qootec's profile - activity

overview network karma followed questions activity

2021-01-26 10:22:23 -0500	received badge	● Student (source)
2020-04-06 16:25:09 -0500	received badge	● Famous Question (source)
2020-01-20 09:55:34 -0500	received badge	● Famous Question (source)
2020-01-13 19:13:12 -0500	received badge	● Famous Question (source)
2020-01-13 19:13:12 -0500	received badge	● Notable Question (source)
2019-12-27 13:36:14 -0500	received badge	● Notable Question (source)
2019-12-09 03:44:16 -0500	received badge	● Famous Question (source)
2019-10-04 09:20:57 -0500	received badge	● Notable Question (source)
2019-09-19 22:35:42 -0500	received badge	● Popular Question (source)
2019-09-17 05:06:29 -0500	commented question	ROS2, Micro-ROS & intra-process Hmmm, when trying to post to discourse, their forum indicates that questions need to go to answers.ros.org anyway, so no
2019-09-17 05:00:45 -0500	commented question	ROS2, Micro-ROS & intra-process My mistake, they point to https://discourse.ros.org/c/embedded as the most suitable location. I guess I shouldn't be cro
2019-09-17 03:48:05 -0500	received badge	● Popular Question (source)
2019-09-17 03:24:18 -0500	asked a question	ROS2, Micro-ROS & intra-process ROS2, Micro-ROS & intra-process Dear (Micro-)ROS developers, From an applied research point of view, we are interes
2019-09-13 03:03:08 -0500	received badge	● Popular Question (source)
2019-09-13 03:02:21 -0500	marked best answer	ROS2 serialization ConnextStaticSerializedData Environment: ROS2 Dashing Patch 2 Windows 10 messages based on msg files (no idl yet, since I can't seem that to get that operational) RTI Connext DDS 5.3.1 Reproduction: Create a custom message type and a Publisher & Subscriber for it. Start your nodes Expected behavior: They communicate - ok they do. Their type is observable through RTI's Admin Console Observed behavior: The topic's type is not observable through RTI's Admin Console. Instead, Admin Console reports the type as "ConnextStaticSerializedData". Consequentially, the Admin Console shows shows only partial matches (conflicting data type). Even loading data types from XML (supported by RTI Admin Console) is not accepted (could be my mistake). Question(s): Does this mean that ROS2 is using non-standard serialisation? Looking at the code it seems that serialisation happens independently in the ROS2 RMW layer and is then submitted as a serialized packet to a topic typed by ConnextStaticSerializedData, whatever the original type. This happens for custom types, but e.g. not for the rq/…/list_parametersRequest and other built-in types. Any way to avoid this behavior? It is quite annoying from an interoperability point of view (Admin console, but also other non ROS2 DDS-based applications). Does the behavior change when I would use IDL instead of msg files? I didn't find a way to get that working although it should work on Dashing. Thanks, Johan
2019-09-13 03:02:21 -0500	received badge	● Scholar (source)
2019-09-13 02:59:15 -0500	received badge	● Popular Question (source)
2019-09-13 02:59:15 -0500	received badge	● Notable Question (source)
2019-09-10 08:48:04 -0500	received badge	● Supporter (source)
2019-09-10 08:47:55 -0500	commented answer	ROS2 serialization ConnextStaticSerializedData Hi Karsten, thanks for your extensive answer. (from my question) It is quite annoying from an interoperability point
2019-09-09 08:08:05 -0500	asked a question	ROS2 disables local shmem ROS2 disables local shmem Environment: ROS2 Dashing Patch 2 Windows 10 RTI Connext DDS No customizations of DDS layer
2019-09-09 03:49:15 -0500	asked a question	ROS2 serialization ConnextStaticSerializedData ROS2 serialization ConnextStaticSerializedData Environment: ROS2 Dashing Patch 2 Windows 10 messages based on msg file
2019-06-17 17:32:41 -0500	asked a question	ROS2 DD - debug release fails to create process ROS2 DD - debug release fails to create process Platform: ROS 2 Dashing Diademata, patch 1, debug version from here Wi