Hello,
I tried to get turtlesim to initialize with FastDDS’ typelookup_config.use_server set to true, so I could gather information about topics via DDS readers/writers and on demand get typeinformation/TypeObjects to instantiate dynamic types and get involved.
But I didn’t manage to find out how to accomplish this. Plus, there are a couple of relevant questions about basic facts, I seem not to be able to find the answers to.
(For now, I’ll devise some systematic manner in which to gather the idl-files from our ros projects, process them with fastddsgen, and generate some code for the results to end up with some library to retrieve dynamic types by name. Something new for me to learn too, but I’ll manage. Long term, though, that’s not good enough for me.)
Motivation:
Our company (Framework Robotics GmbH) has developed a framework/modular design (mechanical structure, internal power distribution, internal communication) to build ROVs, stationary devices for now, later autonomous robots also. The software side is just developing, but meant to cater to the goal to offer bespoke devices.
This means we’ll end up with an ever growing assortment of ros projects for different actor and sensor modules and stuff.
The way to go with the mission control gui application would be for it to not be specific to any particular device configuration in any way. There shouldn’t be any module-fleet driven knowledge maintenance required either. There should just be some form of configuration data - provided alongside the assembled device - that may be as fuzzy on topic identification and description as useful and practical and contain information on how to present everything either script-ish or descriptive (I’m not there, yet). (Well documented of course - the user shall be enabled to reconfigure the whole device.)
Currently working on:
A library to be used by the mission control app, that gathers information from the network, sorts DDS topics into representations of ros topics, services, actions, parameter interfaces (is there an established name for this one?), and recognizes the special ones like ros discovery or rosout. On demand those entities would be setup for use. As said before, for now I’ll try to enable it by providing it with a dynamic type lookup library.
Next iteration/future plans - extending ROS2:
Ideally ROS2 would have easy enough to enable functionality, so that ros’ dds participants would hold the necessary information on the static topics in use to be able to serve up typeinformation and TypeObjects on those on request via FastDDS’ typelookup functionality and to enable the latter. The needed information would than only be needed to be maintained, where it’s defined, and still be available to those that do not know beforehand, whom they would be dealing with later on. The library I’m currently working on would be more readily be useful to others, too.
Early preparation/fact check/thoughts:
(I tried to find out myself, but - at least to me - dds and ros’ middleware are to complex to just look things up in source code, and I couldn’t find matching examples or answered questions no matter how hard or long I tried. I hope you chime in.)
Basic questions:
The most critical question with which this whole thing stands or falls; [DDS] Can a message created with a dynamic type be on-the-wire indistinguishable from a message created with a static type? (I guess, I’ll find out soon enough.)
I’m not even clear on whether FastDDS’ dynamic types are a way to dynamically handle normal DDS topics (too) or if it’s only about DDS XTypes.
Expected TODOs?:
Which parts of the ROS2 framework would one need to touch? What parts that aren’t in there yet might need to be fleshed out?
My guesses would be ros’ FastDDS specific middleware and/or FastDDS’ XML parser to give the ros user the option to enable the typelookup stuff and additions to the build process to create and equip the compilation with the information to send out on typelookup requests. I haven’t developed enough trusted understanding, yet, to get more concrete than that on my own at the moment.
Also, would you say this was something to add to mainstream ROS2 or should that rather be done in a fork to be maintained separately?
As I see it, this undertaking requires some deeper studying of ros’ missleware salad and the FastDDS implementation. So for me that’s something for later - I first need to develop something usable with what’s already there.
I hope some of you see some value in what I’d like to do and we gather some needed information and ideas here.
Regards,
Michael
Disclaimer:
I’m utterly new to ROS and also to DDS, i.e. that’s the first thing I try to do with it. And at the moment I’m rather confused and dizzy. So I fear this wall of text is not very polished or concise. Sorry for that.
Also, I had already asked a less ambitious/informed question on Answers in this regard:
https://answers.ros.org/question/377775/how-to-enable-fastdds-typelookup-functionality/