ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Intro - Brandon from OpenCV AI Kit

Hi everyone, Brandon from the OpenCV AI Kit team here!

I just wanted to pop in to say hi as Josh Whitley recommended I reach out here!

For quick background, we’re working on a PoE variant of the OpenCV AI Kit (more on that here).

We’re relatively new to ROS overall, but excited to learn more and get easy integration.

Our USB variants of OAK-1 and OAK-D already have ROS2 support - see here.

And for our Power Over Ethernet (PoE) variant, we are wanting to make it show up in ROS2 automagically when on the same network as ROS2.

So based on John Whitley’s advice, we’re going to see about porting Micro-ROS directly to the platform.

So if you see me around asking n00b questions, that’s why. :slight_smile:



Hi Brandon,

This sounds like an excellent idea! And I’m looking forward to hearing how this project goes.

We did some work trying to do something similar with Micro-ROS back in June and we concluded the following from our side

  • Changing the IP address of the Agent required to reconfigure/rebuild micro-ROS
  • The need of the broker (agent) on a fixed IP address (plus previous point) sort of loses the idea of plug and play
  • The QoS settings available on the constraint DDS, at the time, were very limited
  • There’s only one vendor for the XRCE implementation

Just to point out what were we working with:

  • STM32 (different varieties)
  • FreeRTOS
  • NUTTX (Just to compare)
  • Laser scan data

Nonetheless, everything would be possible to be done, we unfortunately just didn’t have the resources to commit to polishing this work better.

A few things more to have in mind.

  • It was prior to the Foxy release, we haven’t seen what updates have been made since June.
  • We tried to use fastDDS or cycloneDDS, but we would end-up without enough resources on our system. Thus, if you’re on a constraint system, micro-ROS is the way.
  • I’d like to add that the micro-ROS developers were very helpful with any of our inquiries.

Hi @mrbhjv,

Thanks for the data! This is super helpful.

So to contribute back from our learning offline (from Joe Speed, thanks, Joe!):

In a couple weeks Eclipse Foundation is releasing cyclonedds+zenoh as a microROS drop-in replacement for XRCE.

But you may not need microROS in OAK. You can instead run cyclonedds (1/2MB RAM) or zenoh (10s of KBs) in OAK

So we will be digging into these soon. They seem like great solutions for direct support (and so may be great for you as well @mrbhjv).

Thanks again,


Hi @Luxonis-Brandon,

Thanks for sharing such info. Really looking forward to see how it looks like and trying it out! At first glance it does seem to do what we needed. We’ll be most certainly giving it a spin.

I’m really looking forward to having on of those OAK in hand!


Thanks @mrbhjv. We are looking forward to trying this out as well.

And thanks, we’re heads-down working to delivery the KickStarter ASAP. Iterating now on the aluminum enclosures that will now come with the KickStarter units because of the KickStarter surpassing $1 million in funding.

We’re not sold on this look for OAK-1 yet. Continuing to iterate.


1 Like

Hi @Luxonis-Brandon,

XRCE-DDS is an official standard of the OMG, with the support of all OMG members of the DDS WG, but Adlink. You have available our implementation (open source), and also RTI has developed its own implementation, and more are coming. Perhaps @GerardoPardo could want to add something.

Let me answer also @mrbhjv points briefly (Pablo from the Micro-ROS team will write also a detailed response):

1.- Changing the IP address at runtime: Totally possible. I think you tested a non updated version of Micro-ROS.
2.- Broker on a Fixed IP: Again, not necessary, you have a discovery mechanism for the Agent.
3.- QoS: You have all the Fast DDS QoS available.
4.- Both eProsima and RTI implement the XRCE-DDS standard. More to come.

Micro-ROS is a common project between eProsima, Bosch, PIAP, and the FIWARE Foundation, with more than 4M Eur of funding, based on standards, and we have alliances and support for the following platforms:

  • FreeRTOS
  • Zephyr
  • Canonical
  • NuttX
  • WindRiver (VxWorks)
  • PX4

And more are coming. So you are right, Micro-ROS is the way to go, supported already by many important organizations and based in OMG standards, and with a long history (our implementation of XRCE-DDS is now 4 years old).

You have very good documentation and examples of Micro-ROS and XRCE-DDS here:

Please let us know if you need some guidance.

PD: On the contrary, Zenoh is just promoted by one organization, they tried to standardize the protocol at the OMG and they failed, with massive support to XRCE-DDS as a better option (12 votes to 1), with basically no activity since then (5 years ago), no users, no community, lack of docs, and no support.

1 Like

Hello everyone,

Regarding the points @Jaime_Martin_Losa have mentioned:

  1. You can find a micro-ROS RMW userspace configuration API example here
  2. The plug and play features are implemented in the micro-ROS middleware (Micro XRCE-DDS Client) with a discovery agent. Information about this dynamic discovery process can be found here. Currently, this discovery features are not implemented in the micro-ROS RMW configuration API but this can be integrated soon if there is some use case.
  3. micro-ROS has two modes for creating DDS entities in the agent:
    Default mode (internally uses XML): where only DDS best-effort or reliable QoS can be selected. Check RCLC API for the default profiles.
    Reference mode: where DDS QoS can be fully defined in the agent side and the client provides a reference to this description.
    To clarify these concepts, we are going to create a new tutorial in micro-ROS webpage. Check this issue for more information in the following days.

UPDATE 26/8/2020: Here you can find the tutorial on how to customize DDS QoS in micro-ROS

Hi @Jaime_Martin_Losa,

Thanks for the very detailed response! A lot for us to digest.

So we have two independent, in-development product lines that will benefit from microROS:

  1. OAK-D-WIFI, which has built-in ESP32:

  2. OAK-1-POE, OAK-D-POE:

So in case 1, microROS would run on the ESP32 itself. So it seems this will be cleanly supported from ongoing community work I see.

On the POE version, the Etherent is direct to the Myriad X. So we would port microROS for our custom firmware/OS (RTEMS based).

@jngai wrote the ROS2 wrapper for our Python API here:

And @saching13 is super excited to play with microROS. His ears perked up when he heard about this and he mentioned how he looks forward to helping with this integration work.

Hi @pablogs,

Awesome, thanks! I’m asking Jon and Sachin for their ROS Discourse handles and will tag them directly here as well to bring them into the conversation as well when I get them. :slight_smile: (And I shared the link to this internally in our slack as well.)

Super useful information - thank you!

Thanks again,

Just tagged @saching13 and @jngai . As mentioned above, @jngai has been doing ROS2 support for the USB variants of OAK, and @saching13 will be working with microROS once we finish some calibration improvements and some API improvements/etc. on the USB variants.

We have been digging into using Zenoh in ROS for the past month or two. Get in touch if you’re interested.

Thank you. Yes, we will likely do so. :slight_smile: