Ask Your Question
0

How to automate inclusion of custom message types into MicroROS Agent build?

asked 2022-05-11 21:14:42 -0500

updated 2022-05-11 23:16:08 -0500

While adding my own custom message type, I'd like to automate the creation of the custom agent package within my existing source tree, without having to invoke the create_agent_ws.sh, build_agent_ws.sh etc files as an out-of-band task.

I can't seem to find any integration (or example) of this in the colcon-cmake mixin. Based on the micro_ros_setup repository, to add a custom message type to the agent, one must update the agent_uros_package.repos file to add a link to the new message package. However, that requires maintaining a forked micro_ros_setup repository for just that one .repos file, which I definitely don't want to do (for numerous reasons).

I'd like to be able to inject these additional message types into the agent build, using a similar approach as is exposed by the micro_ros_arduino and micro_ros_platformio packages (i.e, to add an extra_packages.repos file, and/or extra package folders). Presumably, this would require a wrapper package -- let's call it my_agent_builder -- and a custom cmake function that would associate those steps with the build target, and would have the following layout:

my_agent_builder\
   extra_packages\
      <package1>\
      <package2>\
      ...
      extra_repos.repos
   CMakeLists.txt        <== Some custom function to integrate extra packages into the agent build?

Questions:

  • Is there any existing example or implementation of this that I could use? Github link would be awesome.
  • If not, could someone be so kind as to post such an example?
  • If not, is such a colcon mix-in being planned for development?
  • Am I overlooking a simpler way of including all this into a colcon build task/target?
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-05-12 00:27:01 -0500

Pablogs gravatar image

The micro-ROS agent does not need any kind of type description or msg package in order to work. What is the rationale of your proposal?

edit flag offensive delete link more

Comments

I've seen this more. There seems to be some confusion over how the Agent actually works.

Some people assume it's like ros1_bridge. It's not. It's completely transparent.

gvdhoorn gravatar image gvdhoorn  ( 2022-05-12 02:21:50 -0500 )edit

My understanding (which could be mistaken) was that the micro-ROS agent needs to be "aware" of any new message/service types that the micro-ROS client has been compiled with, in order to be able to allow the client to publish/subscribe and invoke/respond to custom message types to/from the ROS2 network. So, let's say I add a new service type -- MyCustomService.srv -- and I've compiled that into the libmicro_ros_platformio static library (to be flashed onto my MCU). Do I need to build the agent to be aware of that extra service type? Or do I just need to make sure that custom package is sourced into the agent's shell environment before launching the agent? If the agent does not need any type/msg information, why is a separate agent workspace being created in the tutorials, for creating/building an agent? And, why is there no ...(more)

alikureishy gravatar image alikureishy  ( 2022-05-12 12:44:06 -0500 )edit

My understanding (which could be mistaken) was that the micro-ROS agent needs to be "aware" of any new message/service types that the micro-ROS client has been compiled with, in order to be able to allow the client to publish/subscribe and invoke/respond to custom message types to/from the ROS2 network

No, that's how ros1_bridge works.

Do I need to build the agent to be aware of that extra service type?

no.

Or do I just need to make sure that custom package is sourced into the agent's shell environment before launching the agent?

Neither.

If the agent does not need any type/msg information, [..]?

I'll leave the rest for @Pablogs.

gvdhoorn gravatar image gvdhoorn  ( 2022-05-12 13:40:13 -0500 )edit

In general, none of those ideas are correct. The micro-ROS Agest is a bridge that does not serialize or deserialize any message, it just forwards the binary payload from one scope to another.

You do no need to source anything. The only place where your customs should be sourced is in the ROS 2 end where your apps uses and interfaces with the custom type.

In the tutorials the agent is built in a separate workspace in order to maintain a certain order, but you can build it wherever you want as every ROS 2 package.

It will be in your APT repos for binary installation soon, we are working on that.

Pablogs gravatar image Pablogs  ( 2022-05-13 00:45:27 -0500 )edit

Thanks @Pablogs and @gvdhoorn, for the prompt responses.

@Pablogs - Thanks for clarifying this! It's great that this will soon be available via apt repos! I will be awaiting that. Any idea when it might make it in? Given this information, I feel the documentation in micro-ros was rather confusing, and sent me down a very time consuming rabbit hole. If custom types are not required for the agent to function, and if the agent is agnostic of the RTOS being used, the emphasis on create_agent_ws/build_agent_ws, and their inclusion under each of the RTOS-specific tutorials, seems unnecessary. Might I suggest moving the agent installation out into a separate section, and perhaps making it simpler? For example, I was able to get it to compile merely by adding 3 package dependencies -- micro-ros-agent, micro-ros-msgs and drive-base -- into my "meta" package and cloning those reps into my workspace before colcon build.

alikureishy gravatar image alikureishy  ( 2022-05-13 11:01:54 -0500 )edit

I personally don't build the Agent from source, I use the Docker image:

docker run -it --rm --net=host microros/micro-ros-agent:galactic <your args>

as it is a transparent bridge, there isn't really any need to build it in a workspace. Unless you don't want to / can't use Docker.

gvdhoorn gravatar image gvdhoorn  ( 2022-05-13 11:59:32 -0500 )edit

Thanks @gvdhoorn. I'm running this in a resource constrained environment, so don't want to add a dependency onto docker unless absolutely necessary. I will soon utilize the locally built agent and update here about whether that worked as expected. If it doesn't, then I'll consider the docker option.

alikureishy gravatar image alikureishy  ( 2022-05-14 00:14:46 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2022-05-11 21:14:42 -0500

Seen: 56 times

Last updated: May 12