DDS Integration general

[leshy]

How do we actually integrate DDS In general?

Unfortunate way

Do we just have G1Connection?

class G1Connection(Module):
    cmd_vel: Out[Twist]
    lidar: Out[PointCloud2]

... does dds comms internally, the way go2 connection does webrtc

In the case above we are sad, DDS isn't integrated as a proper dimos transport

Fortunate way

Does DDS between robots/manufacturers generally use the same format for common messages, like are those PointCloud2, Image types from ROS? can we have a generic DDSTransport that will accept these common messages across robots?

In case above we could treat third party robots just as dimos modules, subscribe to their topics, let our local_planner send Twist to them?

something like

local_planner.cmd_vel.transport = DDSTransport("/twist", robot_ip, or_however_you_configure_this, qos=something)

or like https://github.com/dimensionalOS/dimos/blob/dev/dimos/robot/unitree_webrtc/unitree_go2_blueprints.py#L114
we can map out known robot topics in a blueprint something like this (the way we do in unitree for detections)

    .transports(
        {
            ("cmd_vel", LocalPlanner): DDSTransport
                "/ddstopic", Twist, robot_ip
            ),
     ...
     )

if we use this DDS transport for our own modules
https://github.com/dimensionalOS/dimos/blob/dev/docs/concepts/modules.md

camera.color_image.transport = DDSTransport("/color_image")
detector.image.connect(camera.color_image)

dds transports here internally parses DDS messages into standard dimos Images within modules
would this /color_image topic be the same format as other robots DDS camera topics?

Robot specific messages

I'm sure robots will have their own specific DDS messages, how do we integrate those smoothly?

Ros

Ros uses DDS internally, rclpy is it's interface towards it. rclpy is annoying since it requires full ros installation and ubuntu.
Is it possible to go further and speak DDS to actual ROS? without rclpy dependency? this would allow us to easily talk to ros dockers

Docs

https://github.com/dimensionalOS/dimos/blob/dev/docs/concepts/transports.md (has some formatting issues, PR appreciated)
https://github.com/dimensionalOS/dimos/blob/dev/docs/concepts/lcm.md

[linear]

DIM-367

[jeff-hykin]

A few things I want to confirm on my end

I'm sure robots will have their own specific DDS messages, how do we integrate those smoothly?

If they don't fit nicely into existing msgs I'm going to add msgs/dds/<thing>.py and/or a CustomDDS type (allows any message structure) since people can define their own message types. Does that sound okay for a first PR? If they fit into existing types I'll have a to_dds and from_dds method on the existing type.

2. (Most important) So basically this task is done when we can connect to a robot that uses DDS natively (let's say the G1) by doing basically what you described:

class MyModule(Module):
    stream1 : In[MaybeCustomRobotType] = None
    stream2 : Out[MaybeCustomType] = None
    
    def start(self):
        self.stream1.subscribe(lambda *args: print(args))
        self.stream2.publish(MaybeCustomType())

mod1 = MyModule.blueprint()
mod1.stream1.transport = DDSTransport("/twist", robot_ip, or_however_you_configure_this, qos=something)

# and also works with

autoconnect(
    mod1,
).transports(
        {
            ("cmd_vel", LocalPlanner): DDSTransport
                "/ddstopic", Twist, robot_ip
            ),
     ...
     )

3. Theres no expection for ROS or rclpy in this next PR, thats just a footnote / future thing
4. Confirming: if it makes sense, I have the flexibility/freedom to add stuff like:

• Adding a global config for a default DDS IP address (kind of like LCM's default address / port)

• enabling default DDS topic selection like:

class Mod1(Module):
    stream1 : In[RobotType1] = DefaultTransport(DDSTransport("/source1", *args)) 

autoconnect(
    Mod1.blueprint(),
) # transport can be overridden but defaults to specific dds topic

If those are all good, I'll have no problem knocking this out.

[spomichter]

Yeah so the approach I prefer here ALWAYS uses normal dimOS types in the module Twist2 etc and relegates the DDS stuff to the blueprint .transport as @leshy suggested like below:

    .transports(
        {
            ("cmd_vel", LocalPlanner): DDSTransport
                "/ddstopic", Twist, robot_ip
            ),
     ...
     )

[leshy]

If they don't fit nicely into existing msgs I'm going to add msgs/dds/<thing>.py and/or a CustomDDS type (allows any message structure) since people can define their own message types. Does that sound okay for a first PR? If they fit into existing types I'll have a to_dds and from_dds method on the existing type.

If they are robot specific and dds is hidden behind a module, we should have the defs under robot integrations not in dimos/msgs since they aren't shared

(Most important) So basically this task is done when we can connect to a robot that uses DDS natively (let's say the G1) by doing basically what you described:

yes given dds turns out to be universal enough between robots that we can write a generic transport

Theres no expection for ROS or rclpy in this next PR, thats just a footnote / future thing

No, but should investigate how ros dds types relate to other dds types just as a part of general dds investigation

Adding a global config for a default DDS IP address (kind of like LCM's default address / port)

yeah that's ok

enabling default DDS topic selection like:

this is a heavy intervetntion into core so out of scope. modules have no knowledge on transports and this is configured externally atm

[jeff-hykin]

Wonderful 👌, so in terms of testing message types; does supporting all the message types for the G1 sound good enough for this first PR?

BTW Miguel finished DDSTransport yesterday morning, including adding the system dependency to the flake, so docs for DDS and adding message type support are basically the only things left on this task.

[jeff-hykin]

@leshy TLDR discussuion we had with Stash last night:

• All DDS messages are custom. Its not like LCM or ROS, there are no standard messages. They're all defined per project with idl types (or just dynamic, no static type information). For the G1 specifically; adding support for G1 messages would not save us any time if we, lets say, wanted to control Booster with DDS (basically zero message type overlap)
• Right now, controlling the G1 via DDS (instead of their SDK) is extremely costly/ low benefit/ low priority because we loose access to high state (even though there are high state DDS messages). The issue is, the SDK is doing extra work using a binary to generate those messages. We would have to reimplemet their black-box message generator to keep high-state functioning. There are other reasons too (they could push updates to their SDK and DDS types, breaking our re-implementation of their black box), but loss of high state is the big one. Eventually won't use their binaries, but definitely not by public release.

So, DDS transport is in Miguels PR, but support for G1 or any particular message types should almost certainly wait till after public release.